Lies, Damn Lies and Business Cases

A 2006 Cranfield University School of Management study[1] found that while 96 percent of respondents developed business cases for most investments involving IT, 69 percent were not satisfied with the effectiveness of the practice. Specifically, they found that while 96% of respondents indicated that a business case was required for IT enabled investments:

  • 69% were not satisfied with the business case development process;
  • 68% were not satisfied with the identification and structuring of benefits;
  • 81% were not satisfied with the evaluation and review of results; and
  • 38% admitted that benefits claims were exaggerated to get the business

Stephen Jenner, described by John Suffolk, the UK Gov’t CIO as the “rotweiller of benefits management”, is quoted in the June edition of CIPFA‘s Pinpoint asking “Why is it that, if the rationale for projects and programmes is to realize benefits, they are so poorly articulated in business cases, and so few projects are able to demonstrate those benefits in practice?” His answer – “…that it’s not perceived in anyone’s interest.” Unfortunately, this is sad but true! Supporting the Cranfield research above, Stephen goes on to quote Bent Flyvbjerg – now BT Professor and Chair of Major Programme Management at Said Business School, who argues that the result is “the planned, systematic, deliberate misstatement of costs and benefits to get projects approved.” Now, when I was at school, this was called lying! Given the dismal track record of IT projects, specifically their failure to create or sustain value while incurring huge costs, we as taxpayers and/or shareholders should be demanding action. Why aren’t we? Because we assume, or have been conditioned to believe that this is “just the way it is”. It doesn’t have to be so! One key to fixing this malaise is an effective business case process.

Unfortunately, in most enterprises today, the business case is generally seen as a necessary evil, or a bureaucratic “hurdle” that has to be got through in order to get required financial and other resources. The focus is on the technology project, and the costs of the technology, with only a cursory discussion of benefits, or of the other changes that the business might have to make – as part of an overall business change programme – to actually create or sustain value from the use of the technology – changes that could impact the business model, processes, people’s competencies, technology, organizational structure etc. Business cases are also all too often treated as ‘one-off’ documents that are rarely looked at again once the required resources have been obtained other than, possibly, at a “post-implementation review”. I worked with one organization who were undertaking a $USM350+ implementation of an ERP. The business case was nine Powerpoint slides – not one statement in which was correct soon into the project. It was never reviewed or revisited. The results – well, you can guess! And, no, there was not even a post implementation review!

This current approach to business cases pretty well guarantees failure. A well developed and intelligently used business case  is actually one of the most valuable tools available to management – the quality of the business case and the processes involved in its creation and use throughout the economic life cycle of an investment has an enormous impact on creating and sustaining value. It describes a proposed journey from initial ideas through to maximising expected outcomes for beneficiaries (i.e. those whose money is being invested and for whom the return should be secured) and other affected stakeholders.

In the case of IT investments – or, more accurately, investments in IT-enabled change  – the responsibility for business cases, and the accountability for the promised return, cannot be abdicated to the CIO and the IT function. Boards, Executive and Business Management have to “step up to the plate” and take ownership. After all, it’s not technology itself that delivers value, it’s how the business – directed by the Board, Executive and Business Management – uses the technology that delivers value and they must be held accountable. I’m certainly not letting the IT function off the hook here – they must also be held accountable for delivering the required technology services reliably, securely and cost-effectively but they cannot be held accountable for how they are used or the results of their use/misuse.

The failure of enterprises to step up to this challenge is disturbing. The consequences are often catastrophic, with the costs being borne by taxpayers and shareholders, and the opportunity cost – the value not being delivered – having huge economic and social impacts on all of us. Again, it doesn’t have to be way – fixing the business case process would be a good start  – it’s time we made our voices heard!

[1] Ward, John; ‘Delivering Value From Information Systems and Technology Investments:  Learning From Success’, Forum (the monthly newsletter of Cranfield School of Management), August 2006

Recession Causes Rising IT Project Failure Rates

Those of you who follow this blog will notice that is been over 3 months since my last post – after many years of heavy workload and extensive travel, and with my 65th birthday coming up fast, Diane and I decided to take an extended European vacation, which ended up being “book-ended” by speaking engagements in Manila and Seoul, the last of which I have just returned from. I had hoped to post occasional blogs while away but my ISP migrated to a new platform the day after I left resulting in the Blogger publisher’s IP addresses being blocked – don’t you just love technology!

Now that I am able to post again, this article by Meredith Levinson in which discusses the latest Standish Chaos Survey results would appear to indicate that not much has changed since I have been away or, indeed, over the years since I wrote The Information Paradox, and began talking about the subject of getting real value from increasingly large and complex investments in IT-enabled change. Certainly, the “failure” rate continues to hover around 30%, with the “challenged” rate fairly constant in the mid 40% range and the “successful” rate equally constant in the low 20% range.
I do however think we need to be very careful in interpreting these numbers and, to his credit, Jim Johnson, Chairman of The Standish Group admits this. First, we need to really understand what we mean by success or failure, and indeed “challenged” – then we need to understand what is really “good” or “bad”.
Is it a “failure” to cancel a project? I would argue that in many cases it is not. Rather, it shows that effective governance is in place to monitor when either a project is unlikely to deliver the results originally expected or that business requirements have changed such that the project is no longer aligned with business objectives. History is replete with projects that should have been cancelled long before they became expensive and highly visible debacles.
Is a “challenged” project bad? If it is over budget &/or over schedule &/or does not deliver all the originally specified functionality but still creates significant business value I could argue that it was successful. On the other hand, if a “successful” project comes in on time, on schedule and delivers all the originally specified functionality, but does not create or sustain business value, or worse, destroys it, I would consider this a failure.
Bottom line – the Standish results are always interesting but we need to move beyond measuring “inputs’ (time and money) and “outputs” (technical capabilities) to measuring “outcomes” – the most important of which (I might say the only one) is creating or sustaining business value.

Mismanagement of prisoner IT system exposed

The UK’s litany of failed public-sector IT projects continues, as described in this Information Age article by Peter Swabey, with the latest being the Department of Justice’s National Offender Management Information System (C-Nomis). Originally estimated to cost £234 million through 2020, C-Nomis has currently spent £115, is now two years late, and projected to cost £513 million through 2011. A recent Information Age interview with the CIO of the Department of Justice, Andrew Gay, provided some valuable insight into the cause of these failures. Gay said that:

It doesn’t matter what type of project it is, whether IT or anything else. It’s a question of not nailing down the functionality you actually need, and that has been one of the principal faults with government IT spend. If you are going to deliver an IT project vaguely near budget, it would be far better to spend a huge amount of time working out exactly what you were trying to do with that programme rather than drift into it.”

There is a subtle distinction in Andrew Gay’s comments between an IT project – that delivers a technology capability or service – and a business-change programme – that includes all the initiatives, including but certainly not limited to the IT project, required to realize the expected outcomes. A recent report by the NAO reinforces this saying that “C-Nomis was treated as an IT project and not as a business-change programme” and identifies another all too common problem in that “bad news about the project failed to go up the ladder of command to those who could have made decisions to rescue it.”

This NAO report contains valuable guidance, not just for the public sector, but for all enterprises in managing IT-enabled business change programmes.