Both options have advantages and disadvantages, and it\u2019s important to fully vet these options before deciding. To help you make an informed choice, we will walk you through some of the vital questions you must consider at the start of your project and the associated pros and cons of each approach. <\/span>\n In the earliest stages of your project, you know you may need software to achieve your goals, but the options can be overwhelming. There are two primary options for how to move forward:<\/p>\n When approaching the build vs. buy question, it’s best to take a design thinking<\/a> approach. Design thinking advocates you must first fully understand the problem you want to solve before searching for or defining solutions. You should consider several factors during your project planning phase. One of the biggest mistakes we have seen is organizations trying to retrofit requirements into an already selected platform rather than using the requirements to vet potential solutions. This often results in selecting a product that does not meet critical business and user requirements. Instead, first focus on defining requirements through your discovery process and then create a matrix of those requirements.<\/strong><\/p>\n Once you develop a matrix of requirements, we recommend prioritizing those requirements based on criteria such as mandatory, highly desired, and nice to have. Be prepared to set a threshold for how many requirements your intended solution must meet to consider acceptable. A good benchmark is that the solution meets roughly 80 percent of your requirements without extensive customization.<\/p>\n If you find the purchased product cannot meet the bulk of your requirements or the design does not promote an optimal customer experience<\/a>, you might need custom development to ensure your solution meets true user needs. Custom development makes certain you design and build your platform per your user\u2019s requirements, for example, ensuring that your platform can support multiple types of customer types and complex billing scenarios.<\/p>\n Vendors build SaaS or COTS solutions to address the needs of as many potential customers as possible and are well-suited to address common industry problems and needs.<\/p>\n Take, for example, an organization considering Oracle Energy & Water\u2019s Customer Care and Billing (CCB). Creating a fully custom customer information system (CIS) solution would be incredibly expensive, time-consuming, and would lack the breadth of functionality the existing market solutions offer. Therefore, in this case, a bought solution is best for the business.<\/p>\n When addressing a common problem, you should vet available options considering product reviews, pricing and licensing plans, customer support options and so on.<\/strong><\/p>\n If you are addressing a need with unique user requirements, a build approach may be more applicable. This is especially strong when you need your product to provide a unique experience to maintain customer satisfaction or to be a differentiator in the marketplace.<\/p>\n When you have a general sense of budget at the start of a project, it helps guide what is feasible. It is important to remember the total cost of ownership (TCO) when it comes to the build vs. buy question.<\/p>\n It is a common misconception that building rather than buying is always more expensive.<\/strong> For example, it may be a higher initial cost to build the software, but the long-term maintenance will be substantially less than the ongoing licensing costs of the bought solution \u2013 especially as your user base grows and you have pay-by-user models.<\/p>\n Here are some factors to consider related to budget for each option:<\/p>\n Utility organizations will want to consider how you classify your software financially. Whether as a Capital Expense (CapEx) or Operational Expense (OpEx), which will be more beneficial to your organization? CapEx funds fixed assets that depreciate over time. OpEx funds are available to support ongoing business operations.<\/p>\n When organizations build and own their software, it is generally considered CapEx, as it is an upfront cost. The buy approach is usually considered OpEx, especially when considering cloud SaaS models. It is important to note on-premises licenses are typically considered CapEx.<\/p>\n While each utility may handle classifications differently \u2013 and there is some gray area \u2013 in general, you can include CapEx expenditures in a rate-case increase, while OpEx would not be eligible.<\/strong> Traditional regulation favors upfront capital investments. That said, there is a potential benefit in classifying your software costs as OpEx, including faster approval cycles as the costs are spread over time, cash flow stability, and flexibility in spending.<\/p>\n When considering your options, it is important to understand both your current requirements, but also your future ones as well. While a bought solution will most certainly evolve with vendors adding new features, that development will be outside of your organization\u2019s control.<\/p>\n With custom software development, you can add new features as needs arise, assuming you have the resources \u2013 people, budget, time \u2013 to execute successfully. The level of flexibility your organization requires, both today and tomorrow, is therefore an important consideration.<\/p>\n Typically, an off-the-shelf solution will support a shorter time to market than a built solution. However, ensuring the implementation timeline reflects the complexity of any required integrations, data migrations and so on is important. A built solution will generally have a longer timeline. As a result, if you have a narrow timeline with minimal complexity in data migration and platform integration, a bought solution may be a better approach.<\/p>\n The utility industry has a high bar for software security. Defining your organization\u2019s security requirements at the start of a development project, which could encompass anything from the development of a customer portal to the implementation of a work asset management system, will help inform whether a bought solution will meet those needs.<\/p>\n When you select a well-supported, well-known product, they will offer a lot of security support. Moreover, using a well-established provider can take some of the security burdens off the utility company when it comes to things like ensuring Payment Card Industry (PCI) compliance, for example.<\/strong><\/p>\n On the other hand, smaller, start-up software organizations may struggle to meet utilities’ security requirements. They may not be able to agree with the typical standards placed in enterprise IT purchasing agreements.<\/p>\n Before your organization gets too far along in the contracting process, we recommend you set up a security conversation early on and make certain the contract documents cover your requirements. There are several software industry standards you can inquire about, including System and Organizational Controls (SOC) and International Organization for Standardization (ISO) compliance as part of this review.<\/p>\n With a custom solution, you can confirm the solution meets your specific security requirements because you control the architecture and feature set. However, this does assume your organization has the required in-house security specializations, which will vary based on the platform you are building.<\/p>\n If you choose to leverage a partner, selecting a vendor that guarantees adherence to secure coding principles such as the Open Worldwide Application Security Project (OWASP) guidelines and your organization\u2019s specific standards will be important. Keep in mind that security compliance is not only a critical component of the initial build but will be an essential part of ongoing maintenance and testing<\/a>.<\/strong><\/p>\nLet\u2019s Get Started: Two Primary Approaches to Utility Software Selection<\/h2>\n
\n
Eight Questions to Consider Before Deciding on Build vs. Buy<\/h2>\n
![\"software](\"https:\/\/centricconsulting.com\/wp-content\/uploads\/2023\/05\/Blog_EU_Buy-vs-Build_01_Build-Buy-Considerations.png\")
<\/a><\/p>\n1. What are your users’ \u2013 both business and customer \u2013 functionality and design needs?<\/h3>\n
2. Do you have a unique problem or a common problem?<\/h3>\n
3. What is my budget for this project?<\/h3>\n
![\"Software](\"https:\/\/centricconsulting.com\/wp-content\/uploads\/2023\/05\/Blog_EU_Buy-vs-Build_02_Budget-Considerations.png\")
<\/a><\/p>\n4. What do you need the platform for in the future?<\/h3>\n
5. What is your desired time to market?<\/h3>\n
6. What are your organization\u2019s security requirements?<\/h3>\n