BetterNPD

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.

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.

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.)

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.

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.