Project Charter

1. Charter Authorization & Document Purpose

This Project Charter formally authorizes the Enrollment & Claims Platform Modernization program, designates C. Tyrrell as Program Manager, and establishes the authority under which organizational resources may be committed to the work. Consistent with PMBOK practice, the charter is the document that brings the program into existence: until it is approved, no cost baseline exists to manage against and no manager holds delegated authority to commit resources.

The charter records the program as authorized at approval. It is deliberately not a status document and is not re-issued as the program progresses — the Program Budget carries current forecast and actuals, the Dashboard carries current status, and the Change Control Log carries every subsequent change to the baselines this document establishes. Where a figure here differs from a live artifact, the live artifact governs current state and this charter governs what was authorized.

One correction is reflected: the cost and resourcing baseline below was corrected from an original 20-person, $7,062,000 estimate to the 55-person, named-labor delivery team recorded in decision D-005. Because that was a correction of an estimating error rather than a change of scope, it propagates backward into this authorizing document rather than being carried as a variance against it.

2. Business Case & Strategic Context

ACME Company's current enrollment and claims processing platform is approaching end of vendor-supported life and can no longer efficiently support the volume, integration, and compliance demands of the business. Manual workarounds have proliferated across Billing, Underwriting, Claims Administration, Commission Management, and reporting functions, increasing operational risk and processing cost.

This program authorizes a modernization of the core enrollment and claims platform, including a vendor-delivered system upgrade, conversion of member/policy, provider/producer, and historical claims data, and new integrations across six downstream systems. This is not a purely discretionary efficiency investment: the legacy platform's vendor has announced end-of-support, and the current system cannot be extended past that date without an unsupported-software risk the organization is not willing to carry. Replacement is required regardless of the return on any specific investment level — the business case evaluates whether the chosen modernization scope, rather than a bare like-for-like replacement, is the right level of investment for a change the organization has to make either way.

That framing matters for how this program should be judged. A discretionary investment is approved or declined on its return. A mandatory replacement is approved on its necessity, and the return analysis governs only the increment of scope above the minimum viable replacement. The Cost-Benefit Analysis is structured on exactly that basis, and the Benefits Realization Plan tracks the benefits attributable to the modernization increment rather than claiming credit for capability the organization would have had to buy anyway.

Beyond the baseline requirement, platform modernization reduces manual processing cost, reduces compliance and data-quality risk, and positions the organization to meet growing transaction volume without proportional headcount growth.

3. Program Objectives & Success Criteria

Each objective below is stated with the measurable criterion by which it will be judged, so that "success" is assessable at closeout rather than argued.

4. Program Scope

4.1 In Scope

• Core platform version upgrade (vendor-delivered).
• Data conversion: member/policy, provider/producer, and historical claims.
• Six new system integrations: Billing, Underwriting, Claims Administration, Commission Management, Data Warehouse/Reporting, Payment Processing.
• Security, performance, and disaster-recovery testing; SOX control impact assessment for financial-system changes.
• Change management, training, and a post-go-live hypercare/warranty period.

4.2 Out of Scope

• Data migration from any system outside the workstreams listed above.
• Ongoing run-state production support beyond the vendor warranty period.
• Any new product or underwriting-rules changes not directly required by the platform upgrade.
• Decommissioning of the legacy platform beyond the planning required to hand it off — execution depends on the warranty period completing (DEP-005).

The out-of-scope list is as load-bearing as the in-scope list. A platform modernization attracts adjacent requests — new products, rules changes, additional migrations — each individually reasonable and collectively fatal to the schedule. Naming these exclusions in the authorizing document means adding them later requires a change request evaluated against the baseline, rather than absorption into a scope that was never bounded.

5. High-Level Requirements

• The upgraded platform must retain functional parity with current production capability for all in-scope business processes.
• All six integrations must exchange data with downstream systems using currently-approved enterprise integration standards.
• The platform must pass SOX control testing prior to Go-Live given its handling of financial transactions.
• Data conversion must meet a ≥99.5% record-match accuracy threshold prior to Data Conversion Sign-off.
• Protected health information and member data must remain within existing HIPAA-compliant handling controls throughout conversion, testing and cutover.

These are charter-level requirements only. They are decomposed into numbered business requirements in the Business Requirements Document (per PMBOK §5.2, Collect Requirements) and into functional specifications in the Functional Specification, with coverage evidenced by the Requirements Traceability Matrix.

6. Summary Milestone Schedule

The schedule below is the authorized baseline. Its governing constraint is that Go-Live must precede the next open-enrollment period (assumption A-004) — a date the business cannot move — so the program is planned backwards from Go-Live rather than forwards from kickoff.

The eleven-week interval between UAT Sign-off (Aug 10, 2027) and Closeout (Nov 2, 2027) is deliberate: it carries Go-Live, hypercare and the warranty period. Compressing it to recover schedule elsewhere would move risk into the one window where the program has no capacity to absorb it.

7. Budget Authorization

The following cost baseline is authorized. Figures are the authorized baseline at charter approval, corrected per decision D-005 as described in §1; current forecast, spend-to-date and variance are carried by the Program Budget, which at the time of reading may differ from these figures by design.

The labor subtotal of $7,369,050 reconciles exactly to the rate card in the Resource Plan across the 55-person named roster — the authorized budget and the authorized team are the same commitment expressed two ways, and a change to either must reconcile to the other. The two vendor contracts together represent 23.5% of the base budget, which is why vendor governance is treated as a distinct decision path in §10 rather than folded into general change control.

8. Contingency Reserve & Financial Controls

A contingency reserve of $1,053,000 — 10% of the base budget — is authorized and held by the Program Manager for identified risks materializing within the approved scope. It is not a discretionary fund: drawing on it requires the risk it addresses to be a recorded risk, and the draw is logged against that risk.

One utilization is pre-approved at charter: decision D-002 authorizes up to $150,000 of contingency for a third Data Conversion dry-run cycle should root-cause data cleansing prove insufficient after two. Pre-approving it removes the scenario where the program must choose between an unbudgeted request mid-conversion and proceeding on a dry run it does not trust.

Consumption of the reserve is reported to the Steering Committee as a standing item. Variance that would exceed the reserve is not a Program Manager decision at any threshold — it is a cost-baseline change requiring Executive Sponsor approval under the Tier 3 authority described in §10.

9. Organization & Resourcing

The program is authorized a 55-person named delivery team, detailed in the Resource Plan and reflected in the labor baseline in §7. Naming the roster at charter rather than sizing it in the abstract is deliberate: it is what makes assumption A-002 (named resources available at planned allocation) testable rather than aspirational, and it is what allows the budget and the resource plan to reconcile to the dollar.

The team spans program management and governance, solution/data/integration architecture, business analysis, system upgrade, data conversion, dual-shore QA, six integration development tracks, infrastructure and security engineering, UAT subject-matter experts, and change management and training. Reporting lines and role definitions are carried in the Organizational Chart and accountabilities in the RACI Matrix.

10. Governance Structure & Decision Rights

Decision authority is tiered so that escalation is triggered by a defined threshold being crossed rather than by individual judgment about whether something feels significant. The full definition is carried in the Governance Model; the tiers it establishes are:

Change requests are evaluated through the Change Control Board and recorded in the Change Control Log, which is the operational record of every request assessed against these tiers. Vendor governance is handled on a distinct path given the contract value noted in §7.

11. Program Manager Authority & Limitations

C. Tyrrell is authorized to apply organizational resources to program activities, manage the approved budget within the cost baseline, draw on the contingency reserve against recorded risks, and approve task-level schedule adjustments that do not affect a Steering-Committee-level milestone.

That authority is bounded. Changes to scope, to the cost baseline, or to a contractual or compliance obligation require Steering Committee approval; variance exceeding the contingency reserve and any change to program-level scope or governance require Executive Sponsor approval. Stating the limits alongside the grant is the point of this section — an authority whose boundaries are undefined is not delegated authority but an unresolved question that surfaces during the first disagreement.

12. Key Stakeholders

Stakeholder engagement approach, communication cadence and escalation routes are defined in the Communications Plan.

13. Regulatory & Compliance Framework

The program operates inside three compliance regimes, each of which constrains delivery rather than merely reporting on it:

• HIPAA / protected health information. Member and claims data converted, tested and cut over under this program is PHI. Conversion, test-data handling and defect triage must all remain within existing HIPAA-compliant controls — which is a design constraint on the test approach, not only a policy statement.
• SOX. The platform handles financial transactions, so it falls within Sarbanes-Oxley control scope. SOX control testing is a Go-Live gate (§3), and decision D-004 engages an external firm for the SOX compliance assessment rather than relying on internal audit alone, given the scale of the control change.
• State insurance filing and reporting. Requirements can change mid-program; risk R-004 carries the possibility that a mid-program state filing or reporting change adds unplanned compliance scope.

14. Benefits Realization Framework

Five benefits (BEN-01 through BEN-05) are defined for this program, each with a named owner, a measurement method and a realization window, in the Benefits Realization Plan. They span labor efficiency in claims processing, reduction of manual workaround effort, data-quality and compliance-risk reduction, infrastructure rationalization, and the avoided cost of running an unsupported platform.

Because most benefits realize after Go-Live rather than at it, benefit ownership deliberately transfers to operational owners at closeout: the program is accountable for delivering the capability and for establishing the measurement baseline, and the business is accountable for realizing the value from it. A program that claims its own benefits at closeout is claiming them before they exist.

15. High-Level Risks

Six risks are recorded at charter approval in the RAIDD Log, with scoring, owners and response strategies maintained there:

Two of these risks are already funded or sequenced at charter rather than left for later response planning. R-001, the highest-rated risk, is the reason decision D-002 pre-approves $150,000 of contingency for a third conversion dry run — the mitigation is authorized before the risk materializes, so a data-quality surprise does not become a funding argument during the conversion window. R-003 is carried in the schedule as dependency DEP-003, because a vendor SOW delay does not simply raise a risk score, it blocks environment provisioning and therefore the start of build. Recording a risk in one register and its consequence in another is how the charter keeps a threat from being tracked as a concern while its schedule effect goes unowned.

16. Assumptions

A-004 is the assumption with the least give in it. Open enrollment is set by the business calendar, not by the program, so it functions as a fixed constraint: schedule pressure anywhere in the plan resolves against scope or cost, never against that date.

17. Constraints

• Immovable Go-Live window. Production cutover must complete before the next open-enrollment period begins (A-004).
• Fixed cost baseline. Delivery must complete within $11,582,050, with variance absorbed inside the contingency reserve.
• Vendor-delivered upgrade. The core upgrade is performed by the platform vendor, so the program controls the schedule around it but not the upgrade work itself.
• Regulatory control gates. SOX control testing and security clearance are Go-Live gates that cannot be waived for schedule.

18. Dependencies

19. Decisions Ratified at Charter

Five decisions are ratified as part of this authorization and recorded in the RAIDD Log. They are listed here because each one shapes a baseline this charter establishes — a decision that changes the plan belongs in the document that authorizes the plan.

20. Document Control & Related Documents

This charter is version 1.0, dated Jul 28, 2026, and is superseded only by a re-issued charter approved by the Executive Sponsor. Changes to the baselines it establishes are made through change control and recorded in the Change Control Log, not by amending this document.

• Project Management Plan — how the program will be executed, monitored and controlled
• Business Requirements Document and Functional Specification — requirements decomposition
• Requirements Traceability Matrix — requirement coverage evidence
• Program Budget and Resource Plan — current financials and the named roster
• Governance Model, RACI Matrix, Communications Plan
• RAIDD Log — risks, assumptions, issues, dependencies and decisions
• Benefits Realization Plan and Cost-Benefit Analysis

21. Approval

This charter authorizes the Program Manager to proceed with planning and execution of the Enrollment & Claims Platform Modernization program as described above, within the authority defined in §11 and the baselines established in §6 and §7.