AI Investment Case and Lifecycle Decision Workbook

Executive Summary

AI initiatives are frequently approved on the strength of a compelling demonstration, a narrow license estimate, or an optimistic productivity assumption. These inputs may be useful, but they do not constitute a defensible investment case. They often omit data preparation, evaluation, human review, governance, security, change, adoption, monitoring, recurring operation, retraining, vendor change, and eventual exit. Even when a credible case is approved, the original assumptions are not always carried into delivery and post-launch governance. The result is a break in the evidence chain: approval is based on one set of expectations, while later continuation decisions are made with different or incomplete information.

Resource 08 addresses this break by combining two related decision processes within one controlled workbook:

1. The investment-case decision asks, “Is the proposed AI investment financially defensible?” It brings together the current-state baseline, lifecycle cost, measurable benefits, uncertainty, financial scenarios, downside thresholds, and a four-state recommendation: Proceed, Proceed with Controls, Rework / Defer, or Do Not Proceed.
2. The lifecycle decision asks, “Given the latest evidence, what should happen next?” It uses fifteen KPIs covering business justification, accountability, cost sustainability, value realization, and lifecycle drift to support one of six recommendations: Stop, Pause, Redirect, Re-scope, Continue, or Accelerate.

These two decisions are intentionally separate. The investment case is a forecast-based assessment used to determine whether a proposal is ready to receive funding. The lifecycle dashboard is an evidence-based assessment used to determine whether continued funding and the current course remain justified. A sound forecast can later be invalidated by cost growth, weak adoption, missing baselines, deteriorating assumptions, or poor benefit realization. Equally, an initially conditional case can improve when evidence becomes stronger and value is demonstrated.

The workbook offers more than a financial calculator. Its value is the connection it creates across the initiative lifecycle:

1. A current-state cost pool clarifies the economic area that AI could influence without claiming the whole pool as savings.
2. A twelve-group cost taxonomy surfaces build, run, governance, monitoring, retraining, contingency, opportunity, and exit costs.
3. Separate benefit categories reduce the risk of presenting capacity value, hard-dollar savings, avoided cost, and soft value as if they were interchangeable.
4. Best, Base, and Worst scenarios, probability weights, a hurdle rate, and downside thresholds make uncertainty visible.
5. A KPI evidence log carries the approved case into delivery and operation.
6. Decision rules make the basis of the dashboard recommendation visible.
7. Human sign-off, override rationale, actions, owners, and review dates preserve accountability.

The workbook is designed to complement, not replace, the other AIPM Toolkit resources. Resource 06 provides an early business-case health check. Resource 07 assesses pre-commitment readiness. Resource 08 develops the quantified investment case and supports ongoing lifecycle decisions. Governance resources define roles and controls. Resource 09 explains the integrated workbook build. PRIISM provides an additional financial-authority lens. Benefits and ROI resources provide deeper measurement support.

The workbook is a controlled template for one initiative, not a multi-project portfolio system. Review Log records are append-only static gate records, the Resource 08 selector defaults to Latest Review, and the AI comparison follows the selected project cost source. The Cost Controls sheet remains approved guidance rather than a calculation engine. Dashboard rule precedence and native-Excel release validation remain open. Section 18 distinguishes closed, partially resolved, open, and deferred items.

Used with disciplined ownership, source documentation, Finance validation, append-only evidence, static decision snapshots, and accountable human authorization, Resource 08 can provide a strong bridge between AI ambition and defensible investment governance.

1. Purpose and Scope

1.1 Purpose

The purpose of Resource 08 is to help organizations answer two connected questions throughout the life of an AI initiative:

1. Should the organization commit resources to this initiative?
2. Does the latest evidence continue to justify the current level and direction of investment?

The workbook provides a structured place to capture assumptions, estimate lifecycle cost, define measurable benefits, model uncertainty, evaluate financial outcomes, log operating evidence, apply documented decision rules, and record the accountable human decision.

1.2 Scope

The workbook supports:

1. New AI ideas, pilots, proofs of concept, scaled rollouts, and strategic AI initiatives
2. Generative AI productivity tools, retrieval solutions, machine-learning applications, AI-enabled workflows, and agentic solutions, subject to suitable adaptation of inputs
3. Initial business-case development and funding requests
4. AI-versus-current-state and AI-versus-non-AI option discussion
5. Delivery and implementation gate reviews
6. Go-live readiness reviews
7. Post-go-live benefit and adoption reviews
8. Cost-to-complete and funding-sustainability discussion
9. Annual renewal, re-buy, renegotiation, continuation, re-scope, and retirement decisions
10. Documentation of recommendation, authorization, conditions, override rationale, and follow-up actions

1.3 What the workbook does not do

The workbook does not:

1. Authorize expenditure or replace an organization’s delegated authority
2. Establish that an AI solution is technically, legally, ethically, operationally, or regulatorily acceptable
3. Replace detailed solution architecture, technical feasibility, privacy, security, legal, procurement, model-risk, or compliance assessments
4. Prove benefits merely because they have been forecast
5. Turn capacity released into cash savings automatically
6. Provide market-standard pricing or universal financial thresholds
7. Operate as a portfolio database or enterprise system of record
8. Automatically collect actual cost, adoption, or benefit data from source systems
9. Eliminate the need for independent review of formulas, assumptions, evidence, and decision logic

1.4 Appropriate use

Resource 08 is most useful where a proposal has passed an initial screening and requires a more complete, transparent, and reviewable investment case. It is also useful when an approved initiative needs a common evidence structure for delivery and post-launch reviews.

For small exploratory activities, users may begin with Resources 06 and 07 and use a proportionate subset of Resource 08. For scaled or strategic investments, the full cost, benefit, scenario, evidence, and decision workflow should be applied.

2. Position within the AIPM Toolkit

2.1 The evidence chain

Resource 08 sits at the point where governance concepts become an executable investment and lifecycle decision process. Its relationship to the wider toolkit can be understood as one evidence chain:

1. Define the business problem, intended outcome, stakeholders, and governance context.
2. Screen the early business case and identify critical weaknesses.
3. Assess readiness before material commitment.
4. Cost the full lifecycle, including hidden and recurring exposure.
5. Value the benefits without confusing capacity, hard-dollar, avoided-cost, and intangible value.
6. Decide whether the initial investment is defensible.
7. Monitor actual cost, performance, adoption, and value evidence.
8. Reassess whether the initiative should stop, pause, redirect, re-scope, continue, or accelerate.
9. Record the accountable human decision, controls, rationale, and next review.

2.2 Relationship to key resources

2.3 Why a separate companion guide is needed

The workbook includes a Start_Here sheet and Resource 09 provides a build summary. Neither fully explains the value of the tool, the meaning of its financial and lifecycle outputs, the division of responsibilities, the evidence controls required, or the current-release limitations. This companion guide fills that gap while leaving Resource 09 as the technical record of how the integrated workbook was constructed.

3. Value Offered by the Workbook

3.1 A single controlled artifact across the lifecycle

The workbook brings forecast and actual evidence into one controlled artifact without treating them as the same thing. The original investment assumptions remain visible while later review evidence is logged separately. This supports a disciplined comparison between what the organization expected and what it is observing.

3.2 Full lifecycle cost visibility

AI cost is wider than licensing or initial development. The workbook’s cost taxonomy includes internal effort, specialist time, data preparation, evaluation, security, privacy, compliance, governance, adoption, monitoring, human review, retraining, contingency, vendor change, and exit. This helps reduce the common pattern in which an AI proposal appears attractive because essential costs are omitted or absorbed invisibly by operational teams.

3.3 More credible benefit claims

The workbook separates benefit types and asks how each will be measured and owned. It explicitly warns against presenting the full current-state AI-addressable cost pool as guaranteed savings. Productivity or capacity value must be adjusted for adoption, ramp-up, decay, and the percentage of released hours that can create usable value. Hard-dollar reduction should be linked to committed or contract-backed reduction. Soft value should be included only when Finance accepts the proxy and the evidence.

3.4 Explicit uncertainty and downside

Best, Base, and Worst scenarios make uncertainty visible instead of hiding it inside a single point estimate. Probability weights create an Expected NPV. The hurdle rate, minimum Expected NPV, and maximum acceptable Worst-Case loss make the financial decision rule explicit. These features move the discussion from “Is the ROI positive?” to “What assumptions drive the result, what is the credible downside, and what conditions must be controlled?”

3.5 Continued funding discipline

The lifecycle dashboard evaluates whether the business justification remains valid, whether accountable ownership exists, whether cost remains sustainable, whether benefits are being realized, and whether adoption or value is drifting. This reduces sunk-cost continuation and enables a wider range of responses than a binary go/no-go decision.

3.6 Human accountability and auditability

The workbook separates the formula-driven recommendation from the human decision. It provides fields for sign-off, override rationale, actions, owners, due dates, and the next review. The goal is not automated approval. The goal is a transparent, evidence-informed decision that can be explained later.

4. The Two-Decision Model

4.1 Investment-case recommendation

The investment-case engine is forecast-based. It asks whether the proposal is defensible before or at a funding decision. It uses:

1. Project and economic assumptions
2. Current-state AI-addressable cost pool
3. Year 0 build and Years 1-3 run costs
4. Measurable benefits by category
5. Adoption, ramp, decay, and hours-to-value assumptions
6. Best, Base, and Worst certainty factors
7. Scenario probabilities
8. Hurdle rate and decision thresholds
9. NPV, IRR, payback, ROI, and downside results

The four recommendation states are:

The recommendation does not approve the investment. The accountable authority must consider feasibility, risk, compliance, strategy, affordability, opportunity cost, and any factors outside the model before authorizing a decision.

4.2 Lifecycle recommendation

The lifecycle engine is evidence-based. It asks whether continued funding and the current course remain justified at a delivery, go-live, operating, or renewal review. It uses fifteen logged KPIs and produces one of six recommendations:

4.3 Why the recommendations should not be collapsed

The investment case and lifecycle decision serve different moments and rely on different evidence. A proposal may be financially defensible at approval but later require re-scope because adoption is weak. A pilot may initially require controls but later support acceleration when actual benefits and unit economics are strong. Keeping the two recommendations separate preserves the distinction between a forecast and a current evidence reading.

4.4 Recommendation, authorization, and action

Every review should produce three separate records:

1. Workbook recommendation: the formula-driven output based on the entered assumptions or evidence.
2. Human authorization: the decision made by the person or forum with delegated authority.
3. Required action: controls, mitigations, changes, owners, due dates, and the next review.

Agreement between the recommendation and the human decision should still be documented. An override requires greater explanation, not less.

5. Intended Users and Responsibilities

5.1 Primary users

The workbook is intended for coordinated use. No single role is expected to own every input or validate every conclusion.

5.2 Minimum accountability conditions

Before an investment recommendation is relied upon, the initiative should have:

1. A named Sponsor or Decision Owner
2. A named Value Owner
3. A Finance Partner or equivalent reviewer
4. A Project or Program Manager responsible for workbook control
5. Owners for the principal cost and benefit assumptions
6. A defined source and review date for material evidence
7. A decision authority and escalation path
8. A next review date and conditions that would trigger an earlier review

5.3 Human-in-Command principle

The workbook is designed to support Human-in-Command governance. A formula can apply agreed thresholds consistently, but it cannot assume accountability for the decision. The human authority must consider the completeness of evidence, the materiality of missing information, non-financial risks, feasibility, regulatory constraints, strategic options, and the consequences of both action and inaction.

6. Workbook Architecture

6.1 Visible working sheets

6.2 Hidden calculation and reference sheets

6.3 Data flow

Figure 1. The lifecycle Dashboard brings together KPI status, decision blocks, confidence, and recommendation logic.

The principal investment-case data flow is:

Project_Inputs → Cost_Model_Template or Worked_Example_ChatGPT → ROI_Benefits → Start_Here

The principal lifecycle data flow is:

KPI Logs → KPIs Table and Logic Rules → Dashboard → Review Logs and Start_Here

The two engines meet at the front-page summary and within the review conversation. They do not automatically convert forecast data into actual evidence. Users must deliberately refresh assumptions and log actual observations.

6.4 Editable and controlled areas

The workbook identifies inputs, assumptions, cost lines, evidence fields, ownership fields, notes, and human decisions as editable. Formula outputs, decision-rule formulas, validation lists, and load-bearing helper sheets should be treated as controlled content. The Dashboard sheet is protected. Other Resource 08 worksheets and workbook structure remain intentionally unprotected in this release. The PMO should therefore restrict access, preserve a publication master, and use controlled file-level versioning.

7. Preparing to Use the Workbook

Figure 2. Project_Inputs centralizes assumptions, rates, scenario probabilities, and decision thresholds.

7.1 Create a controlled initiative copy

Keep the published workbook as an unedited master. Create a separately named, access-controlled copy for each initiative. A practical filename is:

[Initiative] - AI Investment Case and Lifecycle Decision Workbook - [Version] - [Date].xlsx

The current workbook should be treated as a single-initiative model. Do not combine evidence from multiple initiatives in one KPI Logs table.

7.2 Confirm compatibility

The workbook uses modern spreadsheet functions, including LET, XMATCH, and SWITCH. Use a current version of Microsoft Excel and confirm that formulas recalculate without errors. Test explicitly before using the workbook in older Excel versions or other spreadsheet applications.

7.3 Establish ownership and decision authority

Before entering assumptions, confirm:

1. Who owns the intended business outcome?
2. Who can authorize funding?
3. Who can stop or pause the initiative?
4. Who validates cost assumptions?
5. Who validates benefit assumptions and actual benefit evidence?
6. Which forum reviews material exceptions or overrides?
7. What decision cadence and escalation triggers apply?

7.4 Define the decision in scope

State what decision the workbook is supporting. Examples include:

1. Whether to fund a discovery or pilot
2. Whether to move from pilot to scaled implementation
3. Whether to approve go-live
4. Whether to continue funding after a benefit review
5. Whether to renew or renegotiate a vendor arrangement
6. Whether to re-scope, redirect, or retire a capability

A model without a defined decision can accumulate detail without improving judgment.

7.5 Gather minimum source evidence

At minimum, prepare:

1. Problem statement and intended organizational outcome
2. Current-state process and performance baseline
3. User and volume estimates
4. Vendor, license, usage, and infrastructure assumptions
5. Internal loaded rates or approved costing approach
6. Data, integration, security, privacy, legal, and compliance requirements
7. Delivery and operating resource assumptions
8. Benefit hypotheses and measurement methods
9. Adoption and process-change assumptions
10. Approved hurdle rate and decision thresholds
11. Feasibility evidence and unresolved gaps
12. Named owners and source references

7.6 Remove or clearly identify example data

The workbook contains a worked ChatGPT Enterprise example and sample lifecycle review rows. Before using the workbook for an actual initiative:

1. Decide whether the cost-source toggle will use the worked example or the project template.
2. Replace project-input assumptions with initiative-specific values.
3. Replace or remove sample KPI and Review Log entries in the controlled working copy.
4. Confirm that the Dashboard selector points to the intended review.
5. Label any values retained for demonstration as illustrative.

7.7 Agree model governance

The PMO or model owner should define:

1. Who may edit assumptions and formulas
2. How input changes are approved
3. How versions are named and retained
4. How evidence sources are referenced
5. How formula changes are tested
6. How decision snapshots are preserved
7. How workbook access is controlled
8. How confidential commercial, employee, client, or regulatory data is handled

8. Building the Investment Case: Detailed Workflow

8.1 Step 1 - Define the initiative and archetype

In Project_Inputs, define the project archetype, the users or operating units in scope, the expected production scale, the pilot scale, and the proposed delivery period. The archetype should describe the economic and operating pattern, not merely name a technology.

Examples include:

1. Enterprise productivity rollout
2. Retrieval-augmented knowledge assistant
3. Predictive model supporting an operational decision
4. AI-enabled customer-service workflow
5. Agentic workflow with human approval

The archetype influences which cost lines apply, how benefits are measured, and how adoption and risk should be interpreted.

8.2 Step 2 - Confirm project tier and risk context

Select Pilot, Scaled, or Strategic and record:

1. Compliance applicability
2. Decision stakes
3. Reversibility
4. Explainability strategy
5. Feasibility status and gaps

Project tier is a scoping aid, not a substitute for assessment. A Pilot may still require extensive privacy, security, legal, or evaluation work if it uses sensitive data or affects consequential decisions.

8.3 Step 3 - Validate rates and resource drivers

Replace illustrative values for:

1. License rates and escalation
2. PM, SME, employee, and champion rates
3. Build and run resource levels
4. SME hours
5. Pilot and production user volumes
6. Working hours
7. Adoption support
8. Productivity dip during transition

Each material value should have a source or note. If the organization uses standard Finance rates, identify the rate set and effective date. If a vendor price is indicative or negotiated, label its status.

8.4 Step 4 - Establish the current-state AI-addressable cost pool

The current-state baseline estimates the cost of producing potentially AI-addressable work under the existing approach. It includes areas such as drafting, lookup, summarization, SME bottlenecks, waiting time, tools, external services, rework, and onboarding.

This cost pool is not:

1. Total organizational cost
2. Guaranteed savings
3. Replacement value
4. A claim that all affected labor will be removed

Its purpose is to define the economic area within which measurable benefits may occur. The benefit model then applies specific improvement, adoption, ramp, decay, and conversion assumptions rather than treating the entire pool as avoided cost.

Opportunity cost is shown separately because it is not automatically a cash saving. Use it as supporting value unless Finance approves a different treatment.

8.5 Step 5 - Build the lifecycle cost estimate

Figure 3. Cost_Model_Template structures Year 0 build and Years 1-3 operating cost by lifecycle cost group.

Use Cost_Model_Template for the initiative-specific estimate. Populate Year 0 build and Years 1-3 run cost for every applicable line. Review the full taxonomy in Cost_Reference, including the hidden-cost checklist.

For every material line, apply one of three outcomes:

1. Included in the estimate
2. Marked zero with a documented reason
3. Captured as an assumption or unresolved exposure with an owner and review date

Do not assume that a zero in the template means the cost is not applicable. Many zeroes are placeholders.

8.6 Step 6 - Separate cost types

The workbook distinguishes:

1. One-time build cost: discovery, setup, initial integration, initial evaluation, initial training, and similar items
2. Recurring run cost: licenses, usage, monitoring, support, governance, human review, refresh, and similar items
3. Both: activities that begin during build and continue in operation

This separation helps decision-makers see whether an apparently affordable implementation creates an unsustainable operating commitment.

8.7 Step 7 - Review the twelve cost groups

8.8 Step 8 - Test the non-AI alternative

Figure 4. AI_vs_Non-AI_Comparison places the AI option alongside current state and a non-AI alternative.

Use AI_vs_Non-AI_Comparison to avoid treating AI as the default solution. Compare:

1. Current state
2. Proposed AI option
3. A credible non-AI alternative, such as process redesign, conventional automation, revised controls, better search, or targeted system improvement

Compare cost, time to value, flexibility, adoption risk, vendor dependence, hidden-cost exposure, measurable benefits, net value, ROI, and payback. The current sheet includes illustrative worked-example values and TBD fields; tailor all relevant cells before using it as decision evidence.

8.9 Step 9 - Reconcile affordability and funding treatment

TCO is not the same as approved budget. Confirm:

1. Which costs require new cash funding
2. Which costs are internal effort
3. Which costs are pass-through or client-funded
4. Which costs are already approved
5. Which costs are notional or opportunity costs
6. Which costs remain uncertain or outside the current SOW
7. Whether the operating budget can sustain Years 1-3

8.10 Step 10 - Apply cost controls

Cost_Controls provides a method for discussing cost-to-complete and illustrative variance bands:

1. Green: up to 5 percent variance
2. Yellow: more than 5 percent and up to 15 percent
3. Red: more than 15 percent

These are illustrative defaults. Confirm organizational thresholds with Finance and the Sponsor. The sheet is guidance only; actuals, commitments, forecast-at-completion, and variance calculations must be maintained in an appropriate cost-control record or added through a governed enhancement.

9. Developing the Benefit Case

9.1 Begin with an outcome and baseline

Every benefit should connect to an intended organizational outcome and a measured or measurable baseline. A benefit statement should answer:

1. What will improve?
2. For whom?
3. Compared with what baseline?
4. By how much and by when?
5. How will it be measured?
6. Who owns the result?
7. What other change is required for the benefit to occur?

Without a baseline and accessible data, realized ROI cannot be demonstrated.

9.2 Keep benefit types separate

9.3 Prevent double counting

Common double-counting risks include:

1. Counting the same saved hours as both productivity and hard-dollar reduction
2. Counting lower rework in both quality and productivity
3. Counting the full cost pool as savings and then adding productivity benefits
4. Counting avoided headcount and released capacity simultaneously
5. Counting soft-risk proxies and the related hard-dollar avoided loss without reconciliation

Each benefit should have a clear boundary and owner. Where two benefit categories overlap, use the more defensible treatment or document the reconciliation.

9.4 Apply realization drivers

The workbook applies four important realization drivers:

1. Year 0 realization: recognizes that build and pilot periods provide only partial benefit
2. Year 1 ramp: recognizes that adoption and workflow change take time
3. Annual benefit decay: recognizes that value may erode without refresh, retraining, and operating discipline
4. Active adoption: limits benefit to meaningful use
5. Hours-to-value conversion: recognizes that time saved does not automatically become productive or financial value

These drivers should be evidence-based and owned. They are often more influential than the headline productivity percentage.

9.5 Use per-benefit certainty

The workbook provides Best, Base, and Worst certainty factors for each benefit row. This is preferable to applying one global confidence percentage because different benefit claims have different levels of evidence. A contract-backed tool reduction may have high certainty; an early productivity hypothesis may have much lower certainty.

9.6 Soft value

Soft value is switched off by default in the reviewed workbook. Include it only when:

1. The value is relevant to the decision
2. The proxy is clearly defined
3. The evidence source is identified
4. The accountable owner is named
5. Double counting has been addressed
6. Finance accepts its inclusion in the financial case

Soft value can still be reported qualitatively when it is not included in ROI.

9.7 Benefits-realization planning

The ROI_Benefits sheet includes a post-go-live tracking block for expected and realized values. At minimum, define:

1. KPI
2. Source driver
3. Expected result
4. Realized result by period
5. Variance
6. Accountable owner
7. Reporting cadence
8. Notes explaining major differences

The default reporting cadence shown in the workbook is quarterly, but the organization should select a cadence proportionate to the initiative and benefit profile.

10. Financial Metrics and Scenario Interpretation

10.1 Total cost of ownership

TCO includes Year 0 build plus Years 1-3 run cost. It should be read alongside the annual profile because two initiatives with the same TCO can create very different affordability, liquidity, and operating-budget implications.

10.2 Net value

Net value is:

Total measurable benefits - Total investment cost

A negative value indicates that modeled benefits do not recover modeled investment over the horizon. A positive value does not by itself establish feasibility, compliance, affordability, strategic fit, or authority to proceed.

10.3 Return on investment

The workbook calculates ROI as:

(Total measurable benefits - Total investment) / Total investment

Users should state the period, scenario, included benefit categories, and treatment of internal effort when communicating ROI.

10.4 Benefit-cost ratio

The benefit-cost ratio is:

Total measurable benefits / Total investment

A ratio above 1.0 indicates that modeled benefits exceed modeled cost over the period. A ratio below 1.0 indicates the opposite. The ratio should not be interpreted without the timing and risk of cash flows.

10.5 Payback and break-even

Payback identifies the first modeled year in which cumulative net value becomes non-negative. The reviewed workbook uses Year 0 through Year 3. “Beyond Year 3” means break-even was not achieved inside that horizon; it does not prove that break-even will occur later.

10.6 Net present value

NPV discounts future net cash flows using the hurdle rate recorded in Project_Inputs. The organization should replace the illustrative 8 percent rate with a Finance-approved rate or document why a different rate applies.

Positive NPV indicates that the modeled cash-flow case exceeds the applied hurdle rate. Negative NPV indicates that it does not. NPV is only as reliable as the cash-flow classification, timing, and assumptions supporting it.

10.7 Internal rate of return

IRR is the discount rate at which NPV equals zero. Compare it with the Finance-approved hurdle rate. IRR may be unavailable or misleading where cash flows do not produce a valid sign change or have unconventional patterns. In the worked example, IRR is shown as not available because the modeled net values remain negative.

10.8 Best, Base, and Worst scenarios

The workbook uses per-benefit certainty factors to produce:

1. Best Case: higher benefit certainty
2. Base Case: realistic central outcome
3. Worst Case: lower benefit certainty and downside outcome

The labels describe modeled scenarios, not statistical guarantees. The scenario factors should be supported by evidence and reviewed when material assumptions change.

10.9 Probability-weighted Expected NPV

Expected NPV is calculated as:

P(Pessimistic) × Worst NPV + P(Base) × Base NPV + P(Optimistic) × Best NPV

The reviewed workbook uses illustrative probabilities of 25 percent, 50 percent, and 25 percent. The probability check must equal 100 percent. Replace the defaults where initiative evidence supports a different distribution.

Expected NPV is a decision aid, not a promise of expected financial return. It compresses three scenarios into one value and should always be presented with the scenario range and downside.

10.10 Decision thresholds

The workbook contains:

1. Minimum acceptable Expected NPV
2. Maximum acceptable Worst-Case loss
3. Hurdle rate
4. Base-Case NPV test
5. Worst-Case payback test

These thresholds should be approved by Finance and the relevant authority. They should not be changed merely to make a proposal pass.

10.11 Sensitivity analysis

The workbook recommends changing one driver at a time, observing the effect on total benefits and ROI, and then restoring the baseline value. Prioritize:

1. Productivity gain
2. Active adoption
3. Hours-to-value conversion
4. Benefit certainty
5. License or usage cost
6. Build effort
7. Run cost
8. Annual decay
9. Time to value
10. Hurdle rate

Record the drivers to which the decision is most sensitive. These become monitoring priorities and potential invalidation conditions.

11. Interpreting the Business-Case Recommendation

11.1 Proceed

The workbook’s intended Proceed condition requires the modeled case to clear the minimum Expected NPV, maintain a non-negative Base-Case NPV, achieve Worst-Case payback within the modeled horizon, and remain above the accepted Worst-Case loss floor.

Before authorization, confirm that:

1. Feasibility is established
2. Critical risks and regulatory constraints are acceptable
3. Funding is available
4. Benefit and cost owners accept their assumptions
5. Measurement and governance controls are in place
6. The decision authority has reviewed the downside

11.2 Proceed with Controls

This recommendation means that the principal Expected NPV and downside conditions pass, but the case does not meet every condition required for an unqualified Proceed recommendation. Controls should be specific and decision-relevant, for example:

1. Limit initial scale
2. Require a baseline before the next release
3. Cap license or usage expenditure
4. Complete a security or privacy action before go-live
5. Establish a minimum adoption threshold
6. Require contract-backed savings evidence
7. Set a short review interval
8. Define a stop condition

11.3 Rework / Defer

Rework / Defer means that the current case should not be approved as presented. Appropriate responses include:

1. Reduce or stage scope
2. Reassess the non-AI alternative
3. Correct missing cost lines
4. Strengthen benefit evidence
5. Establish a baseline
6. Revise adoption or process-change assumptions
7. Negotiate commercial terms
8. Resolve feasibility gaps
9. Delay the request until material uncertainty is reduced

Rework is not approval to begin additional work unless that work is separately authorized.

11.4 Do Not Proceed

Do Not Proceed indicates unacceptable downside in the circumstances defined by the decision rule. The human authority should record whether the initiative is rejected, retired, redirected, or returned for a fundamentally different proposition. Safe closure, contractual, data-retention, employee, client, and regulatory obligations may still require action and funding.

11.5 Human sign-off

The ROI_Benefits sheet provides fields for reviewer, decision, override or deviation rationale, and date. Complete them for every formal investment decision. If the organizational approval record is held in another system, reference that record from the workbook.

12. Lifecycle Evidence Workflow

12.1 Purpose of the KPI log

KPI Logs is the primary lifecycle evidence-entry sheet. Each row represents one review point and contains the selected or measured value for fifteen KPIs. The Dashboard reads a selected Review ID, calculates status and trend, and applies the decision hierarchy.

12.2 Before each review

The PM should coordinate an evidence pack containing:

1. Latest approved baseline and forecast
2. Actual and committed cost
3. Forecast-at-completion or cost-to-complete assessment
4. Current run rate and unit economics
5. Benefit baseline and realized results
6. Core KPI performance
7. Adoption and use evidence
8. Assumption-validity review
9. Open hidden-cost or funding exposures
10. Decision-owner and stop-authority status
11. Material changes in technical, vendor, regulatory, security, privacy, or operating context

12.3 Enter one chronological review row

For each review:

1. Create a unique Review ID.
2. Enter the review date.
3. Select the lifecycle stage or gate.
4. Enter values or approved options for all fifteen KPIs.
5. Do not substitute a favorable assumption for missing evidence.
6. Append the row chronologically; do not insert it above later reviews without checking trend logic.
7. Retain the evidence pack or source references supporting the row.

The current Dashboard treats the last populated row as the latest review, rather than selecting the maximum date. Chronological, append-only entry is therefore an operating requirement.

12.4 Select the review

On the Dashboard, select the intended Review ID or Latest Review. Confirm that the displayed review date and stage match the intended evidence row before interpreting the recommendation.

12.5 Review KPI status and trend

The Dashboard groups the fifteen KPIs into baseline validity, cost reality, value evidence, and lifecycle drift. Review:

1. Current value or option
2. Status: Healthy, Caution, Critical, or Missing
3. Trend: Improving, Deteriorating, Stable, or No prior reading
4. Decision effect
5. Concentration of risk by decision block

A recommendation should never be reviewed without the underlying KPI distribution and the source evidence.

13. Lifecycle KPI Framework

13.1 Status thresholds

The current workbook applies the following thresholds:

The thresholds are model defaults. Any organizational change to them should be governed, documented, tested, and reflected consistently in the KPI table, logic documentation, and Dashboard formulas.

13.2 Decision blocks

Business Justification

Tests whether the initiative still solves a defined business problem, has defensible success criteria, and remains ready for commitment. A technically successful initiative can still fail this block if the business case has become invalid.

Accountability and Governance

Tests whether a Value Owner and stop authority exist and whether the original assumptions remain sufficiently valid. Weak ownership is not a documentation inconvenience; it is a decision risk.

Cost and Sustainability

Tests whether TCO, remaining funding, operating run rate, unit economics, and hidden exposure remain acceptable. It prevents the organization from reviewing cost only at approval.

Value Realization

Tests whether the baseline exists, benefits are being realized, the financial position remains defensible, and the core business KPI is moving.

Lifecycle Drift

Tests whether adoption and realized value are drifting away from the approved promise. Drift may require process redesign, retraining, scope change, or a different value pathway rather than additional technology alone.

13.3 Missing evidence

Missing evidence should remain visible as missing. It should not be converted automatically into a favorable status. The review authority should decide whether the missing evidence prevents a decision, requires a pause, or can be accepted temporarily with a named owner and due date.

14. Reading the Lifecycle Dashboard

14.1 Selected review

Confirm the Review ID, review date, and stage. The current sample workbook is set to an illustrative review rather than Latest Review; change the selector deliberately.

14.2 Recommendation and primary reason

The headline recommendation is produced by the decision hierarchy. The primary reason summarizes the highest-priority condition. Read it alongside the triggered-rule section because more than one rule may be active.

14.3 Confidence

The Dashboard displays High, Medium, or Low confidence based on the confidence values held in the KPI backbone. In the current release, these confidence values are not entered separately for each review. Treat the displayed confidence as a model indication, not a complete evidence-quality assessment. The review group should explicitly discuss source quality, recency, completeness, and independence.

14.4 Net value position

The Dashboard net-value position is a logged lifecycle evidence value from the KPI record. It is intentionally different from the forecast values shown in ROI_Benefits. Do not reconcile them by assuming one is wrong. Instead ask:

1. Is the lifecycle value actual, forecast, or a blended forecast-at-completion?
2. Is it measured over the same period as the investment case?
3. Are the benefit and cost definitions consistent?
4. Has the approved case been refreshed?

14.5 KPI status distribution

Review the number and percentage of Healthy, Caution, Critical, and Missing KPIs. A headline recommendation can conceal concentrated weakness. For example, a small number of hard-gate Criticals may outweigh many Healthy readings.

14.6 Risk concentration

The Dashboard shows the distribution of risk by decision block and identifies the highest-risk block using a score based on Critical and Caution counts. Use this to focus management action, not to replace judgment about the materiality of individual issues.

14.7 Trends

Trend compares the selected review with the prior populated row. It indicates direction, but not the size, duration, or cause of change. Because the current workbook is designed for one initiative, do not interleave multiple initiatives in the same log.

14.8 Triggered rules

The Dashboard displays whether the hard-gate, evidence, redirect, re-scope, default, and acceleration patterns are active. Review all active rules and document which condition the human decision addresses. Section 18 identifies current formula-precedence issues that should be considered when interpreting Pause and Redirect.

15. Human Decisions, Overrides, and Action Records

15.1 The human decision record

After reviewing the evidence and workbook recommendation, record:

1. Human decision
2. Whether it aligns with or overrides the recommendation
3. Decision Owner
4. Rationale
5. Required actions or controls
6. Action owner
7. Due date
8. Next review date
9. Status
10. Evidence snapshot or reference
11. Person recording the decision

15.2 When the decision aligns

Alignment should still be explained briefly. Record the principal evidence, conditions, and follow-up. “Agreed with the model” is not sufficient where the decision commits material resources or affects stakeholders.

15.3 When the decision overrides

An override may be appropriate where the model does not capture a material consideration, evidence has changed after the data cutoff, an urgent regulatory or operational obligation applies, or the authority accepts a specific risk within its mandate.

An override should state:

1. The workbook recommendation
2. The authorized decision
3. The evidence or consideration supporting the difference
4. The risk accepted
5. Required mitigation
6. Named owner and due date
7. Conditions that would reverse the override
8. Next review date

An override should not be used to avoid correcting weak evidence or unfavorable economics.

15.4 Static evidence snapshot

In the current release, Review Log recommendation, confidence, rationale, and evidence-summary fields are append-only static values. At each formal gate, populate the row from the approved Dashboard state and retain the supporting evidence and accountable human decision.

1. Export the Dashboard and decision record to PDF
2. Paste the recommendation and evidence summary as values into an approved decision record
3. Store a versioned copy of the workbook at the decision date
4. Reference an approved governance-system record containing the snapshot

Do not overwrite prior Review Log rows; retain each formal gate as a static historical record.

15.5 Closing actions

A decision is not complete when the meeting ends. Review open actions, confirm owners have accepted them, and track completion before the next gate. Where a control is a condition of proceeding, funding or release should not advance until the authority confirms that the condition has been met or formally waived.

16. Review Cadence across the Lifecycle

Cadence should be proportionate. High-stakes, irreversible, fast-changing, or weak-evidence initiatives require shorter review intervals.

17. Illustrative Worked Example

17.1 Purpose of the example

The workbook contains an illustrative ChatGPT Enterprise rollout for 500 knowledge workers. Its purpose is to demonstrate how cost categories, benefits, scenarios, and recommendations interact. It is not a recommended architecture, price benchmark, return expectation, or generic business case for enterprise generative AI.

17.2 Illustrative investment-case outputs

The reviewed workbook shows approximately:

The result indicates that the modeled benefits do not recover the modeled investment within the horizon and the Base-Case and Expected NPV do not clear the illustrative threshold. The appropriate interpretation is not that enterprise generative AI is generally uneconomic. It is that this particular illustrative combination of scope, cost, benefit assumptions, adoption, conversion, and horizon does not support approval as modeled.

17.3 What a practitioner should investigate

The result should prompt questions such as:

1. Are the use cases sufficiently specific and valuable?
2. Are the benefit assumptions supported by task-level evidence?
3. Is active adoption realistic?
4. Can released capacity produce measurable value?
5. Are all cost lines necessary for this scope?
6. Can the initiative be phased around higher-value users or workflows?
7. Can commercial terms be improved?
8. Is the non-AI alternative more attractive?
9. Is the modeled horizon appropriate?
10. Are there hard-dollar, quality, or avoided-cost benefits supported by evidence but not yet included?

The objective is not to manipulate assumptions until the model passes. It is to improve the proposition or decide not to proceed.

17.4 Illustrative lifecycle reading

The sample lifecycle review RL-002 shows:

1. Recommendation: Stop
2. Confidence: Medium
3. Primary reason: Critical hard gate triggered
4. KPI distribution: 5 Healthy, 9 Caution, and 1 Critical
5. Critical issue: missing benefit baseline and data confidence
6. Logged human decision: Re-scope, recorded as a Human Override

This illustrates why the headline count is not enough. Although only one KPI is Critical, it is a hard-gate KPI. It also illustrates Human-in-Command: the human decision differs from the formula-driven recommendation and should therefore be supported by a clear rationale, risk acceptance, mitigation, owner, and next review.

The sample investment-case figures and lifecycle evidence are demonstration data. They should not be assumed to represent the same real initiative state, and neither set should be treated as a benchmark.

17.5 Scenario-label caution

In the current workbook, the front-page total benefits, net value, ROI, benefit-cost ratio, and payback are drawn from the main ROI summary, which uses Best-Case certainty factors, while Base-Case and Expected NPV are shown separately. The front page does not clearly label the first group as Best Case. Users should label the scenario explicitly in presentations and apply the interim control in Section 18 until the workbook is corrected.

18. Governance, Data Quality, Operating Controls, and Known Limitations

18.1 Essential operating controls

18.2 Data-quality questions

Before accepting an input or KPI reading, ask:

1. Is the definition clear and consistent with the approved case?
2. Is the source authoritative?
3. Is the value current enough for this decision?
4. Is the period consistent with the model?
5. Is the value actual, forecast, committed, sampled, or assumed?
6. Has it been independently reviewed where material?
7. Is missing or uncertain information visible?
8. Can another reviewer reproduce the result?

18.3 Current-release limitations and interim controls

18.4 Model-change governance

Any change to the following should be treated as a model change rather than an ordinary project input:

1. KPI definitions or hard-gate designations
2. Status thresholds
3. Decision-rule sequence
4. Scenario formulas
5. Benefit calculation method
6. Cost taxonomy structure
7. Named ranges and data validations
8. Dashboard formulas
9. Review Log mapping
10. Hidden helper-sheet formulas

Model changes should be documented, peer-reviewed, tested across positive, negative, missing-data, and boundary cases, and released under a new controlled version.

18.5 Evidence retention

Retain enough information to reconstruct the decision:

1. Workbook version
2. Input and evidence sources
3. Review date and data cutoff
4. Dashboard snapshot
5. Recommendation
6. Human decision and authority
7. Rationale and override, if any
8. Conditions and actions
9. Completion evidence
10. Next review date

19. Quick-Reference Checklists

19.1 Before first use

1. [ ] Create a controlled copy for one initiative.
2. [ ] Confirm current Excel compatibility and successful recalculation.
3. [ ] Remove or identify sample data.
4. [ ] Name the Sponsor, Value Owner, PM, Finance Partner, and evidence owners.
5. [ ] Define the decision and delegated authority.
6. [ ] Confirm version-control and access arrangements.
7. [ ] Gather baseline, cost, benefit, feasibility, and risk evidence.

19.2 Before requesting funding

1. [ ] Problem and intended outcome are clear.
2. [ ] Resource 06 health check and Resource 07 readiness assessment have been considered.
3. [ ] Feasibility is confirmed or gaps are visible.
4. [ ] All material lifecycle cost groups have been reviewed.
5. [ ] Every material zero has a rationale or owner.
6. [ ] Current-state cost pool is not presented as guaranteed savings.
7. [ ] Benefits are separated by type and have measurement owners.
8. [ ] Adoption, ramp, decay, and hours-to-value are evidence-based.
9. [ ] Best, Base, and Worst certainties are reviewed.
10. [ ] Probabilities total 100 percent.
11. [ ] Hurdle rate and thresholds are Finance-approved.
12. [ ] Non-AI alternative is credible and complete.
13. [ ] Scenario and sensitivity results are understood.
14. [ ] Recommendation is clearly distinguished from authorization.
15. [ ] Human sign-off and conditions are recorded.

19.3 Before each lifecycle review

1. [ ] Review ID is unique.
2. [ ] Review date and stage are correct.
3. [ ] Evidence is current, sourced, and comparable with the approved case.
4. [ ] Actual and forecast cost are distinguished.
5. [ ] Benefit baseline and actual results are available.
6. [ ] Assumptions have been revalidated.
7. [ ] Adoption and core KPI movement are measured.
8. [ ] Hidden-cost and funding exposure are updated.
9. [ ] All fifteen KPI fields are completed or intentionally shown as missing.
10. [ ] The evidence row is appended chronologically.
11. [ ] Dashboard selector matches the intended review.
12. [ ] Recommendation, primary reason, distribution, trends, and risk concentration are reviewed together.
13. [ ] Known formula-precedence limitations are considered.
14. [ ] Human decision, rationale, actions, owners, and next review are recorded.
15. [ ] A static snapshot is retained.

19.4 Before go-live

1. [ ] Benefit baseline and measurement access are confirmed.
2. [ ] Value Owner and stop authority are confirmed.
3. [ ] Operating budget and cost-to-complete are acceptable.
4. [ ] Support, monitoring, human review, refresh, and incident costs are funded.
5. [ ] Security, privacy, legal, compliance, and governance conditions are closed or formally accepted.
6. [ ] Adoption, training, and process redesign are ready.
7. [ ] Success criteria and stop conditions are explicit.
8. [ ] Go-live authorization is documented separately from the workbook recommendation.

19.5 Before renewal or re-buy

1. [ ] Actual cost and benefit evidence replace outdated forecasts where available.
2. [ ] Vendor pricing, usage pattern, and unit economics are refreshed.
3. [ ] Alternative vendors and non-AI options are reconsidered.
4. [ ] Switching, retraining, data export, decommissioning, and transition costs are included.
5. [ ] Benefit and adoption drift are reviewed.
6. [ ] The initiative still supports the intended organizational outcome.
7. [ ] Renew, renegotiate, re-scope, replace, or retire is explicitly decided.

20. Common Misuses to Avoid

1. Treating the recommendation as automatic approval
2. Using the worked example as a pricing or ROI benchmark
3. Presenting the entire current-state cost pool as savings
4. Counting saved time as cash without an agreed conversion mechanism
5. Adding soft value to ROI without Finance acceptance
6. Omitting internal, governance, human-review, monitoring, retraining, and exit costs
7. Changing probabilities or thresholds to achieve a desired answer
8. Mixing Best-Case ROI with Base-Case NPV without labeling scenarios
9. Entering multiple initiatives in the same KPI log
10. Backfilling favorable evidence while leaving unfavorable evidence undocumented
11. Overwriting formula cells or hidden helper sheets
12. Using a dynamic Review Log as the only historical record
13. Ignoring the non-AI alternative
14. Continuing because of sunk cost rather than remaining value
15. Treating missing baseline data as a minor documentation issue
16. Accelerating based on adoption alone without cost, benefit, and control evidence

21. Glossary

22. Related Resources

Use this guide with:

1. 00 - AIPM Toolkit - Practitioner Guide
2. 01 - AIPM Toolkit - Core White Paper - Ontology, Taxonomy and Value Delivery
3. 02 - AIPM Toolkit - Governance Operating Model
4. 03 - AIPM Toolkit - Practical Application Guide
5. 04 - AIPM Toolkit - Governance Intelligence and Semantic PMO Roadmap
6. 05 - AIPM Toolkit - Reference Assets and Implementation Templates
7. 06 - AIPM Toolkit - AI Project Business Case Quick Health Checklist
8. 07 - AIPM Toolkit - AI Project Pre-Commitment Readiness Scoring Grid
9. 08 - AIPM Toolkit - AI Investment Case and Lifecycle Decision Workbook.xlsx
10. 09 - AIPM Toolkit - AI Investment Case and Lifecycle Decision Workbook - Change Log and Build Summary
11. The AIPM Toolkit PRIISM financial-authority resource
12. 11 - AIPM Toolkit - Benefits ROI Tracking and Agent

The complete resource set and current licensing terms should be confirmed in Resource 00.

23. Licensing and Disclaimer

23.1 Licensing notice

© 2026 the applicable author(s) and contributors identified in this document.

Text is licensed under **Creative Commons Attribution-**ShareAlike 4.0 International (CC BY-SA 4.0): attribution is required, changes must be identified, and adaptations must be distributed under the same license. Proprietary frameworks, methodologies, tools, terminology, and know-how are excluded.

This document is part of the AIPM Toolkit. Refer to Section 12 of 00 - AIPM Toolkit - Practitioner Guide for the complete licensing terms and disclaimer, and Section 3 for the current component set.

23.2 Disclaimer

This guide and its companion workbook are thinking, planning, and decision-support tools. They do not constitute financial, investment, accounting, tax, legal, regulatory, procurement, security, privacy, technical, engineering, employment, or other professional advice. They are not substitutes for organizational policy, delegated authority, independent assurance, due diligence, or advice from appropriately qualified professionals.

The contributors have sought to make the material accurate and useful, but no guarantee is made that the workbook, formulas, thresholds, examples, recommendations, or guidance are complete, error-free, suitable for every jurisdiction, suitable for every organization, or appropriate for a particular decision. AI technologies, costs, regulations, risks, vendor terms, and organizational conditions change over time.

Users are responsible for:

• Validating all assumptions, formulas, evidence, and outputs
• Confirming applicable law, regulation, policy, accounting treatment, and authority
• Obtaining qualified professional advice where required
• Protecting confidential, personal, client, commercial, and regulated information
• Applying proportionate governance, testing, and human oversight
• Making and documenting the accountable human decision

No recommendation generated by the workbook authorizes expenditure, deployment, continued operation, or any other action. Any decision made, or not made, using the guide or workbook remains the responsibility of the authorized decision-maker and the organization applying it.