IT is never 100 percent at fault for any massive project

If you read my previous blog post on Executive Support For Agile Adoption, I described how management support is important.

This topic is tocuhed on in Thomas Wailgum’s recent article in the CIO.com [5 Aug 2009], After a Massive Tech Project Failure: What IT Can Expect.  In his article he states –

IT is never 100 percent at fault for any massive project

Thomas’ statement is supported by the Chaos Report by The Standish Group whereby the top 10 reasons for project failures have nothing to do with Technology but more to do with business governance –

1. Incomplete Requirements
2. Lack of User Involvement
3. Lack of Resources
4. Unrealistic Expectations
5. Lack of Executive Support
6. Changing Requirements & Specifications
7. Lack of Planning
8. Didn’t Need It Any Longer
9. Lack of IT Management
10. Technology Illiteracy

Furthermore, the Chaos Report indicates that the three major reasons that a project will succeed are user involvement, executive management support, and a clear statement of requirements.  There are other success criteria,  but with these three elements in place, the chances of success are much greater.

Thomas’ article is not advocating agile (the word is only mentioned once).  What is mentioned is a common theme – be pragmatic, provide common sense and be practical.  Agile is pragmatic, common sense and practical.  And the first step to adopting agile is to have an open mind to it.  You can be skeptical about Agile, but remain open-minded.

CIOs who resist against changing implementation methods—holding firmly to the waterfall when agile is the best option—and killing projects and their careers

The advice for such massive undertakings, which CIOs and analysts talk up but many don’t follow, is practical: Think bite-sized project chunks and set proper expectations.

“For some reason,” he adds, “we haven’t learned as an IT industry about driving incremental planning and change, which, in my mind, would help to mitigate the high rises and high falls of project failures.”

Agile is about incremental planning and change. For example, Scrum is an Empirical Process Control whereby you exercise control through frequent inspection and adaptation. The idea is that you do some planning and then do what you planned, inspect what you did and then adapt your behaviour to improve on what you did. You are constantly going through cycles of learning and improving the way you work.

As part of this learning, we need to encourage our managers to –

embrace change and transparency—even if it hurts at first. “The corporate culture—the status quo—tends to be: ‘Everything’s good. We don’t talk about problems until they are near unrecoverable, because we know people don’t like bad news,'” ….. But there are always going to be problems—vendor issues, or architecture, compliance or performance problems.

Agile provides the framework to detect bad news early.  However, as mentioned in my last blog entry “managers need the ability to hear unwelcome news and should it occur deal with this effectively” as IT is never 100 percent at fault.

Like any illness, the earlier the detection the better as a cure can be found and applied sooner.  Leave it too late and the illness can be fatal and you inevitably end up doing the Death March.