Monday, June 22, 2009

Recession causes rising IT project failure rates?

According to an article in CIO, Jim Johnson, the chairman of The Standish Group, says the recession is causing an increase in IT project failure rates. The Standish Group's latest report, CHAOS Summary 2009, reported a marked decrease in project success rates:
  • 32% of all projects succeeded, i.e. delivered on time, on budget, with required features and functions [this is the Standish definition of success, which unfortunately perpetuates the focus on delivery of technology rather than benefits. For more about the problem with this definition refer to John Thorp's blog];
  • 44% were challenged, i.e. late, over budget, and/or with less than the required features and functions; and
  • 24% failed, i.e. cancelled prior to completion or delivered and never used.
In the CIO article, Johnson gives these reasons:
  1. "People are more prepared to cancel projects than they have been in the past. When they see a project that's not going well, they have more political clout to cancel it and move on." Johnson admits this is a good thing, but he still counts it in the failure statistics.
  2. Staff reductions within IT departments and other project stakeholders taking on increased workloads.
  3. Risk aversion that has led organizations to "overemphasise compliance and governance - to such an extent that too many checks and balances are slowing down projects. And the longer a project takes the more likely it is to fail."
Unfortunately the article does not mention the critical role of good governance to achieving success. Research by Weill & Ross, of the MIT Sloan School of Management, concluded that, "Effective IT governance is the single most important indicator of the value an organization generates from IT."

Good governance enables good decision making. This does not mean bureaucratic processes, which do not enable good decision making.

Killing a project that is no longer viable is a good thing. It is a success for good governance. Busy executives can manage by exception if they have an up to date business cases on which they can make the right decisions. Projects should be governed this way, otherwise they will truck on and fail spectactularly with a huge commitment of resources and lost opportunities.

Not understanding what resources are needed to deliver strategic objectives and not understanding and prioritising their commitments will result in poor cost cutting decisions and create unbalanced and unsatisfactory workloads for remaining staff, thus threatening the organization's ability to deliver key strategic projects.

Good governance has oversight over the whole portfolio of projects, and manages resources and risks (including the impact of the economy) appropriately.

The article states that too many checks and balances are slowing down projects. It is bureaucracy and an immature approach to governance processes that slows down projects. This should not be confused with good governance, which will result in more speed in the long run:
  • Good governance over the whole portfolio of projects leads to good decision making about which projects will result in optimal value being achieved, at an affordable cost and an acceptable level of risk.
  • Good governance over individual projects leads to good decisions about the viability of projects. The business case is enabling, it allows good projects to continue so long as they can achieve their objectives within the stated parameters of the business case and stops as soon as it is apparant the business case will not be achieved.
Organizations are often able to invest huge amounts of resource in starting or rescuing ill-conceived projects.

If only these organizations would put this time into establishing the right governance structures, processes and leadership, to do the right projects the right way in the first place.

Refer to ISACA's Val IT framework for a best practice framework and supporting publications to address the governance of IT-enabled business investments.

2 comments:

Denver said...

Success = on (or before) time, on (or below) budget, and with required features and functions?

Really?

What about business benefits?

Perhaps the original proposal, that a system with such features and functions would deliver a particular set of business benefits, was faulty?

Is the project still a success?

Well, yes, but only if you take a narrow "IT unit" view, which was something I thought you were discouraging in other posts?

Baz said...

I agree with you Denver. These are The Standish Group's definitions, which unfortunately perpetuate the problem of focus on delivery of technology rather than benefits. Accordingly, I don't agree with their definitions. One can also argue that a project that was "challenged" but still delivered the intended benefits was actually a success, especially if the updated business case confirmed it was still the best use of available resources.