Archive for January, 2011

Do it wrong or do it over: 11th-hour project crises

Thursday, January 13th, 2011

In an article in the December 2010 issue of PDMA’s Visions magazine, Preston Smith and I talk about how preparing for change helps project leaders avoid costly 11-th hour crises. 

The mantra “do it right or do it over” encourages developers to eliminate changes with thorough planning.  But in dynamic innovative markets, relying on upfront planning to eliminate mid-project changes often leads to 11th-hour project crises. When customers change their minds or innovation works out differently than you thought, you’re stuck with the dilemma to do it wrong or do it over.  You either stick to the plan and launch a product that misses the market or change the plan and suffer costly rework and schedule delay. 

Even with the best of plans, mid-project learning may be unavoidable.  Instead of trying to eliminate change, Flexible Product Development seeks to reduce the cost of change by preparing for it.   You eliminate the dilemma because changes incur little rework or schedule delay.

Do you deal frequently with the do-it-wrong-or-do-it-over dilemma?  Look carefully–the symptoms may not show up as mid-project changes.  Project managers in plan-driven organizations may refuse to make a worthy change, but the impact only shows up later in a disappointing market launch.

For more information:

Preston G. Smith and John S. Farnbach, “Avoid costly 11th-hour project dilemmas by preparing for change,” Visions XXIV No. 4 (December, 2010): 24-27.  (Available on my web site here.)

You can read more about Flexible Product Development here, or on Preston Smith’s website.  (Preston coined the phrase “do it wrong or do it over.”)

The Fly on the Window and “Best Practices”

Thursday, January 6th, 2011

A colleague, Gary Lundquist of Market Engineering, has a great analogy for understanding barriers to improvement.

Imagine a fly on a sunny window.  The fly knows where it wants to go, but spends a lot of energy banging its head on the glass without ever getting there.  The problem is that the fly doesn’t understand the barrier it’s facing.  Flying feverishly toward the light works for other flies in other situations, but not for this fly.

Some product development organizations (not yours, I’m sure) act like the fly on the window.  Managers seeking improvements feverishly try solutions that worked for other managers at other companies, without making much real progress.  They call these solutions “best practices.”  

Best practices may work for someone else, but are they best for you?  The first step to improving product development is an honest diagnosis of the barriers that you are facing currently.  This is where a good consultant can be critical to getting you off the window.  A consultant can perform an impartial diagnosis of your barriers, and then work with you to explore solutions and design an improvement program that’s tailored to your specific situation and company culture.

Here’s an example:  At a semiconductor company, a newly hired executive from a strong command and control culture wanted to improve schedule performance.  Based on past experience, he raised himself to his full height and pronounced that henceforth engineers would meet their schedules or face serious consequences. 

Schedule performance did improve, but other problems cropped up.  Expensive post-release design changes increased when developers cut corners to meet deadlines.  Time to launch increased as developers padded schedules.  Throughout this activity, real new product results declined as the fly bounced around on the window.

The manager’s initial “solution” was based on what worked at another company–Increasing schedule pressure only works in the unlikely case that engineers don’t understand the importance of schedules.  A diagnosis of performance barriers might have shown that resources were being spread too thinly across too many projects.  Or the company’s development processes may have been too cumbersome to keep up with increasingly dynamic markets.

Addressing the real barriers would have provided real improvement sooner than applying “best practices” from another company.

My point here is that to avoid acting like a fly on a window, don’t start an improvement initiative without first understanding your performance barriers.  They won’t likely be the same as another company’s, and what worked at that company probably won’t be best for you.