This guide explains how predictive, PMBOK-standard program management actually works, using the Enrollment & Claims Platform Modernization program as a running example — the same program this entire suite is built around. It's written for anyone who knows Agile/Scrum well but wants to understand why a large, infrastructure-heavy program often runs on a phase-gated, predictive model instead.
Why predictive delivery, for this program specifically: a legacy core-platform modernization with a hard data-conversion cutover, vendor selection, and a fixed regulatory go-live isn't a good fit for iterative, evolving scope — the platform either cuts over correctly on a known date or it doesn't. That's the case for PMBOK/waterfall here; it isn't a claim that predictive delivery is always the right choice.
Contents
1. Methodology at a Glance
PMBOK-standard delivery is predictive: scope, schedule, and budget are defined and baselined during Planning, before major execution work begins, and the program is measured against that baseline for the rest of its life. This is the opposite instinct from Agile/Scrum, where scope is deliberately left flexible and re-prioritized every sprint. Predictive delivery trades flexibility for predictability — which is exactly the trade a program with a hard cutover date and a fixed regulatory deadline needs to make.
The core discipline that makes predictive delivery work is change control: once the baseline is set, nothing — not scope, not schedule, not budget — changes without a documented, impact-assessed, formally approved Change Request. This is slower than an Agile team just re-ordering its backlog, but it's what lets a sponsor trust that "on track" actually means something measurable.
2. The Five Process Groups
Initiation
The program starts with a Business Case justifying the investment, followed by a Charter that formally authorizes the PM to spend budget and use organizational resources — signed by the sponsor, not just written by the PM.
Why it matters: the Charter is what gives the PM actual authority — without a signed Charter, a PM is coordinating volunteers, not running a funded program. It's also the first place success criteria get written down in a way everyone can be held to later, which is exactly what Closeout will measure against.
Planning
The Program Management Plan, RACI, and baseline budget are built here — this is where scope, schedule, and cost get fixed into the baseline that change control will protect for the rest of the program.
Why it matters: everything measured for the rest of the program — the 43% budget spent, the 37% schedule elapsed, the Yellow/Green health calls — is only meaningful because it's measured against a baseline that was locked once, on purpose, during Planning. A moving baseline can't produce a trustworthy status report.
Execution
The actual delivery work happens here — vendor selection, system upgrade, data conversion, integration build — while the PM coordinates resources against the plan built in Planning.
Why it matters: Execution is deliberately the largest process group by duration and effort, but it's not where the PM's attention concentrates most — that's Monitoring & Controlling, next. Execution is where the plan gets carried out; Monitoring & Controlling is where the PM finds out whether carrying it out is actually working.
Monitoring & Controlling
This runs in parallel with Execution, not after it — the RAIDD Log tracks active risks, the Status Report measures progress against baseline, and any proposed change flows through the Change Control Log before it's approved.
Why it matters: this is the process group most people underestimate, because it doesn't produce a visible deliverable the way Execution does. But it's what turns "the program will probably be fine" into "here's exactly which risk could derail us, here's the plan to prevent it, and here's the fallback if the plan doesn't work" — the difference between a program that gets ambushed by a problem and one that saw it coming with runway to respond.
Closeout
Formal acceptance of final deliverables, lessons learned captured for future programs, and release of program resources — documented in a Closeout Report.
3. Key Disciplines vs. Agile Delivery
| Discipline | PMBOK / Predictive | Agile / Scrum |
|---|---|---|
| Scope | Fixed at Planning baseline; changes go through formal Change Control | Deliberately flexible; re-prioritized every sprint via the Product Backlog |
| Schedule | Single baseline schedule tracked to completion (e.g. 331 working days) | Fixed-length sprints (e.g. 2 weeks); scope flexes, timebox doesn't |
| Risk tracking | RAIDD Log — Risks, Assumptions, Issues, Decisions, Dependencies in one register | Risks surfaced and retired sprint-by-sprint, often in the Sprint Retrospective |
| Progress measurement | % complete against baseline schedule/budget | Velocity and burndown against sprint commitment |
| Change authority | Sponsor/Steering Committee approves formal Change Requests | Product Owner re-orders the backlog; no formal change board needed |
| Retrospective mechanism | Lessons Learned captured at Closeout (or as issues arise) | Sprint Retrospective every sprint — continuous, not one-time |
Neither approach is strictly better — they're suited to different kinds of uncertainty. PMBOK/predictive delivery works when the end state is well understood and the risk is mostly in execution (a data conversion either reconciles or it doesn't); Agile/Scrum works when the end state itself is uncertain and needs to be discovered through iteration (which is why the Agile suite's methodology guide covers a very different set of mechanics for MedConnect Mobile).
4. Change Control in Action
It's easier to understand formal change control by seeing two real approved changes than by reading the definition. Both are logged in the Change Control Log:
- CR-001 — Add Project Kickoff Meeting. A formal kickoff was missing between Charter sign-off and Requirements Gathering. Even a one-day schedule addition this small still went through the log — approval authority was the PM alone (informational only, since a 1-day addition was within the PM's discretion), but it's still a documented, traceable change against the baseline, not an informal adjustment.
- CR-002 — Formalize Requirements & Design Sign-off cycles. Added a structured walkthrough + 3-day feedback + recirculation + 3-day sign-off pattern to both gates, adding 6 days total to the schedule. This one needed a higher approval bar since it changed the baseline schedule by nearly a week.
Notice what both have in common: a plain-language description of what changed, why, the schedule/cost/scope impact, and who had authority to approve it. That's the whole discipline — not bureaucracy for its own sake, but making sure nothing shifts the baseline without someone accountable actually deciding it should.
5. Understanding RAIDD
A RAIDD Log tracks five related categories in one register rather than five separate lists, because in practice they constantly convert into each other: an Assumption that turns out false becomes an Issue; a Dependency that's late becomes a Risk; a Decision is often what resolves a Risk in the first place. Tracking them separately loses that connective tissue.
- Risks — things that might happen and would hurt the program if they do (e.g. R-001, historical claims data quality)
- Assumptions — things being planned around as if true, not yet confirmed
- Issues — risks that already happened, now being actively managed
- Decisions — logged choices, so nobody re-litigates them later without knowing why they were made
- Dependencies — things this program needs from outside itself (another team, a vendor, a system) to stay on track
See the full RAIDD Log for how R-001 through R-007 are tracked live on this program.
6. Enrollment & Claims by the Numbers
| Figure | Value | Source |
|---|---|---|
| Total Program Budget (baseline) | $7.06M | Project Budget |
| Spent to Date | $3.05M (43%) | Project Budget / Program Dashboard |
| Baseline Schedule | 331 working days, Kickoff 04 Aug 2026 | Program Dashboard |
| Schedule Progress | 37% (123 of 331 days elapsed) | Program Dashboard |
| Overall Health | Yellow — driven by R-001 | Program Dashboard |
| Next Milestone | Data Conversion Sign-off, 16 Mar 2027 | Program Dashboard |
| Sponsor | G. Whitfield, VP of Operations | Charter |
7. Roles at a Glance
The RACI Matrix names who does what across the program's major deliverable sign-offs. A few worth knowing:
| Role | RACI | Owns |
|---|---|---|
| C. Tyrrell — Program Manager | Accountable (nearly everywhere) | Overall delivery, schedule, budget, and being the single point of accountability to the Sponsor |
| G. Whitfield — Sponsor, VP of Operations | Informed / Approves major changes | Charter authority, success criteria, funding |
| F. Jones | Responsible | Requirements Sign-off |
| W. Donnelly | Responsible | Vendor Selection & SOW |
| M. Alvarez | Responsible | System Upgrade Validation |
| T. McCormick | Responsible | Data Conversion Sign-off |
Notice the pattern: C. Tyrrell is Accountable across nearly every major sign-off without being personally Responsible for the work itself — that's the PM's role in predictive delivery. Being accountable for an outcome someone else is directly responsible for producing is exactly what the RACI model is designed to make explicit, rather than leaving it ambiguous who actually owns the result when something goes wrong.
8. Questions & Answers
Initiation, Planning, Execution, Monitoring & Controlling, and Closeout. Monitoring & Controlling runs in parallel with Execution rather than after it — that's a common misconception.
Because the whole point of a baseline is to have a fixed reference point to measure variance against. If the baseline moved every time something changed, "on track" and "behind schedule" would stop meaning anything measurable — which is exactly what formal Change Control exists to prevent.
A risk register is one of RAIDD's five categories. RAIDD adds Assumptions, Issues, Decisions, and Dependencies because those categories constantly convert into and explain each other — see Section 4 above.
The Business Case justifies why the program should be funded. The Charter — issued once funding is approved — formally authorizes the PM to spend that budget and names the sponsor and success criteria.
Because the discipline isn't about the size of the change, it's about traceability — even a minor addition to the baseline needs a documented record of what changed and who approved it, so nobody has to reconstruct history later to explain a schedule variance.
Yes — Yellow means an active risk needs attention, not that the program has already missed a commitment. Enrollment & Claims is Yellow because of R-001, but both Schedule and Budget are independently rated "on track" at the same status date — the color reflects risk exposure, not current performance.
9. Related Reading
PMBOK Glossary — glossary.html — plain-English definitions of every PMBOK term used across this suite.
Lessons Learned Register — lessons-learned.html — real program lessons captured during Enrollment & Claims delivery.
Compare methodologies — see how this differs from Agile/Scrum delivery and federal civilian contracting in the other two suites.