Lean Product Development
Mark Twain said ”it aint what you know that gets you into trouble but what you know for sure that justain’t so”. That being said, I believe the dominant paradigm for managing product development is completely wrong. It is my sincere belief that a newer paradigm for product development is about to evolve. It is thus, my intention to help accelerate this new school of thought, hence this article.
This approach has always been present in some form in development processes. However, discovering and repeating successful behaviour is not enough to create it large-scale. The underlying mechanisms need to be taken and put into action to make it work. I would like to make this as simple as possible, so let us begin with an illustration.
In product development, work is usually divided intophases separated by gates. Each phase must becomplete before another can begin. For instance, a full description or definition of product requirements must be submitted to the management before any other step is taken. However, this is not exactly what happens. Most times, the design is started before the full description is submitted or even more critical, understood. The management is usually unaware that the design process has begun and as a result, cannot interfere with the process. The truth is the management does not really take the time to find out details about each stage. Basically, they only want to be kept in the loop briefly when a new stage commences. Most developers prefer to keep quiet about the fact that they are farther along than they should be in order to avoid doing the work all over again when there is a need for revisions. This brings about a lack of communication that can lower the product’s quality. It might become another product altogether as a result of the fact that the developers failed to understand the complete product’s requirement as deemed correct by the management. If the first stage goes wrong, there is little that can go right to correct it in the following stages or phases.
The alternative school of thought I am trying to introduce has a lot of similarities to the methods of lean manufacturing and could be labelled as lean product development (LPD). However, there are several challenges affecting this new paradigm. These challenges force us to go far beyond the ideas of lean manufacturing, to do this; we must be more innovative and sensitive to the needs of the product consumers and process economics.
Today, product development has a tightly knit circleof tradition around it. The developers would rather not change certain procedures or the lack of them.They would prefer to run the show barely under management radar as illustrated above. It has become a system of sorts really difficult to break away from. Sometimes, tradition absolutely stinks as it can affect progression in the worst possible way.
If we combine the belief that efficiency is good, withblindness to queues, we will load our development process to a point where capacity can be properly utilized.
Let’s take another example; if we combine the belief that variability is bad with the failure to correctly quantify economics, we will be able to minimize variability by sacrificing otherunquanitified economic goals. This way, we will be able to create risk-averse development processes that will help us get it right the very first time.
Few developers know the cost of delays in the development process and this obviously has negative effects on processing cost. Developers must be well aware of how much delays cost the product owners in the long run. Tighter schedules should be created. This may seem a bit overboard but it is the only way to create a quality development process that is also completely professional and workable. We must be able to quantify the loss indirectly caused by unnecessary delays and get the right people to take responsibility for it. Few developers realize that queues are the single most important cause of poor product development performance. They cause development processes to have way too much Design-In-Process inventory, also known as DIPs.
Developers are quite unaware of DIPs and as such do not even know how to measure it. DIP inhibits innovation and increases cycle time. Increased cycle time makes any sort of innovation to occur really late that it is changed to imitation. The fact remains that if the cost of queues can be effectively quantified in terms of economics and made known to developers, then they would be motivated to measure and manage them.
Product developers do pay attention to efficiency but wrongly. They incorrectly try to maximizeefficiency. However, this is as a result of queue blindness and the failure to associate it with increased processing costs. The absence of clear economic thinking also leads to a profoundmisunderstanding of the role of variability in product development. In addition to deeply misunderstanding variability, today’s product developers have a really wrong idea about how to react to variability. They need to recognise that original plans are mostly based on noisy date, are mostly projections and subject to change when the real processing begins. This blindness towards queues and the focus on efficiencybrings about large batches.
Product developers do not measure batch size and as a result, cannot manage them. Today’s development cadence delivers information in large batches while a flow – based process delivers information in smallbatches. Cadence must be utilized in order to lower transaction costs and to make small batches more economically feasible.
For example, in many companies, manufacturingwant to receive a fully completed design from engineering. They tell engineering they do not want to see any drawings until they completely finishedwith the design. Once all drawings are ready, they are reviewed in one large batch. All 200 drawings may be reviewed on a single day because they can see the designs at once. However, these 200 drawings were not prepared in a single day. They may have been completed over a 10 week period. The first 20 drawings may have waited for 9 weeks to be reviewed. So, if an engineer makes a bad assumption in one of the first set of drawings (the first 20 for example), then it has to wait 9 or so weeks to be reviewed. If the 180 drawings were prepared based on the first 20 drawings, they have to be redone. This is an enormous waste of manpower, time and mental energy. This would have been easily prevented if the review had been broken up into batches along with the number of drawings. The first set; most probably the most critical, should be reviewed first after preparation, and then, a scheduled set of reviews for the other drawings. This way, time, energy and cadence are properly utilised. Cadence and synchronization should be seen as the powerful tools that they are.
Most companies manage timelines instead of queues, taking them even farther from an effective solution.We must note that misunderstanding variability is dangerous in the repetitive world of manufacturing. There are several products that do not understand schedules. Details about them need to be perfected and this should not be rushed. Even worse, when performance is incentized, the variance becomes much more as people struggle tm meet deadlines in other to earn the incentives offered. Needless to say, this is truly bad for business and the consumers. The more we increase planning detail and the harder we try to incentize performance, the worse our problem becomes. However, when flow is emphasized, we get to focus on queues rather than timelines. They are a far better control variable than cycle time because queues are key indicators of future cycle – time problems. Controlling queue size gives us control over timelines.
The WIP Constrain is a very powerful way of controlling queues however it is a technique virtually absent in today’s development processes. This technique should be looked into and adopted for a high efficiency rate and process control. In pursuit of efficiency, our current orthodoxy accepts inflexibility in return for efficiency. What happens when this inflexibility encounters variability? We get delays and this reduces performance and sometimes even quality. As earlier explained variability reduction is simply not the answer. We can reduce variability directly or build buffers and reserves that will help to mask the variability.
There are many systems used to control flow in today’s development process. Unfortunately, none of them is based on economics. They place the same demands on resources and have the same cost of delay. These two conditions are hardly ever present in product development. Today’s product development has a centralised system. Product developers often avoid decentralisation and this can also have pitfalls.
One way to solve the limitations of this “system” is economically-based decision making. Another is by taking into consideration the importance of queues. Even a basic understanding of queuing will dramatically change perspective on product development. It should also be recognised thatvariability is not always bad and its reduction should not be the focus.
Batch size must be reduced. By recognizing that queues are the problem, we will be led to examine methods for reducing queues effectively.
WIP constraints are also an effective and powerful way of gaining control over cycle time in the presence of variability.
Cadence, Synchronisation and flow control should be explored. The importance of fast feedback loops should also be emphasized and control should be decentralised to avoid problem expansion and the loss of opportunities.
Lean manufacturing provides us with a mature set of ideas for managing certain types of flow. We will learn that popular ideas like “the customer is the ultimate judge of value-added” actually make little sense with an understanding of economics. The intersection of statistics and economics will help product developers understand the economics ofvariability. As we have seen from the above points, this is very important and absolutely necessary. Using the internet for flow management should also be explored. Computer operating systems are another rich source of ideas that can help and should not be overlooked.
Finally, we should draw on ideas from the military for manoeuvre warfare and learn advanced ideas on how to combine decentralized control and alignment of effort. Remember uncertainty cannot be removed from development processes (like it cannot be removed from warfare) and make preparations to manage them before they evolve into full blown, time consuming and resource wasting problems.
I believe that a powerful set of principles can be used to solve an incredibly wide range of problems. Let’s find out what truly works and stick to it. Further delay is not an option.