Enrollment & Claims Platform Modernization

1. Why This Document Exists

An org chart shows who sits where. A RACI shows who touches which deliverable. Neither answers the question a new joiner actually asks in week one: what am I accountable for, and who can tell me to do something? On this program those are different questions with different answers, and the gap between them is where most of the friction lives.

This document names every function, states what it owns, and — more usefully — states what it does not own. It also names the two bodies the program cannot instruct, because knowing where your authority stops is more operationally useful than knowing where it starts.

2. The Shape of the Organization

Fifty-five people, one accountable manager, zero reporting authority. That is not a defect in the design; it is the normal shape of enterprise IT delivery inside a payer, where engineers belong to Application Development, testers to Quality Engineering, and infrastructure staff to Technology Operations. The program borrows them.

What that costs is real and worth stating plainly. Priority conflicts are resolved by the functional manager, not by the program. When an integration developer is pulled onto a production incident, the program is informed rather than consulted. The mitigation is not authority — the program will never have it — but visibility early enough to re-sequence: named individuals in the resource register rather than headcount, and a standing conversation with each functional manager rather than an escalation after the fact.

3. Governance — Who Decides

Three tiers, and the distinction between them is the size of what is being changed rather than the seniority of who is asking.

4. The Functions, One at a Time

Business Analysis owns the requirement, not the want. F. Jones's team decides when a requirement is specified well enough to hand to a developer; the sponsor decides whether it should exist. Conflating those two is the most common failure in requirements work — an analyst who starts adjudicating whether has stopped being an analyst.

Data Conversion carries a burden the others do not: it inherits its inputs. T. McCormick's team can find and report source-data defects, and can build reconciliation to prove what moved, but it cannot fix a legacy record that was wrong when it was written in 2009. Conversion scope has to be stated as what will be reconciled, never as what will be correct.

Quality Engineering recommends; it does not decide. A. Ferreira's team gives a quality recommendation at each gate, and the Steering Committee decides whether to accept the residual risk. Separating the recommendation from the decision is what stops testing being pressured — the team is never in the position of having to approve a date it does not believe in.

Integration Development is 15 people across six tracks, and the tracks are where the real coordination cost sits. Each track owns its own technical design. What no track owns is the order in which tracks integrate, which is the Solution Architect's, because a decision that optimizes one track routinely damages another.

Organizational Change measures readiness; it does not manufacture it. L. Bergström can report that Claims Operations is not ready. If the answer to that report is to change the report, the function has been neutralized.

5. The Bodies the Program Cannot Instruct

Two, and both matter more than their headcount suggests.

Internal Audit / SOX (G. Fenwick, K. Ibrahim). They appear in the resource register under the Program Manager, and that line is administrative only. The program cannot direct a finding, soften a finding, or set the scope of control testing. When CR-012 proposed deferring SOX control testing until after go-live, the request went to the Executive Sponsor with Internal Audit's position attached, and was declined — see the Change Control Log. That is the arrangement working: the program asked, and the answer was not the program's to give.

The Steering Committee. The program serves it, briefs it, and recommends to it. It does not manage it, and cannot decide on its behalf between meetings. A program that starts making steering-level calls because the meeting is three weeks away has quietly changed its own governance without telling anyone.

6. The External Organizations

Three of the six QA testers (V. Rao, S. Banerjee, N. Fernandes) work offshore through a vendor. ⚠ They are not simply cheaper capacity. PHI-handling constraints require every offshore- executed case that touches member data to be reviewed onshore, so offshore execution consumes onshore review capacity at a fixed ratio. This is exactly why CR-011 — a request to triple offshore throughput — was declined: the constraint was review capacity, not execution hours.

The platform vendor sits outside this structure entirely. The program has a contract, not authority: vendor priorities are set by the vendor's own commercial planning, and the only levers are contractual and relational.

7. Who Decides What

8. Translating From Roles You Already Know

Titles travel badly between industries. If your background is elsewhere, these map roughly as follows — with the caveat that the mapping is about what the role decides, not what it is called.