Free Article By Paul Glen of C2
Consulting
Every month we add to this collection of articles from the free monthly
newsletter IT Professionalism.
You are also free to print these articles in your newsletter or magazine if
you follow our Reprint Policy.
To subscribe to it, click here.
Detecting Disaster Projects
If you've been in this industry for any length
of time, you've probably been caught up in some sort of project disaster. They
happen to the best of us, and they cause financial suffering for our companies
and personal pain for all involved.
Careers are trashed and personal lives
disrupted.
Even by optimistic estimates, about 75% 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.
© Copyright 2006 by Computerworld Inc., One Speen Street, Framingham, MA, 01701. Reprinted by permission of
Computerworld. All Rights Reserved.
