Developing Products in Half the Time

By Preston G. Smith, Donald G. Reinertsen (1997)

We are reminded of the story of the wise man who was approached by a youth who asked him how long it would take to walk to Athens. The wise man simply replied, “Get going!” The youth, disappointed, concluded 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.

My Notes

Faster isn’t always better (e.g., higher quality or lower costs may be preferred) although it speed means more flexibility.

💡 Do the math. Create a baseline model—include dev time and n years/months after launch, with estimates for each period:

Then, generate variations, e.g., development cost overrun, schedule delay, performance shortfall.

Use these numbers to help support decisions. E.g.,

☝️ Take the hit on the overrun and avoid the delay

The rest is fairly lean/agile/servant-leader/etc: incremental dev, staying flexible, changing plans, collaborating 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…

💡 Everyone to be aware of all the time:

💡 Projects should deliver two outcomes: the product, and learning about the process.

Let people fail:

Nothing saps innovation 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.