Title and authors
Project Economics Under Uncertainty: From Concept to Realization
I wrote it with Glen Alleman and Christian Smart. Glen has spent forty years in program planning and controls on aerospace and defense programs, writes the Herding Cats blog, and wrote Performance-Based Project Management. Christian directed cost estimating at the Missile Defense Agency and wrote Solving for Project Risk Management; in 2021 the International Cost Estimating and Analysis Association gave him its Frank Freiman Lifetime Achievement Award.
What it argues
Projects still fail, after decades of improvement in how they are managed, and they fail in two different ways. Some never deliver at all. Others deliver precisely what was promised, on the date and for the money agreed, and are still not worth what they cost. The second kind is the more interesting failure, because the usual scorecard cannot see it. On time, on budget, on the agreed scope: that measures how faithfully a plan was followed. It says nothing about whether the plan deserved to be followed, and nothing about whether anyone should still have wanted that plan by the time it was built.
So the book starts by asking what success actually means, and it answers with three principles rather than a scorecard. Carry the uncertainty instead of hiding it: duration, cost and delivered benefit are ranges, and narrowing them is itself progress worth reporting. Think like an investor: a development project is capital placed at risk in the expectation of a return, and the return need not be money, but it does have to be quantified, whether it is measured in revenue, in lives saved or in acres protected. And reason about the whole system, meaning both the thing being built and the organization building it.
The three are not competing perspectives, to be weighed against each other by a manager with good judgment. They fit together into one calculation, and that is the claim the book is really making.
The third principle is about the way the components of a product combine. The value of the product is determined by how its components interact, so that value is a joint probability, and it cannot be read off the components one at a time. The joint probability is found by running a digital twin model of the product, built from its components and the uncertainty attached to each of them. The same holds for the qualities that requirements documents call the ‘ilities’. Reliability, maintainability and scalability belong to the assembled product, and they are found from the same digital twin model. They set what the product costs to operate once it is in service, and that cost is part of the return.
In the middle of all this sits a question most project accounting answers wrongly, which is what an unfinished project is worth. It is not worth what has been spent on it: that is the sunk-cost fallacy, and it is no better in a project than it is anywhere else. Nor is it worth nothing until the day it ships, a view the markets contradict every time a half-built development, a drug in trials or an unfinished product changes hands for real money. A project gains value as it eliminates the things that could still go wrong, and that value can be priced: what someone would pay for the right to finish it, given that they would not be obliged to. Once that price exists, progress reporting has something to report other than percentages.
Two economic cases run through the book, because projects come in two shapes. When the delivery date can move, the project is valued the way an investment is, and the date becomes something to decide rather than something to defend. When the date cannot move, a launch window or an opening ceremony or a contract with a penalty attached, the project is closer to a wager: a stake, a payoff, and a probability of collecting it. Each is worked end to end as a case study, one for a consumer product, one for a spacecraft landing system.
The hardest conclusion is about control. A project cannot be steered toward three targets at once, and the reason is not a want of discipline. Cost, schedule and quality held side by side will tell you that two possible outcomes differ, but not which of them you should prefer, and a manager picking a corrective action needs to know only whether the previous one helped. Steering requires a single measure. Insisting on one costs nothing, because that measure is assembled out of everything you care about rather than being one of those things elevated above the others. Everything else has one of two honest homes: it feeds the measure, or it settles which outcomes are admissible at all. The one thing it can never be is a second destination. On this reading the iron triangle is not a trade-off to be managed but a control problem with no solution, which is why exhortations to be faster, better and cheaper at the same time have the history they do.
None of this asks anyone to discard what they already do. Earned value management, quantitative risk management, capability-based planning and agile practice all survive the argument intact; what changes is what they are measured against. The book proposes no maturity model, ranks no organizations, and does not claim that better arithmetic removes the risk. It makes the risk legible, so that the people spending the money can price it.
What is in it
Six chapters. The principles are built up in the first three. The remaining three put them to work, as a lifecycle and then as two case studies.
- Chapter 1 Embracing Uncertainty. Why the quantities a project runs on belong in the plan as ranges, and how to tell apart the uncertainty you can only model from the uncertainty you can spend money to shrink.
- Chapter 2 Investment Thinking. The economics of a project as something management owns. The variable-date project judged on what it returns, the contracted project judged on a payment it either collects or does not, and the benefits that will not turn into money but can still be counted.
- Chapter 3 Systems Thinking. How the shape of the product, and the shape of the organization that produces it, decide where uncertainty collects, what the qualities are worth, and what can be seen while the work is still going on.
- Chapter 4 The Investor’s Lifecycle. Four phases, each of which exists to carry one investment decision and to generate no more analysis than that decision needs: ideation, chartering, controlling and release. Mapped onto SAFe, the Unified Process and the INCOSE Vee.
- Chapter 5 A Flexible-Date Example. The first worked case, a consumer product followed from first idea through to release, with a ship date that is priced as a choice rather than defended as a promise.
- Chapter 6 A Hard-Deadline Example. The second worked case, in which a start-up works out whether to bid for a Mars entry, descent and landing system, and at what price, with a launch window that is not going to wait.
Nine appendices carry the supporting theory, the algorithms and three case studies in what project success has actually meant. The chapters are written to be read without them. Three of the algorithms are written out at a level of detail a tool vendor could build from, which is deliberate rather than incidental.
Who it is for
Practitioners, and deliberately two groups of them at once. The people executing and delivering: project and product managers, developers, engineers and architects, quality assurance, change management, and the staff responsible for earned-value reporting. And the people planning and chartering: sponsors, business analysts, financial analysts and controllers, and program managers. Portfolio management is outside the book’s scope, although the reasoning carries over to it.
Writing for both groups at once is the point rather than an accident. They routinely fail to understand one another, and much of the conflict on a troubled program is the two of them arguing past each other about an estimate. The book is trying to give them a common way of talking about uncertainty and value.
It does not assume a statistics background. The mathematics lives in the appendices, and the chapters are written so they can be read without it. It is not a textbook and it is not a certification study guide, and it does not expect anyone to read it front to back; it suggests a path instead, according to what you are responsible for.