In a recent post http://jaycaplan.com, I explained why medtech companies should look to software and tech companies, to improve project management techniques to drive increases in new product development productivity. Today I’d like to re-emphasize that despite common belief, new product development is rarely limited by the classical critical path. Instead, I assert that our timelines are almost always capacity limited. You’ve been trained not to believe me, but I beg you to look at the evidence dispassionately. Read on to learn more.
As a lean manufacturing enthusiast, the critical chain approach really had intuitive appeal for me. And, the critical chain approach taught me a lot. In the critical chain approach, Gantt charts tell a story of precedence – each new set of tasks begins after the preceding tasks end, sequentially defining a critical chain of events, which ultimately determines the best-case project timeline. Well-managed time buffers are used compensate for noisy estimates of task durations. The grand result is the “buffered end date,” a so-called realistic estimate of project duration. Project tasks are managed to their best case duration, and time-buffers are consumed (or not) as the project team executes.
In my experience, though, projects rarely hit their buffered end-date, because in reality, projects are capacity-limited not critical-chain limited. We simply fail to recognize that projects are capacity limited, because we so much want to believe in our own power to get things done. We attribute long project durations to vendor lead times, the need for successive iterations, and “unpredictability.” It’s true that vendors have long lead times and we often need several design iterations. It’s true too that events are unpredictable (that’s why critical chain projects have time buffers!). But I’m here to tell you that finite team capacity is the real limiting factor.
Let’s face reality together. Here are the top five signs that your project is actually capacity-limited, not critical chain limited:
- Resource-leveling the gantt would drive the timeline out. Stop and think about this. Every resource in the plan is fully loaded or overloaded. How many times have project managers told me that they won’t run resource-leveling because it would extend the timeline to an unacceptable date? Is this a technical problem with Microsoft Project or are we just afraid to face reality?
- It takes longer than planned to get long-lead items on order, despite the fact you know they are a high priority. You can’t blame a vendor lead time if the order doesn’t happen on time. After all, you built the ordering tasks into the plan, didn’t you?
- Chores* (aka non-NPD tasks that should be performed by the product development group) are routinely deferred, reports of completed experiments are deferred, design reviews don’t happen on a timely basis or are of poor quality, and meeting minutes are poorly documented. We know we should get these things done, but we’ve run out of time, right?
- Everyone feels overloaded all the time. You know the feeling. You can feel it when you’re capacity constrained.
- You don’t have enough time to complete the project plan on a timely basis, and you don’t have enough time to maintain the project plan on a timely basis.
In other words, if your project isn’t capacity constrained, you’d be working down the backlog of everything else on your plate.
When you’re capacity limited, instead of a critical chain approach, tech and software companies have learned that project management must focus on optimizing the use of limited capacity. That’s a subject for another post.
*My friend Jon mentioned several types of chores that get the short shrift when we’re capacity limited:
- Incomplete or inadequate failure investigations
- Reduced participation in CAPA and NCMR
- Disconnect between manufacturing and engineering
- Reduction or abandonment of continuous improvement efforts
Jon also makes another critical point – being capacity-limited affects our culture and scalability in negative ways: siloing due to an inability to provide cross-functional support, deferred personal development activities, and deferred company process development. All the more reason to focus on optimizing resource utilization.