April 11, 2008, 2:03 PM — I am always amused when I read stats of the form: "X percent of IT projects fail". It would be funny if it wasn't so misleading. "That darned IT stuff.", the subtext goes. "It has failure written all over it..."
Right.
Here is an alternative headline: "X percent of attempts to fundamentally change the way an organization operates, fail."
I can live with that formulation - even for very high values of X. Change is just plain hard. Change doesn't always work. Change is not always well conceived and not always well executed.
IT just happens to be part and parcel of most change initiatives. The IT (generally) isn't the root cause of failures to change an organization. It is however, a
beautifully inert stooge that is easily allocated blame when failure comes to town. "Everything would have been just peachy except for that darned IT stuff messing everything up.".
Uh huh.
One of the reasons that change is hard is that it is very difficult (in general) to identify crisp success metrics. In an ideal world you would formulate a set of measurements of the "as is" process. You would then formulate a set of measurements of the "to be" process. Then, by relating the "as is" metrics to the "to be" metrics you have the basis for measuring success. Obvious right?
It never ceases to amaze me how many IT projects are embarked upon without clear metrics for measuring success. The IT guys come in, do their thing on the back of whatever requirements they can muster and then watch as the requirements change and change and change...
In "successful" IT projects this bottoms out. In "failed" IT projects, the requirements, the definition of "success", the definition of "complete" is never formulated. Somehow, the world at large has become inured to the idea that IT is the root cause of many such failures and good governance is responsible for all the successes.
Go figure.
It is really, really important for IT professionals to operate with clear definitions of success. It is also really important to know the extent to which you have dominion over the definition of success. For example, if the definition of success is 99.999 percent uptime of a server you may have control over most of the variables. However, if the definition of success is fifty percent more traffic to a website, you are not in overall control. The IT can be made to support it but the IT is rarely the reason why traffic jumps by 50 percent.
Also, be careful if someone tries to convince you that there is no real definition of success. This is a big red flag. If there is no avoiding the fact that you are working in a project environment with no strong definition of success, create one and share it with your boss.
If you are anything like me, to sleep at night all I need to know is that I am getting somewhere with my projects. Everything else is detail. If nobody is defining success for you. Define it for yourself! Then, if storm clouds gather and IT - yet again - finds itself being singled out for stooge duty, you will have your metrics, even if the project as a whole does not.
You won't regret it.
