Who refreshes it, did it meet the criteria, how a crew ships

A dashboard nobody refreshes decays

The Q1 dashboard is built. If that were deployment, CRISP-DM would have one task there instead of four. The other three exist because a dashboard is a living report: in April it is wrong unless someone re-runs the script, and in June it is a museum piece. The deployment plan for Maple & Birch, four lines:

• Owner — the analytics lead (named, not "the team").
• Refresh cadence — monthly, on the third business day, from orders.csv through prep.R to agg.csv to Refresh All.
• Location — the shared drive, one file, MB-sales-dashboard.xlsx; copies are not the dashboard.
• What to monitor — the row count after each refresh (nrow(orders) printed by the script: 12 in Q1, more each month, never fewer) and the three tiles (a blank tile means a broken link). A missing column or a new province will show up here first.

That is plan deployment and plan monitoring and maintenance. Produce the final report is the dashboard plus its one-page memo; review the project is the last task, and it is the one students confuse with evaluation.

Worked example — the evaluation memo

Evaluation comes before deployment and asks three things of the result:

1. Evaluate results against the criterion from Lesson 1.4: a province averaging $100 or more above Ontario would justify a second store. AB averages 1,150.00, ON 498.75 — a gap of 651.25. The number clears the bar six times over. But the AB figure is two orders, one of them the 1,320 outlier that Module 4's fence flagged; drop it and AB is one order of 980. The result is a negative finding: not yet — the AB figure cannot carry a store. A negative finding that stops a bad decision is still decision-relevant, and a project that changes what Renata does has met its success criterion. It has not failed because the answer was "no".
2. Review the process — what was skipped or done badly? The two-order base should have been noticed in data understanding (table(orders$prov) prints AB 2 at Module 11), not at the memo. What took longest and what would be done differently belongs here, under evaluation, not under deployment's review project — which is written after the hand-over, about the hand-over.
3. Determine next steps — collect Q2, re-run, decide at the half-year; meanwhile deploy the dashboard, because the monthly view is useful whatever AB does.

How a crew ships

The crew project is five people, twelve weeks and one deliverable, and its brief is short. The CRISP-DM deliverables are the structure: one document per phase, in order. Five artefacts are shared by the whole crew and owned by one person each:

• One data dictionary (Module 2) — every variable, type and unit, agreed before anyone computes.
• One source file — never edited by hand; every change is a script step.
• Version-named copies — dashboard-v03-2025-03-28.xlsx, never final, final2, FINAL-real. Two members editing two copies of the source is the failure this rule exists to prevent; the merge afterwards is a morning lost and a number wrong.
• One R script — the audit trail from Lesson 14.2.
• The peer-evaluation form — Lesson 14.4's six lines, filled in by each member for another crew's dashboard and for their own.

Roles follow the phases: one member owns business understanding and the memo, one the dictionary and data understanding, one the preparation script, one the model and evaluation, one the dashboard and deployment plan. Everyone reads everything; one person signs each artefact.

Write a plan for a new case, then list the artefacts

CRISP-DM: this lesson is the last two phases in their proper order — evaluation, then deployment — with the crew workflow as the project-management layer around them.