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
All five suites have a Cost-Benefit Analysis, a Total Cost of Ownership page, and — as of the latest build — 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 |
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.