Go/No-Go

Every AI project has a moment — usually somewhere between the enthusiastic kick-off workshop and the first sprint — where the organisation has to make a real decision.

Not the budget approval. Not the vendor selection. Not the architecture review. Those are necessary, but none of them are the decision that determines whether the project actually succeeds.

The real decision is the Go/No-Go gate at the close of Phase 1.

It is the moment when an organisation, having completed an honest assessment of business feasibility, data feasibility, and implementation feasibility, looks at what it actually has and decides whether the conditions for success are genuinely in place. It is also the moment most often skipped, rushed, or conducted so informally that it provides no real governance value.

Getting this decision right — taking it seriously, giving it structure, and being willing to return a genuine "not yet" or "not this" — is arguably the highest-value a project leader can do on an AI initiative. It is certainly the one that saves the most money.

What a Real Go/No-Go Gate Requires.

A Go/No-Go gate is not a presentation to executives. It is not a steering committee update. It is a structured decision with 3 non-negotiable inputs:

1.Genuine Stakeholder buy-in.

Stakeholder buy-in is not measured by how many people attended the kick-off. It is measured by:

> The business owner of the process being changed is actively involved and committed — not just informed and copied in. If the department head whose team will use the AI output hasn't been part of the feasibility process, that is a red flag.

> The people who will be most affected by the change have been consulted. AI projects that are designed for a workforce without meaningful input from that workforce consistently encounter implementation resistance that could have been designed around.

> The relevant governance and compliance functions have been engaged. Legal, data privacy, information security — these functions need to be aware of the project, not surprised by it at deployment.

> The executive sponsor has sufficient authority to make decisions and remove obstacles throughout the program, not just authorise the initial spend.

Stakeholder buy-in is not measured by how many people attended the kick-off. It is measured by:

> The people who matter have been engaged, 
> The people who matter stayed engaged,
> They understand what they are agreeing to, and 
> They have the authority and willingness to see it through.

2. A Clear, Precise Definition of the Problem AI will Solve.

Committed means the budget is allocated, not anticipated. AI projects that proceed on the assumption that additional budget will be approved once early results are demonstrated routinely stall at exactly the point where early results start to emerge — because the funding decision has not been made.

Realistic means the budget reflects the full cost of what is being built, not just the visible costs. The most common sources of budget underestimation in AI projects:

Data Preparation.

This is almost always the most time-consuming and expensive phase, and almost always undercosted. If data preparation is not a significant line item in the project budget, the budget is wrong.

Integration.

Connecting an AI model to existing systems — CRM, ERP, data warehouse, operational platforms — is engineering work that carries its own cost, complexity, and risk. It is not "a few API calls."

Change management and training.

The cost of helping the organisation adapt to working differently alongside the AI system. Underinvesting here is the primary cause of technically successful AI projects that deliver no business value because no one uses them.

Ongoing monitoring and maintenance.

AI models are not set-and-forget systems. They drift as the world changes. They require monitoring, periodic retraining, and governance overhead. These are ongoing operating costs that need to be in the business case, not discovered post-deployment.

3. Committed budget with realistic scope.

This is the discipline that the feasibility work is designed to produce — and it's the most important of the three requirements. It needs to be:

> Specific enough that a data scientist can design a model to address it,
> Measurable enough that success can be objectively evaluated,
> Bounded enough that the scope doesn't expand during implementation, and
> Validated enough that someone with operational knowledge has confirmed it reflects a real problem worth solving.

If these 3 inputs are present, you have the conditions for a meaningful Go/No-Go decision.

If any one of them are absent, the honest answer is "not yet" — with a clear specification of what needs to change before the gate reopens.

Questions Every Leadership Team Must Answer.

Beyond the 3 gate requirements, closing Phase 1 properly means working through foundational questions. These are not rhetorical — they require written, documented answers that the project team and sponsor can point to throughout the program.

1. What Problem are we Solving?

   See above — this needs to be specific, measurable, and bounded. "Improving efficiency" doesn't qualify. "Reducing the time to complete monthly financial reconciliation from 3 days to 4 hours" does.

2. Is AI or cognitive technology actually the right solution?

   This is the question that distinguishes disciplined AI strategy from AI enthusiasm. Sometimes the right answer is "no — a better-designed workflow, a simpler automation, or additional human capacity would solve this faster and cheaper than AI." .
   
   AI is powerful, but it is not the right tool for every problem, and it carries costs and risks that simpler solutions often do not. The willingness to ask this question honestly and answer it accurately is a mark of program maturity.

3. Which parts of the problem specifically require AI?

   Even within a project where AI is the right overall approach, not every component needs to be AI. Identify the specific sub-problems that genuinely require cognitive capability — pattern recognition, prediction, language understanding — and apply deterministic automation, conventional software, or process redesign everywhere else. 
   
   This keeps scope manageable, reduces risk, and is often significantly cheaper.

4. Which AI patterns will we use?

   The answer to this question determines data requirements, infrastructure requirements, skill requirements, governance requirements, and risk profile. 
   

   A project that has not answered this question in Phase 1 - has not finished Phase 1.

5. How will we measure success?

   The measurement framework needs to be defined before the project begins, not invented after results are available. Success metrics fall into several categories:

   Financial.

   Cost reduction, revenue impact, fraud loss reduction, risk cost avoidance.

   Operational.

   Process time, error rates, throughput, cycle times.

   Compliance.

   Audit trail quality, regulatory reporting accuracy, data governance improvement.

   User Experience.

   Satisfaction scores, adoption rates, task completion rates.
   

6. What are the project requirements?

   This is the formal scope statement — a clear articulation of what is in scope and what is explicitly out of scope. 
   
   In AI projects, scope creep is particularly damaging because the data requirements, model complexity, and integration surface all expand in proportion to scope. 
   
   A clearly documented and agreed requirements baseline is essential, and changes to it should require formal approval from the sponsor.
   

7. What other considerations exist?

   This is the catch-all for everything that doesn't fit neatly into the feasibility framework — ethical questions, regulatory requirements, competitive implications, dependencies on other programs, reputational risks. 
   
   Some considerations that frequently arise in AI projects:
   

   Regulatory and compliance.

   Is the AI system subject to any existing regulation? Financial services, healthcare, and HR applications are subject to significant regulatory requirements in most jurisdictions. 
   
   Increasingly, AI systems themselves are subject to emerging AI-specific regulation — the EU AI Act being the most prominent example, with penalties that make non-compliance extremely expensive.
   

   Explainability.

   Can the AI model explain its decisions? 
   
   In regulated industries and in any application where the AI's output affects individuals (loan approvals, healthcare recommendations, hiring decisions), the ability to explain why the model produced a particular output may be legally required — not just desirable.
   

   Security.

   Security is a Phase 1 consideration, not a retrofit.
   
   For agentic or autonomous AI systems, the security surface is particularly significant. An agent that takes actions — executes transactions, sends communications, modifies records — needs access controls, audit trails, and anomaly detection from the outset
   

   Bias and fairness.

   Who will this AI system affect, and could it treat different groups differently in ways that are unintentional, harmful, or unlawful? 
   
   This is most acute for systems that make or support decisions affecting people — but it is worth asking of every AI project, not just the obviously high-stakes ones.
   

8. What skills and resources are required?

   Documented clearly, with gaps identified and a plan to close them.  
   
   The answer should cover: 
   
   > Data engineering,
   > Data science,
   > Software development,
   > Domain expertise,
   > Project management,
   > Change management, and 
   > Ongoing operational support post-deployment. 
   
   For each, identify whether the capability exists internally, needs to be hired, needs to be trained, or needs to be sourced through partnership.

POC or Pilot?

The distinction that saves projects.

Assuming the Go/No-Go gate is passed, the next decision is how to proceed. And here, another piece of terminology confusion does real damage: the difference between a Proof of Concept and a Pilot (or MVP: Minimum Viable Product).

These are not the same thing, and conflating them leads to either under-investment in early learning or over-investment before assumptions are validated.

Proof of Concept (POC): confirming capability.

A Proof of Concept asks: can the technology do what we think it can do?

It is a technical validation exercise, conducted in a controlled environment, using representative data, to confirm that the AI approach under consideration is technically feasible for the problem at hand. A POC typically:

> Uses a controlled or sandboxed environment, not the production system,
> May use synthetic, anonymised, or a limited sample of real data,
> Is evaluated by the technical team and a small group of domain experts,
> Has a binary output: yes, the technology can address this problem / no, it cannot, and
> Is time-boxed and budget-capped — typically weeks, not months.

A POC does not prove that the solution will deliver value in a real environment.

It proves that the capability exists.

This is valuable — and essential before committing to a full pilot — but it is not proof of real-world value.

Treating a successful POC as a green light for full deployment is a common mistake. A technology that works in a controlled environment with clean data and expert users may fail completely in a production environment with noisy data and real users. 

Pilot (MVP): confirming real-world value.

A Pilot — or MVP: Minimum Viable Product — asks: can this solution deliver real value in a real environment, to real users, solving a real problem?

It is a production-equivalent test, using real data and real users, in the actual operational context where the solution will eventually run. A Pilot typically:

> Operates in the live environment with real data (with appropriate controls and monitoring),
> Involves actual end users from the target function or team,
> Is evaluated against the success metrics defined in Phase 1,
> Produces evidence of real-world impact — or real-world limitations — that a POC cannot, and
> Has a defined scope of no more than one or two core use cases — not the full ambition of the program.

A Pilot — or MVP: Minimum Viable Product — asks: can this solution deliver real value in a real environment, to real users, solving a real problem?

The Pilot is where you find out what the POC did not tell you, such as:

> How users actually interact with the system,
> What edge cases emerge in real data, 
> Where the integration pain points are, and
> What the organisational response is when the AI makes a mistake.

The correct sequencing:

→ Feasibility Assessment

→ Go/No-Go Gate

→ Proof of Concept (POC)

→ Pilot (MVP)

→ Program Roll-out.

Each stage answers a different question. Each stage is a decision point where the organisation can choose to proceed, adjust, or stop — with far less cost than discovering problems later.

This Phase Is Where Consultants Earn Their Fees.

The Business Understanding phase is the most important and the most skipped. It's skipped because it doesn't produce anything that looks like progress — no code, no dashboards, no demos. It produces questions, assessments, and a decision.

But that decision, made rigorously at the start, is what determines the shape of everything that follows. An AI program with clear problem definition, validated feasibility, committed buy-in, and a well-designed go/no-go gate runs differently from one that started with enthusiasm and a technology selection. It makes better use of its data team. It delivers earlier value. It encounters fewer organisational surprises. And when it hits problems — which all AI projects do — it has the documented baseline and governance structure to address them without losing momentum.

This is precisely where experienced program and project management adds disproportionate value in AI initiatives.

The technical capabilities to build AI systems have become increasingly available. The governance discipline to deploy them successfully has not.

Getting Phase 1 right is not glamorous.

It is, however, what separates the 10% of AI projects that deliver measurable value from the 90% that don't.

Take the AI Feasibility Test here > free resources.

………

This content series is informed by the PMI Certified Professional in Managing AI (PMI-CPMAI™) program — a six-phase methodology developed by the Project Management Institute to help professionals plan, deliver, and operationalise AI initiatives responsibly.

PMI's commitment to building a structured, tool-agnostic framework for AI project management is exactly the kind of rigour the industry needs as AI moves from pilot to production. I'd encourage any project or program professional navigating this space to explore their work at pmi.org.