Vendor and Third-Party Governance in Programmes

The Programme-Level Vendor Challenge

Individual projects manage their own vendor relationships. The Programme Manager's concern is different:

• Cross-vendor coordination: Multiple vendors must deliver compatible outputs that integrate
• Aggregate vendor risk: If one vendor fails, it may cascade across the programme
• Commercial governance: Ensuring contracts across vendors are consistent and enforceable
• Performance standards: Maintaining quality standards across all vendor deliverables
• Knowledge retention: Ensuring the organisation isn't locked into vendor dependency

Vendor Governance Framework

Tier 1: Strategic Vendors (Programme-Critical)

Vendors whose failure would significantly impact the programme. Typically 1-2 per programme.

Governance:

• Monthly executive relationship review (Programme Manager + Vendor Account Director)
• Weekly delivery sync (PM + Vendor Delivery Lead)
• Quarterly commercial review (Procurement + Programme Manager + Vendor)
• Formal SLA monitoring with contractual consequences
• Escalation path defined to C-level on both sides

Tier 2: Delivery Vendors (Project-Level)

Vendors delivering within specific projects. Important but not programme-critical.

Governance:

• Fortnightly delivery review (PM + Vendor Team Lead)
• Monthly performance assessment against KPIs
• Quarterly relationship review
• Standard SLA monitoring
• Escalation through Programme Manager if project-level resolution fails

Tier 3: Commodity Vendors (Transactional)

Infrastructure, tooling, or service providers with standard offerings.

Governance:

• SLA monitoring (automated where possible)
• Quarterly review only if SLAs are missed
• Standard procurement management
• Replacement planning if performance degrades

Performance Management

Key Performance Indicators

Define KPIs in the contract and measure them consistently:

• Delivery quality: Defect density, rework rate, code review pass rate
• Delivery speed: Velocity, throughput, milestone delivery rate
• Resource quality: Skill level of assigned resources, resource stability (turnover)
• Communication: Responsiveness, transparency, proactive risk reporting
• Commercial: Invoice accuracy, change request volume, dispute frequency

The Performance Scorecard

Monthly scorecard per vendor:

| KPI | Target | Actual | Trend | RAG | |---|---|---|---|---| | Defect density | <0.5/story | 0.3 | ↓ | 🟢 | | Milestone delivery | >90% | 85% | → | 🟡 | | Resource stability | >90% | 75% | ↓ | 🔴 | | Responsiveness | <4hr | 2hr | → | 🟢 |

Performance Conversations

Green performance: Acknowledge and maintain. Brief monthly check-in. Amber performance: Formal discussion. Root cause analysis. Improvement plan with timeline. Red performance: Escalation to vendor leadership. Formal improvement notice. Contingency planning activated.

Contract Management at Programme Level

Contract Alignment

Ensure contracts across vendors are compatible:

• Consistent intellectual property terms (who owns the code?)
• Compatible liability and indemnity clauses
• Aligned change control processes (so cross-vendor changes don't get stuck)
• Consistent quality standards and Definition of Done
• Compatible data handling and security requirements

Change Management Across Vendors

When a programme-level change affects multiple vendors: 1. Assess impact across all affected vendor contracts 2. Coordinate change requests to all vendors simultaneously 3. Ensure consistent pricing and timeline across vendor responses 4. Approve changes holistically (not piecemeal per vendor) 5. Update all contracts consistently

Exit Planning

For every strategic vendor, maintain an exit plan:

• What would trigger exit? (Persistent underperformance, commercial dispute, strategic change)
• What's the transition timeline? (Typically 3-6 months for strategic vendors)
• What knowledge transfer is needed? (Documentation, code handover, operational procedures)
• Who could replace them? (Alternative vendors identified and pre-qualified)
• What's the cost of exit? (Contractual termination fees, transition costs, productivity loss)

Cross-Vendor Integration

When multiple vendors must deliver components that work together:

Interface Agreements

• Define integration points between vendor deliverables (APIs, data formats, protocols)
• Document interface specifications that all vendors develop against
• Establish integration testing cadence (weekly or per-sprint)
• Assign integration ownership (usually the programme team, not any single vendor)

Integration Testing

• Shared integration environment where all vendor outputs are deployed
• Automated integration tests that validate cross-vendor compatibility
• Regular integration checkpoints (at least fortnightly)
• Clear process for resolving integration failures (who investigates? who fixes? who pays?)

The Integration Risk

Cross-vendor integration is the highest-risk area of multi-vendor programmes. Mitigate by:

• Starting integration testing early (not at the end)
• Keeping interface contracts stable (changes require cross-vendor agreement)
• Having a dedicated integration team or role
• Building rollback capability for each vendor's deployment independently

Measuring Vendor Governance Effectiveness

• Vendor performance trend: Are vendor KPIs improving, stable, or declining?
• Integration success rate: % of integration test runs passing. Target: >95%
• Dispute resolution time: Days from dispute raised to resolved. Target: <10 business days
• Contract compliance: % of contractual obligations met by vendors. Target: >95%
• Knowledge transfer progress: Can internal team maintain vendor-delivered components? (Assessed quarterly)

---

Download the [Programme RAID Register template](/templates) to track vendor-related risks and dependencies at programme level.