Program Management Plan (PMP) — Version 1.0

Project Catalyst — $99,000,000 AI Transformation Program, ACME Highland Health. This Program Management Plan is the master operational document governing how the program will be executed, monitored, controlled, and closed across 36.5 months (Aug 2026–Aug 2029). It integrates all PMBOK subsidiary management plans plus AI-specific governance, model risk, data privacy, and regulatory compliance plans unique to enterprise AI deployment in regulated healthcare. Approved by Executive Steering Board; updates require formal change control.

1. Introduction & Document Purpose

This Program Management Plan (PMP) is the single authoritative document governing how Project Catalyst will be planned, executed, monitored, controlled, and closed. It integrates all subsidiary management plans — scope, schedule, cost, quality, resource, communications, risk, procurement, and stakeholder — plus three plans unique to enterprise AI deployment in regulated healthcare: AI Governance & Model Risk, Data Governance & Privacy, and Regulatory Compliance. Together, these plans constitute the operational blueprint for a 262-person, $99 million, 36.5-month program.

This PMP operates under the authority of the Program Charter (approved August 3, 2026) and the Program Governance Model. It is reviewed at every phase gate and updated through the formal change control process defined in Section 21. No section of this plan may be modified without Executive Steering Board approval and a corresponding entry in the Change Control Log.

1.1 Intended Audience

• Program Director (C. Tyrrell) — primary owner; executes and enforces all procedures in this plan
• PMO Lead (T. Valdez) — day-to-day coordinator; maintains all tracking artifacts referenced here
• 25 Team Leads — responsible for compliance with the section(s) applicable to their team's work
• Executive Steering Board — approves this plan and its updates; reviews status against it at phase gates
• AI Governance Board & Enterprise Architecture Board — enforce AI-specific and technical sections
• Program Finance (A. Rodriguez) — enforces cost management procedures in Section 8

1.2 Related Documents

2. Program Overview & Strategic Context

Project Catalyst is a three-year enterprise AI transformation program for ACME Highland Health, a national health insurer with approximately 4 million members. The program delivers production AI capabilities across three business requirement documents (BRDs), supported by two cross-cutting workstreams, under a governance-first strategy that embeds responsible AI practices from Day 1 rather than retrofitting compliance post-deployment.

2.1 Strategic Drivers

Two converging forces make this program necessary and time-bound:

• Regulatory mandate (CMS-0057-F): The CMS prior-authorization interoperability mandate takes effect January 2027. ACME's baseline compliance project (separate from this program) handles minimum regulatory requirements. Project Catalyst authorizes the larger, durable capability: production AI at scale, governed against NIST AI RMF and ISO/IEC 42001, with defensible risk controls that survive regulatory scrutiny.
• Competitive pressure: UnitedHealth, Humana, and Oscar Health are already running production AI across claims, prior authorization, and member engagement. ACME's competitive position erodes with every quarter of delayed AI deployment. Moving fast without governance is risky; moving slowly while competitors deploy is unviable. This program proves the two are not in tension when governance is built in from the start.

2.2 Program Scope Summary

2.3 Objectives & Success Criteria

1. Governance: Zero Critical or High security findings from first production release onward. No model reaches production without clean Independent Model Validation sign-off.
2. Model Quality: Every production model passes accuracy, fairness, explainability, and security validation. Override/escalation protocols documented and tested for every model type.
3. Schedule: All three BRDs delivered to production by August 2029 within the phase-gate structure. Schedule changes formalized through change control; no unauthorized acceleration or compression of validation gates.
4. Budget: Deliver within the $99M authorization. Contingency reserve ($9.0M) used only through formal Executive Steering Board approval with documented root cause.
5. Benefits Realization: Measurable operational outcomes (PA cycle time reduction, call-center handle-time reduction, underwriting consistency improvement) benchmarked at Phase 0 and tracked against actuals through Year 3 closeout.
6. Sustainability: AI Governance & CoE, Independent Model Validation, and data privacy functions transitioned to permanent ACME operations at program closeout — governance does not end when consulting ends.

2.4 Key Milestones

3. Management Approach & Delivery Methodology

Project Catalyst uses a hybrid delivery methodology that combines phase-gated governance (waterfall structure for program-level oversight, phase gates, and regulatory sign-offs) with agile execution within each BRD delivery workstream (sprint-based development, continuous integration, iterative model training). This is not a concession; it is deliberate: regulated healthcare AI requires documented phase gates for audit and compliance, while the AI/ML development work itself requires the iterative feedback loops that only agile execution provides.

3.1 Program-Level Governance (Phase-Gated)

• Five formal phase gates per BRD cycle (Phase 0 through Phase 4), each requiring concurrent sign-off from all three governance boards
• Phase-gate packages prepared by Program Director, tabled 7 business days before gate date
• No phase advancement without documented sign-off; gate rejection requires remediation plan with re-gate date
• Charter, RAIDD Log, and Change Control Log updated at every gate

3.2 BRD-Level Execution (Agile/Sprint-Based)

• Each BRD delivery team operates in 2-week sprints with its own Scrum Master, Product Manager, and backlog
• Sprint ceremonies: Daily standup (15 min), Sprint Planning (Day 1, 90 min), Backlog Refinement (mid-sprint, 60 min), Sprint Review/Demo (last day, 45 min), Sprint Retrospective (last day, 45 min)
• Cross-BRD coordination via Scrum-of-Scrums (2×/week, 15 min: Program Director + Scrum Masters + Platform Lead)
• Sprint velocity tracked per team; burndown charts maintained and reported in monthly status reports
• Definition of Ready and Definition of Done established per BRD at Phase 1 and maintained through program lifecycle

3.3 Integration Points Between Governance and Agile

The hybrid model's critical integration points are where sprint-level work must pause for governance review:

• Model Validation Gate: No trained model advances from sprint-level development to production without independent validation. The sprint team delivers a model to the validation queue; the validation team (P. Okafor) operates on its own cadence (typically 5–10 business days per model review). Sprint planning accounts for this handoff.
• Phase-Gate Freeze: During the 7 business days before a phase gate, no new sprint work is started that would change the gate package. Teams use this period for documentation, test completion, and defect remediation.
• JAD-to-Sprint Handoff: Requirements locked at JAD sign-off become the Product Backlog seed. The Product Manager decomposes JAD requirements into Epics and Features; team decomposes Features into Stories during Sprint 0.

4. Phase Structure & Gate Process

4.1 Phase Definitions

4.2 Phase-Gate Sign-Off Procedure

This procedure is mandatory and invariant across all phase gates:

1. T minus 7 business days — Package Submission: Program Director submits the phase-gate package to all three board chairs. Package contents: executive summary (2 pages), deliverable completion matrix (with evidence), risk assessment update (RAIDD Log delta since last gate), resource plan for next phase, budget forecast vs. actual, quality metrics summary. Package is uploaded to the project portal and notification sent to all board members.
2. T minus 5 to T minus 1 — Board Review: Each board reviews the package independently. Board chairs submit written questions or concerns to Program Director no later than T minus 2. Program Director responds in writing before the gate meeting; responses are appended to the gate package for the record.
3. Gate Day — Gate Meeting: 2-hour meeting with all three boards present (minimum quorum: chair + 1 additional member from each board). Program Director presents the package (30 min), followed by Q&A (45 min), followed by board deliberation (30 min). Each board votes independently: Approve, Approve with Conditions, or Reject.
4. T plus 1 — Sign-Off Record: PMO Lead documents the gate decision in the Phase-Gate Record: deliverables accepted (enumerated list), risks re-assessed (updated RAIDD Log entries), next-phase budget approved (amount), next-phase team leads confirmed (names). Record is archived in the project portal as an immutable document. Distribution to all 25 team leads within 24 hours.

5. Scope Management Plan

Scope is defined through the five-workstream structure in Section 2.2 and controlled through the WBS (to be published in the Multi-Year WBS Console). The scope baseline is the set of deliverables committed at Charter sign-off, refined through JAD sessions (Phase 0/1), and locked at the Phase 1 gate for each BRD.

5.1 Scope Definition

• Program-level scope is defined in the Program Charter Sections 4–6 (vision, objectives, five workstreams).
• BRD-level scope is developed through JAD sessions (see AI Governance & JAD Charter) and locked at requirements sign-off.
• Each BRD requirements document is decomposed into a WBS by the BRD Lead and Product Manager during Sprint 0.

5.2 Scope Validation

• Each phase gate requires formal business and technical sign-off on deliverables completed in that phase.
• Deliverable acceptance criteria are defined in the phase-gate package (Section 4.2) and verified against the requirements traceability matrix before gate submission.
• UAT sign-off is the final scope validation step before production release — it confirms that what was built matches what was specified.

5.3 Scope Control

• Scope changes are logged as change requests and processed through the change control process (Section 21).
• Any request that adds, removes, or materially alters a deliverable defined in a signed BRD requirements document is classified as a scope change, regardless of estimated effort or cost.
• Scope changes >5% of BRD value-at-risk require Executive Steering Board approval. Scope changes affecting model governance or validation criteria require AI Governance Board approval.
• Shadow AI prevention (RAIDD R-10): Any AI initiative identified outside the program's governance perimeter is evaluated by the AI CoE within 10 business days; disposition is fold-in, defer, or reject (see Section 15.4).

6. Requirements Management Plan

Requirements are distinct from scope: scope defines what the program delivers; requirements define the specific functional, non-functional, and regulatory conditions those deliverables must satisfy.

6.1 Requirements Gathering

• Requirements are gathered through structured JAD sessions with 8 mandatory attendees (see JAD Charter Section 02). Each session is 2–3 hours, facilitated by the Program Director.
• Requirements are captured in the BRD requirements document using a standard template: requirement ID, description, business justification, priority (MoSCoW: Must/Should/Could/Won't this phase), acceptance criteria, regulatory traceability (if applicable).
• For AI model requirements specifically, each requirement must include: model type (classification/regression/generative), expected input/output, performance threshold (accuracy, latency), fairness criteria, human-override protocol, and explainability standard.

6.2 Requirements Prioritization

• MoSCoW prioritization is applied during JAD consolidation workshops. "Must have" requirements are non-negotiable for the current phase; "Should have" are expected but can be deferred with documented justification; "Could have" are included if capacity allows; "Won't have this phase" are explicitly deferred.
• Regulatory requirements (CMS-0057-F compliance, NIST AI RMF alignment, state AI-in-insurance mandates) are always classified as "Must have" regardless of effort estimate.

6.3 Requirements Traceability

• A Requirements Traceability Matrix (RTM) links each requirement to: its JAD session origin, its WBS element(s), its design artifact, its test case(s), and its UAT scenario. The RTM is maintained by the BRD Lead and reviewed at each phase gate.
• No requirement may be marked "complete" without at least one linked test case that has passed. This is verified automatically through the testing tool integration; manual overrides require QA Lead approval with documented justification.

6.4 Requirements Change After Baseline

• Requirements are baselined at JAD sign-off (Phase 1 gate). Changes after baseline are treated as scope changes and processed through formal change control (Section 21).
• Emergency requirements changes (e.g., regulatory mandate shift, critical defect requiring re-specification) follow an expedited 48-hour review by the relevant board, with retrospective documentation in the Change Control Log.

7. Schedule Management Plan

The schedule baseline spans 36.5 months from Kickoff (17 Aug 2026) to Closeout (29 Aug 2029), organized into the five-phase structure defined in Section 4.1, with Year 2 and Year 3 phases following the same gate rhythm.

7.1 Schedule Development

• Program-level schedule is maintained in the Program Plan Console (to be published as the Multi-Year WBS Console) by the Senior Scheduler (M. Torres).
• Phase-gated milestones use finish-to-start dependencies: Phase 1 cannot begin until Phase 0 gate is passed; Platform Foundation must be live before BRD-01 model build accelerates (dependency DEP-03 in RAIDD Log).
• BRD-level schedule is maintained in 2-week sprint increments by each BRD's Scrum Master, with sprint velocity tracked and reported.

7.2 Schedule Contingency

• A schedule contingency buffer of 5% is held at the program level — approximately 9 weeks across the 36.5-month program, allocated to absorb minor slippage without requiring Executive Steering Board escalation.
• If cumulative schedule slippage exceeds 2 weeks on any single BRD, Program Director escalates to the relevant board with a recovery plan within 5 business days.
• Critical path activities are identified and monitored weekly. Any critical-path activity that falls behind plan by >3 business days triggers an immediate working-group session (Program Director + affected BRD Lead + PMO Lead).

7.3 Schedule Performance Monitoring

• Schedule variance (SV) and Schedule Performance Index (SPI) are calculated monthly against the schedule baseline.
• SPI threshold: Green (SPI ≥ 0.95), Yellow (SPI 0.85–0.94), Red (SPI < 0.85).
• Yellow status triggers a recovery plan from the BRD Lead within 5 business days. Red status triggers Executive Steering Board escalation with options analysis (compress, descope, extend, add resources).
• Sprint velocity is tracked per BRD team and reported in monthly status reports. Velocity trend is used to forecast completion dates; if forecast completion date exceeds the phase-gate target by >2 weeks, the BRD Lead must submit a schedule change request.

8. Cost Management Plan

8.1 Budget Baseline

8.2 SOW Fee Schedule

8.3 Cost Tracking & Variance Management

• Monthly tracking: Program Finance (A. Rodriguez) tracks actual spend against budget by cost category on a monthly basis. Variance report delivered to Program Director by the 10th business day of each month.
• Variance thresholds: Cumulative variance >5% in any cost category triggers an investigation report from Program Finance. Monthly variance >10% in any category triggers Executive Steering Board escalation with root-cause analysis and corrective action plan.
• Earned Value: Cost Performance Index (CPI) and Cost Variance (CV) calculated monthly (see Section 22). CPI threshold: Green (CPI ≥ 0.95), Yellow (CPI 0.85–0.94), Red (CPI < 0.85).
• Forecast accuracy: Estimate at Completion (EAC) recalculated quarterly using the formula EAC = BAC / CPI. If EAC exceeds the $99M authorization by >$1M, the Program Director prepares an options analysis for the Executive Steering Board: descope, extend timeline, draw contingency, or request additional funding.

8.4 Contingency Reserve Management

The $9.0M contingency reserve (approximately 10% of total budget) is governed by the following rules:

• Contingency is not discretionary overhead. It exists to absorb identified risks that materialize — not to fund scope growth, nice-to-haves, or unplanned initiatives.
• Any drawdown up to $500K requires Program Director + CFO joint approval, documented in the Change Control Log.
• Any drawdown $500K–$1M requires Executive Steering Board approval.
• Any drawdown >$1M requires Executive Sponsor direct approval with formal presentation of root cause, alternatives considered, and payback timeline.
• If the contingency reserve drops below $2.0M remaining, the Program Director issues a formal risk escalation to the CFO and Executive Sponsor, regardless of whether the drawdowns were individually approved.
• Anticipated contingency uses (from RAIDD Log): data remediation (R-01, up to $1.2M pre-approved via CN-001), compute cost overrun (R-02, FinOps controls in place), and staffing increases for adoption resistance (R-07).

9. Quality Management Plan

9.1 Quality Philosophy

Quality on this program has two distinct dimensions: software quality (does the system work as designed?) and model quality (does the AI model produce accurate, fair, explainable, and safe outputs?). Both dimensions require different testing approaches, different competencies, and different sign-off authorities. This plan addresses both.

9.2 Software Quality Standards

• Unit Testing: Minimum 80% code coverage for all production code. Automated, run on every commit via CI/CD pipeline.
• Integration Testing: End-to-end testing across system boundaries (claims system ↔ AI model ↔ notification engine). Automated where feasible; manual for complex multi-system flows.
• Performance Testing: Load and stress testing against production-equivalent volumes. Latency threshold: P95 response time ≤ 2 seconds for synchronous API calls; ≤ 30 seconds for batch PA decisions.
• Security Testing: OWASP Top 10 scan, penetration testing, and adversarial-input testing (specific to AI models). Conducted by Cybersecurity team (M. Hassan) independently of delivery teams.
• DR/BCP Testing: Disaster recovery test executed once per phase (minimum), with documented recovery time against RTO/RPO targets.

9.3 AI Model Quality Standards

1. Accuracy Testing: Model performance evaluated against a ground-truth benchmark dataset. Accuracy threshold set per model type during Phase 1 (e.g., PA decision accuracy ≥ 92% on benchmark; member chatbot factual accuracy ≥ 97% on policy questions).
2. Fairness / Disparate-Impact Testing: Model outputs tested for disparate impact across demographic groups (age, gender, geography, plan type). Threshold: no demographic group's approval/denial rate deviates >5% from the population mean without documented clinical justification.
3. Explainability Review: Model outputs must be interpretable — for every PA decision, the system must produce a human-readable explanation of the factors that drove the decision. Black-box models without explainability are rejected.
4. Security Testing (Model-Specific): Adversarial input testing (prompt injection, data poisoning, model inversion), data exfiltration resistance, and output sanitization. Conducted by Cybersecurity team in coordination with Model Validation.
5. Regulatory Compliance Check: Override/escalation protocols verified (mandatory human review for adverse PA determinations), audit logging confirmed (every model decision traceable), and regulatory anchors validated (CMS-0057-F alignment for BRD-01, NAIC model bulletin alignment for BRD-03).

9.4 Quality Metrics & KPIs

9.5 User Acceptance Testing (UAT)

• UAT is owned by a dedicated Operational Testing Manager (Y. Sorensen6), who reports independently — not through the delivery team chain. This independence prevents delivery pressure from compressing UAT timelines or lowering acceptance thresholds.
• UAT participants (11 people) are loaned from operational business units: Claims, Customer Service, Underwriting, and Provider Relations. They test the system as end users, not as QA engineers.
• UAT criteria are defined by business SMEs during Phase 1 and validated against the requirements traceability matrix. UAT sign-off is required before production rollout — this is a blocking gate.
• UAT cycle is 4–6 weeks per BRD. Defects found during UAT are classified by severity (Critical/High/Medium/Low). UAT sign-off requires zero open Critical or High defects.

10. Resource Management Plan

10.1 Staffing Summary

Total program roster: 262 people across 25 functional teams. Not concurrent headcount; staffing ramps by phase. Peak Year 1: approximately 120 active. Complete named roster with role, location, allocation, rate, and cost in Resource Plan and Organization Chart.

10.2 Staffing Ramp & Phase Allocation

• Phase 0 (Months 1–3): ~80 people active — PMO, governance teams, platform leads, JAD participants. Delivery teams not yet fully mobilized.
• Phase 1–2 (Months 4–10): ~120 people active — full BRD-01 delivery team, platform team, QA ramp-up. Offshore ramp begins.
• Phase 3–4 (Months 11–14): ~120 people — peak delivery. UAT team activated. Post-production, BRD-01 delivery team begins transition to sustain mode.
• Year 2 (Months 15–29): ~180 people at peak — BRD-02 and BRD-03 teams fully mobilized while BRD-01 sustain team continues. Largest concurrent headcount.
• Year 3 (Months 30–37): ~100 people — optimization, sustain, knowledge transfer, closeout. Pulaski consultants begin roll-off. ACME FTEs transition to permanent operations.

10.3 Team Lead Assignments & Reporting

All 25 team leads are named in the Resource Plan with their organizational affiliation (ACME FTE or Pulaski consultant). Reporting structure:

• Solid-line authority: Executive Board → Program Director (C. Tyrrell). This is the real contractual authority chain.
• Dotted-line coordination: Program Director → all 25 team leads. Christian coordinates; he does not directly manage. Each team lead has a solid-line boss in their home organization (ACME department head or Pulaski engagement manager).
• ACME FTE non-billable leads (14): Their time is "borrowed" from their home departments. Their allocation percentages (typically 15%–40% for executives, 80%–100% for dedicated staff) reflect the realistic share of their time committed to this program.
• Pulaski consultant leads (11): Fully billable to the SOW. Roll off at program closeout or when their deliverable is complete.

10.4 Onboarding & Offboarding

• Onboarding: All team members complete mandatory compliance & data-handling briefing before accessing program systems. Offshore personnel complete additional data-residency briefing. Onboarding packets issued by PMO; completion tracked.
• Offboarding: Knowledge transfer checklist required for any team lead departure. Successor identified and briefed before departure. Access revoked within 24 hours of last day. If a team lead departs mid-phase, a replacement must be named within 10 business days — this is a resource change requiring formal notification to the relevant board.
• Resource change thresholds: Changes >5 FTEs or >2 team lead replacements require formal change control (Section 21).

11. Communications Management Plan

Full communications matrix is maintained in the Communications Plan. This section summarizes the management approach.

11.1 Communication Cadence

11.2 Escalation Communications (Mandatory, Time-Bound)

11.3 Stakeholder Information Needs

• Executive Sponsors: Need program health at a glance (dashboard), budget status, risk escalations, and board-level talking points. Do not need sprint-level detail.
• Team Leads: Need phase-gate readiness, cross-team dependency status, resource changes, and RAIDD Log updates. Need sprint-level detail for their own team.
• External Regulators (when briefed): Need governance framework summary, model validation methodology, audit trail demonstrations, and compliance posture. Do not receive budget, staffing, or vendor details.
• ACME Board of Directors: Need strategic progress summary, risk exposure, competitive positioning impact, and financial status. Briefed through Audit Committee liaison (A. Thompson).

12. Risk Management Plan

The RAIDD Log is the system of record for all risks, assumptions, issues, dependencies, and decisions. This section defines the management process.

12.1 Risk Identification

• Initial risk identification occurs at Phase 0 (pre-program kickoff). The program starts with 10 identified risks (R-01 through R-10), each with named owner, probability/impact score, and mitigation strategy.
• New risks may be identified at any time by any team member. The risk is submitted to the Risk & Issues Coordinator (V. Patel), who logs it in the RAIDD Log within 24 hours and assigns a preliminary score and owner.
• Quarterly Risk & Assumption Review (all 3 boards) is the formal mechanism for comprehensive risk re-assessment — but risks that emerge between quarterly reviews are logged immediately, not held.

12.2 Risk Assessment

Risks are assessed on a 1–9 scale (Probability × Impact), each dimension rated Low (1), Medium (2), or High (3):

Score interpretation: 1–3 Low (monitor) · 4–6 Medium (active mitigation) · 7–9 High (escalate to board within 48 hours).

12.3 Risk Response Strategies

• Avoid: Eliminate the risk by changing the plan (e.g., switch vendor, adjust scope). Requires change control.
• Mitigate: Reduce probability or impact (e.g., dual-source qualification for R-01, FinOps guardrails for R-02). Most common response on this program.
• Transfer: Shift impact to a third party (e.g., vendor contractual liability clauses for R-05). Requires Legal review.
• Accept: Acknowledge and monitor. Used for low-score risks or risks where mitigation cost exceeds impact. Requires documented justification.

12.4 Risk Monitoring & Escalation

• Risk owners update their assigned risks weekly in the RAIDD Log. Stale entries (>2 weeks without update) are flagged by the PMO and escalated to Program Director.
• If a risk's probability or impact changes materially (moves to a different quadrant in the assessment matrix), the owner notifies the Program Director and the relevant board within 48 hours.
• A risk that materializes becomes an Issue (logged in the RAIDD Issue section with owner, target resolution date, and status).

12.5 AI-Specific Risk Categories

Beyond standard program risks, this program carries risk categories unique to enterprise AI deployment:

• Model accuracy degradation: Production model performance drifts over time as data distribution shifts. Monitored via automated model-performance dashboards; retraining trigger thresholds defined per model during Phase 1.
• Hallucination/factual error: Generative AI models produce incorrect or harmful outputs. Precedent: Moffatt v. Air Canada. Mitigated by mandatory human-in-the-loop for adverse determinations and real-time output monitoring.
• Bias/fairness violation: Model outputs exhibit disparate impact across protected classes. Mitigated by mandatory pre-production fairness testing (Section 9.3) and ongoing production monitoring.
• Adversarial attack: Hostile actors manipulate model inputs to produce desired (incorrect) outputs. Mitigated by adversarial testing during validation (Section 9.3) and runtime input sanitization.
• Shadow AI: Departments deploy AI outside the program's governance perimeter. Mitigated by quarterly architecture reviews and CoE authority to fold in or defer non-compliant initiatives (RAIDD R-10).

13. Procurement & Vendor Management Plan

13.1 Vendor Landscape

Project Catalyst relies on three categories of external vendors:

• Hyperscaler Cloud Provider(s): AWS, GCP, and/or Azure for compute, storage, and managed AI/ML services. Multi-cloud strategy adopted (Change Control CN-003) to reduce single-vendor lock-in.
• LLM / AI Model Provider(s): OpenAI, Anthropic, or comparable provider for foundation model access (inference and fine-tuning). BAA required; data residency requirements apply.
• SaaS Tooling Vendors: Governance, compliance monitoring, test automation, and MLOps tooling. Evaluated during Phase 0; contracts executed with standard SLAs.

13.2 Vendor Governance

• Vendor Manager (L. Park, Pulaski): Owns day-to-day vendor relationships, SLA tracking, and escalation. Reports vendor performance monthly to Program Director.
• Vendor Performance Reviews: Monthly for hyperscaler and LLM providers; quarterly for SaaS tooling. Reviews cover: uptime vs. SLA, support ticket resolution time, cost vs. forecast, and contract compliance.
• BAA Requirements: All vendors handling PHI must execute a Business Associate Agreement before accessing any program data. BAA status tracked by Legal (S. Patel, Vendor Contract Specialist).
• Vendor Contingency: For single-source vendors (LLM providers), a documented contingency plan exists identifying alternative providers and the estimated switching cost/timeline. Updated annually or when the vendor landscape changes materially.

13.3 Procurement Thresholds

14. Stakeholder Engagement Plan

14.1 Stakeholder Identification & Classification

14.2 Stakeholder-Specific Risks

• Frontline adoption resistance (RAIDD R-07): Operational staff may resist AI tools due to job-displacement concerns, trust issues, or workflow disruption. Mitigated by phased opt-in rollout, change management investment, and internal comms framing AI as augmentation (not replacement).
• Executive sponsor turnover (RAIDD R-09): If M. Kavanagh departs mid-program, replacement sponsor may not prioritize AI investment. Mitigated by documented governance charter and phase-gate authority (governance survives individual sponsor changes).
• Regulatory relationship: Proactive engagement with state regulators and CMS is preferred over reactive responses. Quarterly briefings (R. Thorne) are designed to build trust and demonstrate governance maturity before any regulatory inquiry.

15. AI Governance & Model Risk Management Plan

This section defines the AI-specific governance and model risk management framework that sits on top of — and is enforced through — the standard program governance structure. It is the single most important differentiator between this program and a conventional IT project: every decision about model design, training data, validation methodology, and production release is governed here.

15.1 Two-Line-of-Defense Model Risk Structure

• First Line — AI Governance & CoE (S. Khurana, 12 people): Embedded in delivery. Sets enterprise AI standards (NIST AI RMF, ISO/IEC 42001 alignment), reviews model design at JAD sessions, defines fairness and explainability requirements per model type, manages model documentation (model cards, data lineage, training methodology), and operates the shadow-AI prevention process. The CoE is a working team, not a rubber-stamp committee.
• Second Line — Independent Model Validation (P. Okafor, 6 people): Deliberately separate from delivery teams. Reports to the AI Governance Board, not to BRD leads. Tests every model against accuracy, fairness, explainability, security, and regulatory compliance criteria before production release. Has formal blocking authority: a model rejected by validation does not go to production regardless of schedule pressure.

15.2 Model Lifecycle Governance

Every AI model on this program follows a governed lifecycle with defined checkpoints:

1. Concept & Design (Phase 1): Model concept reviewed at JAD sessions. CoE reviews model type selection, training data assumptions, fairness criteria, and human-override protocol design. Output: approved model design document.
2. Development & Training (Phase 2): Model developed by BRD delivery team using approved design. CoE conducts interim reviews of training data quality, feature engineering decisions, and preliminary accuracy metrics. Output: trained model ready for validation.
3. Independent Validation (Phase 3): Model submitted to Independent Model Validation. Validation runs the five-criteria assessment defined in Section 9.3. Output: validation report with findings classified as Critical/High/Medium/Low. Critical or uncorrected High findings = model rejected.
4. Pilot Deployment (Phase 3): Validated model deployed to controlled pilot environment with limited user group. Pilot duration: minimum 4 weeks. Monitored for accuracy drift, fairness drift, and operational workflow integration. Output: pilot results report.
5. Production Release (Phase 4): Model deployed to full production with ongoing monitoring. Retraining triggers defined (accuracy drift >X%, fairness deviation >Y%, data distribution shift >Z%). Output: production model with monitoring dashboard.
6. Ongoing Monitoring & Retraining (Year 2–3): Production models monitored continuously. If retraining trigger is hit, model re-enters the validation cycle at step 3 — no production model is updated without re-validation. CoE reviews retraining cadence quarterly.

15.3 Responsible AI Standards

• Transparency: Every model decision must be explainable in human-readable terms. For PA decisions: the system must produce a plain-language explanation of the factors that drove the approval or denial. For underwriting: the system must identify the top 5 risk factors and their relative weight.
• Human-in-the-Loop: Mandatory human review for all adverse PA determinations (BRD-01). Mandatory human review for underwriting decisions that fall within defined edge-case bands (BRD-03). Human escalation path for member chatbot (BRD-02) when confidence score falls below threshold.
• Audit Trail: Every model decision is logged with: timestamp, input data hash, model version, output decision, confidence score, and (for PA decisions) whether human review was triggered. Logs retained per ACME's data retention policy (minimum 7 years for healthcare records).
• Regulatory Anchors: CMS-0057-F (prior-auth interoperability, Jan 2027), NIST AI RMF 1.0, ISO/IEC 42001, NAIC Model AI Bulletin, state AI-in-insurance statutes. CoE maintains a regulatory tracker updated quarterly.

15.4 Shadow AI Prevention

• The AI CoE conducts a quarterly architecture review to identify AI or ML initiatives operating outside the program's governance perimeter (RAIDD R-10).
• Identified initiatives are evaluated within 10 business days. Disposition options: fold into program governance (with resource and scope adjustment), defer to post-program, or reject (with documentation of why).
• Persistent non-compliance after notification is escalated to the Executive Sponsor. The CoE has authority to recommend that non-compliant projects be suspended until governance alignment is achieved.

16. Data Governance & Privacy Management Plan

16.1 Data Classification & Handling

• PHI (Protected Health Information): Claims data, member health records, PA decisions, clinical notes. Handled exclusively in onshore US environments. Offshore resources do not access PHI — this is a design constraint, not an operational workaround (RAIDD R-08).
• PII (Personally Identifiable Information): Member name, address, DOB, contact information. Encrypted at rest and in transit. Access restricted by role-based access control (RBAC).
• Model Training Data: De-identified and anonymized per HIPAA Safe Harbor or Expert Determination method before use in model training. Data Privacy Office (E. Sato) reviews de-identification methodology before any dataset is approved for model training.
• Model Output Data: PA decisions, member interactions, underwriting scores. Subject to the same retention and audit requirements as the input data that drove them.

16.2 Data Residency Architecture

• All PHI-containing data resides exclusively in US-based cloud regions. No PHI is stored, processed, or accessible in non-US jurisdictions.
• Offshore development teams work with synthetic/anonymized datasets for model training and testing. Real PHI is never exposed to offshore environments.
• Data residency architecture is reviewed and approved by the Enterprise Architecture Board (D. Chen) and Chief Privacy Officer (E. Sato) at Phase 0 and re-validated at each annual review.

16.3 Privacy Impact Assessment

• A Privacy Impact Assessment (PIA) is conducted for each BRD before model development begins. The PIA evaluates: data elements used, consent basis, de-identification adequacy, access controls, retention period, and breach notification obligations.
• PIA is owned by the Data Privacy Office, reviewed by Legal, and approved by the AI Governance Board.
• Material changes to data handling (new data elements, new use cases, new vendor access) trigger a PIA update.

17. Regulatory Compliance Management Plan

17.1 Regulatory Landscape

17.2 Compliance Monitoring & Reporting

• Compliance Officer (J. Martinez) maintains a regulatory tracker updated quarterly. Each regulation is mapped to: applicable BRD(s), compliance status (compliant/gap identified/remediation in progress), compliance evidence, and next review date.
• Regulatory developments that could impact the program (new mandates, enforcement actions against peer companies, CMS guidance changes) are flagged to the AI Governance Board within 10 business days of identification.
• Annual compliance audit conducted by Internal Audit (K. Williams) with findings reported to Executive Steering Board.

18. Governance Structure & Decision Rights

Full governance structure is defined in the Program Governance Model. This section summarizes the decision-rights framework as it applies to day-to-day program execution.

18.1 Decision Authority Matrix

19. Meeting Cadence & Reporting Framework

The meeting cadence is designed to provide sufficient oversight without consuming delivery capacity. Every meeting has a defined owner, duration, and expected output. Meetings that consistently run without actionable output are candidates for frequency reduction at the next quarterly governance review.

19.1 Standing Meetings

20. Escalation Framework

20.1 Standard Escalation Path

Escalation is expected and healthy — it means the governance structure is functioning. The following path applies to any issue that cannot be resolved at its originating level:

1. Level 1 — Team Level (0–24 hours): Team Lead or Scrum Master attempts resolution within the team. If resolved, log resolution in RAIDD Issues section.
2. Level 2 — Program Director (24–48 hours): If unresolved at team level, escalated to Program Director. Director convenes a working group (affected team leads, relevant board lead, functional manager). Most issues resolve here.
3. Level 3 — Board Level (48 hours–5 business days): If the working group cannot resolve, escalated to the relevant board: AI Governance Board (model-risk issues), EARB (technical issues), Executive Steering Board (scope/budget/schedule issues). Board provides direction within 5 business days.
4. Level 4 — Executive Sponsor (5+ business days): If board deadlocks or the issue exceeds board authority (e.g., requires >$1M contingency drawdown, regulatory escalation, program viability question), escalated to Executive Sponsor (M. Kavanagh). Sponsor makes final decision or escalates to CFO/CIO.

20.2 Emergency Escalation (Bypasses Standard Path)

21. Change Management & Configuration Control

21.1 What Requires Formal Change Control

• Scope change: any addition, removal, or material alteration of a BRD deliverable or cross-cutting capability
• Schedule change: >2 weeks on any BRD phase or program milestone
• Budget change: >$500K in any cost category
• Resource change: >5 FTEs or >2 team lead replacements
• Model governance change: alteration to validation criteria, fairness thresholds, or human-override protocols
• Risk materialization: any anticipated risk (R-01 through R-10) that materializes, requiring mitigation plan adjustment

21.2 Change Control Process

1. Submission: Change request submitted to Program Director using the standard form (in Change Control Log). Requestor documents: what is changing, why, impact on scope/schedule/budget/quality, alternatives considered, and recommended action.
2. Impact Assessment (5 business days): Program Director assesses impact across all dimensions. Consults with affected team leads, Program Finance, and relevant board chairs as needed.
3. Routing: Based on impact assessment, the change request is routed to the appropriate approval authority: Program Director (Tier 1, within standing authority), relevant Board (Tier 2, exceeds standing authority), or Executive Sponsor (Tier 3, exceeds Board authority).
4. Review & Decision (within 2 weeks of submission): Approver reviews impact assessment and makes decision: Approve, Approve with Conditions, Defer, or Reject. Decision documented.
5. Implementation: Approved changes are entered into the Change Control Log with effective date, baseline adjustment (if applicable), and owner accountability. All affected artifacts (WBS, RAIDD Log, Resource Plan, Budget) updated within 5 business days of approval.

21.3 Configuration Management

• All program artifacts (plans, requirements documents, model documentation, test reports, governance records) are maintained in the project portal with version control.
• Baseline documents (Charter, PMP, BRD requirements, SOWs) are stored as immutable versions. Updates create new versions; prior versions are retained for audit trail.
• Model artifacts (trained models, training datasets, validation reports) follow a separate configuration management process defined by the AI CoE, with version tagging that links every production model to its training data, validation report, and approval record.

22. Performance Measurement & Earned Value

22.1 Performance Metrics

22.2 Program Dashboard

The Program Dashboard (separate artifact, updated weekly) provides a visual summary of all performance metrics. Dashboard sections: Overall Program Health (RAG), Schedule Health (SPI + milestone tracker), Budget Health (CPI + spend vs. forecast), Risk Health (active risk count by quadrant), Quality Health (defect trends + validation status), Staffing Health (actual vs. planned headcount). Dashboard reviewed at every Program Status Sync and presented to Executive Steering Board bi-weekly.

23. Benefits Realization Management

23.1 Benefits Framework

Benefits are tracked against baselines established during Phase 0 (AI Readiness Assessment). The Cost-Benefit Analysis defines the expected benefit drivers; this section defines how realization is measured.

23.2 Benefits Tracking Cadence

• Phase 0: Baseline measurement. Current-state metrics captured for all benefit categories.
• Phase 4 (post-production): Initial measurement. Compare actual production metrics against baseline.
• Quarterly (Year 2–3): Benefits realization update included in quarterly risk review and monthly status reports.
• Program Closeout: Final benefits-realization audit comparing actuals against CBA projections. Results documented in Closeout Report and presented to Executive Steering Board.

24. Knowledge Transfer & Transition Planning

24.1 Transition Scope

At program closeout (August 2029), the following capabilities transition from Pulaski Advisory Group consulting delivery to permanent ACME Highland Health operations:

• AI Governance & CoE: Enterprise AI standards, model governance processes, shadow-AI prevention, regulatory tracking. Transferred to a permanent ACME AI Governance function.
• Independent Model Validation: Validation methodology, testing protocols, and tooling. Transferred to ACME's internal audit or risk management function.
• Platform Operations: Data & Cloud AI Platform Foundation, MLOps pipelines, FinOps controls. Transferred to ACME IT Operations (H. Nakamura).
• Model Monitoring & Retraining: Production model monitoring dashboards, retraining triggers and processes. Transferred to ACME data science function (to be established).

24.2 Knowledge Transfer Process

• Knowledge transfer begins 6 months before program closeout (February 2029) with a formal KT plan approved by the Executive Steering Board.
• Each transferring capability has a named Pulaski transferor and a named ACME receiver. KT progress tracked weekly by PMO.
• KT completion criteria: ACME receiver can operate the capability independently for 4 consecutive weeks without Pulaski support. Verified by the Program Director and signed off by the relevant board.
• Runbooks, process documentation, and operational playbooks are delivered as KT artifacts and archived in the ACME knowledge management system.

25. Assumptions, Constraints & Dependencies

25.1 Assumptions

• ACME member volume and PA case mix remain stable: approximately 4 million members, 800,000 annual PA cases. Material volume changes (>10%) would require re-baselining model training data and capacity planning.
• State regulatory environment remains stable within current risk envelope. New AI-in-insurance mandates or CMS guidance changes are absorbed through CoE standards updates, not model redesigns (unless mandated).
• Cloud/LLM vendor ecosystem remains viable and accessible through program duration. No major platform discontinuations, pricing shocks, or access restrictions that would require platform migration.
• ACME executive commitment to the program (budget, staffing, governance participation) remains through all three years. Budget re-authorization for Years 2 and 3 proceeds as planned at the respective Phase 4 gates.
• Offshore labor market conditions remain stable for the duration. Offshore billing rates escalate per contractual terms (typically 3–5% annually) without requiring renegotiation.

25.2 Constraints

• Budget ceiling: $99M total authorization. No mechanism for additional funding without ACME Board-level approval.
• PHI data residency: All PHI must remain onshore US. This constraint limits offshore team scope to non-PHI platform work, synthetic-data model training, and general engineering tasks.
• Regulatory timeline: CMS-0057-F mandate effective January 2027. While baseline compliance is a separate project, Project Catalyst's BRD-01 must demonstrate governance maturity by that date.
• Model validation independence: The Independent Model Validation team cannot be combined with or report to BRD delivery teams. This is a structural constraint, not a preference.

25.3 External Dependencies

• DEP-01: CMS-0057-F mandate (external regulatory driver). Dependency: ACME's separate baseline compliance project must deliver independently.
• DEP-02: AI Governance & CoE Charter completion (Phase 0) is prerequisite for BRD-01 JAD sessions (Phase 1).
• DEP-03: Data & Cloud Platform Foundation must go live before BRD-01 model build accelerates (Phase 2).
• DEP-04: Hyperscaler vendor infrastructure provisioning must meet Phase 0 timelines.
• DEP-05: LLM provider API access and terms must remain stable through Year 1 (BRD-01 model development).

26. Baselines Summary

27. Process Improvement & Lessons Learned

• Sprint retrospectives (bi-weekly, per BRD team) are the primary mechanism for continuous process improvement at the team level. Action items from retrospectives are tracked by the Scrum Master and reviewed at the next retrospective.
• Program-level lessons learned are captured at each phase gate by the PMO Lead. Lessons are classified as: process improvement (change how we work), governance improvement (change how decisions are made), or technical improvement (change how we build).
• A consolidated Lessons Learned Register (separate artifact) is published at program closeout and presented to the Executive Steering Board. Key lessons are incorporated into ACME's organizational process assets for future programs.
• The Program Director conducts a mid-program retrospective (end of Year 1) to assess whether the hybrid delivery methodology, governance structure, and communication cadence are working as designed — and adjusts if not.

28. Document Control & Approvals

28.1 Document Control

28.2 Approval Signatures

29. Appendices & Cross-References

• Appendix A: Program Charter — authorizing document
• Appendix B: Program Governance Model — decision rights and board composition
• Appendix C: RAIDD Log — risk, assumption, issue, dependency, and decision register
• Appendix D: Resource Plan — complete 262-person named roster
• Appendix E: Organization Chart — full reporting structure
• Appendix F: RACI Matrix — responsibility assignments
• Appendix G: Change Control Log — formal change record
• Appendix H: Communications Plan — full communication matrix
• Appendix I: AI Governance & JAD Session Charter — CoE mandate and JAD structure
• Appendix J: Cost-Benefit Analysis — benefits framework and NPV analysis
• Appendix K: Total Cost of Ownership — 10-year cost comparison
• Appendix L: SOW-01, SOW-02, SOW-03 — contractual scope and fee schedules