How do I decide whether to make or buy something for my project?

The question of whether to build a solution in-house or acquire it from external sources surfaces in nearly every project at some point. A project team may have the raw talent to develop a custom analytics dashboard, yet the timeline might demand a ready-made software package. Budget pressures can make the external purchase look appealing even when internal capacity technically exists. The make-or-buy analysis framework is the tool that transforms these gut feelings into a structured evaluation, weighing direct and indirect costs alongside schedule constraints.

Make-or-Buy Decision: Key Factors Summary

Understanding the Make-or-Buy Analysis Framework

A make-or-buy analysis is a general management technique that determines whether particular work can best be accomplished by the project team or must be purchased from outside sources. It is not simply a procurement activity; it sits at the intersection of scope definition, resource allocation, and cost estimation. In the Project Management Body of Knowledge (PMBOK), this analysis falls under the Procurement Management knowledge area, specifically as a tool and technique of the Plan Procurement Management process within the Planning process group. The output feeds directly into the procurement management plan, shaping whether the project will contract out certain components or keep them internal. This structured approach ensures that decisions are based on a comprehensive view of what the organization can provide and what the market can deliver more efficiently.

The technique forces the project manager to look beyond immediate expense sheets. It asks whether the needed capacity, skills, and intellectual property are truly available and, if so, at what opportunity cost. The term “make” does not necessarily mean manufacturing a physical item; it covers any deliverable or work package that the internal team would produce, from a software module to a training program to a marketing video. Similarly, “buy” includes purchasing off-the-shelf products, contracting a vendor to perform a service, or licensing a cloud-based subscription. The analysis must consider all related costs, both the obvious cash outlays and the less visible support burdens.

At its core, the make-or-buy decision is about aligning project execution with organizational strategy. An IT department may have the capability to build a custom customer relationship management system, but doing so might divert developers from revenue-generating product features. Here the analysis becomes a tool for prioritizing where internal effort yields the greatest long-term value. It also introduces the notion that not every capability residing inside the company is actually available for a given project, because that capability may already be committed elsewhere. This distinction is crucial and often overlooked.

Positioning Make-or-Buy within Project Management Standards

In PRINCE2, the concept surfaces within the Plans theme and the Business Case. The project manager evaluates whether obtaining products from suppliers aligns better with the business justification than developing them internally. The PRINCE2 emphasis on continued business justification means the make-or-buy analysis is not a one-off event but something that can be revisited at stage boundaries. In Agile environments, the decision often emerges during sprint planning when a team realizes that a certain feature could be built from scratch or integrated via an API from a third-party service. While the terminology might be less formal, the core calculus remains the same: what will deliver the highest value soonest with acceptable risk and cost?

From a process integration standpoint, the make-or-buy analysis interacts with cost estimation and budget determination. The cost of internal labor needs to be compared against vendor quotes, and both must be evaluated against the project’s cost baseline. If the analysis leads to a buy decision, the procurement statement of work is drafted, and seller proposals are solicited. If a make decision prevails, the activity gets added to the project’s work breakdown structure and resource assignments are finalized. Thus, the analysis is a pivot point that reshapes the entire project plan.

Key Insights on Make-or-Buy

Strategic management technique

Make-or-buy analysis strategically evaluates whether a task is best performed by the project team or an external supplier, shaping cost structures and operational control.

Cross-functional decision tool

Rooted in the intersection of scope, resources, and cost estimation, this analysis goes beyond procurement to influence project execution and team capacity decisions.

PMBOK planning process tool

Applied within the Plan Procurement Management process, it produces outputs that steer supplier engagement strategies and the procurement management plan’s core directives.

Total cost awareness

A rigorous evaluation compares direct cash outlays with hidden support burdens, such as the long-term opportunity cost of pulling developers from revenue-critical product innovation.

Key Cost Considerations in a Make-or-Buy Decision

Cost is rarely as simple as comparing an internal developer’s hourly rate to a license fee. The make-or-buy analysis demands a full examination of direct and indirect costs in make-or-buy decisions. Direct costs for making something include the salaries of the team members assigned, materials, equipment, software tools, and any specialized testing environments that must be set up. For a buy decision, direct costs encompass the purchase price, shipping, taxes, and any upfront customization fees. These numbers are relatively easy to obtain and, consequently, many project managers stop there, assuming they have done a thorough analysis. They have not.

The real complexity emerges when indirect costs enter the picture. On the make side, these include management overhead to supervise the development, training time for staff to learn new technologies, infrastructure support such as server space and security patches, and the opportunity cost of not using those skilled people on other high-priority work. If a cross-functional team is pulled away from its core deliverables to build a peripheral component, the hidden drag on the project’s critical path can exceed the apparent savings. On the buy side, indirect costs range from the procurement department’s effort in issuing requests for proposals and evaluating bids, to legal review of contracts, to the integration engineering needed to connect the purchased item with existing systems, to ongoing vendor management and license compliance. And here’s the thing: these hidden costs have a nasty habit of appearing exactly when you’ve committed to the budget.

Take, for instance, a project that needs a reporting module. The team considers building a lightweight internal tool; the direct cost is estimated at two weeks of a developer’s time. The purchased alternative costs a monthly subscription that seems modest. But the built solution soon requires frequent updates to handle new data formats, consuming developer time each sprint for years. The purchased module, meanwhile, demands a complex single sign-on integration that requires hiring an external consultant for two months. In both scenarios, the indirect costs dwarf the initial estimate. A layered explanation helps here: the direct cost is like the sticker price of a car, while the indirect costs are the insurance, fuel, maintenance, and depreciation that you actually pay over time. The make-or-buy analysis must capture that full lifecycle.

Indirect Costs: The Hidden Budget Eaters

Several indirect cost categories routinely trip up even experienced project managers. For internal efforts, the cost of quality can be substantial: the team must build in testing, documentation, and compliance checks that a commercial vendor would have already absorbed across many customers. Additionally, there is a hidden learning curve cost. When the internal team attempts something outside its core expertise, the inefficiency of the early stages can blow the schedule. On the procurement side, transaction costs extend beyond the purchasing department. The integration effort often triggers changes in neighboring systems, requiring regression testing and user acceptance sign-offs that were never budgeted. The analysis should therefore treat indirect costs as a line item, even if they must be estimated as a percentage of the direct cost based on historical data.

One subtle point many overlook is that indirect costs may vary by project phase. During development, the make path incurs training and infrastructure costs; after deployment, maintenance becomes the dominant indirect expense. For the buy path, license renewal and vendor support agreements can escalate year over year. A project that spans multiple years needs to model these trends. Failure to do so leads to what practitioners refer to as a “cost creep” that turns a seemingly brilliant buy decision into a long-term financial drain. The lesson is that no decision should be taken without a multi-year cost projection, at least in broad strokes.

Lease vs. Purchase: The Second Decision Layer

Once a buy decision is made, the project team must decide whether to purchase the asset outright or lease it. This lease vs. purchase decision in project management is driven by several factors: the duration of the project, the asset’s useful life beyond the project, and the organization’s cash flow situation. For a short construction project, leasing heavy equipment avoids a large capital outlay and transfers maintenance responsibility to the lessor. For a long-term software implementation, purchasing perpetual licenses might be more economical than annual subscription fees if the tool will be used for five years or more. The analysis should compare the net present value of both options, factoring in tax implications and residual value.

Leasing often bundles support services that would otherwise be separate indirect costs. A leased server may come with hardware replacement and monitoring included, while purchasing the same server would require internal IT staff to manage it. On the other hand, leasing locks the project into a recurring expense that continues even if the asset is underutilized. If the project’s scope changes dramatically, a purchased asset can be repurposed or sold, whereas a lease might impose early termination penalties. The decision should therefore be documented with the same rigor as the initial make-or-buy choice, showing how the selected path best serves the project’s objectives and the organization’s financial policies.

When Internal Capability Meets Schedule Constraints

Capability and capacity are not the same thing. A project organization may have world-class database architects on staff, but if those architects are already assigned full-time to a regulatory compliance initiative that cannot be delayed, that capability is effectively unavailable. This resource contention frequently forces a schedule-driven make-or-buy decision. The project manager, looking at a timeline that cannot budge, realizes that waiting for internal resources to free up would push the project past a critical deadline or market window. In such cases, the buy option becomes a schedule risk mitigation strategy, even if the internal team could build a superior solution given enough time.

The dynamics of resource commitment are often more nuanced than a simple availability check. A functional manager may promise that a key expert will become available in three weeks, but that expert’s previous project might face last-minute overruns. The project manager must assess the reliability of that commitment and consider the cost of delay. If a two-week delay in starting the internal build results in a one-month slip at the end due to integration dependencies, the analysis shifts decisively. This is where portfolio-level thinking enters: a make-or-buy analysis should be conducted not in isolation for one project but with an understanding of the broader program’s resource pool. Tools like resource breakdown structures and capacity planning dashboards help visualize the real contention.

Schedule pressure can also distort the cost analysis. When a project is behind schedule, the temptation to “just buy it and move on” can lead to accepting a vendor’s solution without rigorous due diligence. The short-term schedule relief may introduce long-term technical debt if the purchased product does not integrate well. A balanced approach evaluates whether the schedule gain from buying outweighs the integration and support burdens that will accumulate later. Sometimes the answer is to buy a temporary solution and plan a replacement once internal capacity frees up, effectively staging a make-after-buy transition. This hybrid approach is legitimate but demands a clear roadmap to avoid the temporary fix becoming permanent.

Key Insights on Resource Driven Make or Buy

Unavailable experts are not capability

World-class expertise creates a false sense of readiness because specialists fully committed to undelayable critical work are effectively off-limits, rendering internal development unviable regardless of their skill.

Schedule pressure triggers buying

When a fixed deadline or a fleeting market window rules out waiting for internal staff to become free, the buy option becomes a deliberate tactic to neutralize schedule risk rather than a simple gap-filler.

Assess commitment reliability

Project managers must stress-test the realism of promised expert hand-offs because even minor schedule slippage in preceding tasks can quietly erode the start date and cascade into broader delays.

Use portfolio level resource visibility

A sound make-or-buy decision demands program-wide resource insight, leveraging resource breakdown structures and capacity dashboards to reveal actual contention that single-project views often conceal.

Broader Organizational Factors and Strategic Alignment

Budget constraints alone rarely dictate a clear answer. A severely restricted budget might appear to favor making because it avoids large upfront payments, but internal labor is not free, and accounting practices may treat it as a sunk cost that does not hit the project’s cost budget as visibly. This can create a distorted incentive to overburden internal teams while keeping the external spend low. Astute project managers must challenge such accounting illusions and present the true economic cost to the organization, not just the project’s ledger. The question of whether to make or buy should align with the organization’s core competencies. Building a commodity component that a hundred vendors already produce better and cheaper is a distraction, while creating proprietary intellectual property that yields competitive advantage is a strategic move worth the investment. This organizational strategy in make-or-buy analysis often overrides short-term cost comparisons.

Business Value-Oriented Project Management adds an interesting perspective here. It encourages organizations to treat employee-created tools and open-source software as formal products, which can tip the scale toward a make decision when the in-house solution aligns with long-term value goals and reduces future dependency costs. If the internal development can be positioned as a reusable asset for multiple projects, the initial investment is amortized across the program, making the make case much stronger. At the same time, BVOPM warns against overwork and perfectionism as forms of waste. A make decision that burdens the team with unsustainable overtime creates process damage, an invisible organizational harm that eventually manifests as burnout, turnover, and quality defects. Thus, even a value-oriented approach must guard against heroics disguised as savings.

Risk tolerance also shapes the strategic calculus. A make decision keeps sensitive data and intellectual property within the organization’s firewall, which might be non-negotiable for defense or healthcare projects. Conversely, a buy decision transfers certain performance risks to the vendor, but it also introduces supplier dependency. If the vendor goes out of business or changes pricing models, the project could be severely disrupted. The analysis should therefore include a risk breakdown that compares the probability and impact of key threats under each option. In highly regulated industries, the compliance burden of buying a third-party component may involve extensive auditing and certification that outweighs any efficiency advantage.

Common Pitfalls and Practical Guidance

The most pervasive error in make-or-buy analysis is ignoring the full spectrum of indirect costs. Project teams often treat the decision as a simple price comparison and move on, only to discover later that they have grossly underestimated the effort to maintain an in-house build or integrate a purchased module. One of the most common make-or-buy analysis mistakes is to assume that internal development cost equals the number of hours multiplied by a loaded labor rate, without accounting for the management overhead, rework, and lost opportunity. On the buy side, the mistake is to stop at the vendor’s quoted price and forget the procurement cycle, contract negotiations, and ongoing license management. A practical safeguard is to establish a checklist of indirect cost categories that must be estimated for every analysis, derived from the organization’s historical data.

Another frequent misstep is failing to involve the right stakeholders early. The procurement team can provide data on market prices and typical vendor terms, while legal can identify potential contractual pitfalls. The technical team can assess integration complexity. When the project manager makes the call in a vacuum, the result is often a decision that looks good on a spreadsheet but falls apart in execution. The make-or-buy analysis should therefore be a collaborative exercise, documented with input signatures, much like a risk assessment. This not only improves the quality of the decision but also creates shared ownership when the chosen path encounters inevitable bumps.

A less obvious pitfall is treating the make-or-buy decision as static. Scope changes, resource availability shifts, and market conditions evolve throughout the project. What made sense as a build decision during planning might become unviable when a key developer resigns. An iterative re‑evaluation at major milestones or phase gates ensures that the project does not march blindly down an outdated path. The BVOPM concept of business value points, which signals when ongoing effort no longer justifies continuation, can be applied here: if the cost of sustaining an internal build climbs while business value points decline, it may be time to switch to a buy approach. This dynamic monitoring prevents the sunk‑cost fallacy from locking the project into a poor choice.

When Agile and Make-or-Buy Intersect

In Agile frameworks, the make-or-buy decision often emerges during backlog refinement or sprint planning. A team might discover a user story that requires a sophisticated recommendation engine. Rather than committing to build it over multiple sprints, they could spike a trial integration with a commercial machine‑learning API. The decision is not documented in a heavy governance document but captured in the product backlog and acceptance criteria. The lightweight approach does not eliminate the need for cost consciousness, though. The Product Owner must still compare the subscription cost against the team’s velocity impact and ensure the solution aligns with the product vision. The speed of Agile can work in favor of making, since the team can deliver a minimal viable product quickly, but it can also tempt teams to build everything because they feel empowered, even when buying is clearly more sensible.

The iterative nature of Agile means that a build decision can be reversed later without excessive drama. A team that built a custom search function might replace it with a purchased add‑on in a subsequent sprint if user feedback shows the custom version is hard to maintain. This flexibility reduces the risk of a wrong early decision eating the entire project. However, it also requires disciplined technical practices: the internal solution must be loosely coupled so that swapping it out does not cause cascading rework. From a procurement perspective, long‑term contracts may conflict with Agile’s iterative re‑evaluation, so the organization may favor short‑term subscriptions or pay‑as‑you‑go models that align with sprint‑level adjustments.

Avoiding Common Make-or-Buy Pitfalls

Account for hidden cost categories

Focusing solely on loaded labor rates or vendor quotes overlooks critical hidden costs; using a checklist of indirect cost categories informed by historical data helps ensure a comprehensive analysis.

Engage stakeholders from the start

Bringing procurement and legal into the conversation early improves the quality of the decision and builds shared ownership, which prevents purely spreadsheet-driven choices from unraveling when implementation challenges emerge.

Monitor business value points

Continuously monitoring business value points enables teams to recognize when sustaining an internal build becomes too costly, so they can switch to buying at the right moment. It also helps them resist the impulse to build everything in-house merely because Agile speed allows it.

Connecting Make-or-Buy to Other Project Management Processes

The output of a make-or-buy analysis does not just affect procurement; it ripples through nearly every knowledge area. The impact of the make-or-buy decision on the project plan alters the work breakdown structure, the risk register, the schedule, and the stakeholder communication strategy. If the choice is to buy, the project must add procurement activities such as seller selection and contract administration, which consume time and require specialized skills. If the choice is to make, the project must allocate resources, develop detailed task plans, and manage internal dependencies. The cost baseline shifts accordingly: a buy decision often converts variable internal labor costs into fixed external contract costs.

Quality management is directly influenced. With a make decision, the project team sets and enforces quality standards through testing and reviews. With a buy decision, quality assurance must instead focus on vendor deliverables, acceptance criteria, and service level agreements. Communicating with an external vendor adds a layer of complexity; the communications management plan may need to include regular vendor status meetings, escalation paths, and joint issue logs. Risk management must adjust as well. A buy decision introduces vendor‑related risks such as financial instability, performance failure, and intellectual property disputes. A make decision introduces technical risks, such as the team’s lack of familiarity with the required technology. The risk register and response plans must reflect the chosen path from the start.

Documenting the Make-or-Buy Decision

A properly structured make-or-buy analysis document serves both as a decision log and an audit trail. It should capture the alternatives considered, the direct and indirect cost estimates for each, the schedule implications, the risk assessment, and the final rationale. This document becomes part of the procurement management plan or a standalone appendix. Its value extends beyond the immediate project: lessons learned about which tasks proved cheaper or riskier to make versus buy can inform future analyses. The document should be reviewed and approved by the project sponsor or a change control board if the decision implies significant financial commitment or resource shifting.

Equally important is documenting the assumptions that underpin the analysis. For example, the assumption that a key resource will be available from a certain date, or that a vendor’s price will remain stable for the contract duration, must be stated explicitly. When those assumptions later prove false, the decision can be revisited with full context. Many organizations lack this rigor and then scramble when a make decision blows the budget because the resource was pulled mid‑effort. Proper documentation also protects the project manager from second‑guessing after the fact, demonstrating that the decision was sound given the information available at the time.

Core Takeaways on Decision Documentation

Document serves as an audit trail

The make-or-buy analysis document records all alternatives, direct and indirect costs, schedule implications, risk assessments, and the final rationale, creating a reliable decision log and a defensible audit trail.

Assumptions must be explicit

All underlying assumptions, including resource availability timelines and vendor price stability, must be explicitly documented to ensure the decision can be re-evaluated with full context if any assumption changes.

Benefits extend beyond the current project

This documentation captures which tasks proved more economical or riskier to build in-house versus purchase, and it safeguards the project manager by demonstrating that the decision was prudent based on the information available at the time.

Revisiting the Decision: Make-or-Buy in an Iterative World

As projects evolve, the original make-or-buy basis can erode. A vendor that seemed reliable might start missing deadlines; an internal team that was stretched thin might suddenly free up after a canceled project. In iterative and hybrid lifecycles, the project manager should schedule a formal re‑evaluation at each phase gate or major milestone. This iterative make-or-buy evaluation ensures that the project never clings to a decision that no longer serves its objectives. The re‑evaluation does not need to be as exhaustive as the initial analysis, but it must check the key drivers: costs, schedule, resource availability, and risk levels.

The trigger for a revisit can also come from monitoring activities. If earned value analysis shows that the internal development work package is running significantly over budget, it might be time to explore a buy option to cap further overruns. If a vendor’s performance metrics dip below the agreed thresholds, the project may need to bring the work back in‑house. The transition itself must be planned, with a clear handover or knowledge transfer, and should be treated as a change request with proper governance. Ultimately, the make-or-buy decision is not a single gate to pass but a steering mechanism that keeps the project aligned with reality, and the most effective project managers use it dynamically throughout the lifecycle to protect both value and viability.