Edited by James Braham

Donald G. Reinertsen
President, Reinertsen & Associates
Redondo Beach, Calif.

Some people seem to live in a world without trade-offs, a magical world with no limits, where if you can dream it you can do it. Sadly, engineers are not allowed into this magical world. You are condemned to live in the unforgiving world of trade-offs.

Customers may want a $1,000 car that drives for 30 years on a single tank of gas. Marketing may smile and assure them one will be available next month. However, desire alone is insufficient. If the technology to fill the need does not exist, engineers must make trade-offs, and the engineer who makes the best ones wins.

How do you make these trade-offs? Do you rationally trade off among important objectives such as unit cost, budget, performance, and schedule with hard-nosed, pragmatic choices? The sad truth is that development teams waste millions of dollars every day because they lack even the most rudimentary decision tools to make such trade-offs. This article spotlights the most important of these tools: the project economic model.

Perhaps you feel you don’t need any extra help making decisions. After all, you have been in this business a long time, and you have a finely tuned intuition about your projects. Let’s do a reality check. Stop now, and take this simple test before you read the rest of this article. Assemble all the members of your development project and have them independently estimate how much extra money your shareholders would make if your project was completed three months earlier than the current schedule. Rank the answers from high to low. On a typical project the answers of people on the same team will differ by about a factor of 50. In the last 15 years we have never found a team get a range smaller than 10 to 1 by using intuition alone.

Clearly, it will be difficult to get correct, consistent decisions if we build on this foundation. If people are empowered to act in good faith on what they believe, we will have one person buying a month of cycle time for $100,000 and another person ignoring an opportunity to save the same amount of time for $2,000 because it is too expensive.

This problem is not unique to intuitive decision makers. Companies have armies of overpaid MBAs producing mountains of calculations. They focus on financing decisions: Should I invest in the project or not? They calculate return on investment and a half-dozen other financial metrics. Yet all these are useless when it comes to making the bulk of decisions the practicing engineer confronts.

Engineers don’t need new tools to make investment decisions. What you really need is a tool to help you confront the 10,000 little trade-offs that occur hourly in the course of your project — a simple way to make quick, accurate trade-offs among the multiple financial objectives of a development program. Fortunately, such a tool exists, it is simple to use, and it works.

TACTICAL DECISION RULES
The tool is called a project economic model. Its output is a set of tactical decision rules, which provide a fast way to make tough trade-offs between important objectives. For example, consider a hot new feature that will increase revenue 5%, but will delay the project three months. Our decision rule on revenue may say that 1% more revenue is worth $100,000 in cumulative profits over the life of the product. Our decision rule on schedule may say that one-month delay is worth $500,000. In this case, it would be silly to chase after $500,000 of added profit by incurring $1,500,000 in delay costs.

These tactical decision rules can be created with a simple sensitivity analysis that rarely takes more than a few hours of effort. We start by identifying the four key economic objectives of the development project.

• 1. Market introduction date — when the final product is first available for sale to the customer.

• 2. Product unit cost — typically measured as the manufactured cost of the product plus any variable costs appearing below the gross margin line.

• 3. Product performance — measured as the revenue stream of the product over its life. Product performance changes only by achieving a higher sales price or higher unit sales.

• 4. Development expense — the one-time cost associated with the development project.

Note that such a model views performance in a different way than most companies do. They think in terms of technical performance, or conformance to product specification. They believe that a design that exceeds its specification has automatically achieved higher performance. However, from an economic perspective, changing a technical performance parameter produces no benefit unless we get paid for it. If we don’t change market share or pricing, we haven’t changed business performance. Not every change in technical performance will map into a change in the business performance of the product. We never want to increase cost or give up money and time unless we will get revenue in return.

To develop trade-off rules between these four objectives, we do a simple sensitivity analysis. We begin by creating a baseline model that projects the life-cycle profits of the product. Then we create four variations of this model to test what happens to profits if we miss each one of the objectives independently. For example, we might model a 50% overrun of development expenses, a 10% overrun of product costs, a 10% performance shortfall, and a six-month delay in product introduction.

Once we know the total profit shortfall associated with a variation, we can convert this into a tactical decision rule. These rules convert the profit impact into a simple rule of thumb for the project. The power of these decision rules is astonishing. They let you quickly and rationally make trade-offs among objectives that would normally consume days of debate.

GETTING STARTED
The lessons we have learned using this tool during the last 15 years can be distilled into five tips.

• Keep the financial model as simple as possible. Companies commonly make their financial models too complex. The driver of their accuracy is not the computational method, it is the input data. When inputs such as sales forecasts can easily be off by 20%, it’s silly to model product costs to four-digit accuracy. Most experienced users construct a simple model based on cumulative profit before tax. This is easily understood by all development-team members. Focus your extra effort on scrubbing down the input data, not on creating elaborate spreadsheets. Try to keep the baseline model to a single sheet of paper.

• Involve the right people. Three key groups should participate in this modeling: the development team, management, and finance. The team needs to be involved because its members have the critical information needed to construct the model. Their involvement also helps them understand the model, so they can use it effectively. If they view the model as a mysterious black box, they will not trust it, use it, or benefit from it. Management needs to be involved for the same reason. Managers need to understand basically how the analysis was done and what assumptions underlie the model. Without this they will not trust the model, and they will revert to making decisions based on intuition. Finally, finance must be involved in the modeling process. It can add value analytically and politically. The instant a team asserts that delay costs $500,000 a month, the president will turn to the controller and ask if he agrees. You want the answer to be: “One of my people helped the team develop it. If anything, we believe the assumptions are conservative.”

• Make the results visible. Teams come up with different approaches to doing this. One team at a computer peripheral company printed the tactical decision rules for the project on wallet cards and gave them to each member. Other teams routinely post the decision rules in their war room as a continuous reminder. The goal is to have everyone on the team internalize the numbers.

• Use the project economic model for decision- making. If we want team members to make decisions based on economics, managers must make decisions this way. The shift from intuition to quantification is a fundamental cultural change with abundant opportunity for backsliding. During the beginning of this shift, we must insist that all important development decisions consider a quantification of their economic impact. When a manager says, “Let’s spend $100,000 on a new piece of test equipment, it will help us develop products faster,” our response should always be, “How much faster, and what is this worth?”

If management makes decisions on intuition alone, so will all subordinates. By framing every decision in economic terms, we can calculate how much it will cost to follow our intuition. For example, if it feels risky to use a certain vendor, our willingness to take this risk should depend on whether the potential payoff is $10 or $10 million. If management will not act as a role model for rational decision-making, you are wasting your time doing the analysis.

• Embed these tactical decision rules in your business process. This is necessary to institutionalize them. One simple way is to make such decision rules a routine part of the new-product business plan. Since such a plan already shows the expected profit from the product, it already contains the baseline model. It is a simple step to calculate variations and convert them into decision rules. If you require such calculations in every business plan, every project will start with a consistently calculated, reviewed set of tactical decision rules. These can be updated quarterly or when there a change in a key underlying assumption.

If we plan to use time-to-market as a tool to make money, we need to know what time is worth. By using a project economic model, we provide teams with the tools to make the 10,000 little decisions quickly and accurately. Don’t develop products unless you are ready to do the math.

Author Don Reinertsen is the president of Reinertsen & Associates, a Redondo Beach, Calif., consulting firm specializing in product development. He is co-author of the book Developing Products in Half the Time and author of the book Managing the Design Factory: A Product Developer’s Toolkit (The Free Press, November 1997). He can be reached at (310)-373-5332 or by e-mail at DonReinertsen@compuserve.com.

MAKING TRADE-OFFS AMONG PRODUCT FEATURES
Not all the trade-offs on a development program deal are internal to the project. Another important set of trade-offs are those between individual product features or attributes. Should I decrease the power output of my product by 10% in return for a 30% boost in battery life? We usually make such trade-offs with a lot of shouting and opinions but little quantification. A better way to make feature trade-offs is to use an application economic model. This looks at the economics of the product from the perspective of the customer.

For example, consider a company designing capital equipment for a manufacturing line. The customer’s total cost of this equipment includes more than the purchase price. The machine must be installed and certified. Operators need to be trained and certified. The equipment may use space on the factory floor, consume power, and require some consumable supplies. It must be inspected periodically, cleaned, maintained, and repaired. If the machine breaks, it may produce bad parts that have to be scrapped or reworked, and each hour of downtime may mean lost productive capacity. Each of these factors can be quantified and estimated. We call them the application economic drivers.

We can then express the total ownership cost in dollars, and use this to calculate decision rules that let us make systematic trade-offs among different performance attributes. Like our project economic model, this is a straightforward application of sensitivity analysis. A useful way to express the output is referenced to percent changes in product parameters. These application trade-off rules let us confront the interaction between different parameters in a deliberate and quantitative manner. It keeps us focused on the product parameters that are really important to the customer.


SPEED ISN’T ALWAYS THE ANSWER
As more companies learn about the economic impact of rapid product development, there has been a curious tendency to suspend normal thought processes when dealing with speed. Some managers act as if anything that helps speed is automatically good, and anything that hinders it is automatically evil. The elevation of development speed to a pre-eminent position is a dangerously sloppy way to run a development organization. If fast is “good,” what should you pay for a week of acceleration? Is $10 too much? What about $10,000? Or $10 million? Without quantification you cannot draw the line.

Furthermore, there are other things that are also worth money. As an executive from Ford once said, “A lemon produced at the speed of light is still a lemon.” A better approach is to recognize that our objective is actually life-cycle profits, not speed. This forces you to ask the question, “How does a change in schedule affect the project profits?” This leads inevitably to the sensitivity analysis described in this article.

No prudent manager should allocate a dollar for improving speed just because speed is “good.” There are hundreds of “good” things standing in line waiting to get funded in every company. We must distinguish between the good and the outstanding. The way we do this is quantification. This is critical when profits are affected by changes in more than one parameter. The only way we can make trade-offs between different objectives is if we have quantified them.

© 2010 Penton Media, Inc.