You won’t find too many companies today that aren’t under pressure to increase new product growth which is why this series of articles is focused on uncovering hidden innovation capacity. Unfortunately, most companies report that the innovation projects they are counting on finish late and rarely deliver the sales promised. If any of this sounds familiar, you’ll want to hear this story…
Bob’s stomach knotted as he slumped in his chair at the leadership team meeting. Maybe he’d get lucky and Linda, the CEO and his boss, would skip his status update. But he knew that would only delay the inevitable. The launch of the new XTV, the critically important replacement for the uncompetitive GTS line, was going to be late—by several months or more depending on which estimate you believed. And as the head of R&D, Bob knew he was on the line.
Sure, there were all kinds of perfectly justifiable reasons for it being late. Marketing had changed the specifications twice already. One of the development partners had taken longer than planned. Key end-users had been slow in providing feedback. Testing had found an unexpected problem. The list went on and on. But Bob also knew that neither Linda nor the board were interested in excuses.
Before he could say anything, Linda looked in his direction and simply said, “Save the date.” Bob realized he was sitting there with his mouth wide open not knowing how to respond while the other managers, nervous for him, tried not to make eye contact.
“In case you’re wondering,” Linda continued after the awkward silence, “My best friend’s daughter is getting married next year. And while it’s way too early to send out invitations, they just sent out an announcement asking guests to save the date.” Bob wondered where she was going with this; judging by the looks around the table so did his colleagues.
“Look, I’d have to be pretty checked out not to realize that there’s no way we’re going to make the launch date for XTV,” she said looking around the table. “Am I pissed off? Well the GTS line is losing share badly and every week the XTV is delayed is costing us hundreds of thousands. So yeah I am, and I expect all of you to move heaven and earth to get it done sooner.”
“But it’s more than just that,” she continued. “I’m pissed because I don’t understand why we never find out a project has gone off the rails until there isn’t enough time to save it. That has to change! I want to be able to put product launch dates on my calendar and know that I can ‘Save the date’. Not only that, I want an early warning so that next time we can take action before it’s too late.”
Did I just dodge a bullet, thought Bob, only to get hit by a missile? Sure, he could lead a recovery effort to cut scope and bring the project in closer to the due date. But how was he going to address the underlying problem of on-time performance across multiple projects?
Bob’s problem isn’t unique. His project managers and their reports are playing a game called Schedule Chicken—given that name decades ago by development mangers seeing a similar problem. Most projects consist of multiple work streams (e.g. electronic, mechanical and software) that must all be integrated before completion. As the project proceeds, each element begins to slip a little, but managers find ways to deflect attention and show their work stream is “pretty much” on-time. Maybe by aggressively estimating the work remaining. Maybe by completing lower priority work like finishing drawings or completing documentation. Either way, they don’t want to be seen as delaying the program.
But why would anyone take that risk? The truth will eventually come out—won’t it? Here’s the dirty little secret they are counting on. The other work streams are running late too—what’s more, they all know it. The program manager for the software element just needs to hold on for awhile, delivering predictions that say they’ll be ready for integration. Then when the electronics program manager blinks and comes clean first, the software team dodges the blame. In the game of schedule chicken, it’s just a matter of who flinches first.
But Schedule Chicken is just a symptom-we need to go deeper and try to understand the root causes. What would compel perfectly competent professionals to act this way in the first place?
- Running too many projects at the same time – Projects are like cannon balls and resources are like gunpowder. There are always more targets to shoot at than there is powder to propel the cannon balls. Unfortunately, the answer is usually to spread the powder (your resources) among all the projects. The result being that you make a little progress towards each but finish very few. Wouldn’t you be better off to finish a handful of them much faster? Then you could put the resources released upon the earlier finish towards a new set of targets.
- Multitasking that creates interruptions – Multitasking is a myth so why is it still the predominant way of working? It ties back to the fallacy that everyone needs to be busy for the organization to be efficient. People have to do a little something on everything just to stay busy and keep all the project stakeholders happy. Task-juggling and status updates rapidly consume real work, further delaying you from hitting any targets.
- Milestone mentality that causes procrastination – All too often planning consists of, not developing a detailed network of critical tasks, but a series of high level milestones. Important? Yes, but no substitute for a robust task network. Then based on the high level “plan,” teams estimate the amount of work required. Of course, they know that they’ll be spread thin and required to multitask. So what do you think their estimates will look like? They also know that once they’re in the plan, everyone will treat those estimates as dates certain. Taking all this into account, any smart professional will pad the heck out of their estimates - sometimes by a factor of 2 to 3 times the expected effort–or touch time.
So with all that padding hidden in your projects, why do they still not finish on time? Well the padding actually has the opposite effect of what was intended, encouraging resources to procrastinate until the last possible minute—the student syndrome. It’s not that they aren’t working; it’s just that they’re working on something else. And in what’s called sandbagging, they make sure their task doesn’t finish too early and raise future expectations.
Essentially, all the padding built in to protect the milestones—easily equal to or greater than the work itself—ends up wasted on procrastination of one sort or another. Then as soon as any real problem creeps up, the due date is left unprotected and the project ends up delayed. Frustrating? Yes. Hopeless? Far from it.
Critical Chain Project Management
A Critical Chain Project Management (CCPM) approach addresses is key to effectively utilizing your full innovation capacity. Not to be confused with the critical path, which doesn’t consider resources, the Critical Chain is the project’s longest sequence of tasks without any multitasking. Here’s a quick rundown of how it works:
- Up-front planning for each project is essential. Involve cross-functional team members to identify all of the tasks required to develop and launch the product. Working backwards from the successful launch, arrange all the tasks into a network showing the order of execution. With practice a team can develop a high quality plan in a few days—a minimal investment for the speed and predictability gained.
- Estimate the touch time required for each task assuming no multitasking or interruptions. These durations should be aggressive enough that they only have a 50% chance of finishing on-time. This step is critical, as most projects are full of hidden padding intended to protect against uncertainty. CCPM provides protection but only for the project due date. This prevents the student syndrome (procrastination), apple polishing (unnecessary perfectionism), and sandbagging (sitting on finished tasks so expectations aren’t raised in the future) all of which waste padding without providing any protection against real uncertainty.
- Resource level the plan by eliminating any scheduled multitasking within the project itself. This may appear to lengthen the plan but reflects the reality that you will face in execution. The longest series of tasks is your critical chain. There are several good software programs for identifying the CC.
- Protect the project’s due date from uncertainty by adding a project buffer equal to half the duration of the critical chain. This simple buffer is the key to visualizing progress and managing project execution as you will see in steps 7 and 8. Available software tools add the project buffer automatically.
- To shorten the duration, scrub the network for tasks that can be done in less time with different resources, take tasks off the critical chain by finding ways to eliminate precedence requirements, or change other assumptions limiting earlier execution. Never try to shorten the duration by trimming the buffer—otherwise padding will rapidly creep back into the task estimates you get.
- Execution is synchronized relay racer style with CC tasks starting as early as possible. Resources work as fast as possible without any interruption or multitasking, and the next runner is always ready and waiting for the handoff. CCPM doesn’t focus on task dates or milestones because they drive procrastination and padded task estimates.
- Think of the buffer as a combination shock-absorber and warning light that gets used up as the project is completed. The goal is to finish the project with some buffer left but much of it will be burned. The project fever chart highlights problems when buffer is being burned faster than critical chain tasks are being completed.
- New projects aren’t released into the CCPM pipeline until they won’t jeopardize on-time delivery of any of the projects already in execution. This is done by targeting resource utilization at less than 80% of available work hours for your most constrained resource. This makes the portfolio much more robust to problems and keeps all the projects flowing. Smaller companies can do this by simply limiting the number of projects in execution at any one time. Larger companies will find it preferable to utilize software that look across the portfolio to tell you when a new project can be released into execution without the risk of delaying the projects that are already running.
- Projects enter the pipeline in an order reflecting either strategic priorities or the highest return per hour of your most constrained resource. However, once execution begins the pipeline status chart shows where the priorities should be. Resource managers know that unless there is a significant benefit to finishing one of the projects early or a penalty for finishing late, they should direct shared resources to work on the project that is at highest risk of finishing late. It also gives management an early warning system so they can dispatch additional bench resources when projects start to get into trouble.
Executing projects in a CCPM environment may take extra time with upfront planning and definitely requires new discipline and governance around what enters the portfolio. But the benefits far outweigh the investment. Companies that embrace CCPM report an average cycle-time reduction of 30-50%. As importantly, their projects finish on-time with greater than 95% reliability. Of course, implementing CCPM takes management commitment to both systemic and cultural changes. Without that commitment, people will view it as a tool to get them to work harder or agree to aggressive timelines. If that happens, any gains will be short-lived at best.
Looking to uncover hidden capacity and accelerate your new product innovation? Mike Dalton's Guided Innovation Group has helped companies finish more projects while doubling innovation throughput without added resources. Download their Growth Equation Diagnostic to see what kind of improvements you can expect.