Innovation and the Butterfly Effect

The Merriam-Webster Online Dictionary defines chaos as a state of things in which chance is supreme; the inherent unpredictability in the behavior of a natural system such as the atmosphere, boiling water, or the beating heart; or a state of utter confusion. I don�t know about you, but that last definition sure sounds like every product development I�ve ever been involved in.

Product development or innovation basically is chaotic. Many of the traits of product development are the same as the traits of fractals. That is, everything looks pretty regular and predictable at the macro level, but the closer you get, the more detail is revealed.

After all, if we are truly adding value, the innovation process is fundamentally a discovery process. New information that can potentially completely change the landscape constantly is being uncovered. What tools and techniques does the manager have at his or her disposal to deal with this constant uncertainty? In the end, the goal is to keep small perturbations from rippling into large instabilities as would happen in a chaotic system.

The Macro View vs. the Micro View
It is very common that a schedule is generated fairly early in the development of a new product. There are many methods and techniques used to generate a schedule. But ultimately all schedules look pretty much the same�a series of tasks, each with assigned resources and completion dates.

Keep in mind, however, that this schedule is merely a representation of one possible way to approach and solve a problem or a set of problems in a known period of time. For a project that requires any amount of innovation, at the time the schedule is generated, all the information is not known.

There are many techniques for dealing with this uncertainty in the scheduling process. Most result in including slack time or buffers, so if a specific task or set of tasks takes longer than the original guess, the entire schedule is preserved until the buffer is used up.

When these schedules are generated, the times allocated to each task really are nothing more than educated guesses. We rely on past experience and our best extrapolation of known information to arrive at these task times.

The resultant schedule is nothing short of a work of art. It is a beautifully crafted weave of parallel tasks with complex interdependencies and critical and near-critical paths shown in red, the universal danger color. And it is wrong.

No project involving innovation that I have ever seen proceeds the way the schedule says it will. Tasks never happen completely before others are started, the parallelism is never as envisioned, the interdependencies are not all shown or correct, and there always are things that happen that are not taken into account. People get sick, the weather doesn�t always cooperate, and items really do occasionally get lost in shipping.

And then there are other issues: The selected technology has some quirks that you hadn�t seen before, or a key vendor is hit by a natural disaster. Any number of things could happen that you cannot possibly plan for. Of course, a good risk management strategy helps, but that still is predicting the future. Not something most of us are very good at.

My favorite illustration of the principle is FreeCell, one of the card games that comes with the Windows operating system. The object of FreeCell is to move all the cards to the home cells, using the free cells as placeholders. To win, you make four stacks of cards on the home cells, one for each suit, stacked in order of rank.

You can�t possibly plan the entire game without playing it. You can develop a strategy and plan and execute the first few moves, but developing a plan that will guarantee you will win the game requires playing the entire game.

Reality does not behave the way the simplified model known as the schedule says it will. The reality of an innovation project reveals itself little by little as we navigate the turbulent waters of discovery. So how do we keep the boat on course and upright when the currents of reality toss us around like a ping-pong ball in a wind tunnel?

Know Where You Are
The first step in plotting a course is to determine where you are starting. If you don�t know where you are, you can�t plot a course from there to your destination. Any direction might seem like the right one. And heading off in the wrong direction could set off a sequence of events leading to instability. So how do you know?

It is our natural inclination to decompose the work by subassembly or by discipline such as electrical design or mechanical design. In fact, it makes sense to keep track of which parts are done.

But what ultimately matters is the functionality�what is working and what isn�t. So while it is easy and necessary to report the XYZ board is out for fab and will be back on Thursday, the vital information is contained in how well the XYZ board works.

It is important to define plateaus of functionality for an innovation project. These plateaus are places where the team can be on stable ground, fully informed of where they are, and plan the next moves.

These plateaus don�t need to be huge steps in functionality or all-encompassing. In fact, it�s better if they are relatively small increments. Then, if an approach fails, it�s easy to fall back to the plateau and plot a new course. These plateaus are the stable, known reference points in the development: They help keep things from careening out of control. To an analog engineer, they keep the poles on the left hand side of the j? axis.

Gathering the Right Information
By knowing where you are, you then can use the newly discovered information to steer the boat. There is so much data pouring in from all directions. How do we filter the information from the data? And how do we ensure the information we need is contained in the endless stream of data?

Many if not most project status meetings or reports are nothing more than a weather report: It rained yesterday. It�s below freezing today, and we will have precipitation so it�ll probably be snow or sleet. Eventually, we�re not sure when, the sun will come out, and it will get warmer.

That�s all very interesting data. But it isn�t very relevant to how things are working. And worse, the tone is one of acceptance; we don�t control the weather, we just report it. We can control many factors in a development, and we can affect the direction and, therefore, the outcome.

The important information for steering the boat really is how functional the system is relative to your expectations. It�s obvious that if you are trying to achieve a bandwidth of 10 GHz and the design is only yielding 2 GHz of bandwidth, there is a big mismatch. Something clearly needs to be done differently.

Unfortunately, most gaps are not that obvious. A great deal of information is just handled by the engineer. It simply never comes out in the normal course of events.

The natural tendency for an engineer is to treat new information as a confirmation of something he or she already knew. Consequently, it�s difficult for engineers to see the relevance in their daily discoveries.

As an engineer, I probably was the worst. I loved figuring out the latest puzzle. But once I discovered what was causing the difference from my expected outcome, I was satisfied that I understood the problem and often went on to the next problem without fully thinking about the repercussions of a solution. I seldom asked myself if I should regroup and take a different approach.

I have found that identifying the gaps in functionality from the defined plateaus gives me a good view of what is going on and where to dig down if that is required. With reasonably well-defined plateaus, the functionality gap can be very objective and factual�and precisely the right information to help steer the boat.

Taking Action
Once you have the right information you need to decide what action to take. Sometimes the right answer is to take no action. All too often I have witnessed�and have fallen victim to�an action not being taken when it should have been.

To guide the boat toward the desired destination when it is off-course, the speed and direction must be altered. The actions required to do this frequently can be very small, and timing of the action is key. We�ve all seen Captain Kirk hold off on firing the phasers until precisely the right moment to do maximum damage to the enemy. Sometimes it can be the removal of one constraint, either real or perceived, that makes all the difference.

Summary
The innovation process truly is a chaotic system. As such, small perturbations can ripple into large instabilities causing major slips in schedule, severe compromises in functionality, and considerably more resources than expected being expended on development.

By being careful and managing how perturbations are introduced into the system through plateaus of functionality, some of the instability can be controlled. Carefully gathering the right information helps paint a clear picture of the speed and direction of the development. Taking the appropriate actions to continually guide the development toward the desired goal is the last piece.

Knowing your position, knowing your momentum, and exerting minimum energy to change your momentum can transform chaos and uncertainty into real innovation. Something Dr. Heisenberg might have found interesting.

About the Author
David C. Graef has served as vice president-chief technology officer at LeCroy since April 2003. Previously, he was vice president of R&D for four years, engineering manager for two years, and senior engineer for more than seven years. Mr. Graef has a B.S. in electrical engineering from the University of Bridgeport. LeCroy, 700 Chestnut Ridge Rd., Chestnut Ridge, NY 10977, 845-425-2000, e-mail: [email protected]

May 2005