Joe Dager's Business901 podcast this week has an interesting interview on Creating Flow with Don Reinertsen. Reinertsen is the author of the well-regarded Managing the Design Factory and of the newer The Principles of Product Development Flow. While I enjoyed the entire podcast, the thing that piqued my interest in particular was around using these ideas in managing flow. Real execution advice.
A lot of Reinertsen's ideas - at least in this discussion - come from a Lean mindset. One of the big ideas behind Lean is to create flow. This works on the manufacturing floor, and Reinertsen is doing some interesting things with applying them to new product development (and project management in general). There are a lot of linkages between Lean and Theory of Constraints, so many of the ideas and comments here are quite familiar to me as well.
- 7:00 work in process and queues. Queues are the root cause of problems in product development. We have so much work running at the same time that it creates inefficiencies. Interesting that people still believe "the sooner we get something started, the sooner it will finish" even given all our experience to the contrary.
- 7:50 large queues delay the feedback cycle. If it takes a long time to test or analyze or take some action that tells us how we are going, then it will take that much longer to improve a prospective project.
- 9:00 relay race analogy. Queues block the resource. If the the person receiving the baton isn't ready, it will kill anything the current runner did to accelerate the pace. We use this analogy in our discussions of what projects should be.
- 10:40 work product has to be visible. Ahah! Observable work. In many projects, the work product is information and hidden from view, as opposed to manufacturing where the work product is easily visible. The key in this point of the discussion is that people need to be able to SEE the load in each work center - or even for individual workers.
- 13:00 problems with batch size. This was a new conceptualization to me for projects. In manufacturing, a lot of queue time is spent waiting for a batch to be completed / start. If your batch size is 1000 units, the first unit off the machine has to wait for 999 more units before it moves to the next work center. And the last unit off the previous machine has to wait for 999 to run through the next machine. The more this can be reduced, the faster work flows through the shop. Reinertsen translates this into project management by looking at the hand offs between various steps within the project: does the ENTIRE task have to be done before the next one can commence? In stage-gate setups, this is exactly what happens: stage 1 must be complete and reviewed before anything in stage 2 can start. Similarly in test environments: do you need a final product before testing? or can you test components and parts as you go? The larger the batch size in any system, the longer are the queues - and the longer the overall project.
- 20:00 decentralized control. I am hearing elements of the idea of OODA (observe, orient, decide, act). People "in the trenches" must be given the tools and the initiative to take action. And they have to have the proper alignment with the overall system, so that they are most likely to take the correct actions. Make sure that the iterative process of product development
- 29:30 betting on horse races. Imagine betting on a horse race and placing those bets as the race develops, rather than putting all your money down at the beginning of the race. In product development (and projects), you learn as you go, so there has to be a mechanism to revise our confidence and priority of the project. Emphasize the winners. Get rid of losers as quickly as possible. Some interesting thoughts about portfolio management here. This is learning-by-doing.
- 33:00 relation to services. The big difference with services is that product doesn't get stuck into inventory. Otherwise, there are a lot of similarities. (I'd be a little worried about the cost discussion, but otherwise interesting stuff.)
- 36:25 variability. Innovation requires variation - eliminating variation ends up eliminating innovation. Processes must be designed to work WITH variability, not despite it.
- 39:30 obstacles. One aspect is the wrong focus: trying to understand what successful groups do, instead of why they are doing it. What problem are you trying to solve, rather than how you have decided to do that? Another obstacle is that people want to wait until there are "best practices," even though the current primitive practices work pretty well. A third obstacle is that people don't see that there are a lot of simple improvements that can be made without conducting big-bang implementations. The watch-out, of course, is that teams need to keep climbing up the tree as the low-hangers are eaten.
- 44:00 low-hanging fruit and sports. When the team is losing, it is hard to recruit new players. When the team is winning, players can't wait to join you. The same goes with getting early wins. Early wins generate excitement, which generates more interest. As long as you can keep this rolling, it's a good way to implement new ways of working.
Thanks, Joe and Don for the podcast!
[Photo: "South Africa, Pretoria: Flow" by Kool]