ONLamp.com
oreilly.comSafari Books Online.Conferences.

advertisement


Why Do Projects Fail?

by Andrew Stellman, Jennifer Greene, authors of How to Keep Your Boss from Sinking Your Project (PDF)
06/20/2006

Editor's note: In this excerpt from How to Keep Your Boss from Sinking Your Project (PDF), authors Andrew Stellman and Jennifer Greene address the question of why projects fail. This excerpt serves as the introduction to their concepts of effectively managing upward on projects. If you want to know what steps you can take to keep your software project from running aground, check out their PDF.

By and large, good programmers have one universal response to bad management: "It's not my problem." Unfortunately, it is your problem. You may not be able to control it directly, but if you put your head in the sand and keep coding, your project can fail no matter how good your work is. And in the end, you may be seen as a poor performer because of that failure.

You may be skeptical of this, but the facts are there. Many large corporate and enterprise development projects are troubled-as many as two-thirds of them, according to a recent study (PDF) by the Standish Group. It's a well-established fact that as software projects get larger or more complex, they become much more likely to fail. And while some of the failures are due to poor development talent, the vast majority of them are due to bad decision-making, bad prioritization, and other stuff that your manager does before the project is even assigned to you.

It may seem unfair that you are going to be held responsible for the outcome of a project whose problems were injected before you even got your hands on it. But it happens all the time. And when it does, you end up wasting time, working many late nights and weekends, and delivering software that doesn't make your users happy, if you manage to deliver anything at all.

Luckily, you do have some options. If you understand why projects fail, and the consequences of the decisions being made above you, you can sway those decisions in favor of your project's success. You have one big advantage here: you are the expert on software development, and many people in the company will defer to you on technical matters. If you have a good understanding of the sources of your project's problems, and you voice your opinions, you can use your expertise to make real and positive change in your project's direction (and its success).

The most serious project problems originate in management, but they can be easily confused with technical difficulties. When that happens, you'll be asked to come up with a technical solution to a management problem, and that's unfair to you. (After all, it didn't matter how well tuned the engine was on the Titanic.)

Spot Project Problems Early

It's easy to miss the telltale signs of project failure until it's too late. Think back to your last gut-wrenching project where everything seemed to fall apart. (If you've been around long enough, you have almost certainly seen your share of these. And if you're like most competent developers, you've been very hard on yourself about it.) At the beginning of the project, everyone seemed to have a good grasp on what needed to be done. They were confident when the project started, and every time your boss asked about the project's status, you and the rest of the team reported that things were moving forward.

But at some point, it became increasingly clear to everyone that the project was facing serious problems. It was well past the software release deadline, but major quality problems kept coming up. It might have been that the team was having trouble with a particular third-party tool, or that the database was running far too slowly, or that the system couldn't handle the amount of traffic that the users needed. Or, maybe when the users got their hands on a preliminary version, they kept saying that critical features were missing- features that you had never heard of before then. No matter what the project problem was, the business outcome always seemed to be the same: the project has run late, and now someone has to answer for the problems. And, unfortunately, that usually ends up being the team. (If you're lucky, the manager will share the responsibility.)

One frustrating aspect of this typical failing project is that nobody seems to be able to do anything about it. It always seems like the solution to these nagging problems is right around the corner. But it's been around that corner for weeks or months, and often the manager has to make a very tough decision: to either release the faulty software prematurely with the promise of (possibly interminable) patches and fixes, or go back to the users and tell them they have to wait. If you can influence that decision, your manager will make the right one.

How did the project end up in this sorry state? And, more importantly, how can he prevent the next project from ending up the same way? By understanding what causes project problems and how to correct them, you can use your influence to make all the difference in your project's success.

When projects fail, they most often fail from the top down. Even the most competent and talented software engineering team can fail to produce software if they are not given the right direction and oversight.

Andrew Stellman comes from a programming background, and has managed teams of requirements analysts, designers, and developers. He and Jennifer Greene formed Stellman & Greene Consulting in 2003, with a focus on project management, software development, management consulting, and software process improvement.

Jennifer Greene has spent the past 15 years or so building software for many different kinds of companies. She's built software test teams and helped lots of companies diagnose and deal with habitual process problems so that they could build better software. Jennifer founded Stellman & Greene Consulting with Andrew Stellman in 2003. For more information about Jennifer, Andrew Stellman, and their books, visit http://www.stellman-greene.com.

Return to ONLamp.com.



Sponsored by: