2002 Product Development Management Columns
"Proactive" is a contemporary buzzword. We used it as the leading word in the title of a book we wrote recently, but we pondered this choice carefully before committing to it. Like many buzzwords, this one is far easier to recite than it is to apply.
The idea of proactivity is simple enough: consider what negative outcomes might befall you in advance of an event and then take steps to preclude it from happening or at least mitigate the damage it might cause if it does occur. In the same way that product developers have applied other techniques to product development, such as early supplier involvement, early manufacturing involvement, or having marketing participate continuously throughout a project, so developers have also applied "proactivity" without thinking about it as such. Now that some of the older approaches have lost their competitive edge, we are looking for the next opportunity for improvement, which is to propagate this notion of' "proactivity" throughout all aspects of the project.
This is appealing enough. But it goes against the styles of many managers. Their style is reactivity or as it is more commonly known, firefighting. The idea of firefighting is to let a problem fester until it becomes a crisis, and then swoop in and fix it. Firefighting is popular because it is exciting. Furthermore, it is a win-win situation for the firefighter. If the fix works out, the firefighter is a hero. If it doesn't, the firefighter can't be blamed, because the situation was virtually hopeless to begin with. Notice that it is to the firefighter's advantage to actually let the problem become worse, because then there will be less blame if they fail or more praise if they succeed.
Most of us deplore the firefighting style, yet we tacitly perpetuate it by rewarding firefighters for the miraculous things they do. The methodical work of prevention done by others goes unnoticed. Consequently, the firefighting style can be difficult to eliminate, especially in cultures that thrive on action and excitement. In contrast, in Japan, a crisis is evidence of failure: Japanese culture favors a more proactive approach to problem solving.
If this weren't enough, there is another, more practical difficulty with proactivity. It naturally focuses on the future. In our competitive environment, many managers are having enough difficulties in the present without looking into the future to find even more problems. The thought of investing now to prevent tomorrow's problems, while attractive, simply will not happen with the overload of today's problems. Today's problems are a certainty: tomorrow's are only a possibility. Of course, ignoring tomorrow's problems today means that there will he plenty of work to do in the future to deal with those crises. The approach of denying future issues is self-perpetuating.
As you can see, being proactive is more difficult than simply wearing a badge with a slogan such as, "Be proactive." However, it is still a worthwhile goal, since the benefits of proactivity are significant. Here are some things you can do to become more proactive:
- Stop rewarding firefighters and instead look more deeply to reward those who work behind the scenes to defuse potential problems.
- At management reviews of projects, shift the focus from a concentration on current problems to what is being done about future problems -- shift the discussion from the past to the future.
- Conduct some analyses of problems that have occurred recently. Could they have been anticipated in advance? Would they have been much cheaper or easier to prevent than to deal with afterwards? If so, advertise these case studies to illustrate the benefits of proactivity.
- If your organization must undergo a cultural shift from reactivity to proactivity, start small but work persistently. Start with one project having well-trained participants and managers. Collect metrics for this project and compare them to those for other projects that operate more reactively. Then expand to other projects but only at a rate that you can support with trained participants and managers.
Return to top | Return to Publications | Return to Home
Over the past decade, many companies have worked to improve their time-to-market and most have made great strides in cutting their cycle time. More recently, some of these firms have shifted their attention to managing the risks in their development projects. Is there a connection between these seemingly quite different approaches to excellence - one apparently energetic and optimistic and the other evidently more methodical and even pessimistic? I believe there is, and that this connection reveals a great deal about how product development can be improved.
Product development cycle times vary greatly by industry, company and product. For purposes of discussion, let's say that your cycle time was 24 months a decade ago, and you have reduced it to half this amount - 12 months - today, as shown in the illustration. You base these numbers on solid measurements from many projects for which you have carefully defined the beginning and end dates.
However, in reality, if you have measured your cycle time carefully, you will notice that it varies greatly, even for similar projects. That is, cycle time is actually a random variable. Mathematicians have ways of characterizing random variables. The first thing they measure is its average, also called its mean or expectation. When I said that your cycle time had decreased from 24 to 12 months, I was implying that these were average values over many projects.
The second statistic of a random variable is its variance, measured by its standard variation. To continue with the example, let's say that the standard deviation in your cycle time is three months. This means that about 95 percent of your projects complete within two standard deviations (six months) of the mean. This is shown in the second illustration.
I have applied the same three-month standard deviation to both your decade-old results and your current results. This is the key point I wish to make. Even though you have cut your mean cycle time in half, your variation has remained the same. Why? Because the methods of reducing the mean are completely different from the ones affecting the variation. The techniques we have been emphasizing over the past decade have been aimed at the averages: cross-functional teams, voice of the customer, product platforms and module reuse, and early supplier involvement, for instance.
In contrast, you reduce the variance by means aimed at it, principally by identifying and proactively managing the risks in a project. This is why some companies are now concentrating on project risk management. They recognize that although they can bring products to market relatively quickly now, the uncertainty (or "surprises") in their cycle times are their current challenge. For some products, such as consumer products aimed at certain holidays or seasons, or industrial products dependent on annual trade shows for the majority of their sales, cycle-time uncertainty is more damaging than its average value.
Another advantage to managing risks is that this technique can be applied just as effectively to reducing uncertainty in other measures, such as product cost or performance or project expense.
Return to top | Return to Publications | Return to Home
Those old enough to remember when TV was black and white will recall Joe Friday, the nothing-but-business Los Angeles police detective. When interviewing witnesses, he went straight for the facts with no social intercourse and no embellishment or elaboration.
Perhaps Friday's style didn't win him many friends, but had he been a product developer, his projects would have been completed on time, on budget, and met customer requirements. Joe would have been a master at both identifying the risks lurking within a development project and formulating plans to resolve them before they spoiled his project.
Project manager Guy Merritt and I have been exploring leading practices in managing project risks while preparing a book on this subject. Three essential characteristics of effective risk management stand out. One that is quite apparent is that risk management must be proactive in order to identify and resolve risks while one still has advantageous options available. Secondly, risks must be viewed cross-functionally, because few of them are solely technical. The third characteristic of effective risk management, however, being fact-based, is less obvious.
Unfortunately, risk is a concept about which each of us already knows too much. Due to our personal experience with life's risks, we each operate from our own presumptions and biases. This means that when you assemble a cross-functional team to identify and manage your project's risks, each team member will operate from a different script. You will have great difficulty agreeing on which risks to counteract or how to counteract them. Worse, you may uncover so many real and imagined risks that you scare yourselves and management into believing that your project will never succeed.
Facts about your project's risks are the solution to these difficulties. Initially, when you are brainstorming with your team to identify possible risks, facts about them would amount to judging, which clearly runs counter to the rules of brainstorming. At this stage, Joe Friday's single-minded style inhibits imagination and the free flow of ideas. However, you will all need to know some facts about your project, such as its scope, target customers, and areas of innovation, in order to suggest pertinent risks.
Friday enters once you have a list of risk candidates to work with. Now you have to get tough on these candidates, asking probing questions, such as, "What makes you believe that this might happen?" If you can't come up with some compelling facts—which we call drivers—to support your risk, then you have only an imagined risk, which you can then discard.
But this is just one of the benefits of identifying these drivers. Drivers are what you use to quantify your risk and assess it. Drivers allow you to estimate the likelihood of the actual occurrence of a risk—and if one does occur, what its consequences will be. Furthermore, drivers form the basis of understanding about a risk, so that the team can agree on the seriousness of the risk. Without the underlying facts, attempting to reach agreement among the team on something as intangible as probability of occurrence becomes nothing more than a debating match.
Most importantly, your drivers will guide you toward effective ways of mitigating the risk, what we call risk resolution plans. Many people develop such plans to counteract the risk itself, but this is treating the symptom rather than its causes. Effective risk resolution plans target the underlying facts that could cause the risk to occur. In fact, the way we prefer to formulate such plans is to consider a separate plan to address each listed driver. In short, if you would like to neutralize those unseen gremlins that threaten your project, don't concentrate on the gremlin itself, but instead on the facts that lead you to believe in the gremlin.
 |
Home Flexible Product Development (book)
Proactive
Risk Management Developing Products in Half the Time (book)
Product Development Publications
+1 (503) 274-0673 Last updated: 20 May 2021. Please report any problems you encounter or questions that arise |