Use Flexibility to Control Risk

October 22nd, 2013

(I’m saying that traditional phase-gate processes don’t eliminate waste in turbulent markets; they actually increase risk.  Do you agree? Disagree?  Post a comment and join the discussion!)

The surprising thing is that, in turbulent markets, “best practice” phase-gate development processes actually increase risk and waste: External factors force change on your project before you can complete it, and frozen plans increase the cost of change.

The challenge and the solution:  Your challenge as a product developer is that your biggest opportunities lie in these turbulent markets.  If you can control risk and the waste that goes with it, you can beat your competitors to these choice opportunities.

The solution is to change your dogmas about controlling waste with phase-gate processes.  Preston G. Smith has pioneered new thinking about product development methods for fast changing markets.

Flexible Product Development (FPD), sometimes called “agile hardware development,” translates proven agile software principles for developing products outside of the software domain.  Instead of freezing requirements and plans based on assumptions and preliminary information, you keep key design options open and structure the project to reduce the cost of mid-project changes.

Why is FPD important?  In turbulent markets, frozen plans don’t eliminate uncertainty, they just paper it over.  When customers’ needs change, the frozen requirements are embedded so thoroughly into your design that it is very expensive to make changes.  Paradoxically, by trying to eliminate changes, you actually exacerbate risk by increasing the cost of change.

FPD provides fresh thinking about risk and change in turbulent markets. Surprisingly, the key to reducing risk and waste is to keep design options open as long as you can so that you have the latitude to respond quickly to market changes.

But open design options needn’t create excessive cost.   FPD also includes tools to mitigate project disruption by anticipating change and accelerating learning to close options in a timely way.

Is FPD right for you?  Costly mid-project changes can be caused either by market turbulence or by poor planning.  What makes it tricky to tell the difference is that in companies with a deeply ingrained phase-gate mentality, all mid-project changes are attributed to poor planning or sloppy execution.

Instead, explore the cause of the change.  Did a customer change his mind after your project started?  Were changes driven by customers learning more about their application while you were developing the solution?  Was the change forced by your competitor offering a new solution?  Any of these situations indicates that you’d benefit from a more flexible approach.

Another key symptom of the need for flexibility is hard to see because project post-mortems will never spot it.  This is the risk of sticking to a plan that should have been changed.  When the market target moves but developers fail to adapt, developers get kudos for meeting the plan but the product doesn’t meet its profit goals.

FPD resources:  If you think you might need more development flexibility to meet the challenges of turbulent markets, here are some resources to look into.

I have a brief explanation of FPD on the Silver Streak Partners web site at is a website devoted to FPD that I maintain after inheriting it from Preston.

And of course, Preston’s book, Flexible Product Development, is available on Amazon.

Stage-Gate(r) Thinking Has Arthritis…

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)

Eliminate Waste in the Front End of Innovation

January 22nd, 2013

The front end of innovation (FEI), where researchers explore innovative new product concepts, is crucial to feeding a company’s entire product development effort with profitable new opportunities. Yet despite its importance, researchers working in the FEI often encounter situations where their effort is wasted.  Contrary to common wisdom, the waste is caused by the same processes (such as Stage-Gate(r)) that reduce waste later in the product development.

In a recent paper published in Food Technology, Dr. Carla Kuesten and I look at typical examples of waste in consumer product research and explain an exploratory process designed to avoid such waste. In stark contrast to sequential processes, the exploratory process is based on loose planning, iterations and loop-backs.  Although the paper deals specifically with examples from consumer products, the ideas can be applied to any discipline.

Kuesten-Farnbach iterations

An exploratory Process

Sequential development processes seek to eliminate waste by thoroughly planning a project before spending serious money on it.  That may work when the project doesn’t involve innovation, but it creates waste in the FEI because researchers can’t anticipate where they will make critical discoveries. A critical discovery in a later stage will force researchers to re-do previous work and delay the schedule.

Rather than carefully planning the research project in sequential stages, an exploratory process works in short iterations, intentionally looping back through activities.  At each iteration, researchers adapt to previous discoveries, speculate about remaining uncertainties, and plan the next iteration to reduce the most critical ones.  The process closes in one of two ways:  by launching a development project if no major uncertainties remain, or by abandoning the project if the value hypothesis becomes untenable.

As an example, a team researching a formulation for a functional snack product (one that keeps you feeling full longer) set a 3-hour satiety goal early in the project.  They invested significant effort to reach that goal, only to find that three hours of satiety was incompatible with a superior sensory experienc
The waste was caused by prematurely specifying the 3-hour satiety goal.  An iterative process with a broader goal of “good taste with superior satiety” would have allowed the team to iterate through different taste/satiety combinations to arrive more quickly at a successful formulation.e (taste and texture).  In the end, they discovered that only two hours of satiety would be competitive as long as the product tasted good.

Four steps to beating a cross-functional problem

January 3rd, 2012

In a companion post, I describe an example where an IT manager is taking heat because his group has to work too many hours to meet schedules.  The root cause of the problem is outside of the IT group:  The operating groups are making demands without regard to division-wide priorities or fact-based scheduling.

The IT manager might turn to division management and say “This is your problem.  You haven’t set division-wide priorities.”  He might say that, but I wouldn’t recommend it.

The best approach is for the IT manager to take charge of the problem with a four step process that leads from analysis to building support for a cross-functional solution.

  1. Analyze the problem objectively, avoiding defensive bias.  In our example of high workload in the IT department, are schedules unrealistic?  Are people spending a lot of their time fixing previous releases?  Do shifting priorities create traffic delay for individual projects?
  2. Identify improvements that range from “local” solutions that you can do in your own group to things that need cross-functional support.  The local solutions will have smaller impact, but you will use them to build support for cross-functional solutions later.
  3. Implement one or two of the local solutions to unilaterally within your group.  For example, you might insist on reserving 35% of your people’s time for supporting old releases.  This is the step that’s politically tricky, because outsiders may think you’re just being obstinate.  To combat this, be sure to repeat the cross-functional benefits every time you can.  Perhaps you can argue that dependable schedules are good for everyone.
  4. The last step is to leverage your success with the local solutions into leading a cross-functional task force to solve the problem. You haven’t solved the whole problem, but the limited improvement you’ve demonstrated gives you credibility in the organization.  You can sell upper management the idea of your leading a task force to implement a full solution.

This process isn’t without risk.  You have to be sure that others see that you are promoting worthwhile improvements, not just being an obstinate rabble rouser.  But when you can accomplish a real improvement, you not only make your life easier, you also build your personal reputation as a problem solver.

2012 Resolution: Take charge of a problem

January 1st, 2012

Putting yourself in charge of a cross-functional problem is strong medicine for your career, and it will make your job easier. Here’s a story I heard from an IT group manager at a division of a large company.

The email came from the division GM:  The IT manager’s group was in red status because they were working too many hours (this is a true story).  Despite the manager’s positive evaluations from his group and his boss, the GM wanted the manager’s improvement plan.

Our hero had a serious dilemma.  He was taking heat for something that was really a cross-functional issue outside of his control.  If he pushed the problem back on management, he’d just be whining.  If he ignored the problem, his performance ratings would suffer. Either way, his personal reputation in the company was on the line.

The cross-functional issue in this story is that the IT group was being bullied into accepting unrealistic schedules by the operating groups.  Each operating group wanted the shortest possible schedules for their own projects, and none of them was concerned about other group’s needs.  This was an organizational problem that was outside of the IT group’s control.

The way out of the dilemma is to first make “local” improvements that are possible within your own group and publicize this effort, and then leverage that success into a broader solution.   For example, the IT group could insist on a 35% schedule margin to allow for bug fixes in previous releases.  A local solution like this can’t completely solve the cross-functional problem, but then you have a case for launching a broader, cross-functional solution.

This process of leveraging local improvements into cross-functional initiatives takes political skill, but when you pull it off, you’ll make your own life easier and build your reputation as a problem solver.

In a companion post, I explain a four step process to carry this all off.

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

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.

Use Traffic Delay to Measure Congestion

May 25th, 2011
 “Traffic Delays to Triple” read a headline about highway congestion in my morning paper.  It turns out that planners use traffic delay to measure the cost of highway congestion.

This would be a good way to measure project congestion on your new product highway.

We’ve all experienced traffic jams (if you’re from Southern California you’re an expert).  When traffic is congested, it takes too long to get home, and your arrival time is unpredictable.  The figure below, based on Don Reinertsen’s The Principles of Product Development Flow (pages 170-172), shows how high traffic density reduces throughput.

Traffic density reduces throughput

With highway traffic, too many cars start to interfere with each other, they begin to slow down, and vehicle throughput declines.

The same thing happens in product development.  Companies’ most common headaches are that projects take too long and schedules are unreliable. Yet these same companies start too many projects, congesting project traffic, delaying projects and making schedules unreliable.

But how can you push back on project congestion without coming off as a whiner?  One way would be to build a case against congestion by assessing traffic delay as an objective measure of the cost of congestion.

Put a cross functional task force together for a retrospective on recent projects.  Estimate the total delays in weeks, weighted by the lifetime profit potential of each project to get a delay measurement in $M-Weeks.  (It would be better to use a financial cost of delay model to translate delay directly into economic loss.  But most companies don’t use these models, as I’ve lamented previously.)

Apply your best judgment to look only at delays that are caused by congestion:

  • Time spent waiting in queues at resource bottlenecks
  • Time waiting for an engineer from another project that didn’t finish on time.
  • Delay caused when an engineer was diverted to fight a fire with another project.
  • Delay caused by multitasking.  When sharing resources means alternately putting projects on hold while another one gets resources.
  • Cases where an expert needed to solve an unexpected problem was already committed elsewhere.
  • Opportunity delay, when a project might have been accelerated with more staffing. (For this one, estimate what the project schedule might have been with a reasonable staffing increase.)

Be sure to honestly estimate congestion delays without including delays from other sources, such as underestimated tasks, or “normal” process overhead.

This assessment will tell you how much project congestion is costing you.  If the figure is large, you have a concrete basis for better new project onramp control.  This will ease congestion and make projects faster and more predictable.  And maybe you’ll be able to get home on time.

The Multitasking Mirage

May 24th, 2011

So many projects, so little time.  Individuals, project teams, or whole engineering departments often find themselves overbooked and juggling multiple projects in the effort to keep them all on track.  This is chasing a mirage.  Multitasking doesn’t reduce delay; it creates more delay and spreads it among all the projects.

Here’s an example. Suppose the Red and Blue projects both need time from Amy, your best wireless designer.  She’s just started the Red project when the Blue project lands on her desk. 

Amy might want to put Blue on hold until she finishes Red.  That would be unitasking, and it would delay Blue.  Wouldn’t it?

But both projects are top priority with rigid deadlines.  In order not to delay Blue, Amy should divide her time “fairly” between both projects.  Shouldn’t she?

Let’s take a look.  The figure below compares how Amy might apply her time to Red and Blue by unitasking or multitasking. 

Multitasking doesn't speed up the Blue Project

The multitasking mirage is that multitasking reduces delay time on the Blue project.  But the first thing you notice is that multitasking doesn’t speed blue at.  Amy finishes it at the same time in either case.  This is because total wait time for Blue is the same in both cases.

Perversely, multitasking only creates wait time for Red.   This is waste, since it doesn’t help to speed up Blue at all.

And I’m not talking about the inefficiency and opportunity for error that comes from jumping back and forth between different projects.  That can be a significant cost, but it’s a topic for another post.

Back to the figure, what if Blue really does have an important deadline?  In that case, Amy should switch her effort to Blue once, only going back to Red when Blue is done.

What if Red and Blue are both due at the same time, maybe for a trade show?  You have to keep in mind that Amy won’t finish Blue any sooner with multitasking. With unitasking, you’ll at least finish Red in time for the show, even if Blue is at risk–Better than putting both projects at risk.

What can you do?  Of course, Amy should do only the minimum required for each project, no bells or whistles.  And it will speed up both projects if Amy can get some effective help, maybe with the more mundane parts of the work that don’t need her expertise..

To avoid multitasking, the first thing you can do is to show this figure to whoever is driving the multitasking.  If that person is your manager, be sure you explain that you’re not trying to avoid work, but that it’s best for the company to avoid the schedule waste of multitasking.  If that person doesn’t believe it, have them email me.  A big part of my job is changing managers’ minds.

Another thing you can do to stabilize priorities. Switch from Red to Blue once, and only once, if Blue really does need to be finished sooner.  Unstable, shifting priorities often result from stakeholders of different projects fretting that their project waits while the other project moves forward. 

I know that getting clear, stable priorities is a real challenge in many companies.  Managers who regard themselves as rugged and decisive can get weak in the knees in front of competing executive project champions.

If you can’t get management agreement on priorities, set them yourself.  Just focus on the Red project and tell your manager that it’s in the company’s best interest to at least finish Red quickly, because multitasking will not speed up Blue, and that you’ll start on Blue at the earliest possible moment.  Say that you’re applying onramp traffic control to prevent a traffic jam.

Are you suffering from multitasking?  Leave a comment–there may be another reader who’s already solved your problem.

Dear John, Oh, how I hate to write.

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

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.