Altitude: Enterprise Foundational Gap
Delivery-as-Success
At the quarterly review, all but one initiative delivered its commitments on time and on budget. Customers are doing nothing differently. The one that missed had found out its bet was wrong, and on the report, that initiative is a failed project.
Definition
Delivery-as-Success means a piece of work counts as a success if it delivers what was committed, and the same test is applied whether or not anyone knew at the start what to build.
So a lesson that changes the plan is scored as a failure. And “done” comes to mean delivered, whether or not anything changed for the customer.
The recognition pattern
Look in roadmaps, status reports and portfolio reviews, not in what anyone says about innovation:
- Innovation initiatives lose their funding after one quarter with no return yet.
- Roadmaps list deliverables and dates, not the outcomes the work is meant to change.
- Teams run exploration under the label of technical work, because an experiment does not fit the status report.
- Portfolio reviews praise initiatives that delivered their commitments, whatever happened to customers.
- An experiment that disproves its assumption is recorded as a failed project, not as something learned.
A single sign proves little. Together, the signs point to a scorecard built for one kind of work and applied to every kind.
Two kinds of work, one scorecard
Some work starts with the answer. You know what to build, and delivery is the hard part. That is execution work, and it produces the thing itself. The usual measures of success fit this kind of work: they show how well it was carried out, not whether it was worth building.
Other work starts with a question. Nobody yet knows which answer is right, so the work produces evidence. That is discovery work. A decision is waiting on the question, and the work succeeds if its evidence settles that question.
| Execution work | Discovery work | |
|---|---|---|
| Known at the start | What to build | The question |
| What the work produces | The thing | Evidence |
| The right test | Carried out as committed? | Did it settle the question? |
| A disproved assumption | Changes the plan | Is the finding |
But the organization runs both kinds through the same metrics, approval process and success criteria. To get funded, discovery work is written up as a delivery plan, with a scope and a date, and then judged against that plan.
An experiment that disproves its assumption has done its job, but the record still calls it a failed project, because it missed its commitments.
When ideas are tested, failing the test is the usual result. Of the proposed product changes that Microsoft tested in controlled experiments, only about a third improved the metric they were designed to improve (Kohavi and colleagues). So a scorecard that counts those outcomes as failures punishes discovery for doing its job.
Teams adapt to that scorecard. They write exploration up as committed delivery, hide it inside technical work, or stop running experiments.
What it costs
Teams get good at meeting commitments and get no better at solving customer problems.
Strategic bets get judged as execution commitments. Under that test, a bet with no return on schedule is stopped for missing its date. The learning that would shape the next attempt can arrive after the bet is stopped.
The organization ends up excellent at delivering fixed plans and poor at responding to what it learns.
Boundaries and distinctions
Incentive Misalignment is about what people are rewarded for. The review of a manager’s performance rewards predictability. Delivery-as-Success is the test applied to an initiative’s result, whoever leads it. The two reinforce each other: when success means delivering on schedule, learning becomes a career risk.
Motion-as-Progress judges the work along the way. Counting completed activities as progress corrupts the evidence used for decisions. Delivery-as-Success judges the work when it ends. Treating delivery as success corrupts the definition of done.
Evidence Stalemate stops an experiment before it starts. It demands proof of return before you can run the experiment that would produce the proof. Delivery-as-Success lets the experiment run, then scores what the team learned as failure.
Language Drift gives one word several meanings. “Success” and “done” are among the terms that mean different things at different layers. Here the organization agrees that success means delivered, and that agreement is the problem.
Example
An illustration, by construction. A company approves a strategic bet: a paid service for existing customers. It is funded as a program, with a feature list, a launch date and a budget. A pilot shows that customers will not pay what the business case assumes. The program team stops building, writes down what it learned and hands back most of the money. The portfolio report calls the program a failure against its commitments. Nothing in the report mentions what the pilot found or the money it saved. The next team with an untested idea proposes a feature list with a date, and runs no pilot.
Applied Test: read the judgments on stopped initiatives
Applied End-to-End Flow: Enterprise asks whether stopped and pivoted initiatives get labeled “failed projects” or “successful learning.”
List the five strategic initiatives most recently stopped or redirected. For each one, read past the status label, such as “stopped” or “cancelled,” to how the ending was judged. Does the portfolio record or the status report say what question the work answered and what decision the answer changed? Or does it say only what was missed?
If the list is short or empty, ask whether any current initiative should have been stopped by now.
The result describes how the organization judged those endings. It is not a score, and there is no threshold.
Sources and lineage
Delivery-as-Success is an Applied End-to-End Flow concept developed by Curtis Hibbs and Joshua Barnes. Its framework treatment comes from Applied End-to-End Flow: Enterprise, in the Alignment Drift barrier, where it connects to Incentive Misalignment and Evidence Stalemate, and feeds the Vicious Cycle by producing wrong work and locking decisions in place. The finding on tested product changes is from Ron Kohavi, Thomas Crook, Roger Longbotham, Brian Frasca, Randy Henne, Juan Lavista Ferres and Tamir Melamed, “Online Experimentation at Microsoft” (2009).
Curtis Hibbs and Joshua Barnes are co-creators of Effective Enterprise AI and Applied End-to-End Flow, and co-authors of the Applied End-to-End Flow book series. Their work combines enterprise diagnosis, value-delivery mechanics, and practical intervention patterns across strategy, portfolios, value streams, and teams.