Why this course exists
Data platform builds fail less from bad engineering than from bad framing: no clear scope, no owner, a "100%" mandate nobody sized, hires that never landed, governance decided after the architecture was poured. This course teaches the PMO tools that keep a big build honest - the way senior data and tech leaders actually use them, applied to one real-feeling project. Meet Northwind, a fictional retailer whose CEO wants all its data in a warehouse in 90 days. Over 6 sessions you will charter it, sequence it, de-risk it, and take it to production - artifact by artifact.
Interim vs final: the honesty that saves the project 5 min live
Northwind's CEO says "100% of our data in the warehouse, 90 days." You cannot harmonise, consolidate, and quality-assure 80 TB across five source systems in 90 days - and pretending you can is how projects detonate in month three. The charter's first job is to state, in writing, the difference between the pragmatic interim step and the real deliverable.
LiveState the interim step in writing3 min▶
A raw dump into a staging lake is a legitimate first move - it honours the deadline and unblocks exploration. But without schema harmonisation, table consolidation, and quality assurance, the dump is not a queryable governed warehouse. The charter says this out loud so nobody mistakes month-one for done.
- Interim: raw archive lands in the lake, with a file manifest, source mapping, date ranges, and known quality issues attached.
- Final: a governed platform - harmonised schemas, certified datasets, lineage, access tiers - built in stages on top.
- The position sentence: "We will honour the 90-day deadline with a raw dump, and we are transparent that this is a pragmatic interim step, not a final solution." Put it in the charter, verbatim.
The technical debt clause: mature data teams add one line - "the current approach is a direct consequence of years of deferred data ownership, and its technical debt will be addressed systematically in the rebuild." It reframes the rush as a known, managed liability rather than a hidden one. Boards trust the team that names its own debt.
Self-studyWhy a written charter beats a verbal mandate2 min read▶
PMI's project charter exists for one reason: to formally authorise the project and give the manager a documented reference for scope, objectives, and stakeholders. A verbal mandate ("just get the data in") drifts - everyone remembers a different version. A charter freezes the shared version.
| Verbal mandate | Written charter |
|---|---|
| "Get all the data in" | Scope named: raw dump interim, governed platform final |
| Deadline remembered differently by each exec | 90 days for the dump, staged milestones for the rest |
| No named owner when it slips | Sponsor, PMO, and technical owners on the page |
The charter is not bureaucracy - it is the thing you point at when priorities collide in month two.
Charter anatomy: five blocks, one page 5 min live
A charter is not a plan (that is Session 2's milestones). It is the framing layer above the plan: what, why, who, and the rules of engagement. Five blocks fit on one page and answer every "wait, why are we doing this?" for the next six months.
LiveThe five blocks, plainly3 min▶
- Context - where the data estate is today, the mandate, the deadline. Two or three sentences, no jargon.
- Position - the interim-vs-final honesty from Part 1. This block protects you.
- Priorities - the P1-P4 model (Part 3). The ordered list of what must be true.
- Risks - the top three to five, each tagged HIGH/MEDIUM. The full register comes in Session 4.
- Ownership - named sponsor, PMO, technical owners, and the escalation ceiling (who is the final "yes"). The full RACI comes in Session 5.
Self-studyCharter vs scope statement vs plan2 min read▶
Three documents get confused. The charter authorises and frames. The scope statement bounds (in vs out). The plan sequences (milestones, dates, dependencies). You write them in that order, and each is shorter to write once the one above it exists.
- Charter: "We are building a governed data platform; raw dump is interim." (this session)
- Scope: "In: 5 source systems, curated core datasets. Out: real-time streaming, external data buys." (touched in Session 6 sizing)
- Plan: "M1 raw load, M2 infra, M3 migration..." (Session 2)
The P1-P4 model: hiring is the hard one 5 min live
Priorities are not a wish list - they are the conditions the build depends on, ordered. For a data platform, four recur on every project. Three are workstreams. The fourth, hiring, is a hard dependency: nothing technical can be committed until it lands. Naming that now prevents the most common failure mode of all.
LiveReading the four priorities3 min▶
- P1 Source data & KT: you need schema docs for every table and version, a formal knowledge-transfer programme (not ad hoc), and - because rushed dictionaries are always low quality - a planned independent profiling pass. Assume the handed-over dictionary is a starting point, not the truth.
- P2 Cloud & infra: the landing zone (VPC, IAM, secrets, network security, compliance baseline) must exist before any data is ingested. Ingesting into an unhardened environment is a breach waiting to happen.
- P3 Governance: data classification, PII tagging, retention, and access tiers must be defined before the architecture is finalised - otherwise you rebuild it. Governance is a gate, not a cleanup phase.
- P4 Hiring: the hard dependency. No technical milestone is committed until the Data Architect and Data Engineering Lead are onboarded. Start hiring on day one, in parallel, and pursue internal transfers alongside external search.
Self-studyWhy "governance before architecture" is non-negotiable2 min read▶
If you finalise the warehouse design before governance defines what is sensitive, where PII lives, and who may see which tier, you will re-architect: access controls bolted on late, PII discovered in a "public" schema, retention rules that force a re-partition. Every one of those is a rebuild, not a patch.
- Classification first: what is public, internal, confidential, restricted - decided by the governance office, not the engineers.
- Then design to it: the architecture inherits the tiers as a constraint, so access controls are structural, not afterthoughts.
- This is a gate in Session 3: governance sign-off is a hard predecessor to the M2 infrastructure milestone.
Write Northwind's context & position ★ 7 min · everyone writes
The brief, read aloud: Northwind, $1.2B retailer, 380 stores + e-commerce + loyalty app, ~120 source tables across 5 systems, ~80 TB archive. CEO mandate: "100% of data in the warehouse, 90 days." No shared dictionary, keys not aligned, critical roles not yet hired.
Two minutes solo: write the context block - three sentences, plain language, ending on the mandate and its deadline.
Two minutes: write the position block. Use the template sentence: "We will honour the 90-day deadline with a raw dump into a staging lake, and we are transparent that this is a pragmatic interim step, not a final solution."
Add the technical-debt clause in one line. Read a volunteer's aloud - the room checks: does it honour the deadline AND the truth?
The position block is the single most reread paragraph in any data-platform charter. When month three arrives and someone asks "why can't I query the lake yet?", you do not defend - you point at the paragraph everyone signed. Writing it well now is cheap insurance.
Draft the P1-P4 priorities ★ 9 min · everyone drafts
For each priority, write one line of what Northwind specifically needs. P1: which 5 systems must hand over schema docs and KT? P2: AWS landing zone before ingest. P3: who signs classification and PII? P4: which roles are the critical hires?
Mark P4 as the hard dependency explicitly - the words "no technical milestone committed until critical hires land" go on the page.
Order-check: for each of P1-P3, ask "what blocks this?" If hiring or governance blocks it, note the arrow. You are sketching Session 3's dependency graph without knowing it yet.
Compare with a neighbor: did you both make hiring the hard one? If someone ranked "ingest data" first, discuss why that is the trap.
Name the objective & the escalation ceiling ★ 6 min · everyone names
Write ONE objective sentence for Northwind that a board would approve: "Deliver a governed data platform serving BI, analytics, and AI, built in stages on an interim raw dump that lands in 90 days."
Name the ownership skeleton: sponsor (cross-org + senior hiring), PMO (tracking + cadence), technical owner (acceptance criteria). One name or role per slot.
Name the escalation ceiling - the single final "yes" when two owners disagree. Without it, every conflict floats. Read one aloud; the room checks it is unambiguous.
This week ◐ 30 min total
- Charter a real initiative from your desk - one page, five blocks. Even a small project has a context, a position, priorities, top risks, and an owner.
- Write your hardest "interim vs final" paragraph: pick something in your org that is being sold as "done" but is really interim, and write the honest position block for it.
- Read the self-study cards above: written charter vs verbal mandate, charter vs scope vs plan, governance before architecture.
- Optional deep end: skim the PMI project-charter section of the PMBOK Guide, or any RAID-log primer - both underpin Sessions 2-5.
Three questions before you go 🎯 ◐ 90 seconds
1 · The CEO wants "100% governed data in 90 days." What does the charter's position block do?
Honour the deadline (dump lands) and the truth (governed layer is staged). Naming interim vs final is what protects the project in month three - it is neither over-promising nor refusing.
2 · Among P1-P4, why is hiring called the "hard dependency"?
P1-P3 are workstreams you can push in parallel; P4 gates the technical milestones entirely. Start it day one, run it in parallel, and pursue internal transfers too.
3 · Why must governance be defined BEFORE the architecture is finalised?
Classification, PII, retention, and access tiers are structural constraints. Design to them and controls are built in; add them later and you re-architect. It is a hard gate in Session 3.
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.