Project Up in Flames?

It's disturbing and sad and a little scary. It's that all-too-common point in projects when control is lost, yet everyone
remains in denial, rejecting the possibility that the worst-case
scenario could happen—or has already happened. Once a
project gets into trouble, it often spirals out of control,
regardless of the fixes and patches applied. When a project
reaches this point, only a dramatic intervention can rescue it.

Projects don't just suddenly get into trouble. The telltale
symptoms are there for people who are willing to see them. Some
symptoms should serve as a warning to dig deeper in order to
evaluate the need for a project rescue. Other symptoms should
automatically trigger an immediate project rescue intervention.

Ten Telltale Symptoms of a Project in Trouble

• Lacking or missing deadlines: Project deadlines may be
missed for multiple reasons, such as unforeseen events. But if
your team is missing its deadlines repeatedly, or if there are no
deadlines, that illustrates a lack of discipline.

• Changing requirements: The key is to differentiate whether
the requirements are changing, being augmented or being
replaced. If someone is changing the requirements, does he or
she really know what is needed? Changing requirements
virtually always has a negative impact on the project's timeframes
and costs.

• Final decisions not being made: Some critical decisions
require answers early in the project life cycle, such as what the
final product should look like and how many defects are
acceptable. A lack of clarity results in a lot of rework later in the
project.

• Project completion is stalled at 90 percent: Projects have
a tendency to remain in the "90 percent done" state. Often, this
completion estimate is arrived at by imprecise calculations or gut
feel. The complexity of the remaining 10 percent may be unclear.

• No problems being reported: All nontrivial projects will
encounter some sort of problem. If problems are not being
reported, the team has not dug down far enough, or information
is not being communicated.

• Lack of key project deliverables: Key project deliverables
or milestones are needed to ensure a smooth conclusion. A lack
of interim deliverables is a sure sign of future trouble.

• Interpersonal problems: Interpersonal problems may be
unavoidable. However, managing them poorly can lead to low
employee retention, poor morale and other issues that manifest
themselves in further telltale symptoms, including missed
deadlines and poor quality of work.

• Excessive quality problems: During normal development
phases, the lack of quality may be obscured by explaining that
factors that are not currently present or not currently working
will be delivered in the future. Nevertheless, at some point in
the project, you must draw the line: Either hit the rescue button
or accept the fact that the problems encountered are within
expectations.

• Unknown factors: You can't anticipate, predict and
mitigate every variable—at least not without a substantial
increase in the project's cost and timeline. But regular review of
high-impact and high-probability risks will help the extended
project team understand the expected behaviors when a risk
comes to fruition. Any events that cannot be accommodated in
the project plan should trigger a project rescue.

• Lack of management reporting tools: An absence of
management reporting tools almost guarantees that problems
are not being reported or are not being communicated to the
extended project team. It also usually means that telltale signs
are neglected until it's too late.

Having a process in place to spot these symptoms can help
you avoid a project disaster.

"We're pleased that we do not have any IT projects at risk in
the Commerce Department," says CIO Tom Pyke. "We believe
that's due in significant part to the fact that we have a strong IT
capital investment management process in place."

The Commerce Department's IT Review Board
conducts reviews of ongoing projects that give
insight into the management of each undertaking.
"We can identify potential issues at a very early stage
and take corrective action if necessary," Pyke
explains. He says this "early warning system," along
with "having a good, solid management plan to start
with," is key to preventing a project disaster.

Knowledge Isn't Always Power

Even if you're aware of the warning signs, several
suppression factors could prevent you from
recognizing the true status of a project. These factors
prevent you from pinpointing a worsening situation
and taking action to
correct the problems
before they lead to
inexorable decline.

Fear is a very
strong component
in suppression
factors: The team
members may fear
being blamed, or
they may worry that they'll look foolish. An
unwillingness to admit error can be a powerful
suppression factor, as can laziness.

Enabling people to give you input without
fear of penalty or ridicule is essential to successful
project management. "We have an open
environment," says Patrick Pizella, CIO of the
Department of Labor. "If there are problems, people
surface them and we address them."

When symptoms indicate you have reached
a project break point—the point that signals
an inevitable downward spiral toward project
failure—you need to decide: Will you rescue the project
or continue operating within the same boundaries and
assumptions that led to the project break point?

The most unpleasant choice—canceling the project—might
be appropriate in some situations. However, a well-planned and
well-defined project rescue can reverse the downward spiral by
challenging the status quo and enabling project team members
to make the difficult decisions necessary to salvage the initiative.

Seven Steps to Rescuing a Project

• Admit you have a problem: This is undeniably difficult to
do. People will plead, "I just need one more month. I'm so close."
But, in many situations, that last month never delivers. You
cannot spend your way out of an unsalvageable project, so cut
your losses.

• Pause the project: By continuing unchanged, you burn
more hours and costs against the project—spinning your wheels
because you really don't know where you're going. You don't
even know if you're on the path to completion. Taking a break
gives you a chance to regroup and make a new plan. This may
be the scariest step, but if you don't stop and sort things out,
you're headed for even scarier territory.

• Conduct a project audit: A project audit will help you find
the root cause of why things are going wrong. From my
experience, the primary reason a project spirals downward is
that the project manager is relatively inexperienced for the
project's size and/or scope.

• Assess the effort to complete the project: You need to
know realistically what it's going to take to finish the project. Be
practical as you review the project and determine how long it
takes your team to complete tasks. Don't assume you will do
things much better or that tasks will take less time.

• Validate the return on investment: Someone had a
reason for implementing the project in the first place. So figure
out if the benefits still make the project worth continuing.

• Put the project back into the IT governance hopper:

You must determine if it still makes sense to pursue the project,
and whether this
is the best use of
funds. Compare
the value of this
project to other
IT alternatives
and initiatives.
Two years ago,
the project may
have been a
leading priority, but now a different project may have become
more important.

• Restart the project: Relaunch the project with a new plan
and estimates. Beware of roadblocks such as apathy and disbelief
that may be thrown in the way of your rescued project. People
take their cues from the leader, so tell people the project is
important and then act as though it is.

Most projects are well into the development phase—some are
even in the testing phase—before a strong case can be made to
formally launch an intervention. However, by spotting the
telltale signs early in a project's life cycle, you may be able to
salvage much of the original scope of a troubled project.