Want to improve the success rate of your IT investments? Get the business case right
The failure rate for IT investments continues to show no sign of decreasing. It is hard to comprehend that despite over 60 years’ experience running IT projects, the ability to deliver benefits from these does not seem to have improved. Of course, the reasons why IT projects fail and the factors that contribute to failure (as well as success) are well established, and have been for many years. Indeed, I am often asked by clients to review either failed or underachieving IT investments and, in most cases, I could write my report without doing any investigation. The reasons are usually the same.
We seem to have this “knowing-doing” gap. We know what needs to be done if success levels are to improve, but the doing just doesn’t happen. I have conducted research on why this is so, but the details of these findings — including that it is perceived as too difficult and the poor digital literacy among business managers – are probably best left for another article.
More to the point here is how to reverse the trend. I was recently asked if there was one thing that organizations could do to improve the success rates of their IT investments, and thus IT projects. For me, the answer is clear – get the business case right. I don’t just mean improve the quality of the business case itself and what it contains, but also improve the quality of the process used to build the case.
The Limitations of Templates
The importance of the business case for an IT investment was brought home to me recent with some work that I have been doing in the UK’s National Health Service (NHS). To help hospital CIOs in building business cases, the Department of Health and vendors provide business case templates, partially completed, for an array of different technologies. These can be downloaded and completed with relevant information, usually with minimal involvement of stakeholders.
The result can be an eloquent and “well-constructed” business case document, with strong rationale for the proposed investment (that the vendor has developed), but with no stakeholder buy-in or understanding of what it will take to deliver the expected benefits. Indeed, often the first time many hear about the new investment is when the project actually begins. The quality of the process used to build the case is low.
Additionally, I have also found that most business case templates focus primarily on the costs and benefits for their analysis, with only financial benefits being considered. Furthermore, there is no requirement to describe exactly how each of the benefits is going to be achieved, including the assignment of responsibilities for ensuring that whatever is necessary for each benefit to be achieved actually happens. And, this won’t be the CIO. Remember, apart from pure infrastructure, IT investments are really investments in IT-enabled change.
This observation has led me to build a framework mapping the quality of the business case (i.e. how good is the business case) against the quality of the process of constructing this case (i.e. what is the commitment to the case). This leads to four possible business case scenarios. I have summarised each of these scenarios in the figure below:
While I think that these four scenarios are self explanatory, the one that often provokes debate is the ‘Blinkered Business Case’. This situation arises when there may be better projects to invest in, but these are either not considered or not identified. This is often because investment decisions are made in a very politicized environment or portfolio management is weak. While stakeholders may be committed (‘supportive’ is probably a better word) to the investment decision, this may be due to their reluctance to enter into what one of my colleagues has referred to as the Zone of Uncomfortable Debate (ZOUD) during discussions about the proposed investment.
The ZOUD is where difficult issues lurk. In the contrasting Zone of Comfortable Debate (ZOCD), stakeholders often play with techniques and have fun generating options. Straying into the ZOUD threatens relationships and when tensions are heightened, the usual response is to go back into the ZOCD. These are the issues that are never discussed as they are too sensitive. But, once the project gets going, they inevitably emerge and there is really only one result possible.
The business case as a living document
In my work with organisation on their IT investments, my observations have led me to conclude that business cases are typically produced for one of three reasons. The first is because the company demands one for all investments, not just IT. My characterization of this situation is that it is seen as accountants’ torture: business cases are built because they are mandated by the finance organization. In such situations the business case template is usually highly financial in their orientation.
The second is where the business case process is a game. If you can demonstrate that your proposed investment is going to return a bigger return than somebody else’s, it is more likely to be funded. In these situations, there is usually little rigor demanded of the case or the process. Usually, it is a very politicized process. In both these situations, the case is produced primarily to get the investment funded. Once agreed, the case is usually parked, and never again revisited.
The third situation, and one that is not frequently encountered, is where the business case is seen as a living document and not something that is produced solely for the purpose of investment approval. As such, it accompanies the investment through its lifecycle. Any changes, for example in project scope, are evaluated in the context of the impact that has on the business case, particularly the expected benefits.
Using this framework to analyze IT investments, we can clearly see that many are doomed to failure or at least under achieve right from the outset. Myself and a colleague Prof Don Marchand at IMD Business School in Lausanne, Switzerland have used the phrase “Designed to Fail” to describe such investments and have written a lengthy article of this phenomenon based on our research.
When I advise organizations to focus on both the quality of the case as well as the quality of the process, I often get pushback that this is all very well, but it is difficult, time consuming and can be resource intense. I agree! But if you don’t spend the time up front, you will end up spending many multiples of this sorting out the mess in the future.
In addition to poor business cases and processes, I also have worries that investment committees are undereducated in respect to IT. This makes them ill-equipped to deal with IT investment decisions. While they are generally comfortable discussing costs, benefits (in financial terms), time, scope and budget of projects, they too often have little understanding of what constitutes value (in the context of IT) or how it can be achieved. Their assessment of risk is often limited to financial and technical risk rather than to organizational and people risk. It is overwhelmingly the latter that contributes to IT failures.
These executives need to step out of their comfort zone to understand the complexity of IT investment decisions and their impact on the organization. That change, along with the steps described, should go a long way toward rationalizing IT investments that add true value to the organization.