A wise old soothsayer once said: “The reasons for project failure are more numerous than grains of sand in the desert.”
The diversity of failure reflects the prominent role played by the human element in failure situations. Failures typically arise from mismatched expectations across information silos or boundaries, financial (or other) objectives that run counter to project success, and so on.
Most lists describing reasons for failure focus strictly on direct project management issues. They cover topics such as failure to gather requirements or properly plan for resources, which are important but also frequently repetitive and uninspiring.
On the other hand, there is great value in examining deeper structural conditions underlying IT failure. (Actually, these conditions are generally true for business projects across a range of disciplines, but let’s stick to IT.)
In this spirit, I draw your attention to AntiClue: Musings based on adventures in health care IT. In a recent post, author Elyse Nielsen discusses the difficulty of even defining IT project success or failure.
Her post then presents five common reasons projects fail:
- The wrong business need has been addressed – Nothing is more frustrating that solving the wrong problem. Every so often projects are launched and executed delivering a solution which doesn’t address the true business need. In these cases, the project will be considered a failure, even though everything was delivered according to plan – on time, on budget.
- The business case is a fairy tale and outcome delivery is a dream – Welcome to mission impossible for project managers. Optimistic Honesty is your true course here. We all enjoy challenges, but be truthful about the risks and work to mitigate and avoid the troublesome ones as much as possible.
- Project Goverance has not been define or implemented – Quite often in change transformation projects, sponsorship and project governance are the key ingredients to successful adoption and implementation. Project governance comes in the form of a steering committee.
- Execution is heralded by Hail Mary Passes – If in order to deliver your project, you know it is going to rely on a few hail mary passes its time to look at the execution roadblocks. Delivering technology adoption kicks it up from just implementing a solution, but if the solution implementation is not your team’s strong suit you have an impending project failure.
- The business environment changes – It’s the management renewal process, one day while getting coffee down the hall, the rumor mill is buzzing with the latest management changes. Suddenly your project has become outdated while in mid-step.
Although we all recognize the challenge of running successful IT, difficulty does not excuse failure. To succeed, look closely for subtle warning signs and clues that suggest possible impending problems. Failed projects remind us to look more closely, and act more decisively, next time.
Remember, IT failure is a common experience. Every major enterprise, software vendor, and system integrator has experienced failure. It’s high time we learned to discuss failure openly and honestly.
What do you think? Share your opinion in the comments!
Photo showing the desert, in which each grain of sand represents yet another reason for project failure as predicted by a wise soothsayer, from Flickr Commons.
Hi Michael,
In my experience working with project teams, I have noticed that teams rarely have a chance to sit together with customers (internal or external). Ideally, there should be an opportunity to, as you say, examine “deeper” issues… perhaps to deliberate on the purpose of the project, assumptions behind project goals, project scope, and the definition of failure.
In the examples I’ve seen, teams have had better-than-average success by using a methodology known as ” mind mapping” to manage these kinds of sessions. Mind mapping enables groups of people (or individuals) to visually capture, organize, and annotate ideas and information. Since it uses key words and phrases instead of sentences and paragraphs, mind maps “move at the speed of thought” to capture brainstorming in real time. As the groups talks, an adept mindmapper can capture the conversation (ideally projecting the map on the wal so all can follow along). And when each participant can clearly see what’s being recorded, it’s often much easier to correct misunderstandings, mistakes and miscommunications that can lead to “solving the wrong problem.”
I’m not saying there is a technological magic bullet that will eliminate every project foible. But I do think that if you give people the right tool–one that can help them get on the same page–chances are they will have a better understanding of what each party means to say.
Mind mapping allows groups to capture ideas quickly, organize them until they make sense to all parties, publish the results in any number of formats, and then, finally, to create a kind of project portal by attaching to the map all manner of associated documents, web sites, emails, images, etc. There aren’t many softwares that enable you to aggregate such a diversity of information sources in one document.
You may be interested in going to http://mapthink.blogspot.com/2010/04/using-conceptdraw-mindmap-to-gather_19.html to see and example of how mind mapping is used to gather requirements. Using mind maps, project teams can get the 30,000-foot view by “collapsing the map branches.” Alternately, they can open up these branches to dive way down into the weeds to get to them minutest details. The ability to toggle between overview and details gives project stakeholders the kind of perspective that can improve project success rates.
One of the main challenges of project stakeholders is to make sure everyone involved has a common understanding of the project at hand.. Mind mapping is a dynamic, quickly learned–and often entertaining way to accomplish this.
Thanks for an interesting article.
Hobie Swan