Developing Products in Half the Time
By Preston G. Smith, Donald G. Reinertsen (1997)
We are reminder of the story if the wise man who was approached by a youth who asked him how king it would take to walk to Athens. The wise man simply replied, “Get going!” The youth, disappointed, concludes that he would not get a straight answer and began walking in the direction of Athens. After the youth had taken about 20 steps, the wise man called out, “About four hours!” The youth turned and said, “Why didn’t you tell me that when I asked before?”
“First I had to see how fast you walked,” said the wise man.
Faster isn’t always better (e.g., higher quality or lower costs may derive a higher benefit) although it means more flexibility.
💡 Do the math. Create a baseline model, starting with these key values:
- Launch date
- Unit cost
- Development cost
Then, create some variations:
- Development cost overrun
- Unit cost overrun
- Performance shortfall
- Schedule delay
Then use these numbers to help support decisions/discussions. E.g.,
- A 5% expense overrun costs $200,000
- A 1-month delay costs $400,000
☝️ Conclusion: let’s take the hit on the costs overrun and avoid the delay
The rest is fairly lean/agile/servant-leader/etc: incremental dev, staying flexible, changing plans, contact with customers, not freezing specs, small teams, team cohesion, focus, generalists, involving the whole team from the beginning, removing critical paths, queue management, continual improvement…
💡 Great questions for everyone to be aware of all the time:
- What’s on the critical path right now?
- What’s the next major difficulty?
- Are you getting enough support to get your work done?
- What’s getting in the way if success?
- What would help us do better next time?
Let people fail:
Nothing saps innovative more than someone’s second guessing the decisions made. This is doubly true when that person correctly spots mistakes. Second guessing must be controlled, and the team must be supported so that it will develop its own new operating style and the skills that go with it.
A Native American proverb says that good judgment comes from experience, and experience comes from bad judgment.
💡 Projects should deliver two outcomes: the product, and learning about the process.