1. Purpose & Governance Principles

This document defines who has authority to decide, and how exceptions get resolved, on the MedConnect Mobile program — distinct from the Team Charter, which describes how the teams work day to day. It's deliberately lighter than a PMBOK-style governance model, sized to a two-team, 18-week program rather than a multi-year enterprise platform build. That said, "lighter" does not mean "informal": every decision right below is written down precisely because a telehealth mobile app carries the same PHI-handling, patient-safety, and regulatory exposure as a much larger program, even though the delivery team is small. A two-team, four-sprint release cadence does not buy this program a pass on governance rigor — it just means the rigor has to be proportionate rather than bureaucratic, so it doesn't slow down a team that's shipping every two weeks.

Four principles govern how authority is distributed across this program, each with a specific mechanism that enforces it rather than just stating an intention:

2. Governance Structure

See the Organizational Chart for the full reporting structure. In summary: Executive Sponsor (M. Delacroix, VP Digital Health) → Agile Delivery Lead (C. Tyrrell) → two Scrum teams, with matrixed advisory lines to Clinical (Dr. L. Nguyen, CMIO) and Compliance (T. Brannigan, Compliance & Security Director).

Team Falcon (mobile app: iOS, Android, push notifications) and Team Anchor (platform/integration: video SDK, scheduling API, legacy data migration) each have a Scrum Master and Engineering Lead who own day-to-day delivery decisions inside their team's committed sprint scope. Neither team reports through the other — cross-team dependencies are coordinated through Scrum-of-Scrums (Section 5), not through a hierarchical chain, which keeps the two-team structure genuinely peer-to-peer rather than one team subordinate to the other. The Product Owner is the single point where both teams' priorities are reconciled into one backlog, and the single point of contact the Sponsor, Clinical, and Compliance advisors go through rather than reaching into either team directly.

3. Decision Rights

Full activity-by-activity assignment is in the Agile RACI. Summary tiers:

The tiering exists to keep the Product Owner from becoming a bottleneck on decisions that are genuinely theirs to make (Tier 1), while making sure nothing that touches money, timeline, or patient safety gets decided without the right person in the room (Tiers 2-3). In practice, the overwhelming majority of day-to-day decisions on this program — which story goes in which sprint, how a backlog item gets split, which team picks up a cross-cutting bug — never leave Tier 1. Tier 2 and Tier 3 decisions are rare enough that each one is individually traceable: all three Change Requests to date (CR-01, CR-02, CR-03) are Tier 2, and the PHI/clinical-workflow veto described in Section 9 has not yet been formally invoked as of this writing, though the mechanism exists and is tested via the Definition of Done on every PHI-touching story.

4. Escalation Process

Team Scrum Master attempts resolution within the team → raised at Scrum-of-Scrums for cross-team blockers → Product Owner escalates to Sponsor/Clinical/Compliance as needed → Sponsor decision if scope, budget, or timeline is affected. Full detail in the Agile Team Charter.

A representative example: when Team Anchor's Sprint 7 data-quality spot-check (root of CR-02) surfaced more remediation work than the original migration pipeline could absorb, the Anchor Scrum Master first tried to resolve it inside the team's existing sprint capacity. When that proved insufficient without risking the Sprint 8 cutover date, it escalated to Scrum-of-Scrums (since it had downstream implications for Falcon's dependent work), then to the Product Owner, who raised it to the Sponsor as a formal Change Request rather than quietly absorbing the risk. That's the escalation path working as designed — the issue moved exactly as far up the chain as its actual impact required, no further and no less.

5. Meeting Cadence & Reporting

Each forum has a distinct governance function, not just a distinct frequency. Standup surfaces blockers before they cost a full day; Scrum-of-Scrums exists specifically because Falcon and Anchor's work is interdependent (the mobile app can't complete a video-visit story until Anchor's SDK integration is ready, for example) and a twice-weekly cadence catches slippage early enough to still adjust within the sprint. Sprint Review is where Clinical and Compliance actually see working software, not a slide deck — which is deliberate, since a PHI-adjacent feature demoed live surfaces workflow concerns a written status report would miss. The Steering Committee is the only forum where the Sponsor, Clinical, and Compliance are all in the same room reviewing program health together, which is also why it's the forum where Tier 2/3 decisions (Section 3) most often get their final sign-off, even if the underlying escalation happened earlier via the process in Section 4.

6. Change Control Governance

All formal changes to the budget or schedule baseline are evaluated and logged on the Change Control Log. Backlog reprioritization within approved scope does not require this process — see Change Handling in Agile for exactly where that line sits.

Ten Change Requests have gone through this process across the program's life, spanning cost additions (a dedicated load-test environment, a penetration-testing engagement, temporary offshore QA capacity), schedule adjustments (extending the pre-cutover compliance review window, staggering the Android release), and scope changes (adding SMS/push notifications, deferring Family Caregiver Proxy Access to the post-cutover backlog). What ties all ten together is that each one represents something a Scrum team discovered mid-sprint that the original backlog and budget didn't anticipate — the point of this process isn't to prevent change, it's to make sure each change is priced, scheduled, and approved by the right authority tier before it's treated as committed scope, rather than absorbed silently into a sprint and discovered later as a variance.

7. Vendor Governance

Two vendors, two governance models: PulseConnect (active, ongoing SLA management, technical POC A. Singh) and Vantix Health Systems (outgoing, checklist-driven offboarding, compliance-owned deletion certification). Any vendor contract change with cost impact requires Sponsor approval — see CR-01 on the Change Control Log for a worked example. Full detail in the Vendor Management Plan.

PulseConnect (the video-visit SDK vendor) is governed as an active technical dependency: its SLA, uptime commitments, and integration support are tracked against a live scorecard, and A. Singh (Anchor's Engineering Lead) is the day-to-day technical point of contact, escalating to the Product Owner only for anything with contractual or cost implications. Vantix Health Systems (the outgoing CareLink Classic vendor) is governed entirely differently, since the relationship is winding down rather than ongoing — offboarding is a checklist-driven process co-owned by Compliance (for data-deletion certification, given the PHI involved in the legacy platform) and the Product Owner (for the technical decommission timeline), with no SLA management needed since there's no forward-looking service relationship to maintain.

8. Release Gates

Rather than PMBOK-style phase gates, this program uses two release gates, each requiring a formal Go/No-Go decision at Sprint Review:

Two gates rather than the five-plus stage-gates a waterfall program might use is a deliberate, risk-proportionate choice: Release 1 is the first point real patients touch the new app, and Release 2 is the point the legacy CareLink Classic platform — and the PHI it holds — gets decommissioned for good. Both are irreversible-enough events (once patients are on the new booking flow, or once the legacy platform is switched off, there's no quiet rollback) that they warrant a formal Sponsor Go/No-Go rather than being absorbed into a routine Sprint Review. Every other release-quality decision inside a sprint stays at the team level, consistent with the "governance scales with risk" principle in Section 1.

9. Compliance & Clinical Oversight

This is the one place in the governance model where Agile's usual bias toward team self-organization deliberately does not apply. A Scrum team can decide for itself how to split a story, which developer picks it up, or whether to carry a partially-done item to the next sprint — but it cannot decide, on its own authority, that a PHI-touching feature is "done enough" to ship. The mechanism that makes this real rather than aspirational is the Definition of Done itself: every story tagged as PHI-adjacent or clinical-workflow-adjacent has an explicit DoD line item requiring Compliance (and, where relevant, Clinical) sign-off before the story can move to Done on the board — not just before release, but before the individual story is considered complete. That means a PHI-touching story can sit in a "pending compliance review" state at the end of a sprint without counting against the team's velocity in a way that misrepresents actual completion, which keeps the incentive structure honest: there's no schedule pressure that can make a team's velocity numbers look better by skipping this review.

10. Performance Monitoring

Program health is monitored via the Velocity Chart, Release Burnup, and reported monthly through the Steering Committee Deck. Key thresholds: predictability (delivered/committed) at or above 90%; zero open P1/P2 defects at any release gate; budget variance managed within the approved Contingency Reserve.

These three thresholds were chosen because each one catches a different failure mode a healthcare-adjacent mobile program is prone to. Predictability below 90% is usually the earliest signal that a team is over-committing against real capacity — which matters more here than on a typical consumer app, since a missed sprint commitment on a PHI-touching story can cascade into a missed Compliance review window, not just a slipped release date. The zero-open-P1/P2 threshold at a release gate exists because "we'll fix it in the next sprint" is an acceptable answer for a cosmetic bug and not an acceptable answer for a defect in a patient-facing clinical workflow. And budget variance tracking against the Contingency Reserve is what turns Change Requests from an ad hoc conversation into a governed process — every approved CR draws down a known, bounded reserve rather than an open-ended request to the Sponsor, which is exactly what the reserve is sized for.

11. Approval

This governance model is approved for use across the MedConnect Mobile program.