Reducing lead time is often important for the success of a company. This last out of four posts looks a bit more in detail at the reduction in lead time during product development. This is especially important for make-to-order production, but also for the introduction of new products into the market. Let’s have a look.
Especially for make-to-order, but also for newly introduced make-to-stock products, there are aspects outside of manufacturing that influence the lead time or the time to market, respectively. Most often this is the development of the product, but it can also include logistics, quality control, or other departments.
Let’s look at product development. Here, too, the reduction of inventory (jobs/projects), fluctuations, and utilization and the improvement of the throughput can improve your lead time. Since product development is always individual products “to order,” the lot size is automatically one. Hence, a reduction in lot size is not possible here. On the other hand, with product development we have the possibility to overlap different phases of development, commonly known as concurrent engineering or simultaneous engineering. Let’s have a look at the factors for development in more detail.
In manufacturing, reducing the inventory reduces the lead time proportionally as determined by Little’s Law. The equivalent in product development is reducing the number of jobs or projects. However, especially for a larger number of projects, the reduction in lead time is over-proportional to the reduction in the number of projects. Developers usually need to coordinate with other developers for development. Mechanical engineers, electrical engineers, and programmers are often involved in the same project. Depending on your product, you may also need chemists, biologists, mathematicians, and others to participate in the development.
These need to coordinate, which takes time. The more projects they have, the more time goes for coordination. I have seen departments where developers were in charge of ten projects. After all the coordination meetings there was almost no time left for actual development. The developers subsequently focused on one or two projects, and ditched the rest (although they communicated it more diplomatically to their management). Since eight out of ten projects were not worked on at all, the lead time went through the roof.
There is some academic research on what a good number of projects is for one person. It seems that two to three projects can be handled simultaneously without ill effects. A single project may be faster for this project, but with a lower utilization of the developer. In development projects, you often have to wait for other input. If you have only a single project, you often actually have to wait for such an input before you can continue. Having two to three projects allows the developer to use this time on other projects.
Similar to manufacturing, fluctuations are also bad in development. Also similar to manufacturing, they are not easy to reduce. Yet, a reduction in fluctuation will reduce the swings for developers from being overworked to underutilized … although in the latter case, they will invent some work so as not to look idle to management.
Reducing utilization was an important factor in manufacturing. It is still important in development, although to a lesser degree. For one thing, how do you actually measure the utilization of a developer? Time at work? Forget it. Number of documents produced? Oh, please! Number of meetings attended? No way! I don’t know of any even approximately valid method to measure the utilization of developers. Nevertheless, you should not run your development department at full speed all the time. Delays will pile up, and so does the lead time.
Humans can and will work at different speeds as needed. If the situation is urgent, workers can (and often but not always will) put in an extra effort. If the situation is relaxed, so is the working style. But be aware that if the situation is ALWAYS urgent, then “urgent” will soon be the new “relaxed”! So, please don’t put your developers into a pressure steam cooker, hoping to get more out of them. It won’t work, but your lead time will turn sour.
As in manufacturing, improving the throughput does reduce the lead time. Also similarly, the primary goal of such an activity is usually the reduction in cost and the increase in capacity, with the reduction in lead time being a smaller side effect.
Nevertheless, it is a worthy goal. There are many ways you can improve the throughput. Make sure your developers have the right tools (computers, software, databases, etc.) to do their work. There are many modern software tools that promise to help with development, although you would have to decide if you believe these promises.
The bigger lever, however, often is the reduction of waste. Reduce the non-value added time. One major but often overlooked factor are interruptions. Getting a phone call cuts you out of your current thoughts, and it will take time to get back to the task at hand. A three-minute phone call can easily waste fifteen minutes of time. Some employees can turn off their phones in the morning to focus on work, and handle requests in the afternoon. Other departments forbid any meetings before 11:00AM to give a continuous block of working time. I personally always turn off my email notifications. If my head is wrapped up in a problem, and my monitor starts to blink an email symbol, then I lose my focus. Instead, I answer my emails after I wrap up my thoughts.
Another factor in eliminating waste is meetings … although this is a double-edged sword. I am sure you have had plenty of meetings where you felt like they were a waste of time. But on the other hand, you also surely had meetings that were very important and conveyed crucial information on the project. And the majority of meetings were probably a mix of both important and unimportant information. The trouble is in figuring out how many meetings you need, who should attend, and how they should be conducted to have a good ratio of useful to useless time. Too few meetings – or more accurately a lack of exchange of information – is not a good thing either.
My gut feeling tells me that there is often a tendency for too many and too-long meetings. This is because, for the manager who sets up the meeting, meetings are one of their most important management tools. A second factor is that often promotion is (subconsciously) based on visibility, and many employees believe (sometimes rightfully so) that talking in a meeting increases the chances for promotion.
There are many tricks for conducting efficient meetings, from having the meeting not sitting but standing, to a strict time schedule limiting the time on the different topics, etc. Explaining them all would exceed the scope of this article, but there is plenty of literature available.
Development also has options to reduce the lead time that production does not have, namely concurrent engineering (also known as simultaneous engineering). In manufacturing, the part can be only in one process at a time. In development, multiple people can work on the same project. In concurrent engineering, the different stages of the development project overlap. You start with the next phase before the previous phase has ended. You start the design before the requirements are set in stone, the implementation before the design is finished, the verification before the implementation is completed, and so on. This saves time, but of course at the cost of extra work due to changes in a previous process requiring a re-do of some parts of the next process. It is more effort, but often the reduced time is worth the cost. Details and guidelines for concurrent engineering can be found from many sources, so I won’t go into detail here too.
This concludes my short series of posts on how to reduce the lead time. I hope it was helpful to you. Now, go out, reduce your lead time, and organize your industry!
- Reducing Lead Time 1 – Inventory
- Reducing Lead Time 2 – Fluctuations and Utilization
- Reducing Lead Time 3 – Throughput and Lot Size
- Reducing Lead Time 4 – Development
P.S.: This series of posts is based on an inspiration by Rajan Suri, and also chapter 7 of his book Quick Response Manufacturing and chapter 3 from his book It’s About Time.
- Suri, Rajan. It’s About Time: The Competitive Advantage of Quick Response Manufacturing. 1 edition. New York: Productivity Press, 2010. ISBN 978-1-4398-0595-4.
- Suri, Rajan. Quick Response Manufacturing: A Companywide Approach to Reducing Lead Times. Portland, Oregon, USA: Taylor & Francis Inc, 1998. ISBN 978-1-56327-201-1.
3 thoughts on “Reducing Lead Time 4 – Development”
As always very good!
I think of the Covid vaccine development. Would this be a good project to baseline with your improving throughput recommendations?
Hi Charles, I think the COVID vaccine is already a good example. The development of western COVID vaccines was extremely fast, and they fast-tracked all the paperwork. Important: They did not fast-track the actual testing, where they vaccinated volunteers to check for side effects and effectiveness of the vaccine. This was different with some other countrie’s vaccine, e.g. Russia’s Sputnik vaccine was tested very little. I do trust the western vaccines (Moderna, BioNTech/Pfizer,…) and will get vaccinated as soon as it is my turn. I have no trust in the Russian or Chinese vaccine.