Hans-Kristian Bryn and Jora Gill
Technology transformations is an integral part of strategy delivery. However, the evidence of successful technology transformation projects is limited and is far outweighed by the success of complex civil engineering projects.
In a resource constrained environment with economic headwinds, increased financing costs and a need to respond to the acceleration of AI as a business tool, it is of paramount importance that organisations seek to find ways of creating demonstrable business value from technology and AI projects.
In this article, we are seeking to show how the root causes of failed IT transformation projects can be understood more clearly to create a more effective way of evaluating and executing complex technology and AI projects; setting them up to increase their probability of success.
Why is success so difficult?
In 1986, Alfred Spector, president of Transarc Corporation, co-authored a paper comparing bridge building to software development. The premise: Bridges are normally built on-time, on-budget, and do not collapse. On the other hand, software never comes in on-time or on-budget. In addition, it always breaks down.
One of the biggest reasons bridges come in on-time, on-budget and do not collapse is because of the extreme detail of design. The design is frozen, and the contractor has little flexibility in changing the specifications. However, in today's fast moving business environment, a frozen or inflexible design does not accommodate changes in the business practices.
We also recognise that importance of considering and incorporating the context in which the decision is being made but also the changes in the context when the post implementation review is conducted. In our view, it is useful to considering context through the following lens:
Therefore, a more flexible model would be advantageous. The lack of a flexible model could be and has been used, as a rationale for development failure. But there is another difference between software and bridge failures, beside 3,000 years of experience. When a bridge falls down, it is investigated, and a report is written on the cause of the failure. This is not so in the computer industry where failures are often covered up, ignored, and/or rationalized post event. As a result, organisations keep making the same mistakes over and over again.
According to a report previously published by The Standish Group, only 16.2% of IT projects were deemed successful by being completed on time and budget, with all the promised functionalities. A majority of projects were over cost, over time, or lacking promised functionality, and 31.1% of IT investments classified as failed, which means they were abandoned or cancelled.
So how do organisations set themselves up to increase their probability of success?
In our experience, getting the investment case correct upfront is a critical and foundational step in ensuring success. However, investment cases which involve large technical change often become the domain of the IT department and turn into IT investment cases rather than business cases. From what we have observed, IT investment cases mainly focus on project costs and delivery schedules and tend not to include business outcomes.
It is instructive to consider the business case as a ‘pitch deck’. The structure of a pitch-deck is typically as follows:
Introduction and problem definition
Description and quantification of the underlying problem or opportunity; for example, is there a gap in the market or are the competition cutting into your margins?
What is the potential solution? What are the benefits of your solution to customers and how will these benefits solve their current pain points?
What is the size of market opportunity?
Why this solution?
Can you demonstrate your potential solution so it can be visualised; for example, a mock-up or protype? The will greater engagement with the investment decision makers.
Who are the team and what capabilities do they have to ensure the success of the investment? This helps the decision-makers assess the execution risk.
Roadmap
Have alternative options been considered and why were they discounted?
What are the key milestones the investment case will hit and what are the expected results at each milestone?
Are there any KPIs that can demonstrate value throughout the investment case?
What is the investment cost estimate?
How have you gone about ensuring the outcome milestones and investment costs will not overrun?
What are the risks to the delivery of the project?
Summary
What is the opportunity?
How will the project be delivered?
What will the risk adjusted return look like?
There are a range of approaches that can be taken to the identification of project risks as the business case (pitch deck) is being formulated. A pre-mortem approach allows the user(s) to articulate a future state for an idea or concept, and to identify either the risks that could have crystallised if the projected future state is a negative one. Alternatively, the approach can also be used to identify the success factors that need to be present for the business case to be successful.
In either case, some of the factors that are likely to be identified would include:
Business benefit; what problem is the business case meant to solve
Cost; what is the investment / cost required to develop the solution, and over which time period
Delivery mechanism; is the delivery mechanism proven or is there technology / process / data risk associated with the delivery mechanism
Business context; what changes to the business context could significantly change the value of the business opportunity described in the business case
Skills and expertise (e.g. AI); does the organisation have the skills and expertise required either to deliver or oversee the delivery of the proposed solution
Disruption / disruptive technologies; could the business case be disrupted by competitive behaviour or by disruptive technologies or is the business case designed to disrupt competitors / gain disruptive advantage with customers, consumers and clients
For most organisations, the resources available for technology investments are scarce; be that capital, people, skills and competency. One of the key challenges is therefore to find an appropriate balance between clearing the backlog of potential optimisation improvements and embracing new growth / transformational opportunities. This involves putting technology business cases into a portfolio context rather than just evaluating each business case on its own merit.
The key questions to answer in the portfolio evaluation are:
Does the business case increase the demand on already scarce resources?
Is the value proposition based on an unproven technology?
Does the business case increase concentration risks, e.g. dependency on a particular supplier or technology?
Would project execution require significant external resources?
Does the business case diversify existing risk concentrations?
Would successful delivery of the proposed project lower risk and/or increase returns for the portfolio?
As we discussed earlier in the article, the purpose and business benefit of any technology investment case need to be clearly articulated. In addition, early consideration needs to be given to how the idea / concept is communicated internally in the initial stages of the project, and with a clear stakeholder engagement and communications plan / strategy. In our experience, organisations often fail to consider the need for building demand, excitement and buy-in internally as well as externally.
In many cases, a new technology will require a new target operating model (TOM) in order to deliver effectively the service proposition or capability. The TOM should not be an afterthought developed at the end of the project – the TOM should be designed early and the transition to the new model being undertaken before the technology project is completed.
We have seen many examples of ineffective governance, oversight and steering of technology projects. It is clear that most technology / AI development and implementation projects will include challenging scope management and trade-off decisions (e.g. cost, time, testing, piloting and resourcing). These decisions will have significant implications on the success and delivery of business value. It is therefore critically important that the steering committee composition reflects both technology, business and user perspectives.
It would seem intuitive, that risk-based decision-making needs to be an integral part of a coherent, transparent, insightful, balanced, honest and value-based evaluation of technology projects whether they are conceived to improve efficiency / reduce costs or generate incremental revenue.
When we use the phrase risk-based decision-making, we refer to a decision that is built on the combination of both the expected returns and the associated risks in generating these returns. As a consequence, the go no-go decision will be made based on the returns adjusted for these risks. We recognise that risk-based decision-making can incorporate qualitative, quantitative or indeed hybrid models depending on the availability of data and the sophistication of the decision-making models of the organisation.
In the diagram below, we set out a business case process that can be applied to most technology projects:
Conclusions
In this article, we have highlighted the importance of technology and AI business cases, and we have set out how they are key to both business transformation and developing new categories / propositions that might also be disruptive. However, in a challenging business and funding context, these investments need to demonstrate real value add and demonstrable business value.
In order to achieve this, a new approach is required and the approach needs to incorporate key elements such as:
Technology / AI investments should be business led investments delivered in partnership with the technology function
A single business case that balances risk and return and that justify the time, money and resources required to deliver the business benefit
Joint business and technology leader ownership and accountability for the successful outcome of the initiative
Governance that allows tracking and monitoring of progress and value realisation throughout the project
Agile replanning / rescoping of project if the business context requires it
Comments