Creating Lean Product Development from fundamentals

The lean concept in product management is borrowed from the manufacturing industry and is proudly used as the best way to develop products. But is it? Is there any mathematical proof or statistical evidence suggesting a process to be performed in a lean way is optimal? And also, have we correctly adapted the low variability manufacturing processes to high variability innovative processes of product development?

Principles of Product Development flow by Donald G. Reinertsen does precisely this. Donald decoded what it means to be a lean product development before lean was cool. The book gives deep insights and analysis on queues, batch sizes, variability, feedback, WIP, and the argument of centralization of the product development flow.

In this post, we will be exploring the concept of queues from a product development lens.

Now, let us answer the first question, what are queues in Product Development?

A queue is a set of jobs waiting to be moved from one team to another, from one employee to another, and waiting to be processed by the next unit. You can call them design-in-process (DIP) inventory. The common and significant problem is that teams rarely track this because it is invisible in the form of information.

Similarly, cycle time is the amount of time it takes for a project or feature from start to end.

Capacity is our resources, be it employees, licenses, money, etc.

Why should you track queues?

· Queues make it longer to reach the front of a large line, increasing product cycle time and delaying the feedback to reach the necessary personnel.

· Queues increase risk. As the cycle time goes up, the probability of customer preferences changing, competition changing goes up.

· As many items pile up in the queues, the variability of the entire development process goes up.

· Queues increase the overhead as more items we have in the queues; we need to keep track, report, and update them the longer they stay in the queues.

· Delayed feedback on flawed assumptions lowers the quality of the entire project

· Queues undermine motivation and initiative. When the next process is ready to use our work product within an hour, we feel a sense of urgency. On the other hand, when the next process has a 4-week queue, we feel there is little value in hurrying to finish our work. After all, our work product will simply wait in the queue.

How do we track queues?

· The easiest way is for each team/employee can use sticky notes, whiteboards to make queues transparent.

· Cumulative flow diagrams are also used to monitor queues

To understand the economics of queues, it is important to understand the cost of delay of a task in the queue.

Cost of delay: The cost of delay of a task on the critical path of a project is the cost of delay for the project. The cost of delay for a task that is not on the critical path is the cost of delay for the project times the probability that the task will get on the critical path

How do we have an optimum queue?

Although we mentioned that large queues are bad, it doesn’t mean we shouldn’t have queues. We should aim for the optimum queue size that gives us the best economic returns. The theoretical optimum queue can be achieved using

Queueing discipline

Queue cost is affected by the sequence in which we handle the jobs in the queue.

For example, if two jobs take the same amount of time, it is better to service the one with the highest delay cost first. If two jobs have the same cost of delay, it is better to process the shortest job first

· Two simple heuristics- Higher cost of delay job before the lower cost of delay job, and shorter job before a longer job.

· Is there a difference in the cost of delay of different jobs in the queue?

· Is there a difference in the time a job will block a resource?

· Is the average length of the queue large?

Capacity margin

Maintaining a capacity margin using the theoretical optimum capacity is a better weapon for fighting queues and maintain optimum queue size.

The Usual Suspects

Marketing is a common source of queueing at the front end of the development process

· Capacity is restricted because marketing resources tend to be spread across many opportunities with a low duty cycle on each activity.

· Demand is high because most organizations like to have a surplus of opportunities.

Analysis frequently has queues because of high capacity utilization and high variability.

· Capacity is scarce because resources are highly specialized and expensive.

· Although the demand is only limited, it is highly variable.

·It makes more economic sense to measure analysis groups on response time than efficiency.

Purchasing has queues for slightly different reasons. First, purchasing support for R&D is a small portion of their overall workload.

· It is common for purchasing to delay purchases to search for lower-cost sources of supply. While this makes sense for large manufacturing purchases, it is often the wrong performance measure for R&D support.

Prototyping

· These are specialized resources that service variable demand.

· They are commonly measured on efficiency and usually operate with limited excess capacity.

· Slow prototyping leads to delayed feedback

Testing is probably the single most common critical-path queue in most R&D organizations

· Its queues are caused by limited capacity and variable demand.

· Testing also has queues because tests are often done with larger batch sizes than are desirable.

Management reviews can also create queues

· Sequential phase-gate processes have inherently large batch transfers.

Almost any specialist can become a queue

· Specialists are scarce resources, and they are typically managed for efficiency.

· Furthermore, the pressure for efficiency leads to late involvement, which can raise costs even more.

Sticky note

Thanks to Mahendra B

Source: Principles of Product Development Flow by Donald G. Reinertsen.

Don’t forget to take the sticky note for your easy access in the future :)