What does IT "failure" actually mean? While this question should be easy to answer, many discussions on the topic become little more than word games.
Simple metrics. Some observers, including myself, begin their analysis of failure with three criteria. We ask whether a project is delivered within the established:
This metric offers a convenient, rough-cut measure of project success or failure. This approach is also attractive because it tracks fairly well to the "triple constraints" view of traditional project management.
However, by far the most significant benefit of these criteria is simplicity of analysis and communication. Given the complexity of large projects, determining success or failure can sometimes be a difficult and ambiguous undertaking. Simple metrics offer a clear and straightforward method to gauge whether or not a project is successful.
Complicated facts. As with many schemes intended to force fit complex phenomena into simple black and white metrics, nuance and subtlety can be lost in the translation. In this case, the simplistic definition ignores two important realities associated with IT initiatives:
- Some projects are delivered on time and within budget, yet don't deliver any real business value; although successful from a narrow IT perspective, they actually represent business failures. ZDnet blogger, Joe McKendrick, calls this "failing by obscurity: "Lots of money spent on development with no return....so [the project] ends up sitting as virtual shelfware." Such failures arise out of poor alignment between IT and the business.
- On the other hand, some so-called failures should really be judged successful. Due to in-process changes of scope, these projects exceed their initial budget or schedule, but still add substantial business value to the organization. While these projects may cost more than planned, they deliver far more business value than anticipated. Lewis Cardin from Forrester calls this "first-number syndrome:" management becomes blind to any conditions warranting a change from initial estimates, including higher project ROI.
The bottom line. It would sure be nice to have a standard definition of failure, making it easier to evenhandedly evaluate and compare projects. As it stands, however, anyone can invent their own definition, and pronounce success or failure, in whatever manner they choose. Perhaps needless to say, flexible definitions can quickly become self-serving and therefore unreliable.
The ultimate point: successful projects always deliver business value and ROI. Words may change but that simple truth remains.
[This topic arose during an Enterprise Irregulars discussion of Agile development methods applied to software implementations, which Bob Warfield blogged. Word game image via California Energy Commission.]