Archive for May, 2011

Use Traffic Delay to Measure Congestion

Wednesday, May 25th, 2011
 “Traffic Delays to Triple” read a headline about highway congestion in my morning paper.  It turns out that planners use traffic delay to measure the cost of highway congestion.

This would be a good way to measure project congestion on your new product highway.

We’ve all experienced traffic jams (if you’re from Southern California you’re an expert).  When traffic is congested, it takes too long to get home, and your arrival time is unpredictable.  The figure below, based on Don Reinertsen’s The Principles of Product Development Flow (pages 170-172), shows how high traffic density reduces throughput.

Traffic density reduces throughput

With highway traffic, too many cars start to interfere with each other, they begin to slow down, and vehicle throughput declines.

The same thing happens in product development.  Companies’ most common headaches are that projects take too long and schedules are unreliable. Yet these same companies start too many projects, congesting project traffic, delaying projects and making schedules unreliable.

But how can you push back on project congestion without coming off as a whiner?  One way would be to build a case against congestion by assessing traffic delay as an objective measure of the cost of congestion.

Put a cross functional task force together for a retrospective on recent projects.  Estimate the total delays in weeks, weighted by the lifetime profit potential of each project to get a delay measurement in $M-Weeks.  (It would be better to use a financial cost of delay model to translate delay directly into economic loss.  But most companies don’t use these models, as I’ve lamented previously.)

Apply your best judgment to look only at delays that are caused by congestion:

  • Time spent waiting in queues at resource bottlenecks
  • Time waiting for an engineer from another project that didn’t finish on time.
  • Delay caused when an engineer was diverted to fight a fire with another project.
  • Delay caused by multitasking.  When sharing resources means alternately putting projects on hold while another one gets resources.
  • Cases where an expert needed to solve an unexpected problem was already committed elsewhere.
  • Opportunity delay, when a project might have been accelerated with more staffing. (For this one, estimate what the project schedule might have been with a reasonable staffing increase.)

Be sure to honestly estimate congestion delays without including delays from other sources, such as underestimated tasks, or “normal” process overhead.

This assessment will tell you how much project congestion is costing you.  If the figure is large, you have a concrete basis for better new project onramp control.  This will ease congestion and make projects faster and more predictable.  And maybe you’ll be able to get home on time.

The Multitasking Mirage

Tuesday, May 24th, 2011

So many projects, so little time.  Individuals, project teams, or whole engineering departments often find themselves overbooked and juggling multiple projects in the effort to keep them all on track.  This is chasing a mirage.  Multitasking doesn’t reduce delay; it creates more delay and spreads it among all the projects.

Here’s an example. Suppose the Red and Blue projects both need time from Amy, your best wireless designer.  She’s just started the Red project when the Blue project lands on her desk. 

Amy might want to put Blue on hold until she finishes Red.  That would be unitasking, and it would delay Blue.  Wouldn’t it?

But both projects are top priority with rigid deadlines.  In order not to delay Blue, Amy should divide her time “fairly” between both projects.  Shouldn’t she?

Let’s take a look.  The figure below compares how Amy might apply her time to Red and Blue by unitasking or multitasking. 

Multitasking doesn't speed up the Blue Project

The multitasking mirage is that multitasking reduces delay time on the Blue project.  But the first thing you notice is that multitasking doesn’t speed blue at.  Amy finishes it at the same time in either case.  This is because total wait time for Blue is the same in both cases.

Perversely, multitasking only creates wait time for Red.   This is waste, since it doesn’t help to speed up Blue at all.

And I’m not talking about the inefficiency and opportunity for error that comes from jumping back and forth between different projects.  That can be a significant cost, but it’s a topic for another post.

Back to the figure, what if Blue really does have an important deadline?  In that case, Amy should switch her effort to Blue once, only going back to Red when Blue is done.

What if Red and Blue are both due at the same time, maybe for a trade show?  You have to keep in mind that Amy won’t finish Blue any sooner with multitasking. With unitasking, you’ll at least finish Red in time for the show, even if Blue is at risk–Better than putting both projects at risk.

What can you do?  Of course, Amy should do only the minimum required for each project, no bells or whistles.  And it will speed up both projects if Amy can get some effective help, maybe with the more mundane parts of the work that don’t need her expertise..

To avoid multitasking, the first thing you can do is to show this figure to whoever is driving the multitasking.  If that person is your manager, be sure you explain that you’re not trying to avoid work, but that it’s best for the company to avoid the schedule waste of multitasking.  If that person doesn’t believe it, have them email me.  A big part of my job is changing managers’ minds.

Another thing you can do to stabilize priorities. Switch from Red to Blue once, and only once, if Blue really does need to be finished sooner.  Unstable, shifting priorities often result from stakeholders of different projects fretting that their project waits while the other project moves forward. 

I know that getting clear, stable priorities is a real challenge in many companies.  Managers who regard themselves as rugged and decisive can get weak in the knees in front of competing executive project champions.

If you can’t get management agreement on priorities, set them yourself.  Just focus on the Red project and tell your manager that it’s in the company’s best interest to at least finish Red quickly, because multitasking will not speed up Blue, and that you’ll start on Blue at the earliest possible moment.  Say that you’re applying onramp traffic control to prevent a traffic jam.

Are you suffering from multitasking?  Leave a comment–there may be another reader who’s already solved your problem.

Dear John, Oh, how I hate to write.

Monday, May 2nd, 2011

It’s the classic breakup letter.  How would it look today for an engineering manager looking for a change after a long relationship with her phase-gate process?

Dear Phase-Gate, I hate to do this by email, but I can’t wait any longer.  We have to make some changes. 

It’s not you, it’s me.  You haven’t changed at all since we met, but my needs are different now. 

When we hooked up in the 90’s, my projects were a mess–requirements changing, schedules slipping, and expenses out of control.  Your project structure, thorough planning and gate reviews all seemed so right then.  Freezing plans before starting development seemed to eliminate mid-project changes and gave our managers predictable schedules and milestones to approve at gate meetings.

But in my world today, I need more space.  My most important opportunities are in innovative, fast-changing markets, where my engineers have to learn and adapt in the middle of a project.  What seemed like good management when we met is holding me back now.

The other day after a conference, I heard about Lean Product Development in the bar.  I admit I was interested, but the next morning I realized that Lean would be too big of a change for me. Ideas like “Principles of Flow” all seem too abstract for me to jump into right now.

Phase-Gate, I don’t want to start over and lose everything we’ve invested in our relationship.  Isn’t there a way you could change to accept mid-project learning and adaptation without punishing developers? 

I picked up a self help book by Preston Smith called “Flexible Product Development” with some great ideas about preparing for change instead of trying to eliminate it.  Would you be willing to read it?  We could stay together if you could learn to tolerate mid-project learning without a lot of disruption.

Do you think you could try some new ideas?

(The idea for this post came from a keynote speech by Jean Tabaka at the Mile High Agile conference.  She’s a great speaker; this video is worth a look.)