AI Project Business Case Quick Health Checklist

Executive Summary

AI initiatives are often approved before the conditions needed for a credible business case have been tested. A compelling use case, an impressive demonstration, or a positive vendor proposal can create momentum, but none of these confirms that the initiative has an accountable owner, measurable value, usable data, realistic lifecycle costs, an adoptable workflow, or an acceptable risk position.

Resource 06 provides a rapid, structured challenge before significant budget is committed. It examines fourteen business-case conditions across five themes: strategic intent; value and ROI rigour; delivery readiness; cost and financial health; and risk and change readiness. For each item, the workbook describes three states:

1. Green - Healthy: the required condition is clearly supported;
2. Yellow - Caution: the condition is partly supported and requires a documented response; and
3. Red - Stop: the condition is not adequately supported and should be resolved before the initiative progresses.

Three items receive particular emphasis because their absence undermines the foundation of the business case:

1. a financially accountable Value Owner with active sponsorship;
2. a measurable business outcome and credible ROI logic; and
3. an adequate data foundation.

A Red on any of these critical items should halt the business case before further investment. More generally, the workbook defines Red as a stop condition: the issue should be resolved and escalated to the appropriate human authority rather than being offset by stronger results elsewhere.

The checklist is intentionally fast and judgement-based. It is a static rubric. It contains no response-entry column, dropdowns, formulas, automated scoring, weighted calculation, or automatically generated overall verdict. The user compares available evidence with the Healthy, Caution, and Stop descriptions and records the selected judgement, supporting evidence, and any follow-up actions outside the master workbook or in a controlled working copy established by the organisation.

Resource 06 is the first screening tool in a connected investment sequence:

Resource 06 - Rapid health check → Resource 07 - Quantified readiness assessment → Resource 08 - Integrated investment and lifecycle decision analysis

Its principal value is not numerical precision. Its value is disciplined early challenge. It helps decision-makers identify weak assumptions before detailed modelling begins, makes critical gaps visible, and creates a better evidence base for the more detailed assessments that follow.

1. Purpose and Scope

1.1 Purpose

The AI Project Business Case Quick Health Checklist helps project managers, business leads, sponsors, Finance, and governance bodies determine whether a proposed AI initiative has the minimum structural foundations needed to progress to more detailed assessment.

It is designed to answer an early question:

Is this AI proposal sufficiently credible and supportable to justify further analysis and commitment?

It does not answer whether the initiative should receive final approval. Instead, it identifies whether there is enough evidence to continue, whether identified gaps can be managed, or whether progression should stop until foundational conditions are corrected.

1.2 Scope

The checklist covers:

1. definition of the business problem and intended value;
2. accountable sponsorship and value ownership;
3. outcome, baseline, and ROI logic;
4. strategic and portfolio relevance;
5. data availability, quality, rights, and preparation;
6. realistic MVP or pilot scope;
7. AI, data, and human-oversight capability;
8. workflow integration and operating-model implications;
9. lifecycle and usage-sensitive cost assumptions;
10. model maintenance and continuing operational cost;
11. reversible, value-based funding decisions;
12. stakeholder expectations, adoption, and change readiness;
13. early value delivery; and
14. regulatory and ethical risk.

The checklist is a business-case health check. It is not a technical design review, security assessment, data audit, legal opinion, vendor evaluation, compliance certification, or substitute for detailed financial analysis.

1.3 Intended Timing

Resource 06 should normally be used before substantial budget, procurement commitment, or delivery mobilisation. It can also be used when an existing proposal is being materially revised or when a decision-maker wants a rapid check before authorising a more detailed readiness or investment review.

The source workbook is designed for a rapid assessment that can be completed in less than thirty minutes when the necessary evidence is already available. That duration is not a target for gathering missing evidence. If the evidence cannot be produced, that absence is itself relevant to the assessment.

2. Position Within the AIPM Toolkit

2.1 Role in the Evidence Chain

The AIPM Toolkit connects business justification, governance, cost, value, monitoring, and lifecycle decisions. Resource 06 provides the first structured investment screen within that chain.

It converts broad governance principles into practical questions before detailed analysis begins. The checklist asks whether the initiative has a real problem to solve, an accountable owner, a credible value hypothesis, supportable data assumptions, a realistic delivery path, lifecycle cost awareness, and an acceptable readiness position.

The output is not a final investment decision. It is an evidence-based signal that determines the appropriate next action:

1. continue to detailed readiness assessment;
2. continue only after specified mitigations are accepted; or
3. stop and resolve foundational weaknesses before proceeding.

2.2 Relationship to Resource 07

Resource 07, the AI Project Pre-Commitment Readiness Scoring Grid, provides a more granular and quantified assessment across ten readiness dimensions. Resource 06 should be completed first.

The fourteen check items in Resource 06 feed into the ten broader dimensions in Resource 07. This is not a one-to-one transfer and there is no automated link between the files. Resource 06 screens the evidence and identifies blockers; Resource 07 then evaluates readiness in greater depth using its own scoring logic.

The normal entry condition for Resource 07 is:

1. no unresolved Red conditions; and
2. every Yellow condition has a documented gap, named owner, and accepted mitigation.

2.3 Relationship to Resource 08

Resource 08, the AI Investment Case and Lifecycle Decision Workbook, brings together lifecycle cost, benefits, ROI, affordability, assumptions, and decision support. Resource 06 improves the quality of that analysis by testing whether the underlying business-case assumptions are credible before they are modelled in detail.

Resource 06 should therefore provide Resource 08 with better-grounded inputs, including:

1. the defined problem and intended outcome;
2. the accountable Value Owner;
3. baseline and benefit assumptions;
4. accuracy and performance assumptions relevant to value;
5. data-readiness findings;
6. initial lifecycle cost considerations;
7. workflow, adoption, and human-oversight implications;
8. regulatory and ethical considerations; and
9. known gaps, mitigations, and conditions for continuation.

Within the current publication set, the relevant downstream resource is Resource 08 — AI Investment Case and Lifecycle Decision Workbook.

2.4 Independent Use

Although Resource 06 forms part of a connected sequence, it can also be used independently as a rapid challenge tool. For example:

1. a sponsor may use it before agreeing to support an AI proposal;
2. a PMO may use it when screening ideas entering a portfolio funnel;
3. Finance may use it before accepting a request for detailed modelling;
4. a business unit may use it before engaging a vendor; or
5. an investment committee may use it to identify missing evidence before placing an item on its formal agenda.

Independent use should not be mistaken for final approval. The checklist identifies health conditions; it does not replace the organisation’s governance or investment-authority process.

3. Why AI Business Cases Need an Early Health Check

AI business cases share many features with other investments, but several characteristics make early challenge particularly important.

3.1 Costs Extend Beyond the Initial Build

An AI initiative may incur continuing costs for licences, tokens or other consumption, infrastructure, specialist talent, quality review, human oversight, monitoring, governance, retraining, model refresh, support, and change management. A business case based primarily on the build phase or a vendor quote can materially understate total investment.

Resource 06 surfaces these assumptions early through its data, TCO, maintenance, workflow, and funding checks. It does not calculate lifecycle cost; it tests whether lifecycle cost has been recognised and is ready for more detailed analysis in Resource 08.

3.2 AI Output Quality Is Probabilistic

Traditional software requirements are often framed as deterministic functions. AI outputs commonly involve distributions of accuracy, quality, confidence, or error. Business value may change significantly at different performance levels, and higher accuracy may require additional data, specialist review, controls, or operating cost.

The checklist therefore challenges business cases that assume perfect accuracy or rely on a single unsupported performance target. It encourages the team to connect expected AI performance with measurable business outcomes and realistic ROI assumptions.

3.3 Adoption Can Increase Cost

Successful adoption can increase the number of users, prompts, transactions, API calls, reviews, exceptions, and support requirements. The cost profile may rise as the initiative succeeds. A credible business case should therefore consider how adoption changes both value and cost, rather than treating usage growth as cost-neutral.

3.4 AI Must Fit the Operating Workflow

An AI output does not create value by existing. It must be incorporated into decisions, processes, controls, responsibilities, and human work. If the operating workflow has not been mapped and redesigned, the organisation may produce outputs that are not trusted, not used, or too costly to review.

3.5 Continued Funding Should Depend on Continued Value

AI solutions can change because of data drift, model changes, vendor pricing, adoption patterns, regulation, and operating conditions. Resource 06 includes a “Value as a Service” or VaaS re-buy test: can the organisation reconsider, pause, adapt, or stop investment when the expected value is no longer supported?

This is a governance principle, not an automated subscription mechanism. It challenges fixed commitments, sunk-cost behaviour, and avoidable vendor or technology lock-in.

4. Intended Users and Governance Roles

Resource 06 is most effective as a short cross-functional challenge, not as a solitary administrative exercise.

The PM or business lead may complete the initial review, but Finance and the Value Owner should review the result. Subject-matter specialists should contribute where the proposal depends on claims that the core assessment group cannot validate.

Human accountability remains central. The workbook provides criteria and prompts; it does not make, approve, or authorise a decision.

5. Workbook Structure and Operating Model

The Excel workbook contains four visible tabs.

The workbook currently opens on Playbook-Overview, even though the internal instructions direct the user to begin with Read Me.

5.1 Static Rubric - No Automated Scoring

The workbook is intentionally simple, but users should understand its operating boundary:

1. it has no dedicated response-entry column;
2. it has no dropdown or data-validation controls;
3. it has no formulas or weighted calculation;
4. it does not calculate an overall result;
5. it has no embedded fields for evidence, mitigation owners, due dates, approval, or sign-off; and
6. it does not transfer information automatically to Resources 07 or 08.

The assessment team must compare the project evidence with the three narrative descriptions and record the result through its controlled business-case or decision-record process. If an organisation uses an annotated copy of the workbook, it should preserve the publication master unchanged and clearly identify the working copy, initiative, assessment date, and version.

5.2 What the Workbook Produces

When used properly, the workbook produces a governed set of human judgements:

1. a Green, Yellow, or Red result for each of the fourteen items;
2. identification of critical blockers;
3. a list of evidence gaps and caution conditions;
4. named mitigation obligations outside the master workbook; and
5. a conclusion on whether the initiative is ready to enter Resource 07.

It does not produce a calculated composite score or a final investment recommendation.

6. Evidence to Assemble Before Starting

The quality of the assessment depends on the quality of the evidence. The following evidence should be available or explicitly identified as missing.

Five assumptions receive particular attention in the Read Me tab:

1. AI output: what the AI will and will not produce, and whether the output is advisory, draft, decision support, or automated;
2. Value and ROI: the P&L or equivalent outcome, baseline, payback expectation, and performance assumptions;
3. Data readiness: data completeness, quality, permission, ownership, preparation cost, and use-case suitability;
4. Total cost of ownership: build cost plus continuing run costs, rather than the vendor quote alone; and
5. Regulatory and ethical risk: applicable obligations, assessment requirements, and accountable sign-off.

Evidence need not be perfect at this stage, but the assessment should distinguish between supported facts, reasonable assumptions, unresolved uncertainty, and unsupported optimism.

7. How to Complete the Checklist

7.1 Prepare the Assessment

1. Identify the initiative, business area, assessment date, and version of the proposal being reviewed.
2. Confirm the PM or facilitator, business lead, Value Owner, Finance representative, and any required specialists.
3. Assemble the evidence described in Section 6.
4. Agree where the item results, evidence references, and actions will be recorded. The master workbook does not provide those fields.
5. Read the Read Me and Playbook-Overview tabs before the first facilitated use.

7.2 Review Each Item

For each of the fourteen items:

1. Read the Healthy, Caution, and Stop descriptions in full.
2. Ask the business lead to present the evidence, not only the intended future action.
3. Test whether the evidence supports the condition for this specific initiative.
4. Select the description that most closely reflects the current state.
5. Record the Green, Yellow, or Red judgement in the organisation’s assessment record.
6. Record the evidence used and any assumptions or dissenting views.
7. If Yellow, document the gap, owner, mitigation, due date or decision point, and evidence required for closure.
8. If Red, stop progression and escalate the condition for resolution.

The result should reflect the current evidence. A promise that a condition will be addressed later does not make the current result Green.

7.3 Apply the Decision Rules

1. Green: the condition is clearly met. Record the supporting evidence and continue.
2. Yellow: the condition is only partly met. Progress should be conditional on a documented mitigation with a named owner.
3. Red: the condition is not met. Do not proceed until it is resolved; escalate to the Value Owner and Finance or other relevant authority.

Items 2, 3, and 5 are critical halt conditions. A Red on any of these should halt the business case before further investment.

Do not average the item results. A large number of Greens does not cancel a Red, and the workbook contains no weighting logic that permits such an offset.

7.4 Conclude the Review

At the end of the assessment:

1. confirm the result for every item;
2. list all unresolved Reds;
3. list every Yellow and its mitigation owner;
4. identify evidence that must be obtained or validated;
5. record the human decision and decision authority;
6. state whether the initiative will stop, return for rework, or proceed to Resource 07; and
7. retain the assessment with the business-case package.

The checklist supports the decision; it does not replace formal authorisation.

8. The Five Themes and Fourteen Check Items

Figure 1. Resource 06 health-check matrix, Items 1-6.

Figure 2. Resource 06 health-check matrix, Items 7-14.

8.1 Theme 1 - Strategic Intent

Strategic intent tests whether the initiative begins with a real business need, has accountable leadership, and deserves organisational attention.

Item 1 - Problem-Value Fit

What it tests: Whether the proposal addresses a clear business problem with observable or measurable consequences, rather than beginning with technology enthusiasm or fear of missing out.

Evidence to examine: A specific problem statement; current-state baseline; affected users or stakeholders; financial, operational, customer, risk, or strategic impact; and the causal connection between the proposed AI capability and the intended improvement.

Decision relevance: A weak problem definition makes later ROI, scope, data, and adoption assumptions unstable. Quantification should be proportionate to the decision, but the proposal should show why the problem matters and why action is justified.

Item 2 - The Value Owner and Sponsorship - Critical

What it tests: Whether a named person is accountable for the value case, has appropriate financial authority, remains actively engaged, and can stop or redirect the initiative when continued investment is no longer justified.

Evidence to examine: Named Value Owner; budget accountability; decision rights; active sponsorship; escalation route; confirmation of ring-fenced or otherwise authorised funding; and continued-value review responsibilities.

Decision relevance: Sponsorship without financial accountability may be insufficient. If no one owns the value and has authority to challenge continuation, the initiative is exposed to passive sponsorship and sunk-cost behaviour. A Red is a critical halt condition.

Item 4 - Strategic Fit and Portfolio Priority

What it tests: Whether the initiative supports a meaningful organisational priority and can compete credibly for funding, leadership attention, data, and specialist resources.

Evidence to examine: Link to strategic objectives; portfolio ranking; leadership commitment; funding source; dependencies or overlap with other initiatives; and the consequence of delaying or not proceeding.

Decision relevance: A proposal can be attractive in isolation but remain a poor portfolio choice. Strategic linkage should be specific enough to guide trade-offs rather than relying on a generic statement that AI is important.

8.2 Theme 2 - Value and ROI Rigour

This theme tests whether success is defined as a business outcome and whether the proposal can create useful value before requiring a large, irreversible commitment.

Item 3 - Outcome Alignment and ROI - Critical

What it tests: Whether success is expressed as a measurable business outcome and whether ROI reflects realistic AI performance rather than assuming perfect or binary accuracy.

Evidence to examine: Outcome statement; baseline; benefit metric; financial conversion where appropriate; payback expectation; performance or accuracy thresholds; sensitivity or scenario analysis; non-financial benefits and adverse effects; and the method for validating realised value.

Decision relevance: A technical output-such as deploying a model-does not itself demonstrate value. The business case should show how different levels of AI performance affect operating outcomes, cost, and return. A Red is a critical halt condition.

Item 13 - Early Value Strategy

What it tests: Whether the initiative can create measurable learning or value before an all-or-nothing deployment, with appropriate use of AI-plus-human augmentation and phased implementation.

Evidence to examine: Early use cases; intermediate outcomes; pilot learning objectives; augmentation opportunities; phased benefit profile; coordination improvements; and measures that will show whether early value is materialising.

Decision relevance: The source rubric challenges proposals that expect no useful value for an extended period or rely entirely on a future full-automation launch. References to value “within weeks” are contextual challenge criteria, not a universal requirement. Regulated, safety-critical, or complex initiatives may need longer lead times, but should still identify credible intermediate evidence and decision points.

8.3 Theme 3 - Delivery Readiness

Delivery readiness tests whether the initial scope is realistic, the required capability exists, and the AI output can be integrated into real work.

Item 6 - Build Scope and Realism

What it tests: Whether an MVP or pilot is sufficiently bounded to produce measurable evidence within a credible timeframe.

Evidence to examine: Defined scope and exclusions; deliverables; measurable pilot outcomes; dependencies; delivery approach; acceptance criteria; resource availability; and a realistic schedule.

Decision relevance: Enterprise-wide scope, open-ended exploration, and the absence of intermediate milestones make cost and value difficult to govern. The source rubric uses a working pilot within ninety days as a challenge criterion. This should be tailored to context rather than treated as a universal deadline; the governing principle is bounded scope and timely decision evidence.

Item 7 - AI and Data Talent

What it tests: Whether the initiative has access to the AI, ML, data-engineering, product, assurance, and operational skills required to deliver and operate the solution, including human oversight.

Evidence to examine: Named roles; capacity and availability; internal and vendor capability; skill gaps; recruitment or contracting assumptions; assurance and review requirements; human-oversight workload; and associated cost.

Decision relevance: Capability assumed to be found later creates schedule, quality, cost, and governance risk. Vendor capability does not remove the organisation’s responsibility to provide informed ownership, review, and operational control.

Item 8 - Workflow Integration Plan

What it tests: Whether the AI output has been designed into the end-to-end workflow, including human decisions, exceptions, handoffs, controls, and operating ownership.

Evidence to examine: Current and future process maps; users; decision rights; input and output handoffs; human validation; exception treatment; override paths; service measures; control points; and ongoing process ownership.

Decision relevance: An AI tool added on top of an unchanged process may increase work, create duplicate controls, or fail to influence decisions. Workflow redesign should begin before build assumptions become fixed.

8.4 Theme 4 - Cost and Financial Health

This theme tests whether the business case recognises the full cost of obtaining, operating, governing, and continuing to justify the AI capability.

Item 5 - Data Foundation - Critical

What it tests: Whether data has been assessed for quality, access, permission, ownership, preparation needs, governance, and fitness for the specific use case.

Evidence to examine: Source inventory; data ownership; rights to use; lineage; completeness; quality findings; representativeness; access; security and privacy constraints; preparation effort; pipeline needs; and governance controls.

Decision relevance: “The data exists” is not evidence that it is usable. If data assumptions are untested or there is no provision for validation and preparation, the business case may materially understate cost and overstate achievable performance. A Red is a critical halt condition.

The source rubric refers to data cleaning as 60-80% of budget in its Healthy description. This should be treated as a challenge to recognise potentially substantial data work, not as a universal budgeting formula. The appropriate provision must be based on the actual use case and evidence.

Item 9 - TCO Multipliers

What it tests: Whether total cost includes the less visible and usage-sensitive costs that continue beyond initial development.

Evidence to examine: Licences; tokens or consumption; compute or GPUs; environments; integration; data work; specialist talent; quality review; human oversight; security; governance; assurance; support; scaling; and change management.

Decision relevance: A static vendor quote or build-only estimate does not establish TCO. Resource 06 tests whether the cost perimeter is credible; Resource 08 performs the detailed lifecycle investment analysis.

Item 10 - Maintenance Tail

What it tests: Whether continuing OpEx is recognised for monitoring, drift detection, retraining, model or prompt refresh, testing, deployment, quality assurance, incident response, and support.

Evidence to examine: Run-state operating model; accountable teams; monitoring measures; refresh or retraining approach; service levels; test and release controls; vendor responsibilities; and recurring budget.

Decision relevance: AI maintenance is broader than conventional bug fixing. A solution that performs acceptably at launch may deteriorate as data, user behaviour, business rules, models, or external conditions change.

Item 11 - VaaS “Re-Buy” Test

What it tests: Whether the organisation can reconsider continued funding based on demonstrated value and can pause, adapt, or terminate the initiative without avoidable lock-in.

Evidence to examine: Funding stages; continuation criteria; value-review cadence; contractual exit provisions; data and model portability; vendor dependency; technology dependency; switching cost; and authority to stop.

Decision relevance: Full upfront commitment can weaken governance by allowing sunk cost to replace evidence. The VaaS concept in the workbook is a continued-value discipline: investment should be re-justified when material evidence changes.

8.5 Theme 5 - Risk and Change Readiness

This theme tests whether the organisation is ready to adopt the capability responsibly and whether applicable obligations and potential harms have been identified.

Item 12 - Stakeholder Expectations and Adoption

What it tests: Whether stakeholders understand the intended use and limitations of the AI capability and whether adoption has been planned and resourced.

Evidence to examine: Stakeholder analysis; communications; training; role impacts; trust concerns; workforce anxiety; user support; adoption measures; feedback mechanisms; and change resources.

Decision relevance: Expectations that AI will be effortless, infallible, or fully autonomous can damage trust and distort the business case. Adoption assumptions affect both benefit and cost and should be visible before commitment.

Item 14 - Regulatory and Ethical Risk

What it tests: Whether applicable regulatory, legal, privacy, ethical, bias, fairness, transparency, security, and data-rights issues have been identified, resourced, and assigned to accountable reviewers.

Evidence to examine: Risk classification; applicable law and policy; data-use rights; privacy or impact assessment requirements; bias and fairness review; explainability and traceability needs; control design; compliance budget; and sign-off authority.

Decision relevance: A general statement that Legal will review the project later is not equivalent to a scoped risk assessment. References in the workbook to the EU AI Act, DORA, NIST AI RMF, or other frameworks are prompts rather than an exhaustive or permanently current list. Applicable obligations must be validated for the initiative’s jurisdiction, sector, use case, and date.

9. Decision, Escalation, and Mitigation Logic

9.1 Green - Healthy

Green means that the criterion is clearly met based on available evidence. The assessment record should identify that evidence so the judgement can be traced and revisited if assumptions change.

Green does not mean risk-free, permanently approved, or exempt from detailed assessment. It means the condition is sufficiently supported for this stage.

9.2 Yellow - Caution

Yellow means that the criterion is partly met, uncertain, or dependent on an unresolved action. A Yellow should not be treated as an informal promise to “deal with it later.”

At minimum, the external mitigation record should contain:

Every Yellow should have an accepted mitigation before the business case is submitted or before Resource 07 begins, in accordance with the organisation’s governance process.

9.3 Red - Stop

Red means that the condition is not met and progression should stop until it is resolved. The condition should be escalated to the Value Owner, Finance, and any relevant governance authority.

A Red should not be converted into Yellow solely because the issue is uncomfortable, time is limited, or the team intends to address it after approval. Evidence of resolution is required.

9.4 Critical Halt Conditions

Items 2, 3, and 5 are foundational:

1. no accountable Value Owner;
2. no measurable outcome and credible ROI logic; or
3. no supportable data foundation.

A Red in any of these areas should halt the business case before further investment. These conditions affect the legitimacy of the investment itself, not merely the convenience of delivery.

9.5 No Averaging or Offset

Resource 06 contains no numeric scale, weighting, formula, or aggregation rule. The team should not invent an average score and should not allow several Green results to offset a Red.

The correct interpretation is condition-based:

1. unresolved Red → stop and resolve;
2. no Red, but unresolved Yellow → conditional or return for mitigation;
3. no Red and all Yellows controlled → eligible to proceed to Resource 07.

The responsible human authority records the decision.

10. Outputs and Handoffs to Resources 07 and 08

10.1 Minimum Output Package

A completed Resource 06 review should produce:

1. initiative name and proposal version;
2. assessment date and participants;
3. Green, Yellow, or Red judgement for all fourteen items;
4. evidence references supporting each judgement;
5. identified critical halt conditions;
6. mitigation records for every Yellow;
7. resolution evidence for any former Red;
8. a recorded human decision to stop, rework, or continue; and
9. the name and authority of the decision-maker.

Because the workbook does not contain fields for these outputs, they must be maintained in the controlled business-case package, decision log, governance record, or authorised working copy.

10.2 Handoff to Resource 07

Resource 07 should receive the evidence, assumptions, and mitigation position established during Resource 06. The transfer is manual and analytical; there is no linked formula or automatic data transfer.

Resource 07 then applies its own ten-dimension scored readiness assessment. Fourteen Resource 06 items are consolidated into those broader readiness dimensions, so users should carry the evidence and rationale forward rather than attempting a mechanical item-to-item conversion.

If Resource 07 exposes a deeper weakness, the team should revisit the relevant Resource 06 judgement rather than treating the earlier result as fixed.

10.3 Handoff to Resource 08

Resource 08 should use the validated or qualified assumptions from Resources 06 and 07 to develop the integrated investment case and lifecycle decision analysis.

Particular handoff points include:

1. problem, baseline, and outcome definition;
2. Value Owner and decision authority;
3. benefit and performance assumptions;
4. data preparation and governance cost;
5. usage-sensitive and run-state costs;
6. maintenance and monitoring assumptions;
7. adoption profile and change cost;
8. regulatory, ethical, privacy, and control cost;
9. vendor or technology dependency; and
10. continuation, pause, adaptation, and exit conditions.

Resource 06 tests whether these subjects have been recognised. Resource 08 quantifies and integrates them for financial and lifecycle decisions.

11. Using the Checklist Well

11.1 Ask for Evidence, Not Confidence

Confidence, enthusiasm, and executive interest are not substitutes for evidence. Where an assertion cannot yet be supported, record the uncertainty honestly and select the corresponding Yellow or Red condition.

11.2 Assess the Current State

The checklist evaluates the proposal as it stands. Future actions belong in the mitigation plan. They should not be used to make a current weakness appear resolved.

11.3 Preserve Constructive Challenge

The assessment should include people who can challenge the proposal independently. The Value Owner, Finance, data specialists, process owner, and relevant risk functions contribute different evidence and should not be expected to reach Green merely to maintain momentum.

11.4 Tailor Thresholds Without Weakening Principles

The workbook uses several directional challenge criteria, including a pilot within ninety days, early value within weeks, and substantial provision for data preparation. These criteria are intended to test realism. They should be adapted to organisational and use-case context without weakening the underlying principles of bounded scope, early evidence, and fully recognised data work.

11.5 Keep the Checklist Short

Resource 06 should remain a rapid filter. If an item requires lengthy analysis, record the gap and route it to the appropriate detailed assessment. Do not turn the quick health check into a duplicate of Resources 07 or 08.

11.6 Do Not Use It as a Compliance Badge

A set of Green judgements is not a certification. It confirms only that the evidence was considered sufficiently healthy for the next stage at the stated date and proposal version.

12. Records, Review, and Reassessment

12.1 Record Retention

The completed assessment should be retained as part of the business-case and governance record. The record should make it possible to reconstruct:

1. what proposal was assessed;
2. what evidence was considered;
3. who participated;
4. what judgement was made for each item;
5. what cautions or stops were identified;
6. what mitigations were accepted;
7. who made the continuation decision; and
8. which version subsequently entered Resources 07 and 08.

This traceability matters because the workbook itself does not store structured responses or approval history.

12.2 Version Control

The assessment should identify the initiative and proposal version. If a working copy of the workbook is annotated, its file name or cover record should include the initiative, assessment date, and version. The publication master should remain unchanged.

12.3 Reassessment Triggers

Resource 06 is designed primarily for pre-commitment use. As a good-governance practice, the health check may also be repeated when a material assumption changes, including:

1. a change in the business problem, outcome, or scope;
2. replacement or withdrawal of the Value Owner;
3. a major change in data availability, quality, or usage rights;
4. a material change in expected AI performance or ROI;
5. a vendor, model, platform, or pricing change;
6. a significant workflow or operating-model change;
7. a major adoption issue;
8. a new regulatory, ethical, privacy, security, or compliance requirement; or
9. evidence that cost, value, or risk assumptions no longer hold.

These are governance triggers for a fresh human review; the workbook does not monitor them automatically.

12.4 Closing Mitigations

A mitigation should be closed only when the agreed evidence is available and the authorised reviewer accepts the revised condition. The updated judgement, evidence, reviewer, and date should be recorded. If the mitigation changes the business case materially, the relevant Resource 07 and Resource 08 inputs should also be revisited.

13. Limitations and Appropriate Use

Resource 06 is valuable because it is simple and fast, but that simplicity creates boundaries.

13.1 Static and Manual

The workbook has no automated scoring, data capture, calculation, weighted result, dashboard, or system integration. It relies on disciplined human judgement and an external record.

13.2 Not a Final Investment Decision

The checklist identifies whether foundational conditions are healthy enough for deeper review. It does not calculate affordability, approve budget, authorise procurement, or replace formal governance.

13.3 Not a Technical Feasibility Review

It does not validate architecture, model selection, integration, cybersecurity, performance, safety, or engineering feasibility. Specialist reviews remain necessary.

13.4 Not a Data Audit

The data item asks whether appropriate data work has been performed and funded; it does not perform that work or verify the data directly.

13.5 Not Legal or Compliance Advice

The regulatory and ethical item is a screening prompt. Applicable laws, standards, policies, and assessment requirements change by jurisdiction, sector, use case, and time and must be confirmed by qualified functions.

13.6 Not a Vendor Benchmark

The checklist does not compare products, suppliers, models, contract terms, or market prices. Vendor evidence should be independently validated where it supports a judgement.

13.7 Contextual Thresholds

Time and cost ratios appearing in the rubric are challenge criteria, not universally applicable facts. They should stimulate evidence-based discussion rather than be applied mechanically.

13.8 Judgement and Bias

Narrative criteria can be interpreted differently by different participants. Cross-functional review, evidence references, explicit dissent, and named decision authority reduce the risk of optimistic or politically influenced scoring.

13.9 No One-to-One Mapping to Resource 07

Resource 06 contains fourteen items; Resource 07 contains ten scored dimensions. The relationship is thematic and evidential, not a direct automated conversion.

13.10 Point-in-Time Result

A Green condition can become Yellow or Red when assumptions change. The assessment is valid for the evidence, date, and proposal version recorded-not indefinitely.

14. Practitioner Quick Reference

Before the Session

1. Confirm the initiative and proposal version.
2. Name the Value Owner and Finance reviewer.
3. Assemble the evidence pack.
4. Invite the required data, technology, process, risk, and change specialists.
5. Establish the external assessment and mitigation record.

During the Session

1. Read all three descriptions for each item.
2. Judge the current evidence, not future intention.
3. Record one Green, Yellow, or Red result per item.
4. Capture the evidence and any dissent.
5. Stop and escalate unresolved Reds.
6. Give every Yellow a named owner and mitigation.

Before Progressing

1. Confirm that all fourteen items were assessed.
2. Confirm that Items 2, 3, and 5 are not Red.
3. Confirm that no other Red remains unresolved.
4. Confirm that every Yellow has an accepted mitigation.
5. Record the human decision and authority.
6. Retain the assessment with the business case.
7. Carry the evidence into Resource 07 and, subsequently, Resource 08.

Core Decision Rule

No unresolved Red. No unmanaged Yellow. No progression without accountable human judgement.

15. License and Disclaimer

License

© 2026 Marcin Nowakowski. This article is published under a Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) licence. You are free to share and adapt the text of this article provided you give appropriate credit, indicate if any changes were made (including prior modifications), and distribute any adapted version under the same licence.

All proprietary frameworks, named methodologies, tools, distinctive terminology, and proprietary know-how referenced in this article are strictly excluded from this licence and remain the exclusive intellectual property of the author. No rights to use, modify, or commercialise such intellectual property are granted.

Where this article references methodologies, frameworks, or tools owned by third parties, all intellectual property rights in those materials remain with their respective owners. Such references are for informational and educational purposes only and do not imply any affiliation with, or endorsement by, those rights holders.

Disclaimer

This article is provided for general informational and educational purposes only. It does not constitute financial, legal, technical, or any other form of professional advice, and no reliance should be placed on it as such. Readers should independently verify any information relevant to their specific circumstances before making decisions. No warranty-express or implied-is given as to the accuracy, completeness, fitness for a particular purpose, or suitability of this content for any specific situation. To the fullest extent permitted by applicable law, the author excludes all liability, whether in contract, tort, or otherwise, for any direct, indirect, or consequential loss or damage arising from the use of, or reliance on, this article. Nothing in this disclaimer limits liability where such limitation is not permitted under applicable law. Where material decisions are involved, qualified professional advice should always be sought.