Vendor-Managed Project: When Most Work Lives Outside

A vendor project is a different shape entirely: the team you manage is not the team doing the work. Your job is contract, scope, acceptance, and integration. This case study shows the in-house thin team, the weekly cadence with the vendor, and the artifacts that prevent vendor disputes from becoming project disasters.

When does vendor-managed make sense?

Three signals.

Skill not available in-house. A specialist domain (SAP integration, embedded firmware, regulatory-specific compliance) where building the skill is more expensive than buying.

Time-bounded need. A 6-month project where hiring would take 4 months. Vendor capacity exists today.

Cost predictability matters. Fixed-price vendor contract gives the sponsor a known number. In-house comes with unpredictable scope creep.

If the work is core to your business, will be ongoing, and in-house skill is feasible, do not outsource. Vendors are for non-core, time-bounded work.

What is the cost of poor vendor management?

Three failure modes.

Vendor delivers wrong thing. Spec was vague; vendor built to their interpretation; gap discovered at acceptance. Fixing requires renegotiation and time.

Integration nightmare. Vendor delivers code, in-house has to integrate, integration takes longer than the build. In-house team unprepared.

Vendor lock-in. Vendor controls knowledge; replacing them is impossibly expensive. Project becomes a permanent vendor relationship by accident.

What does the in-house thin team look like?

flowchart TB
    InHouse[In-house Team] --> PM[PM<br/>scope, contract, status]
    InHouse --> SE[Senior Engineer<br/>tech review, integration]
    InHouse --> Buyer[Procurement<br/>contract, payment]
    Vendor[Vendor team<br/>5-15 engineers] --> VL[Vendor lead<br/>weekly sync with PM]
    Vendor --> VEng[Vendor engineers]
    PM <-.weekly sync.-> VL
    SE <-.code review.-> VEng

Two people in-house full-time, plus part-time procurement support. The PM owns the relationship; the senior engineer owns the technical bar. Together they spend ~50% of time on vendor management; the other half on integration work.

What does the contract structure look like?

Contracts are outside this series' scope, but the artifacts that wrap a contract are not:

# Vendor Project Plan — {{ Project Name }}

## Vendor
{{ Vendor name }}; primary contact: {{ name }}; SLA: {{ link }}

## Phased deliverables and payment

| Phase | Deliverable | Acceptance criteria | Payment | Due |
|-------|-------------|---------------------|---------|-----|
| 1 | Architecture document | Reviewed by senior engineer; matches existing system | $X | Week 4 |
| 2 | Auth integration | Passes our test suite; meets SLA | $Y | Week 8 |
| 3 | Core feature alpha | Demo to in-house team; performance test passes | $Z | Week 14 |
| 4 | Production-ready | Security review passes; runbook delivered; 30-day support | $W | Week 20 |

## Acceptance process per phase
1. Vendor demos
2. In-house engineer reviews against criteria (3 days)
3. Pass: payment authorized; Fail: written feedback, retry
4. After 2 fails on same phase, escalation per contract

## Out of scope (vendor will not do)
- Production deployment (in-house owns)
- 24/7 oncall (in-house owns)
- Customer support (in-house owns)
- Training in-house team (separate add-on)

Three details. Acceptance is criteria-based, not opinion. Payment is tied to acceptance phases. Out-of-scope is explicit so the vendor cannot claim "we thought you'd do that".

What does the weekly cadence with the vendor look like?

sequenceDiagram
    participant PM as In-house PM
    participant VL as Vendor Lead
    participant SE as In-house SE
    participant Sponsor as Sponsor
    PM->>VL: Monday: status template due Wednesday
    VL->>PM: Wednesday: written status (RAG, risks, blockers)
    PM->>SE: Wednesday: technical points to review
    SE->>VL: Thursday: code review feedback
    PM->>VL: Thursday: 30-min sync (questions only)
    PM->>Sponsor: Friday: rolled-up status to in-house sponsor

The weekly written status from vendor is non-negotiable. Without it, the PM is flying blind. The Thursday sync is short and structured: questions on the written status, not a status report itself.

What is the integration risk and how do you handle it?

Integration is where most vendor projects fail at acceptance. Mitigations that work:

• In-house SE pairs with vendor early. Not waiting until Phase 3 to look at code; weekly code review starts Phase 1.
• API contract written by in-house. The interface between vendor work and your systems is your responsibility; do not let the vendor define it.
• Integration tests in your CI. Vendor delivers test fixtures; your CI runs integration daily.
• Spike at week 4. Pull a tiny vendor-delivered piece into your environment; verify the integration story is real.

How does this scale to multi-vendor or large programs?

flowchart TB
    Sponsor[Sponsor] --> PMO[Program PM<br/>oversees vendors]
    PMO --> V1[Vendor A<br/>front-end build]
    PMO --> V2[Vendor B<br/>back-end build]
    PMO --> V3[Vendor C<br/>QA / pen test]
    PMO --> Internal[Internal team<br/>integration + acceptance]

A program PM coordinates multiple vendors. Each vendor has their own contract and weekly cadence; the program PM synthesises the rolled-up status. The internal team handles inter-vendor integration since no single vendor sees the whole picture.

What failure modes does vendor management introduce?

• Acceptance theatre. Sign off because deadline pressure, not because criteria met. Mitigation: written criteria reviewed by senior engineer; payment release requires their signature.
• Scope creep through vendor side. Vendor adds "helpful" features; charges for them; in-house didn't ask. Mitigation: contract caps work to written scope; out-of-scope work is a separate change request.
• Knowledge stays at vendor. Migration off vendor is impossible because docs don't exist. Mitigation: ADRs (chapter 19) and runbooks delivered as part of acceptance criteria.
• Vendor relationship goes sour. PM and vendor lead clash. Mitigation: contract escalation path defined up front; if weekly sync isn't working, escalate to executives on both sides; do not let it fester.

When is vendor-managed the wrong shape?

Two cases.

Core ongoing capability. If the work is your competitive advantage and will be ongoing forever, hire instead. The vendor relationship has overhead that hiring eventually amortises.

Highly creative / exploratory work. Hard to write acceptance criteria for "find the right product direction". Vendors deliver against specs; if you don't have a spec, you have an in-house problem.

Where should you go from here?

You have completed the case studies. Next chapter: running-a-project checklist

• the hub that links every artifact you've learned. After that, conclusion wraps the series with the lessons that survive every project shape.