10 Reasons That Projects Fail (And How to Avoid Them)

courtsey: www.certmag.com
October 2005 - David Garrett

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.
Bad Language 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.
Bad Budgets 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.
Forgotten Users 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 term for an act that’s beyond a person’s control. Some call these acts of God. Some people blame the stars. Whatever the reason, it’s fair to say that some projects fail because of calamities beyond our control.
Solution: While you can’t walk on water and stop floods in their tracks, you can engage in a bit of risk planning to minimize your exposure to force majeure. Think of the disasters that could strike when you’re least ready for them, then make arrangements now. Increase your backups, build mirrors and redundant systems, write out a full-scale disaster recovery or business continuity plan. You’ll be glad you have one.
Dumb People This could be said more gently. It could even be said more subtly. But why bother? We all know that projects fail because some of the people who run them aren’t as swift (or merely as focused) as they should be.
Of course, we’re not immune from this ourselves. Remember that patience—that intangible asset that’s in smaller supply every day—is often a project’s best chance for success.
Solution: Choose your team wisely. Find the best people you can with the money you have and the choices you’re given. And invest in training as if it were a blue-chip stock: Choose it wisely, and it does nothing but increase your value.
The Technician-Manager Last but not least, don’t forget that good technicians don’t always make good managers—or good project mangers, for that matter.
You may be a dazzling writer of database systems. You may even know the rigors of ASP and PHP like some people know their ABCs. But can you pull off a project on time?
Remember that good management, and good project management, take a subtle mix of people, planning and communication skills. It takes a diplomat’s touch and an expert’s knowledge of the field. And it’s a skill that few of us are born with. The fact that you’re a whiz with event handlers or ActionScript doesn’t mean you can make the trains run on time—though you can learn to, and even excel at it with effort.
Last, remember that “project failure” and “project death” are very different things. In the end, failure is merely delay, not defeat, and if you take these lessons to heart and watch your projects like a hawk, you’ll find that success is closer than you think.