A complete set of PMBOK-aligned program management artifacts for a fictional enterprise platform modernization at ACME Company — demonstrating hands-on command of program management practice across the full discipline: scope, schedule, cost, quality, risk, resource, communications, and stakeholder management. Each artifact reflects the kind of documentation and reporting I create and maintain in an active PM role, available here as a live interactive page and as a downloadable Word, Excel, or PowerPoint file.
Initiating
Project Charter
The document that authorizes the program: purpose, objectives, high-level scope, risks, summary budget, and PM authority.
Cost-Benefit Analysis (CBA)
Quantified benefits vs. cost, 10-year cash flow, payback period, ROI, and NPV — the financial case for the program.
Benefits Realization Plan
Makes the CBA's 50/80/100% realization curve falsifiable — which operating department each benefit lands in, who is accountable for declaring it, and how measurement survives a program that closes ten weeks after go-live.
Total Cost of Ownership (TCO)
Full 10-year cost model including ongoing licensing, hosting, and support — compared against the cost of the legacy status quo.
Program Kickoff Deck
The actual kickoff presentation — welcome, program overview, objectives, scope, team, timeline, budget, governance, risks, and next steps in one deck.
Planning
The Budget and Governance Model are established here but stay active well into Executing/Monitoring & Controlling — baselines get set in Planning, then tracked against for the life of the program.
Project Management Plan
Full 21-section PMBOK-aligned PM Plan — scope, schedule, cost, quality, risk, governance, and more.
Business Requirements Document (BRD)
The authoritative statement of what the business needs and why — 59 requirements classified using the PMBOK §5.2 Collect Requirements schema (business, stakeholder, solution functional/non-functional, and transition), with current/future state, elicitation approach, MoSCoW prioritization, traceability, and formal baseline at the Nov 3, 2026 milestone.
Functional Specification (FSD)
The bridge from BRD to build — 52 specifications traced to BRD requirement IDs, covering platform configuration and all six downstream integration interfaces grouped by the three BA domains, plus business rules, conversion behavior, a single error-handling standard across all interfaces, and the security model. Written so eighteen developers build from one agreed definition.
Requirements Traceability Matrix (RTM)
The second output of PMBOK §5.2, alongside the requirements documentation. All 59 baselined requirements traced forward to specification, verification method and acceptance — generated directly from the BRD and FSD so it cannot drift from them. Reports 100% functional coverage and names three genuine open gaps rather than hiding them.
Work Breakdown Structure (WBS) Console
Interactive Gantt-style schedule — 315 line items across 8 phases, with live % complete and a "Today" marker. Exports as Excel or a genuine Microsoft Project file, with 223 inferred task dependencies.
Resource-Loaded WBS
Allocation-aware resource loading of all 315 WBS line items — 250 loaded work packages, 55 named resources, 256 assignments. Every package carries one accountable owner plus named contributors, and every person's effort reconciles exactly to their Resource Plan hours: 56,950 hours totaling $7,369,050, tying to the labor baseline in the Program Budget.
Project Budget
Full $11.58M cost baseline by category, a 55-person blended rate card, and Steering Committee sign-off status.
Resource Plan
The 55-person named roster — role, location, allocation, and blended rate, reconciled exactly to the Project Budget's rate card.
Organizational Chart
Program reporting structure — direct line to the PMO, and every matrixed resource on loan from their home department, grouped by function.
RACI Matrix
Deliverable sign-off and governance-process responsibility assignment — Responsible, Accountable, Consulted, Informed for every major decision.
Roles & Responsibilities
Who owns what across 55 matrixed people — and what each function explicitly does not own. Includes the two bodies the program cannot instruct, and a translation table for the same roles in agile, federal and manufacturing programs.
Project Governance Model
Decision rights, escalation thresholds, stage-gate criteria, and compliance oversight — the authoritative framework behind every other document in this suite.
Communications Plan
How every stakeholder group stays correctly informed across fifteen months — influence/impact stakeholder analysis, message architecture, a fourteen-line communication matrix, phase-based intensity with a deliberate quiet period, the change champion network, the cutover and hypercare sequence, four-tier escalation, and effectiveness measured on readiness rather than volume.
Test & Quality Strategy
How a vendor-delivered platform upgrade, a full member/policy/provider/claims data conversion, and six downstream integrations are verified before carrying live traffic. Covers testing under the hybrid delivery model, the dual-shore QA operation, staged conversion dry runs with reconciliation, vendor acceptance testing, parallel run, UAT, and SOX/HIPAA compliance verification — all planned backwards from the fixed open-enrollment go-live.
Data Conversion Plan
Closes RTM gap G-01. The owning document for transition requirements TR-001 through TR-007: the five-stage conversion pipeline, 100% record and control-total reconciliation, auditable and reversible de-duplication, the three-dry-run model with the D-002 pre-funded contingency, the independent parallel run, the cutover outage window, and the tested rollback to the point of no return.
Cutover Plan
Closes RTM gap G-02. Owns TR-010, TR-011 and TR-012 and the operational runbook for TR-006/007: the conjunctive readiness gate, the sequenced cutover-weekend runbook, the single point of no return, the rehearsed rollback, hypercare with severity triage, legacy read-only retention, and member/provider notification.
Training Plan
Closes RTM gap G-03. Owns TR-008 and TR-009: role-based training, competency assessed against representative tasks (not attendance), process-documentation currency, and adoption — jointly owned by the Training Lead and Change Manager.
Vendor Management Plan
Governance of the platform vendor on a vendor-delivered program — contractual structure and SOW content requirements, bi-weekly governance cadence, deliverable acceptance discipline, two-way dependency management, a six-measure performance scorecard with defect SLAs, four-tier escalation, vendor risk and contingency, and the warranty period through transition to steady-state support.
Vendor Statement of Work (SOW-001)
The contract binding the platform vendor — scope and explicit exclusions, nine deliverables with testable acceptance criteria, a ten-day review with deemed acceptance, eight client dependencies, seven milestone payments totaling $1,850,000 reconciled to the budget line, defect SLAs, warranty with attribution settled at signature, and transition assistance secured while leverage exists.
SOW-002 · Integration Middleware
The contract binding the middleware vendor — licensing and implementation support for the six downstream integrations, four deliverables with testable acceptance criteria, a ten-day review with deemed acceptance, four client dependencies with named owners, payment as percentages against named deliverables totaling $620,000, and liability capped at fees paid in the preceding twelve months with confidentiality, PHI and IP uncapped.
SOW-003 · Offshore QA Capacity
The contract binding the offshore QA supplier — manual execution only, with test design and defect triage explicitly retained by the program. Four deliverables, a capped envelope of $947,000 reconciling to the budget line after CR-004 and CR-007, an hour unsupported by an execution record declared not payable, and transition assistance secured while leverage exists.
SOW-004 · Independent SOX Assessment
The contract binding the external assessment firm engaged under decision D-004 — independence is the deliverable, and the clause prohibiting any fee contingent on the findings is the reason the assessment is worth having. Four deliverables, findings presented directly to the Steering Committee, and no total committed: each phase is quoted on confirmation of the control population, because a fixed price agreed before that is either padded or becomes pressure to narrow scope.
SOW-005 · Infrastructure & Hosting
The contract binding the hosting provider to the build, test and production environments every other workstream depends on. Consumption-priced against a committed environment budget of $480,000, with the $601,500 infrastructure labor line named as the program's own staff and expressly not payable. Availability, RPO and RTO stated as measures, and an invoice line without a matching consumption report line declared not payable.
Executing & Monitoring / Controlling
Program Dashboard
Executive summary, RAG status, milestone timeline, top risks, budget snapshot, and phase-by-phase progress at a glance.
Weekly Status Report
Accomplished/planned this week, risks & issues requiring attention, budget health & variance, and the full milestone roadmap.
Steering Committee Deck
15-slide monthly executive update — decision requested, schedule, budget, risk, quality KPIs, and team status.
Change Control Log
Every formal change request against the program's baselines, filterable by category, with full cross-document traceability.
Change Control Detail
The worked change requests behind the log — each CR with its business justification, impact assessment across scope, schedule, cost and risk, options considered, recommendation, and the approval record. This is the evidence layer beneath the Change Control Log.
Closing
Project Closeout Report
Final cost/schedule performance against baseline, deliverable acceptance, outstanding items, and formal program closure sign-off.
Reference
General SOWs Reference
The earlier clause-led drafts of all five Statements of Work, retained for comparison. Each states the same commercial terms as its current counterpart but devotes most of its length to clauses the Master Services Agreement already governs; the restructured versions above give that space to scope, approach and phased delivery instead. These are superseded and are not the current contractual instruments.
SOW-001 · Core Platform Upgrade (v1)
The original clause-led draft of the platform upgrade contract, before the restructure. Seventeen sections weighted toward warranty, liability, IP, termination and precedence.
SOW-002 · Integration Middleware (v1)
The clause-led draft of the middleware contract. Same commercial terms as the current version; the work itself is described in two bullet lists rather than in scope and approach narrative.
SOW-003 · Offshore QA Capacity (v1)
The clause-led draft of the offshore QA contract, retained so the change in emphasis between the two versions is visible rather than asserted.
SOW-004 · Independent SOX Assessment (v1)
The clause-led draft of the independent assessment contract, before Scope, Approach and phased delivery were written out.
Common PMBOK Questions
What are the five PMBOK process groups?
Initiation, Planning, Execution, Monitoring & Controlling, and Closeout — a predictive, phase-gated structure where scope, schedule, and budget are baselined early and changes flow through formal change control.
What is a RAIDD log?
RAIDD tracks five related categories in one register — Risks, Assumptions, Issues, Decisions, and Dependencies — because they constantly convert into and explain each other during a program's life.
What is the difference between a RACI chart's Responsible and Accountable roles?
Responsible is who actually does the work; Accountable is who owns the outcome and answers for it, even if someone else is doing the work itself.
Why does a PMBOK program need formal change control?
Because scope, schedule, and budget are baselined at Planning sign-off, any change has to be evaluated for impact and formally approved before the baseline itself changes.
What is the difference between a Business Case and a Project Charter?
The Business Case justifies why the program should be funded; the Charter, issued once funding is approved, formally authorizes the PM to spend the budget.