Managing Vendor Relationships in Agile Projects

The Vendor-Agile Tension

Traditional vendor contracts assume fixed scope, fixed price, and fixed timeline. Agile assumes evolving scope, iterative delivery, and adaptive planning. These models clash when:

• The contract specifies detailed requirements upfront, but the team discovers better solutions during delivery
• Payment milestones are tied to document deliverables (design doc, test plan) rather than working software
• Change requests are expensive and slow, discouraging the adaptation that makes Agile valuable
• The vendor optimises for contract compliance rather than customer value

Contract Models for Agile Delivery

Time and Materials (T&M)

How it works: Pay for vendor resources by the hour/day. Scope is flexible.

Pros: Maximum flexibility. Easy to adapt scope as you learn. No change request overhead. Cons: No cost certainty. Risk sits entirely with the buyer. Vendor has no incentive to be efficient.

Best for: Discovery phases, R&D work, ongoing support, situations where scope genuinely can't be defined upfront.

Governance needed: Weekly capacity review, clear Definition of Done, regular output assessment, budget burn rate monitoring.

Fixed Price per Sprint/Iteration

How it works: Fixed cost per sprint (e.g. £50K/sprint for a 6-person team). Scope within each sprint is flexible. Number of sprints is agreed (with extension options).

Pros: Cost predictability per period. Scope flexibility within sprints. Aligns with Agile cadence. Cons: Vendor may under-resource to protect margin. Quality risk if vendor optimises for speed over quality.

Best for: Ongoing delivery engagements where team composition is stable and scope evolves sprint-to-sprint.

Governance needed: Sprint reviews with acceptance criteria, velocity tracking, quality metrics, team composition verification.

Capped T&M with Milestones

How it works: T&M billing with a maximum cap. Payment released at agreed milestones (working software, not documents).

Pros: Flexibility within a budget ceiling. Milestones tied to value delivery. Shared risk. Cons: Vendor may slow down as they approach the cap. Milestone definitions need careful crafting.

Best for: Projects with some scope uncertainty but a clear budget constraint. Most common Agile-friendly contract model.

Governance needed: Milestone acceptance criteria defined upfront, regular progress reviews, burn rate monitoring against cap.

Outcome-Based Contracts

How it works: Payment tied to business outcomes (e.g. "reduce checkout abandonment by 20%") rather than deliverables or time.

Pros: Perfect alignment between vendor incentives and business value. Vendor is motivated to find the best solution. Cons: Hard to define measurable outcomes. Attribution can be disputed. Requires high trust and mature vendor relationship.

Best for: Strategic partnerships with trusted vendors. Innovation projects where the "how" is uncertain but the "what" is clear.

Vendor Governance in Agile

Daily Integration

• Vendor team members attend the same standups, planning, and retrospectives as internal team members
• Treat vendor resources as part of the team, not as an external service
• Shared board, shared Definition of Done, shared Sprint Goal
• No "throw it over the wall" — vendor and internal team collaborate continuously

Weekly Commercial Review

• Review hours/cost against budget (T&M) or sprint output against expectations (fixed price)
• Assess quality: defect rate, rework rate, code review feedback
• Flag any commercial concerns early (approaching cap, resource changes, scope disputes)
• Separate commercial discussions from delivery discussions — don't let contract issues poison team dynamics

Monthly Relationship Review

• Vendor account manager + PM + sponsor
• Overall relationship health: communication, quality, responsiveness, value
• Contract performance: are we getting what we're paying for?
• Forward look: upcoming needs, resource changes, contract renewals
• Issues that need escalation to commercial/legal teams

Managing Vendor Performance

Quality Gates

Define quality expectations in the contract and measure them:

• Code review approval rate (vendor code must pass the same review standards as internal code)
• Test coverage requirements (minimum 80% for vendor-delivered code)
• Defect density thresholds (maximum bugs per story delivered)
• Definition of Done compliance (every item meets the team's DoD)

The "Right to Refuse" Clause

Include contractual right to refuse deliverables that don't meet quality standards without payment obligation. This protects you from paying for substandard work while giving the vendor clear quality expectations.

Resource Approval

For key roles (tech lead, architect, senior developers), include contractual right to approve or reject specific individuals. This prevents vendors from staffing with junior resources while charging senior rates.

Knowledge Transfer Requirements

Require vendors to document their work, participate in knowledge transfer sessions, and ensure internal team members can maintain the code after the engagement ends. Avoid vendor lock-in through deliberate knowledge sharing.

Common Vendor Anti-Patterns

The black box vendor: Vendor works in isolation and delivers "finished" work that doesn't integrate. Fix: embed vendor resources in the team. Shared board, shared ceremonies, shared code repository.

The scope dispute: Every request becomes a "that's out of scope" conversation. Fix: use a contract model that accommodates scope flexibility (capped T&M or fixed-price-per-sprint). Define scope at the epic level, not the story level.

The resource swap: Vendor quietly replaces experienced team members with junior resources. Fix: contractual resource approval rights. Track velocity — sudden drops often indicate resource changes.

The dependency trap: Vendor builds in ways that create ongoing dependency (proprietary frameworks, undocumented code, vendor-specific tooling). Fix: require open standards, documentation, and knowledge transfer as contractual obligations.

Measuring Vendor Value

• Cost per story point: Vendor cost ÷ story points delivered. Compare against internal team cost.
• Quality metrics: Defect density, rework rate, code review rejection rate for vendor-delivered code.
• Velocity contribution: Vendor team's throughput as % of total team throughput.
• Knowledge transfer progress: Can internal team members maintain vendor-delivered code independently?
• Relationship health: Quarterly satisfaction survey (both directions — vendor rates you too).

---

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