I’d like to discuss failure — specifically, software development projects that fail. Has it ever happened to a project team you were on? If so, it was probably not for the reason you think.
Before we can examine this further, we need to agree on what constitutes failure. I’ll offer my definitions and you can add yours in the comments if you like.
What is failure?
- The project never finishes. It’s canceled before the team considers it done.
- The budget is exceeded by more than 20%. (Why 20%? It’s a number that feels like failure to me. You might use a different number.)
- The team misses a critical deadline AND ‘must have’ features are not working. (You did prioritize features, right?)
- The team delivers working software but the stakeholders and business users are unhappy with the result.
- The project just drags on. There’s no budget, timeline or definitive requirements — there’s also no definition of done.
I’m sure that anyone who has been involved in software development for more than a few years has experienced one or more of these situations. If you haven’t yet, you will– and it won’t be pretty.
Why do software projects fail?
The reasons for failing projects are as varied as the projects themselves. I don’t want to dwell on information that is available elsewhere so I’ll try to offer a different perspective.
- It’s widely perceived that lack of management oversight and control leads to project failure. I disagree. I believe that projects often have too many managers and too many controls. The focus is on managing the process when it should be on getting stuff done.
- Lack of people management is another widely perceived failure point. Wrong again. If the company has hired good people, they know what they need to do and how to do it. Get out of the way and let them do their jobs. Give them some running room and some time to accomplish something. (Oh — and fire the non-performers and troublemakers.)
- Poorly defined requirements is a real problem but not for the reason you might think. The stakeholders and end users know what they want. Pay attention to them. Problems develop because we don’t spend enough time talking through what’s wanted, establishing common goals, and determining what really matters. (Lengthy requirements specifications can’t solve that problem.)
- Contrary to popular opinion, projects don’t fail due to lack of time, money or people. They fail because expectations are not managed well. People become locked into their favorite solution or approach and are unwilling to accept a different idea. Spend more time leading and less time controlling.
- Lack of process, governance or change control are also often cited as failure reasons. Sorry. Those are invalid reasons too. There is either too much of those things, stifling the project team, or they are being improperly applied resulting in poor decisions. Keep it simple.
Would you like to succeed more and fail less?
- Stop managing so much and start delivering results.
- People are more important than process. Respect them.
- Documentation is a tool not a result. Don’t abuse it.
- Protect relationships not ideas.
- Change is good. Be open to changing your plans.