Designs change. Deal with it!

April 8th, 2011

Study after study shows that while CEOs espouse the importance of innovation, their companies are turning away from significant new product innovations in favor of simple product renovations.  I think one important cause of this split personality is that companies don’t have a good way to deal with mid-project changes.  They avoid changes by favoring simple product extensions in stable, well-known markets.

These companies would be better off to realize that change is an inevitable part of product innovation–It’s just not realistic to expect project planners to know everything about an opportunity before they start development.

An article Preston Smith and I wrote about this dilemma was published in the March 17, 2011 issue of Machine Design.  You can read it on my website here.  We discuss how change is the rule, not the exception, for product innovation.

Three prevailing fallacies about the cost of project flexibility may be hobbling developers with outdated development processes that can’t deal with mid-project changes:

  • The first fallacy is that flexibility is prohibitively expensive.  It doesn’t have to be.  Recognizing and preparing for uncertainties eliminates most of the typical cost of change.
  • The second fallacy is that flexibility makes projects unpredictable.  In fact it’s rigid planning that drives up budget and schedule variance when change is forced on a project.
  • The third fallacy is that development flexibility delays a product’s market launch.  The article gives an example of how flexibility speeds market launch by allowing developers to start work before requirements are completely stable.

In short, project flexibility has gotten a bum rap.  You need to change and adapt to what you learn in the middle of a project, and new flexible development tools give developers what they need to deal effectively with changes.

Agile Hardware Development

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.

Doing More with Less? 4 Tips to Avoid Traffic Jams

February 15th, 2011

When times are tough, we all want to do more with less.  But, more of what?

A recent study reported in Visions magazine takes a look at the portfolio management pain points on the minds of product development stakeholders.  The results indicate to me that companies have trouble answering the question “more of what?”

The Problem

Four of the top five reported pain points (1) were:  

  • Too many projects for available resources
  • Decisions that go back and forth
  • No consistent and transparent way to measure projects’ value
  • Not being able to drive innovation fast enough.

It seems to me that all of these problems orbit a single central issue: companies are overbooking development resources.  Too many projects create a traffic jam on the new product expressway, so unimportant projects block progress on the important ones.  Slow market response can be a vicious cycle when all your resources are already tied up on existing projects, so you can’t grab a new opportunity until it, too, is delayed to market.

Back and forth decisions can also be the result of a project traffic jam, when priorities get set by politics and the product champion with the loudest voice gets priority until another voice gets louder.

And without a consistent and transparent value yardstick for projects, priorities only get more confused.

Four things you can do

If you want to do more with less, you have to clearly understand what “more” means and avoid creating a project traffic jam.  Here are some steps to take.

  1. Set up good metrics for project value that all stakeholders support. The best value metrics won’t help control traffic if some individuals can ignore metrics to push through their pet projects.  You usually need only a few metrics to make priorities clear, and too many metrics can be confusing.  You should have just enough metrics to cover the key value dimensions–financial return, strategic alignment, risk, and time horizon.
  2. Recognize that setting priorities doesn’t mean deciding what to do, it means deciding what not to do.  Steve Jobs is reported to have said the secret to innovation is “saying no to 1000 things.” (2)  Far too often, priority exercises conclude that some projects have top priority, but you still have to make progress on all the rest.  This is weak-kneed management.  You have to put some projects in the parking lot if you want the others to move quickly down the expressway.
  3. Set up models for the financial value of time to market. These tell you, for example, that a month’s delay on a particular project costs $50,000 in lifetime profit. Although these models can be straightforward (3), most companies I know don’t use them.  I believe that stakeholders at both the top and bottom management levels are afraid of them.  Top managers are afraid that developers will use them to justify spending increases to accelerate projects.  And developers themselves are afraid that the models will be used to punish them when schedules slip.  In fact, good financial models will lead to better decisions up and down the management chain.
  4. Finally, be realistic about resource planning–you don’t make money by starting projects, only by finishing them.  Give-and-take (sometimes, push-and-shove) negotiations don’t result in realistic resource plans.  Often the engineers don’t want to push back on plans until resources are stretched to the point of real pain, and other stakeholders are only too willing to let them schedule themselves into an undeliverable project.  As a solution, I know one company that has a question on the business case summary page, asking what the team could do with 30% more resources.  If that would result in a more competitive schedule or product, the portfolio committee shouldn’t start the project until the extra resources are available.

End notes

(1) Data in this post are from PDMA Visions, March 2010 pp13-18.  The full study report is available on the Planview website.

(2) The Steve Jobs quote is from “Innovate the Steve Jobs Way,” Carmine Gailo

 (3) A good reference for modeling the cost of delay is Developing Products in Half the Time, Preston G. Smith and Donald G. Reinertsen, John Wiley, Chapter 2

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

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”

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

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.

Avoid the Short Term Treadmill in R&D Investments

November 9th, 2010

Reading a recent article published by Harvard Business School, it occurred to me that executives allocating R&D funding could take a lesson from financial institutions’ experience in 2008.

One factor in accelerating the economic collapse was that financial firms had put themselves on a treadmill of short term debt.   The attraction of short term debt was low interest, but short term financing requires firms to “roll” their debt, continuously selling new bonds to repay maturing ones.  When the crisis hit, bond investors bolted for the exits, so firms could no longer sell new bonds, forcing them to sell assets to repay maturing debt.  Suddenly everyone was trying to sell assets at the same time, and asset prices plummeted, quickly pushing firms toward insolvency or government bailouts.

What does this have to do with new product strategy?  Executives balancing R&D funding among product lines should avoid putting their companies on a treadmill of short term returns.

The temptation to invest in short lifecycle products is that they can produce faster revenue growth for a given level of R&D productivity (new revenue per R&D dollar).  However, over-investment in short life products puts the new product program on a treadmill.  As revenue from one product generation matures and declines, it must quickly be replaced with even more new revenue to sustain growth:  A decline in R&D productivity can lead to a frightening drop in revenue growth.

Among other strategic considerations, executives should carefully consider the treadmill effect when allocating R&D funding among product lines and avoid the risks of over reliance on short term returns.

The Orthodoxy of the Plan

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.

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:

About this Blog

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.