Archive for the ‘Execution’ Category

Agile Hardware Development

Thursday, March 3rd, 2011

I presented a session about this at Mile High Agile 2011 in Denver on April 7.

The agile movement is proving the value of development agility for software products.  Although you can’t apply Agile practices verbatim to other kinds of products, you can translate the principles to make development for any kind of product more competitive in innovative, dynamic markets.

Agile software developers have learned that the traditional waterfall development process (the software version of phase-gate) has become ineffective.  As a recent article shows, even large, complex software projects work better with Agile practices.  (Visions magazine, October 2009, pages 13-15)

But if you’re developing products outside the software domain, you have to translate Agile principals before you can apply them to, say, an electronic hardware project.

The first step is to break free from the Orthodoxy of the Plan.  I think this orthodoxy dates back to the time of the Pharos, but anyway, it holds that the only way to avoid the costly waste of mid project changes is to plan thoroughly and freeze the plan before starting development.

But if markets are changing faster that your development cycle, freezing the plan keeps you from learning and adapting at market speed.  The trick to getting around this is to keep design options open and take steps to reduce the cost of changes that are likely to occur later in the project.

There’s a copy of the presentation on my web site here.

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.

Two Interesting Resources

Tuesday, December 7th, 2010

You might want to take a look at some online content from two interesting conferences I attended recently.

Pipeline 2010 was an online conference with some interesting sessions about managing product development. The archives should be available until early February.  You have to register (free) to see the archives.  Look under the Agenda tab to assess the seminars.

The 2010 Rocky Mountain ProductCamp was a PDMA event with several interesting sessions on product development and product management.  Look for the sessions I presented on

  • Adapting agile software principles to projects outside the software domain with Flexible Product Development.
  • Making projects predictable in an unpredictable world with Dynamic Resource Management, and
  • Building consensus on where to improve product development using some simple group tools.  Look for the title “So you Want to Improve Product Development.”  The session slides aren’t very descriptive, so use the contact me link in the right sidebar of this blog if you’d like to know more.

The Orthodoxy of the Plan

Friday, November 5th, 2010

The Orthodoxy of the Plan permeates product development:  Mid-project change is costly, and you have to freeze plans to keep the project on track.  But in dynamic environments, The Orthodoxy will increase costs.

An orthodoxy is a belief system so strongly entrenched that people who question it are considered heretics.  Think of Galileo saying the Earth moves around the Sun. Orthodoxies resist correction.  Disconfirming evidence can strengthen the belief rather than weakening it, as researchers studying American politics have found.

The Orthodoxy works when you’re developing products in a stable, slow-moving market, but these days, whose markets are stable?  In fast-changing environments, The Orthodoxy actually increases project disruptions.

Here’s an example.  You’re considering two design options, A and B (gear vs. belt drive, monochrome vs. color display etc.)  Both options have their merits, but in order to freeze the plan, you make the best decision based on available information, let’s say option A.

So far, so good.  But what if a competitor’s product launch resets customers’ expectations before your product launch?  You’re forced to redesign with option B, repeat testing, and probably correct other things that depended on option A.  Your schedule slips and expenses overrun your budget.

I’ve talked with many developers who say that the cost of a change like this is the cost of redesigning for option B, but that’s not the case – Option B was necessary.  The real cost of change is the time and expense you wasted developing option A. 

Heretical as it may seem, freezing the A/B decision increased the cost of change.  You pursued option A, but freezing plans didn’t eliminate the A/B uncertainty, only swept it under the rug.  You stopped gathering more market intelligence and sunk time and effort into option A.

It would have been better to postpone the A/B decision until you had more information.  That might have increased project cost, perhaps for prototypes or more customer visits, you would have bought insurance against a much more expensive change later.

In a dynamic market, you should deal explicitly with uncertainty, instead of following The Orthodoxy of the Plan and sweeping uncertainty under the rug.

For more information:

You can find information about Galileo all over the place.

“When Corrections Fail: the Persistence of Misperceptions” by Brendan Nyhan and Jason Reifler,,  is the study about how orthodoxies resist correction.

Flexible Product Development by Preston G. Smith, Josey-Bass 2007, Chapter 7 explains flexible decision making.

I offer a 2-day workshop on Flexible Product Development.  Contact me to learn more.

Keeping design options open reduces time to market.

Monday, October 11th, 2010

It seems like a paradox, but thorough product definition can delay market launch.  In innovative, dynamic markets, keeping some design options open for a time can speed time to market.

Traditional phase-gate thinking is that you have to freeze your product definition before you start development.  Flexible Product Development (FPD) is a new approach that advocates keeping some options open until later in the project.

How can flexible options reduce time to market?  In a fast-moving business environment, FPD eliminates the need to delay development until requirements become stable.  As an example, consider developing standards-driven products while the standards are evolving.

If you expect a product definition to be rock solid before you start development, you have to delay development until the standards are finalized.  If you could cost-effectively start development before requirements are frozen, you could beat competitors to market.

The usual motivation for freezing product definition before starting development is to prevent costly mid stream changes.  FPD takes a different approach–instead of trying to eliminate change, eliminate most of the cost of change by the way you design the product and plan the development.

If your product line would benefit from more flexibility to respond in dynamic markets, consider the benefits of Flexible Product Development.

Here are some FPD resources: