In one sentence: Scale when value is proven and repeatable under realistic conditions; fix when one bounded, correctable constraint blocks an otherwise credible value case; retest when a better-designed test can resolve the critical uncertainty; stop when the value case, economics or risk cannot justify further investment.
Treat the next phase as a new investment decision
A pilot is evidence, not a promise of continued funding. Management should not scale a project because the team worked hard, a vendor expects a rollout or the demonstration attracted executive attention. The question is whether the next commitment of capital, data, people and operational risk is justified now.
Buy a capability, then search for value
The initiative begins with a model, platform or vendor. The team then looks for use cases and reports technical activity as progress, even when the connection to the organization’s value proposition remains weak.
Understand value, then define AI’s role
The organization starts with customer and internal value propositions, examines the relevant value-chain activities and problems, and then tests whether AI is the appropriate intervention.
Value alignment does not guarantee success. It creates a stronger basis for selecting the right problem, defining measurable outcomes and avoiding investment in technically interesting but economically weak projects.
A specific, addressable constraint is preventing a credible value mechanism from working.
Value has crossed the agreed threshold and can be reproduced under realistic operating conditions.
The evidence is inconclusive, but one bounded test can resolve the decision-critical uncertainty.
Further work is unlikely to produce sufficient value on acceptable economic and risk terms.
The choices are not stages that every project must pass through. They are competing decisions. A project should move only when the relevant threshold is met.
Test six conditions before deciding
The decision should combine the business case with the operating conditions required to sustain it. A high model score cannot compensate for a weak problem, poor adoption or unacceptable production exposure.
| Decision condition | Evidence management needs | Warning sign |
|---|---|---|
| 1. Problem materiality | The affected problem remains important, frequent and connected to a meaningful customer or operating consequence. | The project is now defending the technology rather than solving the original problem. |
| 2. Measured value | A credible baseline and comparison show movement in the agreed business outcome, not only technical performance. | Usage, accuracy or output volume is presented as business value. |
| 3. Workflow adoption | Intended users can act on the output, exceptions are handled and human decision rights are clear. | Results depend on manual workarounds or unusually motivated pilot users. |
| 4. Repeatability | The result survives realistic data, volume, locations, user groups, time periods and operating variability. | The strongest result appears only in a selected dataset or protected environment. |
| 5. Production economics | The expected benefit exceeds total build, integration, operation, oversight, change and risk-management cost. | The business case excludes the resources required to capture the value. |
| 6. Risk and accountability | Guardrails hold, residual risk is within tolerance and named owners can monitor, intervene and deactivate the system. | No leader owns the outcome or the response when performance deteriorates. |
The AI business-value measurement framework explains how to connect the system output to adoption, operational change, economics and guardrails.
Fix the project only when the constraint is bounded
“Needs improvement” is not a decision. A fix recommendation should identify a specific failure point and explain why changing it is likely to improve the business outcome.
The underlying problem is still worth solving
Evidence supports the problem, affected workflow and value mechanism even though the current implementation is not delivering enough.
The blocking constraint is identifiable
Data quality, integration, workflow design, adoption, model performance or governance is supported as the cause, not merely reported as a symptom.
The intervention has an owner and limit
Management defines the change, accountable owner, maximum time, additional cost and evidence required from the next test.
The team cannot iterate indefinitely
If the fix does not cross the pre-agreed threshold, the project returns to a formal decision gate rather than receiving another automatic extension.
If the cause is still uncertain, diagnose it before prescribing more technology. The Why AI Pilots Stall framework separates visible symptoms from value, workflow, evidence, ownership and readiness barriers.
Scale the operating result, not the demonstration
Scale means exposing more users, transactions, locations or decisions to the system. That changes the cost, integration burden and impact of failure. A scale decision therefore requires both value proof and production readiness.
- The primary business outcome crossed the agreed threshold. The result is attributable enough to justify the next decision.
- Guardrails remained acceptable. Quality, safety, fairness, privacy, compliance, customer experience or workforce burden did not deteriorate beyond tolerance.
- The result is reproducible. Evidence covers conditions that resemble the intended deployment context.
- The workflow can absorb the change. Users, exception handling, escalation and human oversight are designed for higher volume.
- Total economics remain credible. Integration, infrastructure, monitoring, support, change and failure costs are included.
- Ownership continues after launch. Named people can monitor value and risk, authorize changes and deactivate the system if necessary.
Use a phased rollout with explicit transition points. Each expansion should confirm that the value and guardrails survive the new operating conditions before the next expansion begins.
Stop when additional work cannot justify its opportunity cost
A stop decision protects capital and leadership attention. It can be correct even when the system is technically impressive or some users like it.
| Stop signal | Why it matters | Required close-out action |
|---|---|---|
| The wrong or weak problem | The problem is not material enough, or AI does not improve the decision that creates the loss. | Record the rejected assumption and redirect resources to a more material problem. |
| The value threshold is missed | A credible test shows that the expected operating or financial outcome is not achieved. | Close the business case unless genuinely new evidence changes the premise. |
| An unacceptable guardrail fails | The apparent benefit creates safety, legal, ethical, privacy, quality or resilience exposure beyond tolerance. | Pause use, protect affected stakeholders and follow the applicable incident and decommissioning process. |
| Production economics do not work | Integration, oversight, maintenance or failure costs erase the expected benefit. | Document the complete cost boundary and terminate avoidable commitments. |
| No accountable owner exists | No leader has authority over adoption, process change, value capture and risk response. | Do not transfer an ownerless pilot into production. |
| The critical dependency is not resolvable | Required data, process stability, access, governance or capability cannot be obtained on acceptable terms. | Preserve useful learning and identify whether the enabling work has value outside this project. |
Stopping development is not the same as safely decommissioning a deployed system. Close-out may require removing access, ending automated decisions, retaining records, notifying stakeholders, preserving fallback processes and monitoring residual effects.
Retest only when one better test can change the decision
Some projects are neither ready to scale nor proven unworthy. A retest is justified when the previous evidence was contaminated or incomplete and a bounded experiment can resolve the critical uncertainty.
A missing comparison can be repaired
A baseline, holdout, phased rollout or realistic operating condition can make the next result interpretable.
One assumption determines the decision
Management can state the question, threshold, owner, time window and maximum additional spend before testing.
The team is repeating the same design
More data or another sprint will not resolve the weakness in the problem definition, value mechanism or decision rule.
The result cannot change management's action
If every possible result leads to continued funding, the activity is not a decision test.
Match the evidence pattern to the next action
| Evidence pattern | Direction | Next management action |
|---|---|---|
| Strong value evidence, repeatable operation, credible economics and acceptable guardrails. | Scale | Approve a phased expansion with monitoring, ownership and explicit rollback conditions. |
| Credible value direction, but one verified and addressable constraint blocks the threshold. | Fix | Approve a bounded corrective action and return to the gate on a fixed date. |
| Potentially material value, but the test cannot support a conclusion and one better test can resolve it. | Retest | Approve only the smallest credible experiment needed for the decision. |
| Weak value, failed threshold, unacceptable risk, negative economics or unresolvable dependency. | Stop | End further investment, decommission safely where needed and capture reusable learning. |
For portfolio choices, compare projects using the same evidence boundary. The AI use-case prioritization framework helps leaders allocate scarce capital, data and attention across competing opportunities.
Write a decision record that can survive scrutiny
A concise decision record prevents the team from rewriting history after the outcome. It should state:
- the business problem, affected workflow and intended value;
- what evidence was reviewed and where its limits remain;
- the primary outcome, baseline, comparison and guardrail results;
- total cost and the assumptions behind the economic case;
- the selected decision and why the alternatives were rejected;
- the accountable business owner and decision rights;
- the next threshold, review date and maximum additional commitment;
- monitoring, escalation, rollback or decommissioning responsibilities.
Use an AI Project Value Assessment when the initiative lacks a decision-ready view of the problem, value, evidence, ownership and readiness.
What keeps weak AI projects alive?
- Treating sunk cost as future value. Previous spend cannot justify the next investment.
- Rewarding technical progress with scale. A working model is not proof of an operating result.
- Calling every weakness fixable. A fix needs a supported root cause, bounded action and stop rule.
- Using one composite score. A high average can hide a failed safety, legal or economic condition.
- Changing thresholds after seeing the result. This converts a decision gate into a justification exercise.
- Ignoring opportunity cost. Continuing one project can delay a stronger opportunity that needs the same people, data or leadership attention.
- Stopping without decommissioning. Access, automated actions, dependencies and residual risks may continue after funding ends.
Questions leaders ask at an AI decision gate
Does a technically successful pilot deserve to scale?
Not automatically. Technical feasibility must connect to a measured business outcome, realistic workflow adoption, repeatable performance, credible total economics and acceptable guardrails.
How long should management allow an AI project to be fixed?
There is no universal duration. Define the smallest corrective action, named owner, decision metric, maximum additional cost and review date before approving more work.
Can a stopped AI project be restarted later?
Yes, if material new evidence changes the value case, dependency or risk position. Restarting should be a new investment decision, not an informal continuation of the old project.
Should the vendor participate in the decision?
The vendor can provide technical and operating evidence, but the organization should retain independent responsibility for the business outcome, risk tolerance and allocation decision.
Editorial note: This framework reflects MoreSight’s business-value and AI-alignment methodology. It provides general decision guidance, not a complete analysis of any initiative. Related external references include the NIST AI RMF Manage Playbook, Google Cloud’s guidance on AI performance, adoption and business-value KPIs, Microsoft’s guidance on connecting AI to outcomes and baselines, and the UK Government’s AI Playbook.