Archive for the ‘Tips and Tools’ Category

Use Flexibility to Control Risk

Tuesday, 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.

Eliminate Waste in the Front End of Innovation

Tuesday, 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

Tuesday, 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

Sunday, 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.

Use Traffic Delay to Measure Congestion

Wednesday, 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

Tuesday, 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.

Designs change. Deal with it!

Friday, 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.

Doing More with Less? 4 Tips to Avoid Traffic Jams

Tuesday, 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

Avoid the Short Term Treadmill in R&D Investments

Tuesday, 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.

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: