Effective Engineering e-Newsletter – 12/2/2004
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-041202:
Bottlenecks:
Concentrate on Fixing What’s Critical!
By
Tom Dennis – President, Effective Engineering [tdennis@effectiveeng.com]
We all experience bottlenecks in our everyday lives.
We’re driving and learn that an accident has caused all but one lane
of traffic ahead to be closed. That
area with the one-lane restriction is a bottleneck, and traffic before it will
get backed up. We look at a production facility, whether it be a factory or
a fast food restaurant, and see that one work area on the production line has
everything before it backed up and waiting to get it’s turn.
That area is a bottleneck. In
product development, it is also true that specific tasks can become
bottlenecks. However, it is
generally more complex than the traffic jam or production examples, in that
many areas can be bottlenecks, and a change in one area can quickly cause the
bottleneck to shift from one task to another, seemingly unrelated task.
In any product development project, many tasks of many varieties must be
completed, and these tasks must generally be carried out in a specific order.
Some tasks can be carried out in parallel with other tasks, while other
tasks must be carried out sequentially with some tasks being completed before
and other tasks starting after the specific task in question.
All of the tasks in a project are important and necessary, but not all
of them are bottleneck tasks. Those
that are bottleneck tasks are critical, such that a delay of one day in a
bottleneck task (or any task in the critical path) will delay the delivery of
the overall project by one day. By
concentrating your primary energies on bottleneck tasks, and not concentrating
on non-bottleneck tasks (the tasks where a delay of a day will not affect the
end delivery date of the project), you can spend your time fixing what’s
critical, and on what can prevent delays in project completion.
As an example, let’s consider a project that has software and hardware
development tasks. [Most projects
have more than two development disciplines involved, but we will simplify the
example by using only two.] To some extent the tasks required to carry out the software
development can be defined and laid out in order independently of the tasks
required to carry out the hardware development. In fact, for each of these development activities, a schedule
can be defined, and a critical path can be identified. In a vacuum, you could concentrate on the critical paths for
each of these development activities to see where your attention should be
applied to reduce risk and meet project delivery goals. The hardware development activities themselves may be very
complex, with many parallel and sequential tasks and with complex
interrelationships among these various hardware tasks.
The bottleneck tasks for the hardware development may be difficult to
determine, and may change drastically should the duration of a single task
change. The same can be said of
the software development activities, again, looking in a vacuum.
However, for this (and for most) project(s), the software and hardware tasks
cannot exist in a vacuum. For the product to be a product, the hardware needs the
software to run and to provide the intelligence that the user experiences.
Likewise, the software needs the hardware in order to have a physical
product to deliver. This is true
for what ultimately gets delivered to customers, and it is equally true at
many points along the development process.
Therefore, the software tasks must include numerous points of
dependency where hardware is required, and the hardware tasks must include
numerous points of dependency where software is required.
This means that not only must software activities proceed in a certain
order with specific dependencies on other software tasks, but this series of
tasks must be linked to completion of specific hardware tasks as well.
The same is true for the hardware tasks.
Now, a delay in the hardware may significantly impact the software
schedule, and a delay in the software may significantly impact the hardware
schedule. Determination of
bottleneck tasks now becomes significantly more difficult, and the way the
schedules interrelate becomes far more difficult to plan and manage.
Throw in mechanical development, industrial design, tooling, packaging,
and many other development activities, and you’ve got an extremely complex
and intricate combination of tasks that need to be carried out in concert with
each other, where any one task can have unexpected implications on seemingly
unrelated tasks.
For very simple projects, it may be possible to try to keep track of all of
this by hand, but even for very simple projects, it can be very difficult.
For complex projects, to try to manage the projects by hand becomes
folly.
Even with good tools, managing complex projects can be a colossal challenge.
The key is to identify, to the extent possible, all of the tasks
that need to be carried out to complete the project.
Each of these tasks should be of short duration, measured in hours,
days, or perhaps 1-2 weeks. Longer
duration tasks should generally be broken down into smaller sub-tasks.
By establishing tasks of reasonably small durations, it is easier to
measure progress in the completion of those tasks.
Remember the old adage, “To Conquer, First Divide”.
After the tasks are identified, then the dependencies of each task on other
tasks must be specified. This
will establish the order in which tasks must be carried out.
There are tools, such as Microsoft Project, that can help, and such tools are
highly recommended. Once all of
the tasks associated with a project are identified, and once all of the
dependencies of any tasks on other tasks are specified, the tool can
automatically identify critical task paths to help you to know where to begin
to concentrate your efforts. With
such a tool, you can also do some “what if” analysis, by changing
durations or dependencies of specific tasks to see if the critical path
changes. It may be possible to
apply resources differently to shorten specific tasks, or some tasks can
actually begin before another task is completed.
Many scenarios can be played out using the tool to help determine the
best way to approach the project. The
tool will help identify where the likely bottlenecks are or are not, and where
you need to concentrate your attention or potentially draw resources from to
help with bottleneck tasks.
Project management can be challenging and confusing, and when things change
from the plan, which they always do, even more challenging to find ways to get
things back on track. The key to
successful project management is identifying where to concentrate your own
time and attention. Finding the
bottlenecks, and working to reduce or eliminate them is what is most critical.
Close behind that is recognizing where the bottleneck moves to when one
bottleneck problem has been addressed. Diligence,
persistence, and determination are necessary to be successful, but
concentrating on the bottlenecks is critical to getting the job done!
Copyright ©
2004
Effective Engineering Consulting Services, All Rights Reserved
