BetterNPD

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.

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.

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.

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.