Our last blog entitled “Navigating complex software purchases and improving speed to market” discussed how to identify problems, align stakeholders and draw out relevant questions in order to build a business case for change.
As a Software as a Service (SaaS) organisation, we have a natural bias towards this topic and unashamedly endorse a buy approach. However, we are passionate about promoting healthy discussion around the topic. The aim is to shed light on the considerations that should be taken into account when embarking upon a business transformation project.
Ultimately, we believe there is a good argument for a combination of buy and build and will explore whether is there room for both.
All decision makers face the challenge of balancing the immediate needs of the business with long term growth trajectory.
Given the uncertain nature of the energy market, suppliers and other commodity ruled businesses arguably suffer this headache more than most, so making the right decision is paramount. Here, we’ll explore 3 key considerations:
Whichever path is chosen, cost is inevitably a major determining factor. The previous blog referenced increasing pressure to provide customer experiences parallel to that of Amazon, Uber and Netflix. However, emulating this success with a solution that is cost-effective is of course easier said than done.
Self-build projects are typically re-charged against departmental budgets. Some may argue this development work represents a ‘sunk cost’, as the team already work for the business. However, the reality is the ‘true cost’ reaches levels far beyond simply recovering overheads and should not be treated lightly.
Calculations and tools consider when assessing ‘true’ cost:
Evaluating ‘total cost of ownership’ for a solution is also an important factor to consider, as self-building may result in future internal trade-offs.
When assessing the ‘true cost’ of the build, you should consider:
Build-time is notoriously difficult to predict as specs change and delays inevitably happen.
The more complex the project, the less reliable these predictions become and the ‘chargeable’ man-hours necessary for development often spiral.
Consider the below when looking at speed to market and buy vs build:
Speed to market is often dictated by a combination of the current commercial environment and capital restraints.
The time it takes to design, build and test are critical and if executed poorly is likely to result in poor build quality.
Ask yourself and your team:
Developing an in-house solution can be very resource intensive. Often additional resources from other departments are required to bolster development or testing efforts to ensure deadlines and go-live are met.
Be truthful to yourselves and consider the opportunity cost of:
A willing team at your disposal who can work closely to deliver your vision as well as fix any on-going maintenance issues – sounds perfect.
However, the technological landscape is evolving rapidly. The skills required to successfully execute a robust and future-ready project are increasingly complex and hard to find.
To borrow a famous principle from Warren Buffet:
“It is wise to only operate within your circle of competency.”
In other words, a business should not be stretched to perform outside its core skillset or focus. These are challenging but crucial questions to ask when assessing buy vs build:
Developing a bespoke system with a limited view of the competitive landscape inherently puts an in-house development team at a distinct disadvantage. It runs the risk of key functionality being overlooked.
To give your team the strongest chance of success during buy vs build, ask:
Conflicting priorities must also be taken into account. Without dedicated resource, fixes and general maintenance could suffer before considering additional man hours required for developing future functionality and enhancements.
Top points to consider regarding priorities:
In order to understand who is best suited to provide a solution, an organisation must carefully assess whether their particular issues are part of a wider industry problem or fundamentally unique to them.
Whilst there is no denying every energy supplier is uniquely complex, an energy company’s unique problems and core value is not in running cloud infrastructure or dealing with ‘non-discretionary’ tasks such as sending flows. This is simply a necessity of being a 21st century organisation in the energy industry. By abstracting away common issues, a business can start to hone-in on truly unique problems.
Energy companies should be asking themselves:
An organisation may consider building a solution ‘from the ground up’, designed to meet 100% of their requirements. Whilst it may make sense to try and shoot for the 100% mark, the reality is often much more difficult and time consuming to achieve.
Firstly, consider the below when looking at what you need to achieve in the buy vs build space:
We wouldn’t be so bold to say that SaaS is exclusively the right approach for every business (as much as we’ve love to). We believe that the road to the ‘perfect’ in-house solution is littered with challenges and is a hard path to take. Therefore, there must be a very compelling reason to do so, i.e. it provides a distinct competitive advantage.
Self-build platforms that are built for purpose can become extremely expensive. Buying SaaS can save costs, as they are distributed across a user base.
Information to consider when deciding on buy vs build:
When investing in SaaS, you invest in something that has been expertly developed over thousands of hours. It’s been driven by the feedback and input of an aggregated user base and reflects a host of learning from across the industry.
What you’re investing in when you ‘buy’ energy supplier software:
The SaaS industry survives on its renewals, so it’s in the best interest to provide best in class products.
A business must consider whether it makes more sense to find a solution that meets 90% of its needs that can be met immediately. They can then devote remaining capacity to core business functions. Otherwise the option is building more niche applications / processes.
According to CIO.com:
“Assuming normalised fit scores where 100% equates to fully met requirements – a score of at least 80% or more will mean ‘buy’ is generally advisable.”
Buying often makes sense if you value speed of product iteration, cost-effectiveness and accessibility. The build scenario should be given serious consideration if it relates to a highly niche technological offering or the source of your competitive differentiation / advantage.
Increasingly, there is a shift towards suppliers purchasing SaaS to fulfil a ‘core’ technology requirement. This acts as a central platform for other bespoke applications to be integrated with via REST-ful API’s.
To achieve this hybrid-like model, it is important to differentiate between a SaaS platform that is built upon strong architectural foundations that allows applications to function in a harmonious ‘hub and spoke’ type manner. This is versus the patchwork legacy systems of the past that have required heavy manipulation to bolt together a number of disparate systems.
The rising popularity of SaaS is beginning to emerge in the energy retail world. More business leaders are realising that it makes good commercial and strategic sense to purchase agile software solutions, particularly when looking at innovation management.
Industry veterans will also know the extent of failure rates of self-build projects - thousands of man hours, and sometimes millions of pounds for a project that is simply tossed to the scrap heap. The cost of making the wrong decision can be felt for years, conversely the right decision will resonate with the bottom line for decades to come.
Whether you choose to buy or build (or buy and build), this article intends to serve as a prompt for organisations to look inwardly and consider some fundamental questions before pulling the trigger on any transformation project.
Ultimately, the ability for an organisation to distill different viewpoints from within the business and answer such questions objectively will have the best chance of making a successful transition to their new software.
With the ‘WHAT’ and ‘HOW’ now defined, our final blog post will take a closer look at what your business can do to best prepare for a large change project as we explore common reasons for failure and tips on how to avoid common obstacles.
If you’d like to get in touch with us to discuss your options for buy vs build and the route that’s best for your company, get in touch.