The Criterion Most AI Prioritisation Frameworks Ignore — and Why That Is Costing Programmes Their Business Case

Most AI prioritisation frameworks score how valuable a use case is and how hard it is to build. Almost none score how hard it is for the organisation to actually use it. That omission is where business cases go to die.

There is a particular kind of AI programme post-mortem that is worth understanding in detail. The model performed well on the test set. The MLOps deployment went smoothly. The model is in production, generating inferences, running at volume. By every technical metric, this use case was a success.

And yet, six months after go-live, the business value projected in the original case has not materialised. The finance team is asking questions. The programme team is scrambling for an explanation.

The explanation, almost always, is adoption. Users are not acting on the model's outputs. Override rates are above 40% and rising. The business process the model was designed to augment has not been redesigned — the AI recommendation sits alongside the manual process, adding a review step rather than replacing one. The productivity saving never arrived because the change management required to capture it was never resourced.

This is not a technology failure. It is a change management failure that was entirely predictable at use case selection — and entirely absent from the scoring framework that selected the use case.

EXECUTIVE SUMMARY

Four reasons change management demand must be a scored dimension in any AI use case prioritisation framework:

1.    AI value is adoption-conditional — a model that users do not trust, cannot act on, or actively resist delivers no business value regardless of technical performance.

2.    Change management cost is inversely proportional to when it starts — effort begun at selection is a fraction of the effort required after resistance has organised.

3.    Override rate is the most reliable early signal of adoption failure — and it is directly linked to change management decisions made at use case selection, not at go-live.

The inverted D4 scoring scale ensures that high change management demand depresses the composite score — making Wave 1 concentration of difficult adoption profiles visible before commitment.

Why Change Management Demand Is Missing from Most AI Scoring Frameworks

The omission of change management demand from AI use case prioritisation frameworks is not accidental. It reflects a systematic bias in how enterprise AI programmes are organised and governed.

AI programmes are typically conceived, designed, and governed by technology-facing functions — IT, data, architecture, and the programme office. The selection criteria that get formalised in prioritisation tools reflect the concerns of those functions: value delivered, technical buildability, data availability. These are real and important criteria. They are also insufficient.

Change management is not a technology function. It sits in HR, organisational development, or a dedicated change practice. In most enterprise AI programmes, change management resource is brought in after the shortlist is agreed, the build plan is drafted, and the delivery dates are set. By that point, the use cases that demand the most change management effort have already been committed — and the change management team is being asked to solve a problem they had no input in creating.

THE STRUCTURAL PROBLEM

Change management is sequenced after use case selection in most programmes. But the change management demand of a use case is determined at selection — not at go-live. By the time the change team arrives, the scope of their problem has already been fixed by decisions they did not participate in.

What Change Management Demand Actually Measures

Change management demand — Dimension 4 in a structured AI use case scoring framework — measures the human cost of adoption. It captures four things simultaneously: the size and sensitivity of the affected user population, the degree of process redesign required for users to realise value from the AI output, the resistance profile of the affected group, and the presence of regulatory or union complexity that requires specialist engagement before deployment.

None of these factors are technical. All of them are predictable at use case selection with the right evidence gathering. And all of them determine whether the business value projected in the original use case will actually be realised after deployment.

The Inverted Scale — and Why It Is Deliberate

Change Management Demand uses the same inverted scoring scale as Technical Complexity. A score of 5 means very low demand — small affected population, minimal process change, high sponsor enthusiasm, no regulatory complexity. A score of 1 means very high demand — large or sensitive affected population, fundamental process transformation, organised resistance, unresolved regulatory or union complexity.

The inversion ensures consistency: across all five dimensions, a score of 5 always represents a favourable outcome for the programme. A high D4 score means low change management burden. A low D4 score means the use case carries a heavy adoption load that will require significant investment to manage — and that investment needs to be planned and budgeted before the use case enters Wave 1, not discovered during sprint 3.

INVERTED SCALE RULE

When scoring D4, ask: 'How disruptive is this change for the people it affects?' Score 5 if disruption is very low. Score 1 if it is very high. A use case affecting 2,000 call centre agents whose roles change materially is a 1. A use case augmenting a team of 30 analysts who requested the tool is a 5. The scoring question makes this explicit.

The D4 Scoring Reference: Five States of Change Management Demand

Each score level in the Change Management Demand dimension reflects a specific, evidence-anchored state of adoption complexity. The table below defines all five levels with the specific indicators that justify each score — and the wave assignment guidance that follows from each.

D4 — Change Management Demand Scoring Reference (Weight: 15% of Composite Score)

The scoring discipline that matters most for D4 is that the score reflects the state today — not after change management has been applied. A use case that scores 2 on D4 does not become a score of 4 because the programme plans to run a good change management campaign. The score reflects the inherent demand of the use case. The change management plan is the response to that demand — it is not the score itself.

This distinction matters because it prevents aspirational scoring. A programme team that scores D4 at 4 because they intend to manage change well is masking a high-demand use case behind a planned intervention. The intervention may not be funded. It may not be resourced at the right level. It may start too late. The score must reflect the demand, so that the resourcing decision is made explicitly rather than buried in an optimistic composite.

The Five Adoption Failure Patterns Change Management Demand Predicts

Change management demand is not a theoretical concern. Each score level on D4 maps to a specific adoption failure pattern that plays out predictably when the demand is not met. Understanding these patterns at use case selection is the only point at which they can be prevented at zero cost.

Adoption Failure Patterns by Change Management Root Cause

The most expensive pattern in the table is organised resistance — because it consumes executive attention, delays the entire wave, and creates a narrative about the programme that persists beyond the specific use case. The most common pattern is ghost adoption — technically live, behaviourally dormant — because it is invisible in deployment metrics until a business review asks why projected savings have not materialised.

Both patterns are predictable at selection. Ghost adoption is the outcome of a use case scored 3 on D4 where no process decommissioning plan was built. Organised resistance is the outcome of a use case scored 1 or 2 on D4 where union or regulatory stakeholders were not engaged before deployment.

That is not an adoption challenge. It is a selection consequence. The change management demand was visible at use case scoring. The programme proceeded anyway — without the change infrastructure to support it.

Override Rate: The Adoption Signal D4 Predicts

The most operationally useful leading indicator of change management failure in a deployed AI model is the user override rate — the percentage of AI recommendations that users review and then discard in favour of their own judgement or the previous manual process.

An override rate below 20% is generally acceptable and reflects normal human-in-the-loop behaviour — users review, occasionally correct, and mostly act on AI outputs. An override rate between 20% and 35% is an amber signal — worth investigating, but not necessarily critical. An override rate above 35% and rising is a red signal that the model is not being trusted, and that something in the adoption approach has failed.

Why Override Rate Is a D4 Signal, Not a Model Signal

The instinctive explanation for a high override rate is model quality — users are overriding because the model is wrong. This is sometimes correct. But in the majority of high override rate cases encountered in enterprise AI programmes, the model quality is adequate and the problem is adoption.

Users override AI recommendations when they do not understand why the recommendation was made. They override when the recommendation conflicts with tacit domain knowledge that was not incorporated into the model. They override when they were not trained on what to do when the model is uncertain. They override when the change management investment communicated 'here is a new tool' rather than 'here is how your role changes and why.'

Each of these causes is traceable back to a D4 scoring decision. A use case that required meaningful process redesign (D4 score 3 or below) and was deployed without a formal change plan will produce high override rates within 60 days of go-live. The model did not fail. The adoption was not supported.

OVERRIDE RATE RULE

A rising override rate three months after go-live is a retrospective indicator of a change management failure that was predictable at use case selection. The corrective investment — re-engaging users, explaining model logic, redesigning the process interface — costs three to five times more after go-live than the same change management investment at wave planning would have cost.

How D4 Interacts With the Other Four Dimensions

Change management demand does not operate in isolation in a composite scoring framework. Its most significant programme risk emerges not from high D4 alone but from combinations — particularly the interaction between D4 and D3 (technical complexity) and between D4 and D5 (time to value).

D4 Interaction Patterns — Change Management Demand Combined With Other Dimensions

The most dangerous combination in the table is the double-low: high technical complexity (D3 score 1–2) and high change management demand (D4 score 1–2) simultaneously. This combination means the build is risky and the adoption is risky — and any delay in the technical build directly extends the change management exposure period. In practice, this combination almost always leads to a programme where the model is eventually deployed to a user population that has been waiting too long, has developed alternative processes, and has no particular motivation to adopt the AI output.

The triple alignment — low technical complexity, low change demand, strong data — is the inverse: the ideal Wave 1 profile. When D3 and D4 both score 4 or 5, and D2 is strong, the composite score will be high regardless of D1. The boring use case, described in Blog 4 of this series, is precisely the use case that hits this triple alignment.

How Change Management Demand Should Inform Wave Planning

D4 scoring does more than deprioritise high-demand use cases. It generates a specific set of actions for each score level that must be built into the programme plan before Wave 1 commits.

Change Management Effort Calibration by D4 Score

The timing column in the table above is the most important column for programme planning purposes. Change management that starts four weeks before go-live is adequate for a D4 score of 5. It is catastrophically insufficient for a D4 score of 2 or 1. The error that produces organised resistance and adoption cliffs is not that change management was absent — it is that change management started at the wrong point in the programme for the level of demand the use case carried.

Reading the change management start date from the D4 score at selection is the earliest possible point at which this decision can be made correctly. It is also the cheapest point. A programme that plans change management resource and timing from the D4 score at selection has the full programme delivery window to build the stakeholder relationships, communication channels, and training infrastructure that adoption requires.

Scoring D4 Honestly in a Facilitated Session

D4 is the dimension most likely to be scored aspirationally in a facilitated session. The reasons are structural: the business unit owner is present, they want their use case to proceed, and a low D4 score creates the impression that they are presenting a problematic or controversial initiative.

The scoring discipline is the same as for D2: the score reflects the current state of the affected population and their relationship to the proposed change — not the planned state after change management has been applied.

Three Questions That Produce Honest D4 Scores

• How many people does this use case directly affect, and what is their current sentiment toward AI augmentation of their role? If the answer is 'we haven't asked them yet', the score is 2 at best. Sentiment is evidence. Assumption is not.
• Has the business process that AI will augment or replace been redesigned to capture the AI output? If the model produces a recommendation and the current process has no defined action for that recommendation, the process redesign has not been done. That is a D4 score of 3 at best — not 4 or 5.
• Are there union agreements, professional body standards, or regulatory requirements that govern how AI can be used in this role? If yes and they have not been reviewed, the D4 score should reflect the unresolved complexity — not the intended resolution. Score the current state.

The programme team's role is to ensure these questions are asked of the right people — not the business unit owner alone, but the affected team leads, the HR or employee relations partner, and the legal or compliance team where regulatory complexity applies. D4 scoring is a multi-stakeholder evidence exercise, not a business unit self-assessment.

Change Management Demand Is Not a Soft Dimension

The framing of change management as a 'soft' or secondary concern in AI programmes is one of the most expensive misconceptions in enterprise AI delivery. It is soft only in the sense that it involves human behaviour rather than technical systems. Its consequences — ghost adoption, override cascades, organised resistance, parallel processing — are entirely hard in their impact on programme ROI, steering committee credibility, and the business case that justified the investment.

Scoring change management demand explicitly, at use case selection, before any delivery commitment is made, is the discipline that prevents these consequences. It is not a guarantee of smooth adoption. It is the necessary condition for planning adoption correctly — with the right resource, starting at the right time, calibrated to the actual demand the use case carries.

The 15% weight assigned to D4 in a composite scoring framework is deliberately modest relative to Business Value (30%) and Data Feasibility (25%). But a D4 score of 1 — very high demand, unresolved complexity, no change management plan — will depress a composite score by approximately 0.6 to 0.8 points, enough to move a use case from Wave 1 to Wave 2. That signal is intentional. A use case with unmanaged high change demand in Wave 1 is a programme liability. The framework makes that visible before the commitment is made.

Change management demand is not an afterthought that follows the build. It is a selection criterion that precedes it. The programmes that score it explicitly, plan to it specifically, and resource it proportionately consistently outperform those that treat adoption as something that happens naturally when a good model is deployed.

AI Use Case Prioritisation Framework — viksya.com

Change Management Demand (D4) is built into the AI Use Case Prioritisation Framework as a full scoring dimension — with inverted scale, five evidence-anchored score states, and a 15% weight in the composite. Use cases scoring 1 on D4 are deprioritised automatically. The framework scores all five dimensions, produces a ranked shortlist, and flags portfolio-level risks including combinations of high D3 and high D4 that signal critical Wave 1 exposure.

Built for Programme Managers, CIOs, Strategy Leads, and Management Consultants. Excel-based. No code. Instant download.

→ Download the AI Use Case Prioritisation Framework 

Frequently Asked Questions

What is change management demand in AI use case prioritisation?

Change management demand in AI use case prioritisation is a scored criterion that measures the human cost of adopting a specific AI use case — covering the size and sensitivity of the affected user population, the degree of process redesign required to realise value, the resistance profile of the affected group, and the presence of regulatory or union complexity. In the AI Use Case Prioritisation Framework from Viksya, Change Management Demand is Dimension 4 (D4), weighted at 15% of the composite score, and uses an inverted scale where score 5 means very low demand and score 1 means very high demand.

Why do AI use cases fail adoption rather than technology?

AI use cases most commonly fail adoption rather than technology because the change management investment required to realise business value from the AI output is not planned, resourced, or timed correctly at the use case selection stage. A model that produces accurate recommendations delivers no business value if users do not trust those recommendations, cannot act on them in their current process, or are not supported through the process redesign required to make the AI output actionable. These are change management failures — and all of them are predictable at use case selection from the characteristics of the use case.

What is an AI model override rate and why does it matter?

An AI model override rate is the percentage of AI-generated recommendations that users review and discard in favour of their own judgement or an alternative process. An override rate below 20% reflects normal human-in-the-loop behaviour. An override rate above 35% and rising is a signal of adoption failure — typically indicating that users do not understand why the model is making recommendations, do not trust the model's outputs, or were not supported through the process change required to act on AI recommendations consistently. Override rate is directly linked to the change management investment made at and after deployment — and is predictable from the D4 score assigned at use case selection.

How is change management demand different from technical complexity in AI scoring?

Technical complexity (D3) measures how difficult an AI use case is to build — covering model architecture, data engineering requirements, and MLOps infrastructure. Change management demand (D4) measures how difficult the AI use case is for the organisation to adopt — covering user population size and sentiment, process redesign requirements, resistance profile, and regulatory complexity. Both use inverted scales in a structured scoring framework. High technical complexity makes the build expensive and risky. High change management demand makes the adoption expensive and risky. A use case can score well on one and poorly on the other — making both dimensions necessary in a complete prioritisation framework.

When should change management planning start for an AI use case?

Change management planning should start at the point of use case selection — not after the model is built. For low-demand use cases (D4 score 4–5), a change management plan four to six weeks before go-live is appropriate. For moderate-demand use cases (D4 score 3), a dedicated change manager and formal change plan starting ten to twelve weeks before go-live is the minimum. For high-demand use cases (D4 score 1–2), change management engagement should start before the use case is formally committed to a delivery wave — including stakeholder analysis, union or HR consultation, and resistance management planning. The earlier the change management investment, the lower the total cost of achieving the target adoption level.

Continue Reading — Viksya Insights

→ The gut-feel problem: why most AI use case selection processes produce the wrong shortlist 

→ Data feasibility as a hard gate: why AI Wave 1 fails when data readiness is assumed 

→ Business value vs. technical complexity — the 2×2 every AI programme team should be using

→ Why your first AI Use Case should be boring -- the Wave 1 use case selection approach

→ AI Production Governance Toolkit — structured go/no-go before every model deployment

Viksya Editorial

Viksya publishes structured governance tools and practitioner content for enterprise AI and digital transformation programmes. All tools are available at viksya.com.

Change Management · AI Use Case Prioritisation · Enterprise AI · AI Adoption · Programme Delivery · Workforce Impact · AI Governance · Wave Planning · Override Rate