Careers are trashed and personal lives disrupted.
Even by optimistic estimates, about 75 percent of projects are late, over budget, missing major functionality or canceled outright. So depending on your definition, most of our projects end up somewhere between failure and disaster.
There are several important things to do once you realize that you're facing a disaster in the making, but you shouldn't do any of them until you are really sure that it's an impending disaster you're up against. So the first key to disaster recovery is disaster detection.
Given that so many projects go astray, you'd think that we'd be better at detecting these sorts of problems. Heck, our default assumption about projects should be that they're in trouble. But that's just not the way we're built.
Why is it so hard to know? Well, I've got a few theories.
No real plan. If there's no baseline to work from, no one really knows that a project is late. Many projects never get to the stage of firming up a detailed plan.
Excessive optimism. In many teams, there's a perpetual optimism that just because the project is behind at the current time doesn't mean that they won't soon catch up.
Fear of admission. When a project team is in trouble, no one wants to go to senior management and admit it. That might bring uncomfortable scrutiny, blame and retaliation. It's easy for team members to delude themselves into thinking, "Maybe no one will notice. Maybe things will get better. Maybe I'll find a new job before someone finds out."
So how do you figure out that you're getting into trouble? How can you monitor projects for those early warning signs that things are going off the rails? Here are a few things to look for:
Poor team morale. This is probably the biggest thing to look for, not because it's the leading cause of project failure, but because it's a great indicator that something else is wrong. Many of the other things listed below may first be visible in the team's morale, since team members will probably be aware of project problems before you are.
Poorly understood team roles. If the people on the team don't seem clear about what their individual roles should be and how they should be interacting, chances are there's a problem brewing.
Absent sponsors. If the sponsoring managers can't be bothered investing appropriate time in a project upfront, chances are they're not going to like what they get at the end.
Not enough methodology. If the team doesn't have a commonly understood approach to completing the work, it is likely to have trouble doing so.
Too much methodology. Methodology is a tool for completing a project, not a guarantee that things will go smoothly. And as with any tool, it may be employed for its intended use or as a weapon. A team that's over-burdened with methodology is usually either too concerned with the means rather than the end or is using the process as a bludgeon to further political goals.
Meager management. Inexperienced or unskilled managers often doom their projects to failure.
Lacking leadership. Although we often have a difficult time defining good leadership, it's one of those things that we usually know when we see it. If a project lacks external and/or internal leadership, chances are good that performance will flag.
Inadequate technical skills. While this is not the most common cause of project failure, it's often a factor. Some teams are assigned without the background and training they need to succeed. Since we usually staff projects with whoever is available at the time rather than with the best fit, critical skills are sometimes missing.
Too many meetings. Project teams that spend too much time in meeting rooms are often doing so to make up for inadequate planning. Because they haven't thought things out in advance, they try to coordinate everything on the fly.
If you want to prevent project catastrophes, early problem detection is the most important thing you can do. By the time an impending disaster becomes obvious, recovery will be quite difficult.