Effective Engineering e-Newsletter – 3/3/2005
This is your monthly e-Newsletter from Effective Engineering Consulting
If you would like to receive Effective Engineering e-newsletters as
they are published, please send an email to email@example.com,
and we will add you to our distribution list.
Comments and suggestions are welcome and encouraged!
When Bad Things Happen to Good Projects
By Tom Dennis –
President, Effective Engineering [firstname.lastname@example.org]
Virtually all projects start out with
strong promise and high expectations. An
exciting product concept has been proposed. It has been fleshed out into something that it believes
customers will appreciate and buy. Surveys
of customers’ interest in the features show that they really do have a
willingness to pay for some of the features, and the feature set has been
adjusted to reflect this. Discussions
among product management, product development, manufacturing, marketing,
sales, and finance, have shown the product to be feasible from all
perspectives – it meets product management’s objectives, product
development views the product as one that can be practically developed,
manufacturing sees the product as manufacturable at reasonable costs,
marketing sees ways to effectively market and promote the product, sales
believes it can sell the product and has developed a sales plan that generates
solid revenues at good margins, and
finance views the product as fitting in with the overall corporate financial
goals. The product requirements
have been firmed up and a project plan for the development effort has been
prepared, and a go ahead to launch the development effort has been given.
It is fully believed that the project is “well begun” (see eN-040902
– Project Planning: Well Begun is Half Done”).
As the development project proceeds, things will happen (some starting almost
immediately) that will impact the project schedule.
A sustaining engineering problem will be found that will require the
skills of one of the key engineers, potentially impacting a critical path
activity. One or more engineers
will come down with the flu (I know this winter has been a particularly bad
one for illnesses). Something in
the market will change, causing one or more of the product requirements to
become obsolete or irrelevant. A
product feature that was believed to be straightforward to implement will be
found to have some serious problems that make implementation far more
difficult and time-consuming than had been anticipated.
There are seemingly endless lists of things that will affect the
pristine plan that represented the original project schedule, rendering a
number of specific project tasks obsolete or delayed.
In fact, the only time the project schedule will be completely accurate
is at the time it was released; it becomes out-of-date almost immediately.
So what do you do when bad things happen to good projects?
If you’ve been able to put together a plan based on what you don’t
know as well as what you do know (see eN-041104
– Project Planning: Plan Based On What You Do Know, and On What You Don’t!”),
then there should be some contingency built into your project schedule. If you’ve done this, then congratulations!
You’re in better shape than the person who didn’t, at least until
the next “bad thing” occurs.
In any event, if your project schedule appears to be going off track, you need
to concentrate on those tasks in the critical path (see eN-041202
– Bottlenecks: Concentrate on Fixing What’s Critical!”).
These are the tasks that will cause a day-for-day slip in the key
deliverables for the project. By
identifying what actions can be taken to get these critical path tasks back on
track, you can hopefully regain control of the project and meet your key
milestones. If appropriate
resources from an entirely different project can be pulled in, without
significantly jeopardizing that project, then that is probably the best way to
handle the situation, as it would allow other tasks in this project to
continue unaffected. However, you
often don’t have that flexibility.
Beware of thinking too narrowly about the current critical path tasks. There are often numerous other tasks that won’t show up in
the schedule as critical path tasks, but if minor perturbations to the
schedule occur they will suddenly become critical path tasks. If you pull someone on this project from a non-critical path
task and put him/her on the critical path task, that may enable you to achieve
the original critical path task, but the task that you pulled this person from
may now become a critical path task with the loss of him/her as a resource.
This is a multi-layered problem (“like an onion”, as Shrek might
say) that must be examined carefully.
Multiple actions must often be made, and predicting their impact
becomes significantly more difficult.
Sometimes shifting resources to address critical path tasks simply can’t
remedy the problems that may arise. These
may be external events (e.g. a critical external delivery is delayed that will
force the entire project to slip), or internal events (e.g. a problem arises
that prevents a critical path milestone from being achievable). In cases such as these, you may have no alternative but to
delay the project. Early
identification and broad notification is key in such circumstances. If you can’t overcome the delay, at least let everyone
affected know about it as early as possible.
The result may be simply adjustment of the delivery dates, or in other
cases may mean the cancellation of the project and product.
Whatever their cause, when bad things happen to good projects it is
imperative to keep the lines of communication open so all involved are aware,
and so that good business decisions can be made.
Copyright © 2005
Effective Engineering Consulting Services, All Rights Reserved