If you're moving between documents in this portfolio and notice a team size or budget figure that doesn't match another page — that's not a mistake. It's the portfolio working as intended.
Every program here evolves the way real programs do: original estimates get corrected once real work reveals a gap, and real customers change scope mid-program. A resume line can't show that kind of history. A working document set can — so this portfolio deliberately keeps every version of the truth, dated and explained, rather than quietly editing old numbers to match new ones.
Two different kinds of change
Every headcount or budget change in this portfolio falls into one of two categories, and each is documented differently on purpose — the mechanism itself is part of what's being demonstrated:
Staffing Correction
An earlier estimate simply didn't staff enough people to deliver the original scope — for example, naming one developer per integration when the build genuinely needed three. This is caught, documented as a dated decision with before/after figures and a stated reason, and corrected. It is not a scope change — the work being delivered didn't grow, the realistic plan to deliver it did. These are logged in each suite's own decision register: RAIDD Decision Log (PM, Agile, Aerospace) — e.g., PM's D-005, Agile's DEC-06, Aerospace's D-05.
Scope Addition
The customer genuinely asked for more — new deliverables, a higher production rate, added integration — and the program grew because the work grew, not because the original plan was wrong. This gets a different kind of paper trail entirely: a Contract Modification with its own negotiated price on the federal Task Order (P00011), or a customer-driven Purchase Order Amendment on the aerospace production program (D-06). Federal's kickoff deck still correctly shows the original 13-person team, because that's genuinely what existed on kickoff day — the Contract Mod came seven weeks later.
Which documents are frozen in time, and which are current
Two kinds of document behave differently on purpose, and knowing which is which resolves most apparent inconsistencies at a glance:
- Point-in-time documents — kickoff decks, specifically — are a record of an actual meeting on an actual date. They show what was true that day, even if it was later corrected or grown. If a correction happened before that date, the kickoff deck reflects it (PM and Agile's corrections both predate their kickoffs). If it happened after, the kickoff deck stays as it was (Federal's Contract Mod happened seven weeks post-kickoff, so the kickoff deck still shows 13 people — that's accurate, not stale).
- Living documents — the Resource Plan, Program/Task Order Budget, Org Chart, and Steering/Status decks — always reflect the current state as of their own stated report date. These are the documents to check for "what does the team look like right now."
One more thing worth knowing: some payback numbers look weak on purpose
Five of the eight suites — PM, Agile, Federal, Aerospace and AI Transformation — each have a Cost-Benefit Analysis, a Total Cost of Ownership page, and a Benefits Realization Plan that names who owns each projected benefit, how it is measured, and when. In four of them (PM, Agile, Federal, AI Transformation) you'll notice the payback periods and NPV figures are thin, or negative, or take longer than a typical planning horizon — that's not a mistake either, and it's not being hidden. Each of those four is a mandatory replacement: a legacy system's vendor announced end-of-support, so "don't spend the money" was never actually an option. A payback-period test only means something when spending is optional — it's the wrong tool for a decision that has to happen regardless. Where that's true, the CBA says so explicitly, shows the real numbers (not adjusted to look better), and explains that the analysis is justifying the scope chosen, not gating whether to act. Federal's case is the clearest because it has real negotiated dollars behind the distinction: its Contract Modification added genuine new scope with its own new benefits, so its numbers are thinner than before but still positive — different from PM and Agile, where the corrected budget covers the same scope more realistically, with no new benefit to offset it, and the honest NPV goes negative. Aerospace is the exception: it isn't a mandatory replacement but a fixed-price production program, so its CBA is a quality-investment case (First Article and Material Review Board discipline versus the cost of one escaped defect) with a healthy return — a different question, honestly scoped as such.
Every suite's history, at a glance
| Suite | Team Size | Budget | Mechanism | Documented In |
|---|---|---|---|---|
| PM (Enrollment & Claims) | 20 → 55 | $7.06M → $11.58M | Staffing correction | RAIDD D-005 |
| Agile (MedConnect Mobile) | 13 → 28 | $1.85M → $3.71M | Staffing correction | RAIDD DEC-06 |
| Federal (BenefitConnect) | 13 → 35 | $3.66M → $7.70M | Contract Modification (new scope) | Contract Mod P00011 |
| Aerospace (CWP-700) | 14 → 25 → 50 | $3.5M → $5.2M → $9.28M | Staffing correction, then customer rate increase | RAIDD D-05, then D-06 |
| AI Transformation (Project Catalyst) | 262 | $99.0M | Tiered change authority — no correction required | Change Control Log |
| Stage-Gate NPD (Beacon Index Advantage) | 90 | $27.9M | Gate 1 recycle, then scope reduced at Gate 2 | Gate 1 Recycle Record · CR-001, CR-002 |
| Drug Development (VitaFlow VTX-401) | 109 | $243.0M | Scope added at Phase 2, then narrowed at Gate 4 | Change Control Log · CR-01, CR-02 |
| M&A Integration (ACME / Cumberland Valley) | 58 → 84 | $52.5M → $60.1M authorized | Re-baseline from a Class 5 deal model to a Class 2 estimate, then twelve change requests | Change Control Log · CR-001–CR-012 |
Why two suites are deliberately unfinished
Two suites behave differently from the other six — the Stage-Gate NPD suite and the Drug Development suite — and they are the places on this site where an incomplete program is the point. The other suites document delivery. These two document decision — five gates at which a cross-functional board votes to continue, stop, or send the work back — and it is shown at Stage 2 of 4, with three gates still ahead of it.
The reason is that a completed stage-gate program is indistinguishable from waterfall. Look backward at a launched product and every gate reads GO, the conditions have all closed, and four separate funding releases look like a single budget. The governance is invisible precisely because it worked. It can only be shown while the decisions are still open — while conditions are outstanding, while money is unreleased, while a gate has not yet met. So that suite carries a gate that was recycled, two conditions still unverified, and $13.7M of authorized cost that has not been released and may never be.
Its documentation set is complete; the program it documents is not, by design. It still shows how a program closes — a Gate 5 Post-Launch Review is carried as an explicitly labelled illustrative end-state, and a Prior Concept Cancellation Record documents an earlier product this same board cancelled outright.
One further difference worth naming: that suite has no correction history in the table above, and its absence is not an oversight. The other five were built artifact-first and their figures were corrected afterwards — which is exactly what the table records. The stage-gate suite was built the other way round, from a locked fact pack agreed before a single document was written, with an automated check that refuses any figure that does not reconcile. Nothing has needed correcting yet.
Why build it this way
Because this is the actual job. A PM who never had to correct an early estimate, or never had a customer change scope mid-program, hasn't run a real program — they've run a fictional one where everything was known on day one. What separates a program that's actually under control from one that only looks that way on a slide is whether the correction gets written down, dated, and reasoned through, or gets quietly absorbed so nobody has to explain it later.
Every figure in this portfolio traces to a document that explains it — a decision log entry, a contract modification, a reconciliation table that closes to zero variance. If two pages ever show different numbers for the same thing with no explanation anywhere, that's a real bug worth flagging — not a feature of the design.
Want to see one worked end-to-end? Start with Federal's Contract Mod Log — it's the clearest example, since a Firm-Fixed-Price contract makes the distinction between "we got the estimate wrong" and "the customer asked for more" a matter of real dollars, not just narrative framing.