Prepare the Final Report and Lessons Learned

What the Final Report Is For

At the close of a CPMAI iteration you produce a final report — a closeout or iteration report — that answers one question for the people who funded the work: did this deliver what the business case promised, and what should we do next? ECO Domain V, Task 5 pairs the report with lessons learned because on artificial intelligence (AI) projects the second half is often worth more than the first. The deployed model is one asset. What you now know about your organization's data is an asset you will spend again on every AI initiative that follows.

Remember that CPMAI Phase 6 Model Operationalization is not a terminus. In an iterative methodology this report is normally the input to the next iteration rather than the end of the work, and it should read as a decision document.

Report Outcomes Against the Objectives as They Were Written

Open with the success criteria and business case exactly as approved in Phase 1 Business Understanding — not a restated version. Then report three separate results, because they are genuinely separate and conflating them is how closeout reports mislead.

1. Model performance achieved. Report against the threshold agreed in Business Understanding and verified at the Phase 5 readiness gate, measured on production data rather than the held-out test set, using the metric that was actually agreed (recall at the operating threshold, precision, mean absolute error), plus performance on the subgroups your bias checks covered.
2. Business impact. This is the key performance indicator (KPI) in the business case: fraud loss avoided, unplanned downtime hours removed, cost per claim. Frequently it is still pending because ground truth lags — charge-offs confirm 60 to 90 days later, an avoided equipment failure only proves itself over a maintenance cycle. Say so plainly, name the date the number becomes measurable, and schedule the reading. Never substitute model accuracy for business impact because the business number is not ready.
3. Adoption observed. How many eligible cases actually ran through the model, how often users overrode it, how many teams onboarded. A model with excellent accuracy running on 12 percent of eligible volume did not deliver the business case, and the report has to say that.

Reporting a Shortfall Honestly

This is the behavior the exam tests hardest in Task 5. When measured business impact falls short of the business case, you report the variance with root causes and options. You do not retroactively lower the target, quietly redefine the metric, or extend the measurement window until the number improves. Reframing an objective after the fact destroys the organization's ability to estimate the next AI project and is a professional-conduct failure, not a presentation choice.

A credible shortfall report has four parts: the gap stated in the units the business case used; the causes separated into model-side (accuracy below threshold, weak segment, drift) and adoption-side (users overriding, integration friction, only part of the volume routed); what would close the gap and what it would cost; and a recommendation with a decision date.

Lessons Worth Capturing on an AI Project

Analyze both sides. Record what worked well and is worth repeating as a reusable best practice — the pattern selection that fit, the pilot that surfaced an adoption problem early — and record the areas for improvement with equal specificity. Generic closure templates produce generic lessons; AI projects have their own recurring signatures, and these are the ones that pay:

• Data effort variance. Planned versus actual effort for Phase 2 Data Understanding and Phase 3 Data Preparation. If you estimated 30 percent of the project and spent 60 percent, record the ratio and the reason. That single number is the best planning input the next project will get.
• Data sources that proved unusable, and why. No retention history, free text with no schema, a license that forbids model training, a system that overwrites rather than versions. Name the system and the reason.
• Where the labeling burden landed. How many records, who labeled them, over how long, what the agreement rate between annotators was, and whether the subject matter experts' (SMEs') time was ever budgeted.
• Phase 1 assumptions that failed. Assumed the data was in the warehouse, assumed one SME could answer definitional questions, assumed the business process would not have to change.
• What the model could not do. The case types it never handled, the segment it stayed weak on, the explanation a regulator wanted that the chosen technique could not produce.

Building the Organizational Knowledge Base

Lessons that live in a closed project folder are lost. Land them where the next team will collide with them: an entry in a maintained data source register, an update to the AI estimating baseline, a reusable model card template, and a short pattern note filed against the relevant one of the Seven Patterns of AI. The point is blunt: the next project should not rediscover that the customer relationship management system has no reliable timestamps.

Knowledge Transfer and the Leadership Presentation

Two audiences need different documents. Operational teams need material they can run the system with: the model card and its known limitations, monitoring thresholds, the retraining procedure, and the escalation path. Packaging and rehearsing that material is Task 6, the transition plan, and it is covered next.

Leadership needs a short presentation that ends with the next decision on the slide: scale to the remaining regions, run a second iteration against the identified weakness, hold at current scope, or retire the solution. Give each option a cost, a risk, and a date. Because CPMAI iterates, the final report that ends without a recommendation simply stalls the program.