Stephen Mulva used an automotive plant to challenge a familiar capital decision. If a forecast said the business might need capacity for 1,000 cars a month several years later, should the owner build all of it at once?
In our 2017 conversation, Stephen proposed a research-stage alternative. Build capacity for 40 percent of the estimate, use a repeatable design, watch what the market does, and add another unit if the business needs it. He was not presenting a finished formula. He said the wider OS2 model still required years of research and development.
The value of the example was the choice it exposed. How much capital should a forecast commit before the owner has better information?
The forecast was a starting point, not a promise
Stephen Mulva argued that conventional planning creates an illusion of certainty. He described owners spending a long planning period on demand they could not predict precisely, then moving through design and construction in sequence while the business continued to change.
His smaller-capacity example was meant to preserve a decision. The owner could start with capacity the business expected to use, learn from actual demand, and decide later whether to repeat the design. Stephen acknowledged that a larger facility could have scale advantages. He argued that repeated smaller units might also change purchasing, production, maintenance, and the value of keeping options open.
The exact percentage was provisional. The operating question was durable: what does the owner gain or lose by committing the full forecast today?
The finish line sat outside the project plan
Stephen Mulva said a project was not ultimately about cost, schedule, or technical deliverables. Those measures remained important, but he pushed the decision toward the benefit created for shareholders, customers, or the public.
That distinction changes the review. A team can deliver the defined scope and still miss the reason the business needed the investment. The owner has to connect the project decision to the financial, customer, operating, or public outcome it is meant to support.
Business and project teams needed a translation
When Stephen Mulva described business and project teams as "like oil and water," he was naming a language problem. He argued that engineers and project leaders needed to speak the language of the business, while both groups worked together on agility, flexibility, and the options that could remain open.
Translation changes the conversation from whether the team can deliver a scope to why that scope, at that size and time, serves the business. It also gives project leaders a way to raise an option before it disappears inside a fixed plan.
Value creators bring choices before the scope arrives
Stephen Mulva contrasted project groups that waited for a request with groups that brought ideas to the business. In an owner study he described, the first group knew how to deliver once the phone rang. The second group proposed ways a facility or project decision might create more business value, knowing that many ideas would not move forward.
The distinction was not a request for project teams to take over business strategy. It was an invitation to bring technical knowledge into the decision early enough to create a real choice.
Run a translation test before the scope hardens
Take one capacity or scope decision under discussion. Put the technical deliverable beside the business or public benefit it is intended to support. Name the uncertainty behind the forecast and the option the current decision preserves or removes. Then ask business and project leaders to review the connection together.
If the team cannot explain that connection, the decision needs another conversation before the scope hardens. The goal is not to adopt Stephen's 40 percent example as a rule. It is to keep a forecast from consuming the owner's options before the business has examined them.
A capital project serves its purpose when the technical choice, the uncertainty, and the intended benefit can be discussed in the same language.
