Effective Engineering 
                Consulting Services
                                           "Helping Engineering Excel!"

Our Premise
The Problem
Our Promise
Our Approach
Our Deliverables
Case Study
Our Results
Our People
Contact Us


Back to e-Newsletter Archives:

 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!


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

Back to e-Newsletter Archives:



Society of Professional Consultants


Copyright © 2002-2013 Effective Engineering Consulting Services, All Rights Reserved