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 CIO.com 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.
Be Sociable, Share!
Bookmark the permalink. Follow any comments here with the RSS feed for this post. Post a comment or leave a trackback: Trackback URL.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*


Warning: Illegal string offset 'solo_subscribe' in /home/blprnt/webapps/thorpnet/wp-content/plugins/subscribe-to-comments/subscribe-to-comments.php on line 304

Subscribe without commenting