The Feasability Tests.

Most AI projects don't fail because the technology didn't work. They fail because nobody asked the right questions before the project started.

The data is consistent and uncomfortable: somewhere between 70% and 95% of enterprise AI initiatives fail to reach production or deliver measurable business value, depending on which study you read. 

Gartner puts the figure at over 40% of agentic AI projects specifically expected to be cancelled by 2027 due to "escalating costs, unclear business value, or inadequate risk controls."

MIT research found that only 5% of AI pilots deliver meaningful profit impact.

These are not failures of engineering. They are failures of planning — specifically, failures to honestly assess feasibility before a single line of code was written or a single vendor was selected.

The antidote - a structured, rigorous Business Understanding: the first and most important phase of any AI initiative. 

At its core, Business Understanding comes down to 3 tests. And each one has a binary quality - you pass it or you don't. A strong pass on two and a weak pass on the third is not a green light. It's a flag.

ROI Comes First.

What it actually means in AI.

Before reaching the 3 tests, there is a prior question every sponsor needs to answer: what are you hoping to gain?

This sounds obvious, and in most organisations it is addressed — but often at a level of abstraction that does not hold up when the project hits friction. 

"We want to be more efficient" is not a ROI definition. "We want to reduce the time our accounts payable team spends on invoice processing from four hours per day to forty-five minutes" is.

In AI projects, ROI needs to be defined across four dimensions to be useful:

Financial.

What is the measurable monetary impact — cost reduction, revenue increase, risk reduction with a dollar value attached? Be specific. An AI-assisted fraud detection system that reduces annual fraud losses from $4.2 million to $1.8 million has a ROI conversation. One that will "significantly reduce fraud" does not.

Time.

What manual effort will this eliminate or reduce? Where does that time go — into higher-value work, reduced headcount, faster cycle times? If the answer is "it frees people up," the follow-on question is: freed up to do what, specifically?

Data Integrity.

Will this improve the quality, consistency, or completeness of our data? For organisations dealing with manual data entry, fragmented records, or high rates of human error in data processes, this is a legitimate and significant ROI — but it needs to be quantified.

Audit & Compliance.

Will this create better audit trails, reduce compliance risk, or enable reporting that is currently manual and error-prone? 

Regulatory cost avoidance is real ROI; it just needs to be expressed as such.

If your ROI case does not have numbers attached to at least two of these four dimensions, the project is not ready to proceed to feasibility assessment. You have not defined what success looks like, which means you cannot assess whether it is achievable.

Test 1: Business Feasability.

Business feasibility asks the foundational question: is this a real problem that AI is the right tool to solve?

This sounds simple. It rarely is. In practice, many AI initiatives are launched because AI is interesting or because a competitor has done something that generated headlines — not because there is a clearly defined, high-priority problem that specifically benefits from cognitive technology.

There are 3 questions at the core of business feasibility. All 3 need clear, affirmative answers:

Is there a clear problem with a clear definition?

Vague problem statements produce vague AI systems that produce vague results. 

"Improve customer experience" is not a problem definition. "Reduce the average time to resolve a Tier 1 customer service query from 8 minutes to under 3 minutes" is.

"Improve our reporting" is not a problem definition. "Eliminate the 14-hour manual consolidation process our finance team runs at month-end" is.

The discipline here is specificity — and the willingness to push back when the problem statement is not precise enough to be measured. If you cannot write a sentence that ends with "and we will know we have solved it when [metric] changes from [X] to [Y]," the problem is not defined.

Is the organisation willing to invest in change?

This is the question that sponsors often underestimate, because they conflate "willing to fund the technology" with "willing to change how the organisation works." These are different things.

AI systems do not just add a tool — they change processes, change roles, change decision-making workflows, and sometimes change who holds authority within a team or a function. 

A conversational AI that handles 40% of customer service queries does not just reduce call volume. It changes what the remaining customer service staff spend their time on, changes the skills they need, and changes how performance is measured. 

This is an organisational change program, not a software deployment..

If the sponsor is willing to buy the technology but not willing to manage the change around it, the project is already in trouble. Change management is not a soft extra that gets added if there's budget left. It is core to whether the investment returns any value

Is there sufficient ROI or impact to justify the investment?

AI projects carry real costs — not just the technology licence, but also:

> The data preparation, 
> The integration work,
> The governance and compliance overhead, 
> The training, the ongoing monitoring and maintenance. 

These costs are consistently underestimated in initial proposals.

The ROI calculation needs to account for total cost of ownership over a realistic time horizon, not just the sticker price of the software. A system that delivers $200,000 of annual value but costs $400,000 to implement and $150,000 a year to maintain is not a good investment — regardless of how compelling the demo was.

Test 2: Data Feasibility.

Data feasibility is where the largest number of AI projects die — often after substantial investment has already been made. The discipline is asking the hard data questions at the start of the project, not after the model has been built.

Does your data measure what you actually care about?

This is subtler than it sounds. An organisation may have abundant data about a process without having data about the aspect of that process that matters. 

A hospital might have excellent records of which treatments were administered, but poor data on patient-reported outcomes — which is what you'd actually need to build a predictive model for treatment effectiveness. 

A retailer might have transaction data but no data linking transactions to specific customers, making personalisation patterns impossible to build.

Before any data science work begins, the fundamental question is: do our existing data assets actually represent the problem we are trying to solve?

Is there enough data, and is it accessible?

Most AI patterns — particularly Recognition, Predictive Analytics, and Anomaly Detection — require meaningful volumes of data to train effectively. 

"Meaningful" varies by pattern and complexity, but as a rough orientation: simple classification models might train adequately on thousands of examples; complex recognition systems may need millions of labelled instances; language models require billions of tokens.

Volume is only half the question. 

Accessibility matters equally. Data that exists in a legacy system that requires a six-month data extraction project to access, or data that lives in paper records that require manual digitisation, or data that is technically owned by a third party whose contractual terms do not permit AI training — all of these are accessibility problems that need to be scoped and costed before the project is approved.

Is the data quality sufficient?

Most AI patterns — particularly Recognition, Predictive Analytics, and Anomaly Detection — require meaningful volumes of data to train effectively. 

Completeness.

Are there significant gaps? 

A dataset with 40% missing values for a key field is a problem. How it's a problem depends on which field, which pattern, and which imputation strategies are viable — but it needs to be surfaced and addressed, not glossed over.

Accuracy.

Does the data reflect reality? 

Entered data frequently contains errors — typos, misclassifications, outdated records, duplicates. The famous "garbage in, garbage out" principle is most visibly true in predictive analytics: a model trained on inaccurate historical data will make inaccurate predictions with high confidence.

Consistency.

Is the same thing described the same way across different data sources? 

Data that uses different codes, different date formats, different customer identifier schemas across systems requires harmonisation before it can be used for training — and that harmonisation work is often underestimated. 

Bias.

Does the data reflect the full range of what the AI system will encounter in production? 

Training data that over-represents certain groups, time periods, geographies, or scenarios and under-represents others will produce a model that performs well on what it was trained on and poorly — sometimes dangerously — on everything else.

Test 3: Implementation Feasability.

Implementation feasibility asks: can we actually build and deploy this, given our current capabilities, and within a timeframe that still delivers value?

Do you have the required technology and skills?

AI projects require an unusual combination of skills: 
> Data engineering, 
> Data science or ML engineering, 
> Software development, 
> Domain expertise, 
> Change management, and 
> Project management that understands how AI project lifecycles differ from conventional software development.

Very few organisations have all of these skills in-house at the level required, and that's not a failure — it's a planning input. 

The question is not "do we have everything internally?" but "do we have a realistic plan to assemble the capability we need, whether through hiring, training, or partnership?"

The skill gaps most frequently underestimated are not the technical ones.

Business analysts who can translate operational requirements into data science specs, domain experts who can validate whether a model's outputs make sense, and project managers who understand iterative AI development cycles — these roles are harder to fill than ML engineers, and their absence causes more project failures.

Can you execute the model in a timely manner?

AI projects that take eighteen months to deliver their first output in a fast-moving market may find that the business problem has evolved, the regulatory landscape has shifted, or a competitor has moved faster. 

Time-to-value matters.

This doesn't mean AI projects need to be rushed. It means they need to be structured for early, incremental value delivery rather than a single large release at the end of a long build. 

The Proof of Concept and Pilot model (addressed in the next post in this series) is the answer to this — breaking the initiative into a sequence of stages that test assumptions early and deliver learnings incrementally.

Can the model operate where you plan to use it?

This is the deployment environment question, and it's often treated as an afterthought. 

A model built and validated in a controlled environment may encounter significant obstacles when deployed into the real operating context: 
> Latency constraints
> Integration requirements with legacy systems
> Mobile or edge deployment requirements 
> Regulatory constraints on where data can be processed
> User experience requirements the technical team wasn't aware of.

Deployment feasibility needs to be part of the initial scoping conversation, not a problem discovered after the model is built.

A note on Security.

Security is sometimes treated as a Phase 3 or Phase 4 concern — something to bolt on once the model is working. This is a dangerous sequencing mistake, and one that is increasingly attracting regulatory attention. 

Several security considerations are directly relevant to Business Understanding:

Data security in training.

The data used to train AI models often contains sensitive personal information, proprietary business data, or regulated records. 

How that data is secured during the training process, who has access to it, and how it is handled afterward are governance questions that need answers before the data is assembled, not after.

Model Security.

AI models can be subject to adversarial attacks — inputs specifically designed to cause the model to mis-classify or behave unexpectedly. 

For high-stakes applications (medical, financial, autonomous systems), this threat vector needs to be part of the initial risk assessment. 

Output security.

Generative AI and conversational systems can produce outputs that expose confidential information (through training data leakage), generate harmful content, or be manipulated through prompt injection. 

These risks need to be scoped and mitigated, not discovered in production. 

Agentic AI and autonomous action.

If the AI pattern under consideration is autonomous or goal-driven, the security surface is significantly larger. 

An agent that can take actions — send emails, execute transactions, modify records — needs access controls and audit trails that are designed from the start, not retrofitted.

The right place to address these is in the business feasibility and implementation feasibility assessments — as risk factors that affect project scope, cost, and go/no-go recommendations.

Putting it Together: The Feasibility Matrix.

When these three tests are completed honestly, the output is a feasibility matrix — a clear summary of where the project stands on each dimension, what the known risks and gaps are, and what would need to be true for each dimension to pass before work proceeds.

A project that passes all three with no significant gaps is genuinely ready to proceed to a Proof of Concept. 

A project with one weak feasibility dimension is a conditional go — with specific conditions that need to be met. 

A project with two weak dimensions needs fundamental rethinking before it moves forward.

The discipline is not allowing organisational enthusiasm, executive pressure, or sunk-cost reasoning to override an honest feasibility assessment. The projects that fail with the most damage are usually the ones where the feasibility questions were answered optimistically, not accurately.

Take the AI Feasibility Assessment 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.