Make-or-Buy Analysis

Procurement technique · See it on the map

Runnable here

Comparing doing work yourself against buying it from an outside vendor before deciding.

When to use it

Any time a capability gap shows up on the project and there is a real choice between building it internally and contracting it out — a new deliverable, a specialised skill nobody on the team has, a piece of equipment needed for one phase. Do it before you talk to a single vendor, not after, so the comparison isn't anchored by whatever quote arrived first.

When to avoid it

Skip it when there genuinely is no internal option — you have no one who could do the work even given time and budget, so there is nothing to compare against. Also skip a full write-up for trivial purchases (a software license, a rented van): the analysis costs more than the decision is worth. Running it for a $400 rental is wasted effort, and skipping it for a decision to build in-house capability that will outlast this one project is the same mistake in the other direction.

Steps

1. Write down the capability gap in one sentence: what has to get done, and by when.
2. Price the build option fully: not just wages, but training time, tools or equipment you would have to acquire, and the ongoing cost of maintaining the capability after this project ends.
3. Price the buy option fully: not just the vendor's quote, but the cost of writing the contract, managing the vendor day to day, and the risk of the vendor failing or leaving mid-project.
4. Ask what happens to the capability when the contract or the project ends — a bought capability disappears with the vendor; a built one stays with you, for better or worse.
5. Ask whether this is a capability you should be able to do yourself as a matter of strategy, independent of which option is cheaper this time.
6. Decide, and write the reason down alongside the number — the number without the reason is unreadable in six months.

What it produces

• A short written comparison with a decision and its reasoning
• A decision on whether to proceed to a purchase at all

Common pitfalls

• Comparing only the sticker prices — the vendor's quote against the loaded cost of an employee's day rate — while ignoring vendor management overhead and the strategic cost of never building the capability yourself.
• Treating the analysis as a formality that follows a decision already made, rather than something that could actually change the answer.
• Running a full multi-page analysis for a purchase too small to justify the time it takes to write.
• Never revisiting the decision — a make-or-buy call made once at kickoff can go stale by the time the work is actually needed.

Worked example

A small architecture firm needs a project scheduling tool integrated with its billing system. Buying an off-the-shelf integration from a vendor quotes at $3,000, versus an estimated $4,500 in staff time to build it in-house. Price alone says buy. But the firm's billing system is custom and central to every project it runs, and the vendor's fee is a one-time integration only — every future billing system change will need the vendor's paid involvement again, indefinitely. The firm decides to build it in-house at the higher upfront cost, because the alternative is years of recurring vendor dependency on a system core to the business.

Source

• PMBOK-6 §12.1.2

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.