How to Improve the Success of IT Projects
The Problem...
The success rate of IT projects has historically been shockingly low:
- Projects often fail to provide the functionality hoped for by the end user
- After initial (and unhappy) user feedback, projects go back and add the functionality and fix issues in the interface, but it is so over the initial budget that the project is a failure from that perspective
And many IT systems live somewhere in-between: the initial product did not meet the requirements and some additional monies were added, but only to the point where the system is considered at least minimally successful or "good enough." (And when is "good enough" really considered "good"!)
Despite changes in the software development process, IT failure numbers haven't changed much in the last 10 years either.
- In 2001, a survey by the Conference Board reported that 40% of IT systems are considered by their owners to have "failed to achieve their goal within the first year of launch."
- Logica Management Consulting ran a survey in 2008 that reported a similar 37% of projects "failed to deliver benefits."
- As late as November in 2011, Dr. Dobbs's Journal reports failure rates between 30% and 50% ("traditional" projects failing at a rate close to 50%,"lean" projects failing at a rate of just over 40%, and "agile/iterative" projects failing at a rate of close to 30%).
It's a sorry state indeed.
The Solution...
The software industry is the only industry that attempts to design and develop (manufacture) products at the same time. No other construction- type industry does this and for good reasons.
Consider the building construction industry. No one would consider hiring plumbers, carpenters, electricians, and other construction workers and tell them to start building without first drawing up specific plans defining what to construct. The problems inherent in this approach (lack of common vision, potential for cost overruns, potential for in process changes, lack of assurance the end product will meet the user's expectation), not eliminated by asking the construction team to build a house a little bit at a time and then having the end user look at what they've done so far to see if they're headed in the right direction. (Can you imagine the headaches and associated costs if construction was executed in such a manner? The arguments over in-process approval when the user really didn't know what they are approving? Can you imagine the end result?)
Yet this is exactly what is expected in an "agile" software development process - the latest in a series of approaches that try to merge the two distinct worlds of design and development (after RAD, JAD, collaborative design, participatory design, and SCRUM to name just a few).
Acknowledging these issues some agile teams do try to conduct a "run 0" process to try to define the interface before starting development, but this run is not thorough or complete enough, hardly ever testing, so it's not much better than leaving it out.
So where's that solution!
To improve the chance of IT project success, try implementing the first rule of a user-centered design approach: "design and development are not the same thing and can't be done at the same time." The creation of interface sketches, interactive mockups, and a full specification prior to starting development will ensure the system will meet the users needs thus drastically reducing the potential for cost overruns to add missing functions. Interactive mockup testing can ensure the product will be usable, thus drastically reducing the potential for redesign cost overruns. It even allow for a better estimate of the actual development cost. And, if implemented correctly (the right team the right tool, the right authority or support), it can be done quickly enough and save so much redesign effort, it's actually a faster overall design and development process!
For more on this topic, read our full article.
If you're interested in reading any of our other articles or seeing some of our presentations, you can visit the page on our web site.
