How the program manages the platform vendor and supporting suppliers across a fifteen-month delivery. Owned by W. Donnelly, Vendor / Procurement Manager, with technical authority held by the Solution Architect and commercial authority retained by Procurement.
Bi-weekly
Vendor governance cadence
4
Escalation tiers
6
Performance measures
R-003
Top vendor risk
Warranty
Bounded support scope
The structural reality of this engagement. The organization is replacing a platform because its vendor announced end-of-support, and the replacement is delivered by a vendor. The program's central commercial exposure is therefore dependency: the business case has no genuine "do nothing" option, the go-live date is fixed by the open-enrollment calendar, and the vendor knows both. Vendor management on this program is not adversarial, but it is deliberately unsentimental — clarity of scope, evidence of progress, and contractual recourse are what protect a program that cannot walk away.
01 Purpose & Scope
This plan governs identification, contracting, oversight and performance management of third parties delivering into the program, and the transition of vendor responsibilities into steady-state support at closeout.
In scope
- The platform vendor delivering the core system upgrade and associated configuration support.
- Supporting suppliers engaged for specialist capability, including the external firm performing SOX assessment (decision D-004).
- Offshore delivery capacity engaged under the dual-shore QA model (decision D-003).
- Vendor deliverables, dependencies, service levels, and the warranty period following Go-Live.
Out of scope
- Enterprise supplier relationships not engaged on this program.
- Ongoing run-state support arrangements beyond the vendor warranty period — these transfer to IT Operations at closeout.
- Downstream system owners, who are internal stakeholders rather than vendors.
02 Vendor Landscape & Roles
| Party | Provides | Criticality | Program contact |
|---|---|---|---|
| Platform vendor | Core system version upgrade, configuration support, technical guidance, warranty support — governed by SOW-001 ($1,850,000) | Critical — single source | W. Donnelly (commercial) · J. Albert (technical) |
| Integration middleware vendor | Middleware licensing and implementation support for the six downstream integrations ($620,000) | Important — competitively selected | W. Donnelly · M. Castillo (technical) |
| External SOX assessment firm | Independent assessment of controls over financial reporting (D-004) | Important — independence required | G. Fenwick |
| Offshore QA capacity | Manual test execution under the dual-shore model (D-003) | Important — capacity | P. Sundaram |
| Infrastructure & hosting | Environments supporting build, test and production | Important | M. Alvarez |
Internal accountabilities
| Role | Accountability |
|---|---|
| W. Donnelly — Vendor / Procurement Manager | Owns this plan, the SOW, commercial performance, and all contractual correspondence |
| C. Tyrrell — Program Manager | Accountable for vendor delivery within program schedule and budget; owns Tier 3 escalation |
| J. Albert — Solution Architect | Technical authority: accepts or rejects vendor technical approach and deliverables |
| M. Alvarez — System Upgrade Lead | Day-to-day working interface with vendor delivery staff |
| G. Fenwick — Internal Audit / SOX | Independence of the external assessment firm; no program influence over its findings |
| Executive Sponsor | Tier 4 escalation; any decision affecting the commercial relationship |
Separation of commercial and technical authority is deliberate. The Solution Architect can reject a technical approach without that becoming a commercial dispute, and Procurement can enforce a contractual term without adjudicating a technical argument. Collapsing both into the Program Manager — the common shortcut — means every technical disagreement escalates as a contract issue and every contract issue gets argued on technical merit.
03 Contractual Structure
| Instrument | Purpose | Owner |
|---|---|---|
| Master agreement | Governing terms: liability, confidentiality, data protection, IP, termination | Legal / Procurement |
| Statement of Work | Program-specific scope, deliverables, acceptance criteria, milestones and payment schedule | W. Donnelly |
| Business Associate Agreement | HIPAA obligations where the vendor may access protected health information | Legal / Compliance |
| Change orders | Any scope change to vendor-delivered work, priced and approved before work begins | W. Donnelly via change control |
SOW content requirements
The SOW is written against the baselined Business Requirements Document so that vendor scope and business need cannot drift apart. It must specify:
- Deliverables with acceptance criteria — written so that acceptance is a determination, not a negotiation.
- Milestone-linked payment, with payment following acceptance rather than submission.
- Named key personnel and notice requirements before substitution.
- Dependency obligations in both directions, with response-time commitments on vendor-side dependencies.
- Warranty period with defined defect-remediation obligations following Go-Live.
- Data protection and PHI handling terms consistent with the BAA.
- Exit and transition assistance obligations — negotiated at signature, when leverage exists.
The SOW is on the critical path, and that is a known risk. Risk R-003 records that vendor SOW finalization delay could push back environment provisioning and the overall start of build activity. The mitigation is sequencing: the requirements baseline is held at 3 November 2026 regardless of SOW status, so that negotiation works against a fixed specification rather than a moving one. A SOW negotiated against unstable requirements takes longer and binds less.
04 Governance & Cadence
| Forum | Participants | Purpose | Frequency |
|---|---|---|---|
| Vendor delivery working session | M. Alvarez, vendor delivery lead, J. Albert as needed | Day-to-day progress, blockers, technical questions | Weekly |
| Vendor governance review | W. Donnelly, C. Tyrrell, J. Albert, vendor engagement manager | Deliverable status, dependencies, performance scorecard, commercial matters | Bi-weekly |
| Deliverable acceptance review | J. Albert, relevant workstream lead, W. Donnelly | Formal acceptance or rejection against SOW criteria | Per deliverable |
| Executive vendor review | Sponsor, C. Tyrrell, vendor senior leadership | Relationship health, systemic issues, escalated matters | Quarterly, or on escalation |
| Warranty review | M. Alvarez, IT Operations, vendor support | Defect trends and remediation during warranty | Weekly during warranty |
05 Deliverable & Dependency Management
Acceptance discipline
| Step | Requirement |
|---|---|
| Submission | Vendor submits against a defined SOW deliverable with stated acceptance criteria |
| Review window | Fixed review period; the clock is documented so neither party disputes elapsed time |
| Determination | Accepted, or rejected with specific reference to the criterion not met — never rejected on general dissatisfaction |
| Rework | Rework cycle defined; repeated rejection on the same criterion escalates to Tier 3 |
| Payment | Milestone payment released on acceptance, not on submission |
Dependencies run both ways
Most vendor disputes on programs of this shape originate in client-side dependency failure — environments not ready, decisions not made, data not provided — which then becomes an argument about vendor delay. A dependency register tracks both directions, with owner and due date, and is reviewed at every governance session.
| Direction | Typical dependency | Consequence of failure |
|---|---|---|
| Vendor → program | Upgrade release, configuration guidance, defect fixes, technical documentation | Build and test activity stalls |
| Program → vendor | Environment provisioning, requirements decisions, test data, SME availability | Vendor delay claim; schedule and cost exposure to the program |
An early lesson already recorded. Issue I-002 — the initial vendor-provided test environment lacked production-representative data volume, delaying early integration testing — is exactly the class of dependency failure this register exists to surface. It was a vendor-side dependency that met the letter of the obligation (an environment was provided) without meeting its purpose (an environment that could support meaningful testing). Dependency definitions now state fitness, not just delivery.
06 Performance Measurement
Vendor performance is scored on a small number of measures that matter, reviewed at each bi-weekly governance session and trended quarterly.
| Measure | Target | Why it is measured |
|---|---|---|
| Deliverable on-time submission | ≥ 95% | Leading indicator of schedule risk |
| First-pass acceptance rate | ≥ 90% | Quality of what is submitted; repeated rework consumes program capacity, not just vendor capacity |
| Dependency response within agreed time | ≥ 95% | Whether the vendor is unblocking the program or blocking it |
| Defect resolution within severity SLA | 100% critical / high | Warranty and hypercare performance |
| Key personnel continuity | No unnotified substitution | Continuity of understanding on a complex conversion |
| Change order accuracy | No unpriced scope performed | Prevents scope drift becoming a retrospective invoice |
Service level tiers for defect resolution
| Severity | Definition | Response | Resolution target |
|---|---|---|---|
| Critical | Production unavailable, data loss or corruption, incorrect claims payment | Immediate | Continuous effort until resolved |
| High | Core business function unusable with no workaround | Same business day | Defined business-day target |
| Medium | Function impaired with acceptable workaround | 2 business days | Next scheduled release |
| Low | Cosmetic or minor | 5 business days | Backlog |
07 Issue Escalation
| Tier | Trigger | Program side | Vendor side | Timeframe |
|---|---|---|---|---|
| Tier 1 | Working-level blocker or technical question | M. Alvarez | Vendor delivery lead | Same day |
| Tier 2 | Deliverable rejected twice, or dependency missed | W. Donnelly + J. Albert | Vendor engagement manager | 3 business days |
| Tier 3 | Schedule, scope or cost impact to the program | C. Tyrrell | Vendor account executive | 5 business days |
| Tier 4 | Go-Live at risk, or material breach | Executive Sponsor | Vendor senior leadership | Immediate |
Escalation is a normal governance mechanism, not a hostile act. Issues are escalated on defined triggers rather than on frustration, and every escalation is documented with the evidence supporting it — which is what makes the mechanism credible when it is genuinely needed.
08 Vendor Risk & Contingency
| Risk | Exposure | Mitigation | Contingency if realized |
|---|---|---|---|
| R-003 — SOW finalization delay | Environment provisioning and build start pushed; every downstream window compresses against a fixed Go-Live | Requirements baseline held at 3 Nov 2026; parallel drafting of SOW schedules | Re-sequence build; descope "Should" requirements before compressing test |
| Single-source dependency | No practical alternative supplier within the schedule; limited commercial leverage | Milestone-linked payment; acceptance discipline; exit assistance negotiated at signature | Executive escalation; contractual remedy |
| A-003 — upgrade approach requires database platform change | Assumption failure would materially change scope, cost and schedule | Assumption tested explicitly during technical validation, not left standing | Formal change order; Steering re-baseline decision |
| Key personnel substitution | Loss of accumulated understanding of a complex conversion | Named key personnel with notice requirement in the SOW | Require equivalent-or-better replacement plus handover period |
| Vendor warranty scope dispute | Post-Go-Live defects argued as new work | Warranty scope defined precisely at SOW stage, before goodwill is tested | Escalation with defect evidence; commercial remedy |
| Offshore capacity variability (R-002) | Test throughput drops (see I-003) | Throughput tracked as a measure; environment access treated as a program dependency | Rebalance onshore/offshore mix |
09 Warranty & Transition to Steady State
Go-Live is not the end of the vendor relationship; it is the start of the period in which the program discovers what it actually bought.
| Stage | Vendor obligation | Program action |
|---|---|---|
| Hypercare (immediately post-cutover) | Elevated support presence; rapid defect remediation | Daily defect review; trend tracked against SLA |
| Warranty period | Remediation of defects attributable to delivered scope, at no additional charge | Weekly warranty review; defects classified by attribution |
| Knowledge transfer | Documentation, runbooks and handover to IT Operations | Verified by IT Operations acceptance, not by vendor assertion |
| Warranty exit | Open defects dispositioned; residual items transitioned | Formal exit review; unresolved items recorded before closure |
| Steady-state support | Transitions to the standard support agreement | Out of program scope; owned by IT Operations from closeout |
Attribution is settled before it is contested. The predictable warranty argument is whether a defect is a delivery defect (vendor remediates) or a change request (client pays). The classification rule is agreed at SOW stage, when neither party knows which side of it they will be on — and defects are classified as they arise, not batched for negotiation at warranty exit when the answer has become financially consequential.
10 Closeout
- All deliverables formally accepted or dispositioned, with acceptance records retained.
- Final invoice reconciliation against the milestone payment schedule; no unpriced work outstanding.
- Warranty obligations either discharged or explicitly carried forward under the support agreement.
- Vendor performance summarized and recorded to inform future supplier selection.
- Access and credentials revoked; data-handling obligations confirmed satisfied under the BAA.
- Lessons captured into the Lessons Learned Register.
Governing relationship. This plan operates under the Project Management Plan and the master agreement. Vendor scope derives from the baselined Business Requirements Document; scope changes route through the Change Control Log as priced change orders. Vendor risks are carried on the RAIDD Log, and vendor-delivered functionality is verified under the Test & Quality Strategy.