From charter to plan
The charter named the priorities - source data, infra, governance, hiring. That is the framing. Now you owe the board a plan: a sequence of milestones, each with a definition of done that a chairman could tick off without asking a single follow-up question. The trap is writing a task list ("load POS tables", "stand up Redshift") and calling it a plan. Tasks are activity; milestones are outcomes with proof. This session teaches the difference and gives you Northwind's M1-M6 milestone map - the artifact every later session builds on.
The milestone table: five columns that run the build 5 min live
A milestone is an outcome with proof, not a task. "Ingest the archive" is a task - it could be 5% done or 95% done and nobody could tell. "Raw archive loaded, reconciled, and signed off" is a milestone - it is either true or it is not. Five columns turn every milestone into that yes/no test, and the same five columns work for M1 through M6.
LiveMilestone vs task3 min▶
A task is a unit of activity someone does. A milestone is a state the project reaches - verifiable, binary, and meaningful to a stakeholder. The five columns force the distinction, because a task cannot fill them honestly.
- ID - a stable handle (M1, M1.1) so dependencies and risks can point at it later.
- Milestone - the outcome, phrased as a reached state ("raw archive loaded"), not an activity ("loading data").
- Success criteria - the yes/no conditions that make it done. If you cannot tick them, it is not done.
- Key metrics - the numbers that evidence the criteria (reconciliation pass rate, freshness lag).
- Primary dependency - the one thing that must be true before this milestone can even start. This column becomes Session 3's graph.
Self-studyWBS: decomposing a milestone into deliverables2 min read▶
Under each milestone sits a work-breakdown structure (WBS): the deliverables and tasks that produce the outcome. The milestone is the checkpoint; the WBS is how you get there. PMBOK keeps them in separate layers on purpose - the board reads milestones, the team works the WBS.
| Layer | Example (M1) | Who reads it |
|---|---|---|
| Milestone | Raw archive loaded & reconciled | Sponsor, board |
| Deliverable | File manifest, reconciliation report | PMO, tech owner |
| Task | Extract POS tables, hash-compare row counts | Data engineers |
Keep the milestone map free of tasks. When someone asks to add "write the extract script" as a milestone, that is the signal the layers have collapsed.
Success criteria you can actually check 5 min live
The success-criteria column is where most milestone maps quietly fail. "Data loaded successfully" reads fine in a slide and means nothing in a review - successful by whose measure? SMART criteria (specific, measurable, achievable, relevant, time-bound) turn a warm sentence into a checkbox. The test: could two people disagree about whether it is met? If yes, rewrite it.
LiveSMART criteria, applied to Northwind3 min▶
Take the two Northwind milestones everyone touches first and write their criteria the SMART way:
- M1 - Raw archive load. 100% of agreed data loaded; source-to-target reconciliation complete; no unexplained Tier-1 data loss; migration evidence signed off. Each line is either true or false at review time - nothing to argue about.
- M1.1 - Daily incremental (D+1). Pipeline meets a >=98% SLA; daily freshness checks run and pass; late or failed loads raise an alert with an owner. "Reasonably fresh" becomes a threshold and a check.
The phrase that saves reviews is "signed off". A criterion like "migration evidence signed off" names both the artifact (the evidence pack) and the act (someone accountable signs). It moves the milestone from "the engineers think it is done" to "the accountable owner accepted it" - which is the only definition of done a board trusts.
Self-studyLeading vs lagging metrics2 min read▶
Key metrics come in two flavours. Lagging metrics confirm an outcome after the fact (reconciliation pass rate at cutover). Leading metrics predict it early enough to act (daily freshness lag creeping up before the SLA breaks). A good milestone carries at least one of each - one to prove done, one to warn early.
- Lagging (proof): % agreed data loaded, row-count delta by table, certified-dataset count.
- Leading (early warning): freshness lag trend, pipeline failure rate, open reconciliation exceptions.
- The pairing habit: when a lagging metric finally moves, it is often too late to react - so pair it with a leading one you watch weekly.
Laddering M1 to M6 across the lifecycle 5 min live
Northwind's build follows one lifecycle - Ingest, then Infra, then DW construction, then Discovery, then Production. The milestone map is that lifecycle made concrete: six numbered milestones, each landing in a stage, with sub-milestones (M1.1, M1.2, M2.1, M5.2) that carry work too specific to fold into their parent. Read the ladder left to right and you read the whole project.
LiveSub-milestones and why they exist3 min▶
Not every outcome fits neatly under a single numbered milestone. A sub-milestone carries work that is real, checkable, and dependency-bearing, but too specific to fold into its parent without hiding it. Northwind has four that matter:
- M1.1 Daily incremental (D+1) - the ongoing pipeline after the one-time archive load. Different SLA, different failure modes, so it earns its own row.
- M1.2 SIT/UAT environment - an enabler: the data team cannot test migration without a safe environment. Invisible to the board, blocking to the build.
- M2.1 Critical roles hired & onboarded - the hard gate from Session 1, now a tracked milestone. No committed technical milestone until it lands.
- M5.2 Data product idea pool - the prioritised backlog that feeds M6. Discovery has to produce a ranked list, not just exploration.
Self-studyStage-gate go/no-go criteria2 min read▶
Stage-gate governance puts a decision point between lifecycle stages: before Discovery starts, someone asks "is the DW actually certified enough to explore on?" A gate is a go/no-go review, not a milestone - it consumes the previous milestone's success criteria as its entry test.
- Entry criteria: what must be true to pass the gate (M4 certified datasets exist before M5 exploration is trusted).
- The three verdicts: go (proceed), no-go (stop and fix), or conditional-go (proceed with named caveats and a review date).
- Who decides: the accountable owner plus governance - never the delivery team marking its own homework.
Session 3 turns these gates into hard dependencies; here you just note where they sit on the ladder.
Write M1's success criteria & metrics ★ 7 min · everyone writes
Start the row: ID = M1, milestone = "Raw archive loaded into the data lake". Phrase it as a reached state, not "loading the archive".
Two minutes: write the success criteria as a checklist - 100% agreed data loaded, source-to-target reconciliation complete, no unexplained Tier-1 data loss, migration evidence signed off. Each line must be answerable yes/no.
Write the key metrics that evidence those criteria: reconciliation pass rate and row-count delta by table. Add one leading metric (open reconciliation exceptions).
Read a volunteer's aloud - the room applies the done-when test: could two people disagree about whether M1 is met? If yes, tighten the wording.
Teams love to write "archive migrated" and move on. The word that earns its keep is "reconciled" - source-to-target reconciliation is the proof that nothing was silently dropped in an 80 TB move. On a real migration, the reconciliation report is the single artifact the board asks to see before signing M1 off.
Ladder the full M1-M6 map ★ 9 min · everyone drafts
Lay out the six main milestones in lifecycle order: M1 raw load (Ingest), M2 cloud & infra (Infra), M3 legacy migration and M4 governed DW build - silver/gold, certified (DW), M5 raw exploration + data dictionary (Discovery), M6 one-stop platform in production - BI + DS + AI/ML (Production).
For each, write one line of success criteria and one primary dependency. Keep them outcomes, not tasks - if a row starts with a verb like "build" or "load", reword it to the finished state.
Sanity-check the ladder: does each milestone only make sense once the one before it is signed off? Circle any that could run in parallel - you are pre-sketching Session 3.
Compare with a neighbor: did M4 (certified DW) land before M6 (AI/ML)? The first model ships only on certified, traceable data - if M6 floated earlier, discuss why that breaks.
Add the sub-milestones & one gate ★ 6 min · everyone names
Slot in the four sub-milestones under their parents: M1.1 daily incremental (D+1) and M1.2 SIT/UAT environment under M1; M2.1 critical roles hired & onboarded under M2; M5.2 data product idea pool under M5.
For each sub-milestone, name why it split off - different owner, different success test, or its own dependency. If it shares all three with its parent, delete it back into the WBS.
Write ONE stage-gate go/no-go rule for the DW-to-Discovery boundary: "no M5 exploration is trusted until M4 certified datasets exist and governance signs off." Name the verdict options: go, no-go, conditional-go.
This week ◐ 30 min total
- Milestone-map a real initiative from your desk - five columns, outcomes not tasks. Even a small project has three to five real milestones with checkable criteria.
- Rewrite your vaguest success criterion: find a "done successfully" line in an existing plan and turn it into a number, a threshold, and a check that runs.
- Read the self-study cards above: WBS decomposition, leading vs lagging metrics, and stage-gate go/no-go criteria.
- Optional deep end: skim the PMBOK milestone and WBS sections, or any stage-gate primer - both feed Sessions 3 and 4.
Three questions before you go 🎯 ◐ 90 seconds
1 · What is the difference between a milestone and a task?
A task ("load POS tables") is activity that could be any % done. A milestone ("archive loaded, reconciled, signed off") is a reached state that is either true or false. The five columns force that distinction.
2 · What makes a success criterion measurable rather than vague?
"Data loaded successfully" fails: successful by whose measure? ">=98% SLA with daily freshness checks that pass" succeeds - it is a clear yes/no at review time.
3 · Why do sub-milestones and stage-gates exist?
M1.1 has a different SLA than M1; M2.1 gates milestones M2 does not. A stage-gate consumes the prior milestone's criteria as an entry test - go, no-go, or conditional-go.
Frameworks covered & their origins
This course teaches the working 80% of each tool and cites the canon - full standards stay the deep end for anyone who wants them.