Utility Software Development: Build or Buy? Our Comparative Guide Can Help, Part 1

In our two-part blog series, we break down the pros and cons of the build vs. buy debate about utility software development. In this post, we look at eight questions to consider first.

In the energy and utility industry, there is no shortage of software options to choose from. You can find solutions for everything from asset management to zero emissions tracking. When choosing the right software, organizations must decide whether buy ready-made software or build their own custom solution.

Both options have advantages and disadvantages, and it’s 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. 

Let’s Get Started: Two Primary Approaches to Utility Software Selection

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:

• The Build and Manage Approach: With this option, the organization builds the software based on its functional and business requirements. You can either leverage in-house team members or those of a vendor partner both for the initial build-out and ongoing support.
• The Buy Approach: With this option, the organization purchases or licenses an off-the-shelf product, commonly called software as a service (SaaS) or commercial off the shelf (COTS). You can customize this product to meet the user’s needs depending on the vendor partner, but largely, what you see is what you get.

Eight Questions to Consider Before Deciding on Build vs. Buy

When approaching the build vs. buy question, it’s best to take a design thinking 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.

1. What are your users’ – both business and customer – functionality and design needs?

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.

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.

If you find the purchased product cannot meet the bulk of your requirements or the design does not promote an optimal customer experience, 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’s requirements, for example, ensuring that your platform can support multiple types of customer types and complex billing scenarios.

2. Do you have a unique problem or a common problem?

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.

Take, for example, an organization considering Oracle Energy & Water’s 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.

When addressing a common problem, you should vet available options considering product reviews, pricing and licensing plans, customer support options and so on.

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.

3. What is my budget for this project?

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.

It is a common misconception that building rather than buying is always more expensive. 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 – especially as your user base grows and you have pay-by-user models.

Here are some factors to consider related to budget for each option:

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.

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.

While each utility may handle classifications differently – and there is some gray area – in general, you can include CapEx expenditures in a rate-case increase, while OpEx would not be eligible. 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.

4. What do you need the platform for in the future?

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’s control.

With custom software development, you can add new features as needs arise, assuming you have the resources – people, budget, time – to execute successfully. The level of flexibility your organization requires, both today and tomorrow, is therefore an important consideration.

5. What is your desired time to market?

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.

6. What are your organization’s security requirements?

The utility industry has a high bar for software security. Defining your organization’s 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.

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.

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.

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.

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.

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’s 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.

With either approach, we recommend a third-party audit of all the software used in your utility space, given the rising threat of cyberattacks.

7. Will the software platform need to integrate with other platforms?

Understanding the amount and complexity of required integrations is paramount at the start of a project. Generally, the higher the number of integrations required, the more likely you’ll have difficulty managing a bought solution.

Some platforms will offer a wealth of existing APIs to support integration. Others will require custom development work. As such, the integration cost with the prebuilt platform may equal a fully built custom platform.

8. Do you have a trusted vendor partner? Can you support development in-house?

When you buy a solution, you are committing to a long-term relationship with the selected software vendor, with which comes risk. You may face challenges with the platform, such as bugs or downtime, customer support may be lacking, or they may choose to discontinue important components of your system.

Migration from a selected platform can be difficult and expensive, if not impossible, given contractual provisions. Proprietary data models are common with these systems, making migrations incredibly costly. As a result, it is important to fully vet your solution provider.

If you build the software in-house, there are many considerations to ensure your organization is ready to effectively support custom development. Frequent questions that arise during an organizational readiness assessment include:

• Core Values
  • Does your organization want to be in the software development and support business?
  • Do you see yourself as a technology company?
• Team Skills
  • Does your team have the specialized skill sets needed to complete the project? This includes software developer roles, product managers, user experience designers, quality assurance testers, content strategists, and more.
  • Can your organization effectively recruit and hire these team members if your team lacks the required skill sets?
  • Will your team need any specialized training to support the project? Was that built into your timeline and budget?
• Team Readiness
  • Is your team available to support the project engagement at the required timeline?
  • Can your organization support ongoing software maintenance?
  • Will assigning team members to this project hurt other projects in flight or general IT operations due to bandwidth and attention issues?
  • Do you have an existing development and hosting environment available to support the new software?
• Budgeting
  • Does your team have the budget to support the dedication of team members to the project, both short and long-term?
  • What is the cost of in-house team members compared to vendor-supplied team resources?
• Project and Change Management
  • Is your organization ready to support the change management procedures necessary to ensure the software has the intended impact?
  • Have you selected a project management approach to the project, for example, Agile? Is the organization prepared to support the selected process?

If you use a vendor to build your platform with or for you, you can frequently mitigate some of these potential risks.

For example, you can quickly supplement your in-house team’s skill set with vendor-supported resources. This step reduces the need to support a specialized in-house team. However, the vendor partner will require some spin-up time to become comfortable with your organization’s IT environment and setup.

If you choose to use a vendor partner, we recommend you confirm your vendor partner is using common development frameworks and languages such as .NET and JavaScript. This prevents you from limiting yourself to that provider and keeps your options open if you want to move support fully in-house down the road.

Conclusion

Deciding whether to build or buy your utility software requires a great deal of upfront thought and discovery, as well as consideration of factors including cost, time, resources and both short- and long-term needs. For organizations struggling to answer these questions, a consultant will help provide guidance based on their experience implementing similar solutions for other industry clients.

In part two of our series, we’ll take a look at the pros and cons of each option to help you guide those conversations before making a decision.