10 Reasons That Projects Fail/How to Avoid Them
It’s called the Chaos Report, and you need to know about it.
Every year, The Standish Group (www.standishgroup.com), which tracks the success rates of IT projects, issues this report to an eager crowd of analysts, managers and techies who wonder why so many IT projects end in failure. And while the numbers vary by year, they’re often dismal: A recent Chaos Report claimed that “unqualified project successes” are well below 50 percent, and sometimes as low as a third of all projects tracked. Even worse, out-and-out failures, which are defined as projects that are abandoned midstream, can reach as high as 15 percent. Projects that simply have time problems, cost problems or poor execution can make up as much as half of all IT projects per year.
These numbers are bad news. Now more than ever, the world depends on IT—but IT and the people who run it don’t always have a dependable record. This leads to the simple but vexing question of why projects fail—and just as important, what you can do about it.
Projects fail for all kinds of reasons, from insanely low budgets to unwisely tight schedules. But some reasons pop up again and again, everywhere from mom-and-pop shops to the Fortune 500, so they’re listed here, along with advice on how to avoid them.
Scope, Scope and More Scope
Far and away, scope issues are the number-one reason that projects fail. “ Scope” is simply the project manager’s term for the sum of work to be done on a project—what it entails, what it doesn’t and what its end products are. All too often, projects that fail have poorly defined scopes.
Here’s an example: You’re told to build a simple contact management system for your corporate intranet, and you’re given a list of features, a budget and a basic timeline. You build the system to spec, but as you’re building it, your users, impressed with your work, think of new features to add. It’s called “scope creep”—the insidious way that a project’s end-products get larger by degrees. Three weeks into the project, you find yourself bogged down by details that no one ever mentioned at the start. As a result, you miss your deadline, get slapped on the wrists and buy a large bottle of Jack Daniels.
Solution: Write a scope document—a list of what you will and won’t do by a project’s end. And if you’re really worried about scope creep, write an out-of-scope document, in which you explicitly state what you won’t add, emend or deliver. Then enforce it like the law.
Egos (Big Ones)
You won’t find this reason on an official list of project pitfalls, but it’s one of the chief reasons for project failure. People have egos, and all too often they’re loath to swallow their pride, admit they’re wrong and move on. Feelings get bruised and people get mad, and as a result, projects get left undone.
Solution: Remember that a project manager is always a diplomat. True, there are some projects that demand a diplomat of Kofi Annan’s caliber, but even a small amount of courtesy, compromise and common sense can go a long way toward getting things done when politics run amok.
This doesn’t mean curse words. It means poor communication. All too often, we speak and write in ways that don’t make things clear. Or we simply don’t speak or write enough in the first place.
Remember that taking a project from coal to diamonds involves keeping all the miners in the loop. You need to have a clear statement of mission, a well-defined scope, daily or weekly status reports and enough meetings to keep the team organized (but not so many that it steals their time). You also need a simple and direct way to learn about problems as soon as they occur. Without it, you’re flying blind—and your project is bound for failure.
Solution: If you’re doing a large project, write out a brief communications plan. Who needs to be kept in the know? Who gets copied on e-mail? When will you meet, and why? Is there a chain of command? And so on. Pin down these answers before you get started to avoid problems at the end.
This one’s easy: Too many projects don’t have the money they need to succeed. Bootstrapping is a part of life, but a miserly budget can kill a project before it even begins.
Solution: Make sure you know what a project will cost before you start it—the best way is to write a line-item budget—and factor in a safety cushion for cost overruns. Then fight for your budget with the bean counters and decision-makers who control the purse strings. A few extra dollars can mean the difference between a glowing success and something that people whisper about behind closed doors.
Too many IT projects commit this sin in spades. Remember that an IT project is built for the sake of its users, and not for the people who built it. All too often, the coders, engineers and network administrators who run a project speak with users at two points in the process only: the beginning, when they ask what users want, and the end, when they present the goods.
The problem, of course, is that users don’t always know what they want until they see it, or they don’t explain what they want very clearly. If you wait until a project is over to show users the results, you’re simply asking for trouble.
Solution: Involve your users at every phase of the project. If you’re building a Web site, get them to sign off on the site map. Get their input on every color, design and word of copy you write. Ask for their opinions weekly, if not more often, and you’ll have a better chance for a happy ending.
The Missing Bigwig
Projects are merely the people who run them. Whether or not a project works depends on the team that’s assembled to drive it, and that makes politics and human nature an inherent part of project management.
Since people respond to authority, you need a good project sponsor: an executive with the power and clout to force people to work and free up the dollars your project needs. Some call this “ management buy-in.” Some call it “ management by force.” But whatever you call it, make sure you do it—a project that’s sponsored by a high-end executive is a project that’s less apt to fail.
Solution: Don’t be afraid to ask an executive to chair your project. If his name is tied to the project’s success, he’s more likely to exert the effort that’s needed (and perhaps knock some heads together) to get things done in a pinch.
Lack of Planning
It seems easy, but it’s a lesson of such fiendish complexity that people forget it all the time: If you want your project to succeed, plan it thoroughly.
Remember that planning is both art and science, and entails more than a simple calendar. There’s risk management, change management, work breakdowns, documentation and more. So be sure to write up your plan in as much detail as possible. (The mere act of writing makes you view things in a light you may have ignored.) And bear in mind that the days of “cowboy coding,” in which you get to work as soon as you get a concept, are over.
Solution: Write out a project charter, a mission, a scope statement and a communications plan. Invest in a few good project management books for tips and advice on the lost art of planning and how to do it right.
Good Old Force Majeure
Of course, not every project fails because of bad execution. There are things beyond our control—the economy, for instance, or simply a flood that wipes out your data center at two in the morning.
Force majeure is the legal t