Make-or-Buy Analysis in Project Management — Complete Guide

Every project reaches a fork in the road: build it in-house, or bring someone else in to do it? Hire the developers or contract an agency? Manufacture the component or purchase it from a supplier? Get it wrong — in either direction — and you pay the price in budget overruns, delays, or a loss of control over something that matters.

Make-or-buy analysis is the structured tool that removes guesswork from that decision. Used in procurement planning, it turns a judgment call into a defensible, data-backed choice that stakeholders can trust.

In this guide you will find:

• What make-or-buy analysis is and where it fits in PMBOK 8
• When to trigger the analysis — and when not to bother
• A quantitative cost comparison method with a worked example
• Qualitative factors: core competency, control, risk, and more
• A decision matrix you can adapt to any project
• A six-step application process
• How the analysis works in agile and hybrid environments
• The most common mistakes — and how to avoid them
• A ready-to-use decision template

1. WHAT IS MAKE-OR-BUY ANALYSIS

Straight to the point

Make-or-buy analysis is a data-driven evaluation technique used to decide whether a project deliverable, component, service, or capability should be produced internally (“make”) or acquired from an external source (“buy”). It is a core tool in procurement planning and appears explicitly in PMBOK 8 as part of the Plan Sourcing Strategy process.

The analysis is not simply a cost comparison. It integrates financial data with strategic, operational, and risk considerations to produce a recommendation that is both economically sound and aligned with organizational goals.

Make means the organization uses its own resources — people, equipment, facilities, and knowledge — to produce the deliverable. Buy means the organization contracts a vendor, supplier, or service provider to deliver it.

In practice, the spectrum is wider than two options. Between “make” and “buy” sit hybrid models: partial outsourcing, staff augmentation, licensing, joint ventures, and managed services. The analysis must account for this range.

Where Make-or-Buy Fits in PMBOK 8

In PMBOK 8, make-or-buy analysis is positioned within the Procurement Management knowledge area, specifically in the Plan Sourcing Strategy process. This process answers the question: “What do we need from external sources, and how will we get it?”

The outputs of a make-or-buy analysis directly inform:

• The source selection criteria — the standards used to evaluate vendors
• The procurement management plan — the overall strategy for acquiring project resources
• The make-or-buy decisions document — a formal record of what will be made, what will be bought, and why
• The project scope — since what is bought is typically excluded from the team’s work

PMBOK 8 emphasizes that procurement decisions must be evaluated in context — not just on cost, but on value delivery, risk, and strategic alignment. Make-or-buy analysis is the primary tool for doing exactly that.

2. WHEN TO USE MAKE-OR-BUY ANALYSIS

Make-or-buy analysis is warranted whenever a significant component of project scope could realistically be either produced internally or procured externally. Not every decision requires a formal analysis — minor items with low cost and low strategic significance can be handled with a simple management call. But the analysis becomes essential in several scenarios.

Trigger conditions for a formal make-or-buy analysis:

• The component represents a significant portion of the project budget (typically >10%)
• Internal capability to deliver is uncertain or limited
• The deliverable involves specialized expertise the team does not currently possess
• The decision has long-term strategic implications (e.g., building a capability vs. remaining dependent on a supplier)
• There is significant risk attached to either option
• The component involves intellectual property or confidential data
• Regulatory requirements constrain who can perform certain work
• The organization is evaluating whether to insource a previously outsourced function

When NOT to use a formal make-or-buy analysis:

• The item is a commodity with no strategic value (standard office supplies, routine software licenses)
• Organizational policy mandates one option (some procurement rules require competitive bidding above certain thresholds)
• The cost of analysis exceeds the cost of the item itself
• Time constraints make analysis impractical and a reasonable default exists

The timing of the analysis matters. In predictive projects, make-or-buy decisions are typically made during the planning phase, before the procurement management plan is finalized. In agile and hybrid projects, the analysis may be revisited as the product backlog evolves and new needs emerge.

3. QUANTITATIVE FACTORS — COST COMPARISON AND TOTAL COST OF OWNERSHIP

The quantitative dimension of make-or-buy analysis is a structured cost comparison. The goal is not to find the cheapest option — it is to find the option with the best total value when all relevant costs are counted.

The Make Cost

The cost of making a deliverable internally includes:

• Direct labor — salaries, benefits, and overhead for team members working on the deliverable
• Equipment and facilities — any capital investment or lease costs required
• Materials and supplies — raw inputs consumed in production
• Training and learning curve — cost to bring the team to required skill level
• Management overhead — time spent by project managers and coordinators
• Opportunity cost — value of other work displaced by internal resource allocation
• Ongoing maintenance and support — post-delivery cost of sustaining the deliverable

The Buy Cost

The cost of buying from an external source includes:

• Contract price — the quoted price from the vendor
• Procurement administration — cost of RFP preparation, evaluation, contracting, and management
• Transition and onboarding — cost of transferring knowledge, data, and access to the vendor
• Quality assurance and oversight — internal cost of monitoring vendor performance
• Vendor risk premium — cost of contingency for vendor failure or delays
• Exit costs — cost of switching vendors or bringing the function back in-house later
• Dependency risk — value at risk if the vendor relationship becomes a strategic liability

Worked Example: Software Module Development

A project team must decide whether to develop a data analytics module in-house or purchase a SaaS solution. Here is the cost comparison over a 3-year horizon:

At first glance, buying is cheaper by $70,000 over three years. But the analysis does not stop here. Notice two items not yet counted:

• The internal team’s opportunity cost — if those developers could generate $150,000 in value working on core product features instead, the true cost of “make” increases significantly.
• The vendor’s data sovereignty risk — if the analytics module will process sensitive customer data, regulatory constraints may make the SaaS option untenable regardless of cost.

This is why quantitative analysis must be paired with qualitative factors before a final decision is made.

Break-Even Analysis

When the make option has a higher fixed cost but lower variable cost over time, a break-even analysis identifies the volume or time horizon at which “make” becomes cheaper than “buy.”

The break-even formula:

Break-Even Point = (Fixed Cost of Make − Fixed Cost of Buy) ÷ (Variable Cost of Buy − Variable Cost of Make)

For the example above, if the team expects to significantly expand the analytics capability in years 4–5 (increasing internal development costs minimally while vendor costs scale proportionally), the break-even timeline shifts. Organizations with long-term horizons often find that “make” becomes more economical as scale increases.

4. QUALITATIVE FACTORS — CORE COMPETENCY, CONTROL, AND RISK

Numbers tell part of the story. Qualitative factors complete it. In many make-or-buy decisions, a qualitative factor will override even a strong quantitative case.

Core Competency and Strategic Fit

The most fundamental qualitative question is: Is this deliverable part of our core competency?

Core competencies are the capabilities that differentiate the organization in its market — the things it does better than anyone else and that competitors cannot easily replicate. A general rule: make what is core, buy what is not.

A financial services firm should not outsource its risk modeling algorithms — that is its competitive advantage. But it should consider outsourcing its data center operations, cafeteria services, or payroll processing. Conversely, a restaurant chain should not try to build its own accounting software when excellent solutions are available at a fraction of the cost.

When a deliverable is central to the organization’s core competency, the “make” option preserves and strengthens that competency. Outsourcing it creates dependency and erodes differentiation over time.

Control and Visibility

“Make” gives the organization direct control over quality, timeline, and process. “Buy” transfers some of that control to a vendor, which introduces risk if the vendor’s priorities or standards differ from the project’s.

Control matters most when:

• The deliverable must integrate tightly with existing systems
• Quality standards are non-negotiable and difficult to specify contractually
• The timeline is fixed and vendor delays would be catastrophic
• Intellectual property ownership must remain with the organization
• The work involves access to sensitive, confidential, or regulated data

Risk Allocation

Make-or-buy decisions fundamentally redistribute risk. “Make” concentrates risk internally. “Buy” transfers some risk to the vendor — but only the risk that is properly specified in the contract. Poorly specified contracts can result in cost overruns, disputes, and outcomes worse than doing the work internally.

Key risk factors to evaluate:

• Delivery risk: Which option is more likely to deliver on time and to specification?
• Quality risk: Which option provides higher confidence in the final quality?
• Dependency risk: How exposed is the project to vendor failure, bankruptcy, or renegotiation?
• Knowledge risk: If the work is outsourced, does the organization retain enough knowledge to maintain or extend the deliverable later?
• Security and compliance risk: Which option better protects sensitive data and meets regulatory requirements?

Capacity and Capability

Even when “make” is strategically preferable, capacity constraints may make it impractical. If the internal team is already at full utilization, forcing them to take on additional work creates quality risk, burnout risk, and timeline risk. In this case, “buy” may be the right answer — not because it is strategically superior, but because it is operationally necessary.

Similarly, if the deliverable requires capabilities the organization does not currently possess, the “make” path requires building those capabilities first. The question becomes: is this a capability worth building? If yes, the investment is justified. If no, buying is more efficient.

5. THE DECISION MATRIX

A decision matrix converts qualitative judgments into comparable scores, making the final recommendation transparent and auditable. Here is a template you can adapt to any project.

How to Build the Matrix

1. List the relevant evaluation criteria (factors that matter for this specific decision)
2. Assign a weight to each criterion (weights should total 100%)
3. Score each option on each criterion (typically 1–5, where 5 is most favorable)
4. Calculate weighted scores (weight × score for each criterion)
5. Sum the weighted scores for each option
6. The option with the higher total weighted score is the recommendation

Sample Decision Matrix — Software Module Example

In this example, “make” narrowly wins on the weighted matrix (3.45 vs 3.40) despite having a higher 3-year cost, because the data security and quality control factors carry enough weight to tip the balance. This outcome would not be visible from a pure cost comparison.

Important note on the matrix: The matrix is a decision support tool, not a decision replacement. If the scores are close (as in this example), the project manager should present both options to the sponsor with a clear explanation of the trade-offs and let the strategic context guide the final call. A matrix score of 3.45 vs 3.40 is not a mandate — it is a signal that this is a genuinely close decision requiring human judgment.

6. HOW TO APPLY MAKE-OR-BUY ANALYSIS — STEP BY STEP

Step 1 — Define the Scope of the Decision

Clearly describe what is being evaluated. Be specific: “Should we develop the customer-facing dashboard internally or purchase a third-party BI tool?” is a decision. “Should we buy software?” is not.

Include in the scope definition:

• The specific deliverable or capability being evaluated
• The required quality standards and specifications
• The timeline within which the decision must be made
• The time horizon for the cost comparison (typically project lifetime or 3–5 years)

Step 2 — Identify All Relevant Costs

For both “make” and “buy” options, list every cost that will be incurred over the analysis horizon. Use the cost categories from Section 3 as a starting checklist. Do not omit hidden costs — learning curves, procurement overhead, transition costs, and exit costs are frequently underestimated.

Step 3 — Identify Qualitative Factors

List the qualitative factors that are relevant to this specific decision. Not every decision requires every factor. A decision about whether to hire a consultant for a two-week analysis has very different qualitative considerations from a decision about whether to build a manufacturing capability.

Assign weights to each factor based on the organization’s priorities. In a highly regulated industry, compliance and security factors may carry 40–50% of the total weight. In a fast-moving startup, speed to market may dominate.

Step 4 — Gather Data and Score Each Option

Collect cost estimates from internal stakeholders (finance, operations, HR) for the “make” option. Collect vendor quotes or market benchmarks for the “buy” option. Score each option on each qualitative criterion using a consistent scale.

Involve subject matter experts in the scoring process. The project manager should not score qualitative factors unilaterally — the team’s collective judgment produces more accurate and defensible results.

Step 5 — Perform Sensitivity Analysis

Test the robustness of the recommendation by varying key assumptions. What happens if internal labor costs increase by 20%? What if the vendor increases prices at renewal? What if the project’s scope expands? If the recommendation flips under plausible scenarios, the decision is sensitive and requires additional risk mitigation planning.

Step 6 — Document and Present the Recommendation

Produce a make-or-buy decision document that includes:

• The scope of the decision (what was evaluated)
• The cost comparison summary (both options, total cost, time horizon)
• The decision matrix (criteria, weights, scores, totals)
• Sensitivity analysis findings
• The recommendation and rationale
• Key assumptions and risks
• Required approvals

Present this document to the project sponsor, procurement lead, and any other stakeholders with decision authority. Ensure the recommendation is traceable to data — not just intuition.

7. MAKE-OR-BUY IN AGILE AND HYBRID ENVIRONMENTS

Make-or-buy analysis was developed in the context of traditional, plan-driven projects. In agile and hybrid environments, the analysis adapts — but the underlying logic remains valid.

In Agile Projects

In agile projects, procurement decisions often emerge incrementally as the product backlog evolves. The team may not know at the outset whether a particular capability will be built or bought. The Product Owner carries the primary responsibility for make-or-buy decisions, often in consultation with the project sponsor or portfolio manager.

Practical adaptations for agile:

• Just-in-time analysis: Conduct the make-or-buy analysis when a feature or capability enters the “ready” state in the backlog — close enough to implementation that the decision is informed by current context, but early enough to allow procurement lead time if “buy” is chosen.
• Build-and-evaluate: For small, low-risk items, the team may build a lightweight prototype internally before deciding whether to invest in a full “make” or “buy” a complete solution.
• Vendor evaluation in sprint cycles: Running a proof-of-concept with a potential vendor during a sprint is a legitimate agile approach to procurement decision-making.

In Hybrid Projects

Hybrid environments often involve a mix of internally built components and purchased solutions that must integrate seamlessly. The make-or-buy analysis at the portfolio level determines the overall sourcing strategy; at the project level, it governs specific components.

Key considerations in hybrid environments:

• Integration risk: When the “make” and “buy” components must work together, integration complexity is a significant cost and risk factor that must be included in the analysis.
• Governance alignment: Ensure that agile procurement decisions (quick, iterative) are compatible with the organization’s formal procurement governance (which may require approval cycles inconsistent with sprint cadence).
• Revisiting decisions: In hybrid projects, make-or-buy decisions may need to be revisited at major phase gates as the project’s scope and context evolve.

8. COMMON MISTAKES IN MAKE-OR-BUY ANALYSIS

Mistake 1 — Counting Only the Obvious Costs

The most frequent error is comparing only the headline numbers: “The vendor charges $50,000 and our team would cost $80,000 — so we buy.” This ignores procurement overhead, transition costs, ongoing management, exit costs, and opportunity costs. A proper total cost of ownership comparison often reverses the initial conclusion.

How to avoid it: Use a comprehensive cost checklist (like the one in Section 3) for every analysis. Require cost estimates to include all items, not just direct costs.

Mistake 2 — Treating the Analysis as a Finance Exercise

Make-or-buy is not just a financial model. Organizations that hand the analysis entirely to the finance team often get a decision that is financially optimal but strategically wrong — for example, outsourcing a capability that the organization should be building.

How to avoid it: Ensure the analysis team includes finance, operations, strategy, and the project manager. Qualitative factors must be scored by people with domain expertise, not estimated by financial analysts alone.

Mistake 3 — Ignoring the Exit Strategy

Organizations frequently fail to think through what happens if they want to reverse the decision later. Vendor lock-in is real: proprietary formats, contractual obligations, and lost internal capability can make it extremely costly to bring outsourced functions back in-house.

How to avoid it: Include exit cost as a line item in the buy option’s total cost. Evaluate vendor contracts for lock-in clauses (minimum terms, data portability, IP ownership). If the decision involves a core competency, plan explicitly for how the internal capability will be preserved even if external resources are used.

Mistake 4 — Making the Decision in Isolation

The project manager makes the call without adequate input from legal, IT, security, or operations — and discovers too late that the chosen option violates a policy or creates an unacceptable risk.

How to avoid it: Define a standard list of stakeholders who must be consulted for make-or-buy decisions above certain thresholds. Create a sign-off process that ensures key functions have reviewed and approved the recommendation.

Mistake 5 — Not Documenting the Rationale

The team makes a good decision but fails to document why. Six months later, when circumstances change or the project is audited, no one can explain the basis for the original choice. This creates disputes and rework.

How to avoid it: Always produce a make-or-buy decision document, even for relatively small decisions. A one-page summary with the key assumptions, cost comparison, and rationale is sufficient for most cases.

9. MAKE-OR-BUY DECISION TEMPLATE

Use this template as the starting point for any make-or-buy analysis. Adapt the criteria and weights to match your project’s specific context.

MAKE-OR-BUY DECISION DOCUMENT

Project: ___________________________
Decision Date: ___________________________
Prepared By: ___________________________
Approved By: ___________________________

1. Decision Scope
Describe the deliverable, service, or capability being evaluated:
_______________________________________________________________

2. Analysis Horizon
Time period for cost comparison: _______ years / months

3. Cost Comparison Summary

4. Qualitative Decision Matrix

5. Sensitivity Analysis Notes
_______________________________________________________________

6. Recommendation
☐ Make    ☐ Buy    ☐ Hybrid

Rationale:
_______________________________________________________________

7. Key Assumptions
_______________________________________________________________

8. Key Risks
_______________________________________________________________

9. Required Approvals
_______________________________________________________________

CONCLUSION

Make-or-buy analysis is one of the most impactful decisions in procurement planning — yet it is frequently underused, rushed, or reduced to a simple cost comparison. The organizations that do it well gain a strategic advantage: they allocate resources to what they do best, build the capabilities that matter, and avoid paying the hidden costs of poorly justified outsourcing decisions.

The three essential takeaways:

• Cost is not the whole story. Total cost of ownership, strategic fit, control, and risk must all inform the decision. A vendor who is cheaper on paper may be more expensive in reality once transition, management, and exit costs are counted.
• The decision matrix makes the reasoning visible. When quantitative and qualitative factors are combined in a structured matrix, the recommendation becomes defensible, auditable, and easier to communicate to stakeholders.
• Document every decision. Make-or-buy decisions that are made verbally and never recorded create risk — in audits, disputes, and when the project team changes. A one-page decision document is a minimum standard.

Make-or-buy analysis is a tool that pays for itself. The time invested in a rigorous analysis at the start of procurement planning will be recovered many times over in avoided rework, better vendor relationships, and more strategic use of internal talent.

This guide on make-or-buy analysis is part of the complete PMBOK 8 resource library. See all PMBOK 8 articles in the Complete Index

Call to Action:

References

Project Management Institute (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition. Newtown Square, Pennsylvania, USA: Project Management Institute, 2025.

PMBOK Guide 8: The New Era of Value-Based Project Management. Available at: https://projectmanagement.com.br/pmbok-guide-8/

Disclaimer

This article is an independent educational interpretation of the PMBOK® Guide – Eighth Edition, developed for informational purposes by ProjectManagement.com.br. It does not reproduce or redistribute proprietary PMI content. All trademarks, including PMI, PMBOK, and Project Management Institute, are the property of the Project Management Institute, Inc. For access to the complete and official content, purchase the guide from Amazon or download it for free at https://www.pmi.org/standards/pmbok if you are a PMI member.