|
|
Why Are So Many Projects
Late?
"When a
task cannot be partitioned because of sequential constraints, the
application of more effort has no effect on the schedule."
—Frederick P. Brooks, The Mythical Man-Month: Essays on Software
Engineering
It's one of the
harshest realities of project management: some things really just
take as long as they take. And adding more people won't make things
better—or faster.
Frederick Brooks' essay was prompted by
the fact that many software projects are "late." He highlighted many
of the chief reasons so many projects get behind (and stay
behind)—changing requirements, inadequate planning, and ineffective
communications. Faced with a high-profile project that is slipping
behind schedule, many companies try to rectify the situation by
adding more people. The highly-scientific phrase used for this
problem-solving method is "throwing bodies at the
problem."
In reality, adding more people often makes things
worse, not better. If a project is already poorly planned or poorly
managed, the application of more resources will likely exacerbate
rather than alleviate the problem; in turn, even more time and
effort to get things right will be required. In the end, devoting
more resources to a failing project can actually accelerate the
failure rather than avert it.
What if we could do a better
job up front when it comes to estimating time and resources?
Wouldn't that avoid the problem altogether?
The answer
hinges on three important project
realities:
- Uncertainty: Even the most painstakingly prepared
project estimates (of time and people) are only as good as the
facts and assumptions upon which they are based. The earlier an
estimate is provided in the project life cycle—before clear
requirements or design decisions have been determined—the less
precise the estimate will be. That's why defining what the project
requirements are (and what they are not) sooner versus
later is so important.
Continually refining estimates as
project deliverables become better defined is crucial. Breaking
big projects into smaller deliverable chunks can lessen risks
associated with big deliverables and reduce the variability
associated with estimates. That means there is a better chance
that estimates about time and resources will be more accurate and
will enable you to staff your project
appropriately.
Reducing uncertainty enables you to
logically subdivide the work to be done and quantify the types and
numbers of resources needed. Only then can you determine if your
resource plan is appropriately balanced and, if not, what needs to
be done to correct it.
- All Work Is Not Created Equal: All work—and therefore,
all project time—is not created equal. You can't necessarily take
a one-person project estimated at six man-months, add one more
person, and turn it into a three man-month project. Project math
doesn't work that way.
The amount of work one person can
do and the time it takes to do it depend upon the specific
work involved, the specific skill sets required to do it,
and the specific project circumstances at that point in
time: whether scope is defined or not; requirements are
complete or incomplete; key decisions are
made or still pending.
- Estimates Are Almost Always Biased: Most of the project
estimates I've seen have been based on what are usually described
as "most likely" scenarios. That sounds perfectly reasonable. But
for a project that consists of many different tasks and a high
degree of complexity (sounds like most of your projects, doesn't
it?), this estimating method doesn't work. In fact, it tends to
produce gross underestimates.
In your experience, how
often have a set of complex items all been completed exactly on
schedule, even when that schedule was deemed to be "most likely"?
Not often, I'll bet. That's because it takes only one
variable to exceed the "most likely" estimate and bingo—you are
now behind plan and off schedule.
Estimating any task
(regardless of its complexity) based on a "most likely" method is
going to yield a project estimate that understates the total
actual duration. Why?
We're back to
item #1 above: uncertainty. When multiple tasks are being executed
simultaneously (or in close proximity), it takes only one that
exceeds its estimate to make the entire project late. As a result,
the more tasks and the greater the complexity, the more chances that
this will happen.
In the end, the most effective way to
deliver projects on time is to focus on reducing uncertainty. Doing
this produces more accurate estimates that take real- world risks
into account. This can help you avoid throwing bodies at the problem
when it's clearly too late to make a positive impact. And remember,
common sense should always prevail. |
|
