Effective Engineering e-Newsletter – 3/3/2005

This is your monthly e-Newsletter from Effective Engineering Consulting Services (www.effectiveeng.com).  If you would like to receive Effective Engineering e-newsletters as they are published, please send an email to e-newsletter@effectiveeng.com, and we will add you to our distribution list.  Comments and suggestions are welcome and encouraged!


eN-050303:


Project Management: When Bad Things Happen to Good Projects
  By Tom Dennis – President, Effective Engineering [tdennis@effectiveeng.com]


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