Program Charter — MedConnect Mobile

1. Charter Authorization & Document Purpose

This charter formally authorizes the MedConnect Mobile program and grants C. Tyrrell authority as Agile Delivery Lead to apply ACME Health resources to it. It establishes the funding envelope, the team, the cadence, the release boundaries and the governance under which the program operates.

What it deliberately does not do is specify the product. On a predictive program the charter is followed by a requirements document that fixes scope up front. This is a Scrum program: requirements live in the Product Backlog as epics and user stories, are re-prioritized every sprint, and are accepted against the shared Definition of Done. A charter that froze scope here would be authorizing a way of working the program does not use. So this document fixes the things that genuinely must be fixed — money, people, dates, quality bar, decision rights — and leaves the backlog free to move within them.

The charter records the program as authorized. Current backlog state, velocity, spend and status live in the backlog, the velocity chart, the Program Budget and the Dashboard.

2. Business Case & Strategic Context

CareLink Classic, the current telehealth platform, has an announced vendor end-of-support date 18 months out, with no mobile roadmap ever delivered and renewal pricing that rose 34% at last cycle. Patient satisfaction scores for the web-only visit experience have declined over the past two cycles, and provider feedback consistently cites the lack of a native mobile option as a barrier to adoption.

This is not a purely discretionary product investment: the vendor's end-of-support date forces a platform decision regardless of return on any specific investment level, the same way a forced infrastructure replacement would — the question this charter answers is what to replace it with, not whether to replace it. This program replaces CareLink Classic with a native mobile app (iOS/Android) and a companion provider web console, delivered by two coordinating Scrum teams over 8 sprints.

Full business case detail, including the 7-year cash flow and why this is framed as a scope-justification case rather than a traditional payback gate, is in the companion Cost-Benefit Analysis, with ongoing value tracking in the Benefits Realization Plan and lifetime cost in the TCO.

3. Program Objectives & Success Criteria

Objectives and measurable OKRs are defined in full in the Vision & Roadmap. Summary success criteria for this charter:

• Patients can complete a mobile-native video visit end-to-end — check-in, waiting room, visit summary — with zero critical defects at Release 1.
• 60% of visits booked via mobile app within 60 days of Release 1 (Sprint 5, 27 Mar 2026).
• CareLink Classic fully decommissioned by program end (15 May 2026), with zero critical data-integrity defects carried over from historical migration.
• Both Falcon (Mobile) and Anchor (Platform) sustain a consistent 2-week sprint cadence with no missed sprint commitments beyond an agreed carry-over threshold.
• Program closes within the $3,713,000 approved baseline, reconciled to the Program Budget's tracked variance.

4. Scope

In scope: patient mobile app (iOS/Android), provider web console, video visit integration (PulseConnect SDK), full patient-record migration from CareLink Classic, CareLink Classic decommission, secure messaging, and prescription refill requests.

Out of scope — candidate backlog, not committed: remote patient monitoring device integration, multi-language support, group/family visit scheduling, provider analytics dashboard.

The phrasing matters. On a Scrum program, "out of scope" does not mean rejected — it means not committed for this program's funding and horizon. These items remain visible as candidate backlog so that the decision to exclude them stays a product decision made in the open, rather than an omission nobody revisits. Moving one of them into committed scope is a Sponsor-level change under §13, not a backlog refinement.

5. High-Level Requirements

Charter-level constraints that bound every story in the backlog, regardless of priority:

• The mobile app and provider console must meet applicable HIPAA technical safeguards for PHI in transit and at rest, consistent with PulseConnect's existing Business Associate Agreement.
• Video visits must maintain clinically acceptable audio/video quality across the officially supported device and OS matrix defined in the Vision & Roadmap.
• Historical patient records migrated from CareLink Classic must be validated at the field level, with documented remediation for any data-quality issues found (see RAIDD R-01 and the Sprint 7 migration remediation surge).
• Any change touching a clinical workflow or PHI handling must receive Clinical/Compliance sign-off before being marked Done, regardless of sprint pressure.

These are constraints, not a specification. Feature-level requirements are the backlog's job; what the charter fixes is the set of conditions no story may violate to be considered complete.

6. Delivery Approach

Scrum, two coordinating teams (Falcon/Mobile, Anchor/Platform) via a lightweight Scrum-of-Scrums — not full SAFe, which this program's size doesn't warrant. Two teams over eight sprints need dependency visibility and a shared cadence; they do not need release trains, program increments or a scaling framework whose overhead would exceed the coordination problem it solves. Choosing the lighter mechanism deliberately, and being able to say why, is itself part of the delivery approach. Full detail in the Agile Team Charter and the Methodology Guide.

Both teams run a two-week sprint with a common ceremony set — planning, daily standup, review, retrospective — and a shared backlog refinement cadence, so a story means the same thing on either team.

7. Team Structure & Roles

The program is authorized a 28-person delivery organization: six in program leadership and SME roles, and two balanced eleven-person squads. Falcon owns the patient mobile experience; Anchor owns the platform, provider console and data migration. Each squad has its own Scrum Master; the Product Owner role is held once, across both, so backlog priority cannot diverge between teams. Roster detail is in the Resource Plan, reporting lines in the Org Chart, and accountabilities in the RACI.

8. Definition of Ready & Definition of Done

The program's quality bar is a pair of shared checklists rather than a downstream test phase. The Definition of Ready governs what may enter a sprint — a clear user-story statement, written and testable acceptance criteria, and a size estimate from the owning team. The Definition of Done governs what may be called complete — acceptance criteria met, code reviewed and merged, tests written and passing, no defects above the agreed severity threshold, deployed and verified in staging, documentation updated.

Both squads work from the same two checklists, which is what makes "done" mean the same thing regardless of which team delivered a story. Because there is no separate test phase in which quality could be recovered later, these checklists are the enforcement mechanism — which is why the Clinical/Compliance sign-off in §5 is written into Done rather than tracked alongside it. Traceability from vision through to release is set out in the Agile traceability view.

9. Release Plan & Milestone Schedule

Two releases, not eight. The sprint cadence is fortnightly, but the program commits to the business at two release boundaries — an MVP at Sprint 5 and full cutover at Sprint 8 — because CareLink Classic's decommission has to happen once, cleanly. The Release Schedule and Release Burnup track delivery against those boundaries.

10. Budget Authorization

This is the corrected baseline per DEC-06 (see RAIDD Log); the original pre-correction estimate was $3,653,000. Because that was a correction of an estimate rather than a change of scope, it is carried backward into this authorizing document rather than tracked as a variance against it. Full variance tracking and change-request history is in the Program Budget.

The three labor lines total $2,990,000 across the 28-person organization and reconcile to the Resource Plan's rate card — the authorized team and the authorized budget are one commitment expressed two ways.

11. Contingency & Financial Controls

A contingency reserve of $338,000 — 10% of base, drawn as needed — is authorized and held against identified risks rather than treated as discretionary funding. Its most significant use in this program was the Sprint 7 migration remediation surge, where legacy archive data quality (risk R-01) materialized and contractor support was engaged; that draw is recorded as change request CR-02 in the Program Budget.

Drawing on reserve does not change the baseline. A change that would exceed it is a Sponsor decision under §13, not a Product Owner one.

12. Governance & Decision Rights

Agile governance is thin by design, but it is not absent — and the boundary between a backlog decision and a program decision is drawn explicitly:

Decisions are recorded as DEC-## entries in the RAIDD Log, and changes are handled through the process set out in Change Handling in Agile and logged in the Change Control Log.

13. Delivery Lead Authority & Limitations

C. Tyrrell has authority to prioritize and re-prioritize the product backlog within approved scope and budget, facilitate the Scrum-of-Scrums, and represent the program to the Steering Committee.

Changes to the budget baseline, release dates, or the Release 1/Release 2 scope boundary require Sponsor approval via formal Change Request. The Product Owner also cannot waive the Definition of Done or the Clinical/Compliance sign-off in §5 — an authority to reorder work is not an authority to lower the bar it is delivered against.

14. Key Stakeholders

Cadence and reporting routes are defined in the Communications Plan; program-level oversight runs through the Steering Committee and the model in Program Governance.

15. Regulatory & Compliance Framework

• HIPAA / PHI. The app and console handle protected health information, so HIPAA technical safeguards apply to data in transit and at rest — a constraint on architecture and on how test data is handled, not only a policy statement.
• Business Associate Agreement. PulseConnect processes PHI as part of the video visit, so its existing BAA must cover this use case; that coverage is carried as an assumption in §17 precisely because the program depends on it holding.
• Clinical safety sign-off. Any change touching a clinical workflow requires Clinical/Compliance approval before Done — enforced inside the quality gate rather than as a parallel review.
• App marketplace compliance. Distribution through the App Store and Play Store imposes review and privacy-disclosure requirements, budgeted in §10.

16. High-Level Risks

• Legacy data quality (R-01). Data-quality issues in legacy archive records could complicate historical migration — this materialized in Sprint 7 and required contractor support to remediate (see Program Budget, CR-02).
• Third-party SDK dependency. PulseConnect configuration/entitlement gaps could affect the visit experience if not caught in integration testing.
• Cross-team dependencies. Falcon/Anchor dependencies could surface late without disciplined Scrum-of-Scrums tracking, given the two teams share a single cutover date.
• No schedule slack. CareLink Classic's fixed, non-negotiable end-of-support date leaves no room to absorb a major scope surprise late in the program.

Full register in the Agile RAIDD Log. The first and last of these interact: a program with no schedule slack is exactly the one that cannot absorb a materialized data-quality risk, which is why the contingency in §11 was drawn rather than the release date moved.

17. Assumptions, Constraints & Dependencies

Assumptions

• PulseConnect's existing BAA covers this telehealth use case without renegotiation.
• Both teams can sustain a consistent 2-week sprint cadence for the program's duration.

Constraints

• CareLink Classic's vendor end-of-support date is fixed and non-negotiable.
• Any clinical-workflow or PHI-touching change requires Clinical/Compliance sign-off before being marked Done.
• Release 1 and Release 2 boundaries are Sponsor-controlled; the backlog moves within them, not across them.

Dependencies

• PulseConnect SDK availability and entitlement configuration for the video visit experience.
• Vantix (legacy vendor) cooperation for data extraction and decommission — governed by the Vendor Management Plan and the legacy offboarding plan.
• Clinical/Compliance reviewer availability, since it sits inside the Definition of Done and therefore on the critical path of every affected story.

Current status for all three registers is maintained in the RAIDD Log; this charter is not amended when an entry changes.

18. Benefits Realization

Five benefits (BEN-01 through BEN-05) are defined with owners, measures and realization windows in the Benefits Realization Plan. Most realize after cutover rather than at it, so benefit ownership transfers to operational owners at closeout: the program is accountable for delivering the capability and establishing the measurement baseline, and the business for realizing the value.

An incremental delivery model changes when benefits start, not who owns them. Because Release 1 puts a working mobile visit experience in patients' hands at Sprint 5 rather than at final cutover, part of the adoption benefit begins accruing roughly six weeks before the program ends — which is why the 60% mobile-booking criterion in §3 is measured from Release 1 rather than from closeout. That is a real advantage of releasing twice instead of once, and it is worth stating explicitly because it is easy to lose: a program that reports benefits only at closeout would show nothing for a capability that had already been live for a month and a half.

The counterpart is that early release does not mean early claim. Adoption measured within days of Release 1 is a novelty signal, not a benefit; the measurement windows in the Benefits Realization Plan are set accordingly, and the program does not book value it cannot yet evidence or sustain beyond the first weeks of curiosity-driven use.

19. Document Control & Related Documents

This charter authorizes the program as described; it is superseded only by a re-issued charter approved by the Sponsor. Baseline changes are made by Change Request and recorded in the Change Control Log, not by amending this document.

• Vision & Roadmap — objectives, OKRs, device/OS matrix
• Product Backlog and traceability view — the requirements vehicle
• Definition of Ready & Done and Test & Quality Strategy
• Agile Team Charter, RACI, Org Chart, Resource Plan
• Program Budget, CBA, TCO, Benefits Realization Plan
• RAIDD Log, Program Governance, Change Handling, Communications Plan

20. Approval

This charter is approved to authorize the MedConnect Mobile program.