Where the build stands
Five sessions in, Northwind has a full framing stack: a charter that names the interim raw dump, a milestone map M1-M6, a dependency graph with hiring as the hard gate, an eight-row risk register, and a RACI that puts one accountable name on every decision. What is still missing is the honest answer to three questions a chairman will ask: how big is this really, how do we know it is moving, and how will we know it is done? That is this session - sizing, tracking, and the path to production - and it wraps the whole Northwind initiative.
Size the scope with peer benchmarks 5 min live
"100% of 120 tables" is a mandate, not a working scope. Mature analytics does not run on the whole raw estate - it runs on a curated working set that the business actually queries. For a retailer that is roughly 20-50 core datasets: sales, product, customer, store, stock, promotion, loyalty, fulfilment. You size that set by benchmarking against comparable retailers, certify it first, and let the long tail follow on demand.
LiveRaw estate vs the certified layer3 min▶
The 120 tables include duplicates, dead extracts, staging scratch, and low-value logs. The certified layer is the subset the business decisions actually depend on. Sizing is the act of proving which is which - and a peer benchmark is the fastest evidence you can bring to that argument.
- Raw estate: everything that lands in the lake - ~120 tables, ~80 TB. Preserved, archived, searchable, but not certified.
- Certified layer: the ~20-50 core retail datasets, harmonised, quality-assured, lineage-traced, and adopted by BI and DS.
- Benchmark test: "what does a comparable retailer actually govern?" If a peer runs its analytics on ~30 certified datasets, your 120-table mandate is a preservation goal, not a certification goal.
The 80/20 of retail data: in most retailers a handful of subject areas - sales, product, customer, stock - carry the overwhelming majority of reporting and model features. Certifying those eight-to-twelve first gets the business ninety percent of the value while the remaining tables are triaged on request. Boards understand "value first, tail on demand" far better than "everything at once."
Self-studyHow to defend a smaller scope to a chairman2 min read▶
A chairman hears "we are not doing all 120 tables" as "you are cutting corners" unless you frame it as evidence. Benchmarking flips it: you are not shrinking the mandate, you are sizing it the way mature retailers do.
| What the board fears | What the benchmark answers |
|---|---|
| "You are dropping data we need" | Raw estate is fully preserved; only the certified layer is prioritised |
| "How do you know 30 is enough?" | Comparable retailers certify a similar working set - here is the peer evidence |
| "When do we get the rest?" | The long tail is certified on demand, ranked by business request |
Sizing is not a concession you apologise for - it is the discipline that lets you certify anything at all inside 90 days.
The migration & inventory tracker 5 min live
Once the working set is sized, the tracker is how the build actually runs. Each source table flows source -> bronze -> silver -> gold, and for each you record coverage %, the data start and end dates, and any known quality flags. This is the single sheet that answers "where are we?" without a meeting.
LiveWhat to track per dataset3 min▶
The tracker has one row per certified dataset and a handful of columns that never change project to project. Keep it boring and consistent - it is the source of truth the status meeting reads from.
| Source system | Table | Layer | Coverage % | Quality flag |
|---|---|---|---|---|
| POS (Oracle) | sales_txn | Gold | 88% | Clear |
| E-commerce (Postgres) | web_orders | Silver | 72% | Key gaps |
| Loyalty (MySQL) | member | Silver | 65% | Dupes |
| Finance (SAP) | gl_daily | Bronze | 40% | Late dates |
Self-studyReconciliation evidence & sign-off2 min read▶
A dataset reaches gold when the numbers reconcile and someone accountable signs. Reconciliation is the arithmetic proof; sign-off is the RACI accountable owner accepting it against the success criteria from Session 2.
- Row and control-total reconciliation: source row counts and key financial totals match the certified table within an agreed tolerance.
- Quality flags cleared: nulls, duplicates, and key gaps are resolved or formally accepted with a documented reason.
- Accountable sign-off: the one accountable owner (RACI, Session 5) records acceptance - that is the audit trail when the board asks "who certified this?"
Reconciliation evidence is what turns "we loaded it" into "we can trust it" - and it is the gate between silver and gold.
Status cadence & the path to production 5 min live
Tracking data is only half the job - the other half is reporting it so decisions get made. RAG status (red / amber / green) plus a weekly cadence and disciplined action-item closure keeps the build honest. Then the finish line: the M6 definition of done that says when Northwind is actually in production.
LiveRunning a status meeting that ends in decisions3 min▶
A good status cadence is short, weekly, and ruthless about closure. RAG is the language; the meeting exists to turn every red and amber into an owned action, not to admire green.
- Green - on track, no discussion needed. Do not spend the meeting here.
- Amber - at risk. Needs a mitigation owner and a date this week, pulled straight from the risk register.
- Red - blocked or slipped. Escalate to the accountable owner (RACI) and, if needed, the escalation ceiling named in the charter.
- Action-item closure: every item from last week is either done, re-owned with a new date, or explicitly killed. Nothing lingers unowned.
Self-studyGo-live / production readiness checklist2 min read▶
M6 is "one-stop platform in production (BI + DS + AI/ML)". Production is not a date - it is a definition of done that everything must satisfy before the platform carries real decisions.
- Certified datasets adopted: the curated working set is at gold, reconciled and signed off, and BI is actually built on it - not on shadow extracts.
- Critical pipelines meet SLA: the daily incremental (M1.1) lands on time, monitored, with alerting and a runbook.
- Controlled self-service BI: governed dashboards on certified data, access tiers enforced, no ungoverned direct-to-lake reporting.
- First AI/ML product on traceable data only: the first model runs solely on certified, lineage-traced datasets - never on raw or unreconciled tables.
When all four hold, the interim raw dump has become the governed platform the charter promised - and Northwind is in production.
Size Northwind's curated working set ★ 7 min · everyone lists
Start from the mandate: ~120 tables across POS, e-commerce, loyalty, finance ERP, and marketing. The board wants "all of it." Your job is to name the certified working set the business actually queries.
Using the retail benchmark (sales, product, customer, store, stock, promotion, loyalty, fulfilment), write down 8-12 core datasets Northwind should certify first. One line each: name + which source system it comes from.
For each, add a one-word reason it is in the certified set (e.g. "drives revenue reporting", "feeds churn model"). If you cannot name why it is core, it belongs in the long tail.
Read a volunteer's list aloud - the room checks: is this defensible as "what a peer retailer governs", or did someone sneak the whole estate back in?
The curated list is the artifact you take back to the chairman. When they ask "why only 30 and not 120?", you do not defend - you show the benchmark and the value ranking. Sizing well now is what makes the 90-day certified layer actually shippable.
Fill the tracker for Northwind ★ 9 min · everyone fills
Draw the five columns: Source system · Table · Layer · Coverage % · Quality flag. Pick 4-5 datasets from your curated list in Demo 1.
For each row, place it on a layer (Bronze / Silver / Gold) and give it a realistic coverage % - remember coverage is rows reconciled against source, not a guess.
Add one quality flag per row from real retail failure modes: key gaps (e-commerce orders without a customer key), dupes (loyalty members), late dates (finance GL), or "Clear" if it is certified.
Mark which rows are truly "done" (Gold + high coverage + Clear). Discuss with a neighbor: which single flag is blocking the most datasets from reaching gold?
Build a RAG snapshot & the go-live bar ★ 6 min · everyone rates
List M1-M6 down the page. Give each a RAG chip - Green (on track), Amber (at risk), or Red (blocked) - based on where you would honestly expect Northwind to be mid-build.
For every Amber and Red, write the one line the status meeting needs: owner + action + date. No naked reds allowed.
Write Northwind's production go-live criteria in four bullets: certified datasets adopted, critical pipelines meet SLA, controlled self-service BI, first AI/ML product on traceable data only.
Read one go-live definition aloud - the room checks: could a board tell from these four bullets exactly when to declare M6 done?
This week ◐ 30 min total
- Benchmark-size a real scope from your desk: take something being sold as "we will do all of it" and write the curated working set a peer would actually certify first.
- Draft a five-column tracker for one initiative: Source · Table/Item · Layer/Stage · Coverage/Progress % · Quality flag. Fill five rows honestly.
- Write a one-page go-live definition of done for a project you own - the four-to-six bullets that say when it is truly in production, not just launched.
- Read the self-study cards above: defending a smaller scope, reconciliation sign-off, and the production readiness checklist.
Three questions before you go 🎯 ◐ 90 seconds
1 · Why does a curated working set beat certifying "100% of the tables"?
The raw estate is preserved, but you certify the ~20-50 core datasets a peer retailer actually governs. It ships value sooner and is defensible as benchmark evidence, not a cut - the long tail follows on request.
2 · In the migration tracker, what does coverage % actually measure?
Coverage % is arithmetic proof: rows reconciled against the source. It ties directly to the archive-completeness risk (R2), so the tracker doubles as evidence that risk is closing.
3 · What is RAG status reporting for?
RAG is a decision trigger, not decoration. Green needs no discussion; amber and red each need an owner, an action, and a date, plus action-item closure every week - or it is a reading group, not a status meeting.
Frameworks covered & their origins
This finale teaches the working 80% of scope sizing, delivery tracking, and status governance - and cites the canon, so the full standards stay the deep end for anyone who wants them.