The mistake that I have observed most often that also equates to the greatest long-term lost opportunity among product businesses is driving too many development projects at once. My exposure to service businesses is lesser, but I believe that the same mistake prevails there, where businesses take on too many projects or commitments at once. Use the principles of Little’s Law to manage your pipeline and accelerate innovation and profits.
The subject of optimizing a project pipeline for maximum throughput of profitable new products deserves a good, thick book, not a Web post. In fact I have read several. There is one basic principle that every book tries very hard to drive home but businesses and leaders and change agents struggle to accept or put into practice: less is more.
Because I have seen the problem of clogged project pipelines robbing productivity and profits so often, and because it seems to be a problem so inimical to commitment to a solution, I too will try and inspire us to wage war on the human habit of just-one-more. A courteous reader shared with me the following quote by Charles Kettering. (I haven’t successfully confirmed it, but it is meaningful none-the-less.) “We can send a message around the world in under a second, but it takes years to penetrate the human skull.”
Open your skulls and consider perhaps the most important strategy for getting the most out of your product development systems or your service centers. Here we go.
I have been challenged several times to improve product development throughput. Almost every time, I proposed intelligently restricting and controlling the number of projects in the product development pipeline. I proposed ensuring that the best, most promising projects get absolute devotion and that less important or less profitable projects should not be allowed to rob or borrow attention or resources from them.
Getting the top few projects completed quickly is more productive and profitable than getting many projects completed slowly. I’ve supported my arguments and analyses with well-known process improvement principles such as the Theory of Constraints and Little’s Law, and though we all agreed with the concept notionally, accepting the predictions of profit improvement or committing to making the necessary changes to behavior and accountability seems nearly impossible.
I believe that there are two problems that roadblock us from accepting or committing to the proposal to tightly restrict the projects in development. First is our human nature to “just-one-more.” We eat just one more spoonful, we buy just one more gadget, and we take on just one more project; especially when we think it tastes good, or we can pay it off in a month, or we think it will get us just a little more revenue. It requires more discipline than most people and most businesses possess to stand firm and say, “No! We are not going to do that project right now. Get in line.”
Second, product development is much more complicated than figuring out how many widgets can fit through a production line. The calculations that demonstrate the impact of constraints or Takt Time and cadence do not remotely simulate throughput for a pipeline full of differently sized and resourced projects, sharing resources, and ultimately following an iterative, instead of linear, process.
Let’s use Little’s Law to examine the challenge. Little’s Law is a process improvement tool that allows us to estimate or calculate an appropriate pace or cadence for the process. It is a simple mathematical equation as follows.
Lead Time = Quantity of Work-In-Process / Average Completion Rate
To make sure we are all reading this the same way, consider that Lead Time is how long it takes to deliver a service or product, beginning the clock the moment the order is triggered. Work-In-Process (WIP) is how much incomplete work, or the quantity of incomplete orders waiting to be completed or in process to be completed. By the way, completed means satisfactorily delivered to the customer. Average Completion Rate is how many “things” we complete each day, week, month, etc.
As you can imagine, the Little’s Law calculation is pretty straight forward when it comes to manufacturing widgets or processing equivalent (the same) services over-and-over. Suppose that we are calculating the Lead Time of producing cans of soda pop. If we can produce 300,000 cans of pop in a day, and there are typically 4000 cans or orders in the system at a given time, the Lead Time for a can of pop is 4000/300,000 = 0.013 days or 0.32 hours or 19.2 minutes.
Obviously if the actual production system is running as smoothly, then we can reduce the time it takes to get from the moment of order to initiating the production process to reduce the WIP and improve Lead Time, or we can speed up the production rate and keep WIP static and improve Lead Time. Lastly, if we have a Lead Time goal of 17 minutes, we can calculate how much we must increase production rate or reduce WIP in order to meet the goal. Simple right?
The problem is that projects are not simple. No two projects are the same, and even though we can calculate an average rate of project delivery, that number can be different from month-to-month, or quarter-to-quarter as the complexity and number of projects fluctuates. In other words, no one has any faith in the results of the calculation when it is performed on a process such as product development.
But, notionally, if we examine the principles of Little’s Law we can still see that the fundamental tenants still make sense, even if the calculation is too simple to model the complexity of the process. If we increase the rate at which we complete projects, we will reduce our typical or overall Lead Time. If we want to meet a Lead Time goal, we must increase our completion rate. That part still makes sense.
Invariably, in every case in my experience, increasing the production rate is exactly what business leaders chose and directed me to do. But there is another part of the equation that can be adjusted, and I strongly believe that it is the more powerful approach to improving Lead Time. What about the WIP?
Mathematically, we can improve Lead Time by reducing the WIP. Suppose we have 16 product development projects in the pipeline at a given time and, at that time, the average project duration (Lead Time) is 69 weeks. The completion rate is 0.23 projects per week, or 12 projects per year.
When we look at trying to improve the outcome, it becomes easy to look at that number of 12 projects per year completion rate. Additionally, the idea of completing 16 new products in the near future sounds really good, so why would we want to shrink that? We should try and increase that, right? So once again, we naturally focus on increasing our completion rate, and possibly our WIP too.
Let’s take a ½-step back. Let’s pick an arbitrary target for Lead Time, say an improvement of 25%. That would be a Lead Time of 52 weeks. Now, keep the same WIP and calculate the new completion rate. We get 0.31 projects per week, or 16 projects per year. Think about that. In order to meet our target, we must remove 17.25 weeks from the process, on average.
How easy would it be for you and your business team to remove 17 weeks from your product development process? I’ve helped to remove as much as 16 weeks, and it took a dedicated team with sector president support about 9-months of project time to get to the point where we were collecting data to prove our estimates.
Another process improvement expert of my acquaintance claims to have, over the course of several years, reduced the product development Lead Time at one business from 21 months to less than 4 months. I have no reason to doubt him and I tip my hat.
Don’t get me wrong, it is a very worthwhile effort and the pay-off is well worth it, but I firmly believe that there is a better way to give our product development an immediate boost. If I haven’t lost your attention with the math above, then here is where I propose an easier way. If I did lose your attention, then please pull the monitor a little closer and follow the next few paragraphs.
When we battled against change resistance, waste, and paradigms to remove many weeks of waste from the product development system, we, and I mean we-improvement-teams in every case of my experience, observed the same critical phenomenon and cause of waste. Each project in the WIP shared resources with other projects. This is very important.
First, it was always the most difficult problem to solve and the one that often was never solved. Second, it has a very important implication about a relationship between WIP and average completion rate. They are not independent! The manipulation of one will not necessarily translate to a simple proportional change in the other.
Logically, it works like this; no math involved. Multitasking is a myth. In Lean terms, multitasking is a by-product of waiting (one of the classic wastes). When we are waiting for some information or materiel to continue our work, we naturally pick up other work to do in the mean time. The problem is, that when the information or materiel shows up, we don’t necessarily switch gears right away, the work waits for us to return to it, and the waste perpetuates.
When we consciously assign the same engineers to more than one project, we have forced the waiting game upon all of the projects. There are bottlenecks also. Test labs are good places for projects to pile up. So are commonly used suppliers or piece-part manufacturers.
When we shove one more project into the pipe and ask our engineers, sourcing and purchasing professionals, project managers, suppliers, test labs, and other resources to support it in addition to the others, we force everyone involved into a situation where they end up waiting for someone else; the more sharing, the more waiting.
Of course while everyone is waiting they are working on one of the other projects so everything cancels out, right? Not a chance! Rather than share a book worth of observations to support my assertion, let me simply ask a question. What are the chances that more than one project or set of resources are waiting while one resource is working on one project? It really is more work waiting, not more work getting done.
Back to Little’s Law. Suppose, that instead of trying to do more projects faster, we instead try to do fewer projects with the same effort. We’ll keep the same completion rate of 0.23 projects per week with which we began, but instead of doing 16 projects, we’ll only do 12. Our Lead Time becomes 52 weeks instead of 69.
If you are following along, then you are saying the same thing that most executives do if given the same example, “Big Deal. Either way we complete 12 projects in a year. Where’s the improvement?” The improvement comes in when we look at the monetary value of the projects.
If the 12 projects are the 12 most valuable projects, and we deliver them 17 weeks faster on average, we’ll make more revenue and/or profit than delivering 16 projects slower. Forgive me while I ignore ramp-up periods and other complexities to make my example simpler.
Suppose the top twelve projects average $140,000 in added revenues per week for each project. Since the last 4 projects lower the average value, the average for the 16 projects is $120,000 per week in added revenues. Let’s run these rates over three years and calculate the totals.
(0.23 projects/week) X ($140,000/project) = $32,200/week for 156 weeks = $5.02-million
(0.23projects/week) X ($120,000/project) = $27,600/week for 156 weeks = $4.31-million
That’s a difference of $717,000 over three years or $239,200 per year. That’s a pretty big number and a reasonable example of how less can be more. I know that there are complexities that I have ignored, and I promise to discuss some of them, but first I want to return to a point I made above.
Recall that the resources for all of these projects are shared and that they are often waiting on each other. By definition, Lead Time is Wait Time, plus Process Time. What happens when the same set of resources is shared less and waits less? Lead Time and/or completion rate improve because wait time is reduced.
I said that they are not independent and that the relationship would not be proportional. Here is what I mean. By reducing the WIP, we also, coincidentally, improve the completion rate. Of course I have no magic number, but hypothetically speaking the real outcome of our example might be more like this.
When we reduce the number of projects from 16 to 12, instead of keeping the completion rate at 0.23 as we proposed, it might coincidentally improve to 0.29 projects per week, just to pick a number, because we have eliminated some waste or drain on the process by eliminating “multitask” commitments. (work in a production process typically does not experience the multi-task phenomenon)
(0.29 projects/week) X ($140,000/project) = $40,600/week for 156 weeks = $6.33-million
Now the improvement might be as much as $676,000 a year in added revenues. Add in some of that waste elimination to incrementally improve completion rates, that everyone wanted to do from the start, and it will be no time before this example business is making an extra $1-million a year. That’s much more than a 25% improvement.
The reason the improvement is so great is that the value of the projects getting completed is improved. Lower valued projects don’t steal resources from higher valued projects. Of course this assumes that we can keep inserting high-value projects into the pipe and we are disciplined enough to not do the lower valued projects at all.
Truth be told, if this were a stable production process with dozens or thousands of deliverables produced in the time unit used, the calculation would provide a very reasonable estimate of the entitlement that metering the WIP could produce. However, as we all know, more people on a development project don’t necessarily make it happen faster. There is a limit.
I believe that Little’s Law applies to product development or service delivery in principle, but the calculation will be in error. The point that I wanted to make with the calculation is to show that product development can be entitled to better performance and profits when resources are better dedicated and managed, and shared less. Determining a realistic value of that entitlement takes more thought and consideration than the simple equation I used.
Now for some of the other complexities and challenges that I haven’t discussed, but promised I would. First, in order to keep the discussion to a reasonable length and the math simple, I only looked at averages. The only way to assess what the proposal of doing fewer, most-valuable projects might mean to your business is to look at your actual project pipeline and project queue. I recommend accounting for the distribution of your portfolio and project variation, not just the average values.
Also, what if the most valuable projects are also all long-lead projects and by selecting them the average Lead Time goes up? My examples didn’t address this. Please see my comment above. Take a look at your actual project portfolio. I find that assessing priority based on revenue, or better, profits, in a 3-year or 5-year window, which includes development time, is a better method than just assessing first-year revenues. This gives priority to high-profit projects that also are quick to complete.
What about project diversity? What if different markets or customer demographics must be satisfied with a variety of projects? What if the most-valued few projects doesn’t cover all of those needs? I’m a big fan of turning problems into opportunities. In this case the challenge becomes dreaming up more valuable projects in each area so they can make the cut.
When that utopian ideal fails, we must simply insert some human judgment on the decision process. The challenge is to somehow prevent the just-one-more habit from re-surfacing and clogging up the pipeline with too many projects. Use a math model to help you see when you have slowed down profits by adding one too many projects. Even an imperfect model can stop the just-one-more phenomenon.
What if the next project to leave the pipe is small and the next project to enter is big, and the resources made available by the exiting project aren’t enough for the entering one? Actually, this is one of many resource management problems that get brought up when we start proposing a controlled quantity or man-power-volume of projects in the project pipeline.
Think about it. These challenges exist whether we are stuffing the pipe or metering it. Try not to let these challenges roadblock your consideration of the proposal to meter the pipe. There are a great many ways to address resource management, from dedicated tracks for various project sizes and types, to using time that resources are waiting for the purposes of creative innovation and research and development.
I’ll offer my favorite suggestion. Dedicate teams to only a single project and let no member of the team work on more than one at a time. We all hate to wait. Waiting personnel will either invest their free time trying to solve the problem of why they are waiting, which could result in process improvement if they are skilled in such things, or in greater teamwork and collaboration as team members start trying to help each other speed things up.
Alternatively, some team members might use the wait time to work on new project ideas or research and development tasks, so long as they are disciplined to drop those activities the moment the project work returns to their lap. This suggestion requires a great deal of courage to attempt. I have yet to meet the business team willing to try it.
We can find countless holes in using the Little’s Law calculations to justify a proposal to reduce the number of projects in the pipeline. It’s just too simple a calculation to model the complexity of a process where every piece of work is unique and different. If we use actual information from our real portfolios, and do some what-if scenarios, however, we can address that complexity to some degree and make some compelling arguments.
Even when we do, it’s still a hard sell. No one with a product management or marketing responsibility wants to sign up for a method that could eliminate his or her bid to put a favorite project in the pipeline. Also, presenting the proposal can be a delicate challenge.
It doesn’t sell well when we say to the executive staff, “This year we initiated 16 projects and added $4.3-million to our revenue stream. Next year we want to reduce that number to 12 projects in hopes of increasing our added revenue.” Everyone wants and expects more, not less and that kind of delivery sets the alarm off before we can even get the third sentence out or show a projection on the next slide.
Instead we must explain that we want to increase the rate at which our highest-potential projects are completed in order accelerate an increase in revenue and profit. Push better resource management, not fewer projects. Of course at some point it will come up and we need to explain it. Begin with the final numbers and work backwards.
I have worked with some teams that did make good progress toward understanding the importance of pipeline control. We generated better tools of assessing the payout value of projects and used derivatives of the Little’s Law calculations to help gauge how many of what projects our pipeline could handle without becoming “constipated.”
Our models weren’t perfect, and the efforts to develop understanding and exercise discipline were significant. It became an on-going process improvement and re-design effort, but changes did start to take place and things did become more efficient. We even created more opportunity for innovation and R&D.
Bottom line: don’t get too hung up on calculating the optimal WIP number in order to hit your Lead Time target. The calculation can give you some idea of where to start, but your human judgment and experience will need to rule the decision. It’s not the calculation that will save you; it’s the fundamental principle that a project pipeline can be clogged with too many projects and that doing fewer, more valuable projects faster is more profitable than doing more projects slower, that will guide you to a more effective product development, or service rendering, system.
Our executives generally like firm predictions of performance with their numbers. These are hard to come by, in the case of product development, because of the complexity and guesswork. Take your best shot, address the arguments and concerns proactively, and affirm that even if the prediction is in error, the entitlement to improvement is real. It will take courage and discipline to do it. A few have succeeded. Inspire courage and you can make a huge difference for your business.
Take a good look at your own pipeline and portfolio. Is there a project that could stand to get out of the way? Are your engineers and other resources assigned to multiple projects at once? Is there a significant amount of waiting that goes on in your product development process? If so, consider that reducing the number of active projects could substantially improve your Lead Times and completion rates and get you your revenues and profits faster.
Stay wise, friends.
