Archive for the ‘Governance’ Category

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.

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.

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.

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.

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.

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.

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 http://learn.gotomeeting.com/forms/NA-G2MC-WP-SteveJobs-7Prin-S?ID=701000000005Ypv

 (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

The Fly on the Window and “Best Practices”

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