I read Factory Physics (the Managers' Guide version) a year or so ago, and I haven't blogged about it - partially because writing about it might require repeating everything they describe in the book. And then it would be the same as telling you to go read it yourself.
Lean-Driven Product Innovation that describes his story in more detail.) What he describes is a lot of what we do with Theory of Constraints concepts applied in product development (and project management) arenas too. Of course, I found it humorous that Majerus struggled to apply the Lean concepts as described in many of the books out there because they didn't seem like the manufacturing ideas would apply to product development, but then the ideas in a book called Factory Physics made the connection. Here are some highlights from the blog post (and from the book)...
A familiar quote: "computerizing a bad process creates an expensive bad process." Many organizations are fascinated with technology, deciding that this is the solution without fully understanding the problem. At best this gives you "expensive bad processes", at worst it gives you lots of expensive tools and software that no one uses. I had a project with a manufacturer where they had bought a robot, but it was so outside their normal mode of operation that it sat idle.
They used Little's Law by controlling the amount of work released and managed to increase the amount of work completed. This is a baseline concept in applying TOC in manufacturing and projects: release work at the rate that the constraint can handle. And when you don't know the constraint (because it is "everywhere"), it's almost always the case that the system is flooded with too much work.
A concept I often tie to Little's Law is the idea that as utilization nears 100%, the cycle time goes through the roof (to infinity). Turns out this has a name: Kingman's formula. The reason that we can't plan to book to 100% is that variability in the system prevent that from ever being possible - even small variations that you see in repeat manufacturing create this problem. The kind of variation we see in project execution means that "utilization" above 80% is probably going to kill the system overall.
And, finally, the idea of variability and managing in a world where variability and uncertainty are facts of life. While reducing variability helps, it cannot be removed entirely. We must manage in spite of variability. Majerus describes using simulations, instead of trying to teach people formulas, and I find similar success with simulations and "games" that bring out the concepts behind the equations.
