Archive for the ‘Commentary’ Category

Stage-Gate(r) Thinking Has Arthritis…

Wednesday, June 12th, 2013

…It hurts when you have to move fast.

In fact, this may be the reason why product innovation at big companies has declined steadily for the last few decades:  Traditional “best” practices are making innovation hurt.

Healthy, but not too fast

Healthy, but not too fast

How and when did this happen?  Well, back in the day, Stage-Gate(r) processes were developed to eliminate product development waste.  In those days, mid-project changes caused by poor planning were a major source of waste.  Without staging development tasks properly and without freezing requirements, developers would have to scrap design effort and loop back to repeat work they already thought was done.  Budgets soared and schedules slipped.

But then the ossification began.  In many companies, mid-project changes came to always be attributed to poor planning or sloppy execution: If the schedule slipped, plan the next project in more detail; if the project scope changed, enforce frozen requirements more rigidly.

In many companies today, Stage-Gate(r) thinking has ossified into “plan your work and work your plan,” and all mid-project change is tarred with the brush of waste.  This hobbles innovation.

By definition, innovation involves uncertainty and unknowns. The planning called for by Stage-Gate(r) thinking does not eliminate uncertainty, but merely papers it over.

The fallacy that a perfect plan eliminates uncertainty actually exacerbates the cost of change. When an early uncertainty surfaces later to require a change, the design will have internal dependencies that make the change propagate deep into the product, all requiring rework and re-testing.

Flexible Product Development provides fresh thinking that challenges Stage-
Gate(r) by taking a different view of mid-project change.  In innovative, turbulent markets, change is necessary not wasteful.  Rather than trying to plan uncertainty out, you identify major unknowns and take steps to resolve them before they threaten serious project disruption.  In the mean time, you design the product architecture and project structure to minimize the cost of mid-project changes.

To learn more about Flexible Product Development, see my white paper, or the Flexible Product Development web site.

(Stage-Gate is a registered trademark of Product Development Institute)

Are “best” planning practices keeping you in the slow lane?

Thursday, December 29th, 2011

Agile product development— already proven for software products— promises significant advantages for fast delivery of innovative products, but hardware developers have been slow to adopt agile principles.  In a recent article in PDMA’s Visions magazine, I explain that managers and developers may be clinging to outdated beliefs about project planning and development waste.

Agile software practices can’t be translated verbatim into hardware product development, but two schools of thought—Flexible Product Development  and Lean Product Development—offer ways to adapt agile principles to hardware development.

Agile hardware development calls for a new planning approach, one that conflicts with traditional beliefs about “best practices,” frozen plans and the cost of change.  These beliefs can be so deeply ingrained that companies are reluctant to adopt more agile practices.

Back in the day, markets were stable and incremental innovation was enough to get by, so freezing plans before starting development seemed like a good way to eliminate product development waste.  But for rapid innovation in emerging markets, rigid, frozen plans can create waste, rather than eliminating it. 

For example, a team developing a product for a new application environment may freeze the plan around a certain type of enclosure, only to discover late in the project that the enclosure they chose is not acceptable in the new environment.  At that point, the team must delay the schedule to design a new enclosure and rework other parts of the design to fit.

Freezing the enclosure decision too soon actually created waste in this situation, because not enough was known about the new application.  A more agile approach would have been to postpone the enclosure decision until better information was available, keeping design options open to prevent rework when the enclosure decision was finalized.

Both Flexible and Lean product development practices are based on keeping some decisions open until better or more current information is available.  The idea that making decisions too soon creates waste is such a departure from traditional planning practices that organizations must learn to question “best practices” before they can adopt more agile development methods.

For more details and some references about agile hardware development, take a look at the full article.

Dear John, Oh, how I hate to write.

Monday, May 2nd, 2011

It’s the classic breakup letter.  How would it look today for an engineering manager looking for a change after a long relationship with her phase-gate process?

Dear Phase-Gate, I hate to do this by email, but I can’t wait any longer.  We have to make some changes. 

It’s not you, it’s me.  You haven’t changed at all since we met, but my needs are different now. 

When we hooked up in the 90’s, my projects were a mess–requirements changing, schedules slipping, and expenses out of control.  Your project structure, thorough planning and gate reviews all seemed so right then.  Freezing plans before starting development seemed to eliminate mid-project changes and gave our managers predictable schedules and milestones to approve at gate meetings.

But in my world today, I need more space.  My most important opportunities are in innovative, fast-changing markets, where my engineers have to learn and adapt in the middle of a project.  What seemed like good management when we met is holding me back now.

The other day after a conference, I heard about Lean Product Development in the bar.  I admit I was interested, but the next morning I realized that Lean would be too big of a change for me. Ideas like “Principles of Flow” all seem too abstract for me to jump into right now.

Phase-Gate, I don’t want to start over and lose everything we’ve invested in our relationship.  Isn’t there a way you could change to accept mid-project learning and adaptation without punishing developers? 

I picked up a self help book by Preston Smith called “Flexible Product Development” with some great ideas about preparing for change instead of trying to eliminate it.  Would you be willing to read it?  We could stay together if you could learn to tolerate mid-project learning without a lot of disruption.

Do you think you could try some new ideas?

(The idea for this post came from a keynote speech by Jean Tabaka at the Mile High Agile conference.  She’s a great speaker; this video is worth a look.)

Four reasons not to build financial cost of delay models

Friday, April 15th, 2011

I had the chance to chat briefly with Ronica Roth, Agile Solutions Evangelist with Rally Software, about the barriers to developing financial cost of delay models.  Based on this and other conversations with colleagues and clients, I’ve compiled a list of reasons why you should NOT create these models for your company.

To begin, cost of delay models seek to quantify the financial impact of delaying or accelerating the market launch of a product.  For example, a model might say that a 3 month schedule slip will reduce new product revenue by 15%.

It’s tempting to think that models like this might improve project decisions, but watch out!  There are four reasons why you shouldn’t use this approach:

1.  Our developers’ brains are too full of technical knowledge to understand the financial impact of their decisions.  Instead, their decisions should be driven by managers’ sermons on the evils of delay.

In today’s fast-paced markets, decisions have to be made quickly at the lowest possible levels.  Models for cost of delay provide an important tool for developers to optimize day-to-day tradeoffs, without waiting for the next management review.  Good cost of delay models are an important part of delegating project decisions to the team.

2.  Our competitors don’t intimidate us!  We’re happy following them to market with four products, rather than beating them with three.

Cost of delay models help reduce development cycle time with better project staffing decisions.  It’s obvious that you don’t make money by starting projects; you make money by finishing them.  Yet most companies chronically overbook development capacity by starting too many projects, which ends up delaying all of them.  Knowing the cost of delay helps you decide to fully staff three projects, rather than thinly staffing four. 

3. Quantifying the cost of delay would destabilize our time-honored Loudest Voice process for resolving project contention at bottlenecks.

Bottlenecks crop up all the time in product development.  As an example, consider a QA function in an instrument company, where multiple projects may collide to create a bottleneck.  In many companies, the product champion with the loudest voice determines priorities.  Cost of delay models that are understood and supported by all stakeholders support rational priority decisions to optimize financial results.

4. Taking time to agree on good cost of delay models will get everybody talking and undermine the silo walls we’ve built stone by stone over the years.

In today’s competitive markets, functional silos can inhibit the good cross functional collaboration that’s critical to effective product development. In companies where there’s conflict about time to market, a cross-functional task force to agree on cost of delay models will be a first step toward better collaboration.

If, in spite of these cautions, you’re interested in building cost of delay models for your company, a good place to start is Chapter 2 of Developing Products in Half the Time, by Preston Smith and Don Reinertsen (John Wiley & Sons, 1998).  The book’s been around for a while, but the principles still apply.

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.

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.

About this Blog

Wednesday, September 8th, 2010

This blog is dedicated to improving product development at small and mid-sized firms.  I’ll cover topics of

  • Governance: top level management of the firm’s new product investment, including allocating resources to meet business goals, assessing product opportunities, and optimizing the development portfolio.
  • Execution:  tools and methods to meet business goals with a balanced approach to risk, development cost, and project predictability.
  • Finance: financial aspects of product development, including assessing financial returns, metrics to link new product execution with business goals, realistic project status reporting, and useful tools to guide day to day project decisions that create optimum business value.