How do I document make-or-buy decisions? The make-or-buy decisions document captures the conclusions reached about which project deliverables, services, or results will be produced internally by the project team and which ones will be acquired from outside the organization. This documentation can be as simple as a listing with a short justification for each choice, and it may also include decisions to secure insurance policies or performance bond contracts to address identified risks. Even after initial documentation, these decisions often shift as procurement activities reveal new constraints or opportunities, so the document is not frozen but updated as the project evolves. Documenting these choices properly prevents misunderstandings, aligns stakeholder expectations, and creates an auditable trail that supports later procurement processes.
Key Topics for Documenting Make-or-Buy Decisions
| Key Concept | Summary |
|---|---|
| Make‑or‑Buy Analysis | Documents the evaluation and final decisions on whether project deliverables are produced with internal resources or procured externally, balancing cost, risk, and strategic fit. |
| Documentation Format | May take the form of a concise justification list, covering not only routine sourcing choices but also binding commitments such as insurance policies or performance‑bond contracts. |
| Application Scope | Extends to subcontracting, software licensing, acquiring specialised expertise, and investing in in‑house capability through targeted training programmes. |
| Strategic Record | Establishes an auditable sourcing history that directly supports procurement statements of work, requests for proposals, and contract‑negotiation strategies. |
| Outcome Validation | Enables post‑implementation analysis to determine whether deviations originated from flawed initial assumptions or from execution‑level surprises that altered expected results. |
| PRINCE2 Alignment | Within PRINCE2 environments, sourcing decisions are embedded in product descriptions and planning, with formal records maintained in the project plan and business case justification. |
| Agile/Hybrid Methods | In agile and hybrid settings, lightweight artifacts such as decision logs or wiki pages capture sourcing choices while preserving a fully traceable decision trail. |
| Contextual Factors | Effective decisions require capturing the assumptions made, stakeholders consulted, and constraints at play, moving beyond break‑even arithmetic to preserve the full decision context. |
The Nature and Purpose of Make-or-Buy Decisions
Before discussing how to document these decisions, it helps to understand what they represent in project management. A make-or-buy decision is an analysis that determines whether a particular product or service needed by the project should be created internally using the project team's resources or sourced from an external supplier. The concept extends beyond simple purchasing; it can involve the decision to perform work in-house versus subcontracting, to develop software versus licensing it, or to acquire specialized expertise versus training internal staff. At its core, the decision forces the project manager and the organization to consider trade-offs among cost, schedule, quality, risk, and strategic capability.
These decisions are not trivial administrative checkboxes. They shape the project's procurement strategy, influence the make-up of the project team, and affect the project's cost baseline and schedule. A construction project, for instance, might need to decide whether to pour concrete on-site using its own crew or to bring in a specialized contractor. A software development effort might weigh building a custom analytics module against purchasing an off-the-shelf platform. In each case, the documentation captures not just the choice but the reasoning behind it, which becomes invaluable if circumstances change or if the project is audited.
Documenting make-or-buy decisions formally establishes a clear record of strategic sourcing choices, which later feeds into procurement statements of work, request for proposals, and contract negotiations. Without a written justification, team members might revisit the same debate multiple times, wasting effort. Moreover, when a decision leads to an unexpected outcome—say, a bought component fails to integrate smoothly—the documentation helps track whether the original assumptions were flawed or the implementation went off course. It is easy to think of it as a one-time artifact, but that's rarely how projects actually work. More often, you'll update it as procurement activities mature and as the project environment shifts.
Key Insights on Sourcing Decisions
- Definition of make-or-buy
- A make-or-buy choice resolves whether a needed product or service should be produced in-house using the project team's resources or procured from an external supplier.
- Scope beyond simple purchasing
- This framework reaches beyond purchasing to cover decisions like performing work internally versus subcontracting, developing custom software versus licensing existing applications, and hiring specialized expertise versus developing internal staff capabilities.
- Trade-offs across key factors
- Balancing cost, schedule, quality, risk, and strategic capability directly shapes the procurement strategy, team composition, cost baseline, and project schedule.
- Value of formal documentation
- Formally documenting the decision and its rationale supplies critical input for procurement statements of work, requests for proposals, and contract negotiations, and helps determine whether unexpected outcomes arise from flawed assumptions or execution gaps.
Where Make-or-Buy Documentation Fits in Project Management Frameworks
From a PMBOK perspective, make-or-buy decisions are an output of the Plan Procurement Management process, which belongs to the Project Procurement Management knowledge area and the Planning process group. This process involves documenting project procurement decisions, specifying the approach, and identifying potential sellers. The make-or-buy decisions document is therefore one of the critical artifacts that emerges alongside the procurement management plan, the procurement statement of work, and source selection criteria. Its proper creation is not optional; it is a fundamental part of formal project planning that guides all subsequent procurement activities.
In PRINCE2 environments, the concept maps loosely to the approach of planning and defining product descriptions, where decisions about outsourcing are recorded in the project plan and the business case. While PRINCE2 does not have an identically named artifact, the principle of documenting procurement choices with justification is embedded in the management products and the controls for the managing a stage boundary process. Similarly, in Agile or hybrid projects, the documentation might take a lighter form—perhaps a simple entry in a decision log or a page in the team wiki—but the need for a traceable record persists. Even if the team is co-located and self-organizing, someone still needs to hash out whether an external API subscription makes more sense than building an integration from scratch, and that call should be written down somewhere accessible.
Many practitioners first encounter the make-or-buy analysis as part of the PMP exam content, where it is tested as a decision-making tool rather than a document. Yet in practice, the documentation aspect often gets less attention than it deserves. The exam might ask you to calculate a break-even point, but the real world demands you also capture the assumptions, the stakeholders consulted, and the constraints that tilted the decision one way or another. That's the gap this article aims to fill: showing how to document, not just analyze. The formality of the document can and should scale with the project's complexity, but its presence should be non-negotiable wherever procurement choices are made.
What to Include in a Make-or-Buy Decisions Document
The source material describes the document as a simple listing with a short justification. That is an accurate starting point, but to make it durable and useful, you will want to expand on that skeleton. At minimum, the listing should identify each deliverable or service under consideration, its category—make or buy—and a concise justification. The justification might note a cost advantage, a skills gap, a risk mitigation, a schedule dependency, or a strategic alignment. For decisions involving insurance or performance bonds, the document should name the specific risk being transferred and the type of coverage or bond required.
Beyond the basics, consider including the evaluation criteria used to reach the decision. For example, if the team compared three vendors or evaluated internal capacity against cost estimates, capturing those data points—even in summary form—adds credibility. You don't need a massive report; a table with a few columns can suffice. The point is that when someone asks six months later, "Why did we decide to buy the HVAC system instead of installing it ourselves?" the answer should be in the document, not buried in an email thread that nobody can find.
A well-constructed make-or-buy documentation often covers a decision log with justifications and risk notes. This log may include a column for the decision owner, the date of the decision, the stakeholders consulted, and any assumptions that were critical to the choice. If the decision hinges on a volume discount that only applies if you purchase additional quantities, note that assumption. If the market price of a commodity is volatile, note that as well. Transparency about assumptions prevents blame games later, because everyone can see that the decision was rational given what was known at the time.
For insurance and bond decisions, the documentation might cross-reference the risk register. The project team may have identified a risk of supplier default or a natural disaster that could delay a critical equipment delivery. By deciding to require a performance bond or to purchase builder's risk insurance, the team has taken a risk response. Recording this in the make-or-buy document alongside the listing of make items ties the procurement strategy directly to the project's risk management approach. It also reminds the team to verify that the insurance or bond is actually in place before signing contracts. Some project managers also attach the cost-benefit analysis sheet or a scored evaluation matrix as an appendix, making the document a comprehensive record of the decision rationale.
Key Takeaways on Decision Logs
- Minimum listing components
- Every deliverable or service being evaluated should be clearly identified, along with its make-or-buy classification and a succinct justification.
- Justification categories
- A compelling justification may reference a cost advantage, a critical skills gap, risk mitigation needs, a schedule dependency, or broader strategic alignment.
- Risk transfer documentation
- Where insurance or performance bonds factor into the decision, the record must specify the exact risk being transferred and the type of coverage required.
- Credibility through comparison data
- Documenting vendor comparisons or internal capacity assessments, even in brief summary form, reinforces the credibility of the final decision.
- Owner, date, and assumptions
- Capturing the decision owner, date, stakeholders consulted, and key assumptions transforms the entry into a complete audit trail of the rationale.
When and How to Update the Documentation
The source material makes clear that these decisions can be altered as subsequent procurement activities indicate a requirement for a different approach. This is not a one-and-done artifact. For instance, after releasing a request for proposal, the bids might come back far higher than expected, prompting a reevaluation of whether to perform the work internally after all. Or, a key team member with rare expertise might leave, making an internal build riskier than originally thought. In such cases, the document must be updated to reflect the revised decision and the rationale for the change.
Updating the document is not just about editing the choice from "make" to "buy"; it is about capturing the trigger event and the analysis that led to the pivot. A project that fails to update these decisions risks operating on outdated assumptions, which can lead to scope creep, budget overruns, and contract disputes. Imagine a scenario where the project originally planned to buy a commercial off-the-shelf software package, but midsprint the development team realizes the product lacks a critical integration capability. The decision to build internally gets made in a hallway conversation, but nobody updates the document. Months later, when the procurement department inquires about the licensing fees, confusion ensues. The updated documentation prevents that kind of disconnect.
The frequency of updates depends on the project's complexity and the volatility of its procurement environment. Large construction projects might have a formal change control process that triggers updates to all procurement-related documents. In agile software projects, the product backlog and sprint reviews naturally surface new requirements that might affect make-or-buy decisions, and the team can update a lightweight decision register every iteration. Regardless of methodology, the iterative review of procurement decisions ensures that the make-or-buy log remains a truthful reflection of the current strategy. Without this discipline, the document becomes historical fiction, no longer useful for guiding actions. Even small triggers, like a supplier going out of business or a new technology emerging, should prompt a reexamination, and the date and reason for the revision belong in the document itself.
Common Pitfalls and Misconceptions
One of the most frequent mistakes is treating make-or-buy documentation as a purely financial exercise. While cost comparisons are important, they rarely tell the whole story. A decision to buy might look cheaper on paper but introduce delivery risks or quality concerns that are not captured in the cost estimate. Conversely, keeping work in-house might preserve control but stretch the team so thin that other deliverables suffer. The documentation should reflect these non-financial factors, even if they are qualitative, because they often carry more weight in the final decision.
Another pitfall is failing to involve the right stakeholders when creating the initial document. A project manager might make a make-or-buy call based on her understanding of the team's capacity, only to learn later that the legal department requires a specific set of contract clauses for any bought service above a certain threshold. Or the facilities team might know that the machine shop needed for an internal build is already booked for months. Catching these constraints early and documenting them saves rework and embarrassment.
A subtler misconception is that the make-or-buy document is only about major acquisitions. Even small purchases—a software library, a translation service, a piece of specialized testing equipment—can affect project outcomes. The document can be scaled to suit the project's size, but it shouldn't ignore these smaller items entirely. A simple rule of thumb: if the decision requires someone's approval or if it carries any risk, document it. Over-documentation might seem bureaucratic, but under-documentation can leave the project exposed. It is tempting to skip writing it down when the answer seems obvious, but obvious answers have a way of becoming ambiguous under scrutiny.
Some modern methodologies, including business-value-oriented approaches, highlight that make-or-buy decisions can inadvertently generate waste, such as the waste of overwork when internal resources are stretched beyond capacity, or the waste of perfectionism when a team insists on building something from scratch that could be adequately fulfilled by a bought solution. Recording these considerations in the justification section helps keep the team honest about whether the "make" impulse is driven by value or by an unexamined desire for control.
Key Missteps in Make-or-Buy Choices
- A purely financial focus blinds decision makers
- Viewing make-or-buy decisions solely through a cost lens overlooks delivery schedule risks, quality implications, and internal capacity constraints that often determine ultimate project success more than the price tag alone.
- Stakeholder input prevents costly surprises
- Excluding legal, facilities, and other relevant departments from the evaluation risks basing decisions on partial data, such as overlooked contract liabilities or equipment access that is already committed for months ahead.
- Decisions can inadvertently create waste
- Misguided make-or-buy choices generate organisational waste either by overloading internal teams beyond sustainable capacity, or through perfectionism that delays delivery when a capable external solution is readily available.
Connections to Risk Management and Other Processes
The make-or-buy documentation is not an island; it connects tightly with risk management, scope, schedule, and cost baselines. Each decision to buy introduces a new set of risks—vendor reliability, currency fluctuation, intellectual property leakage—that must be captured in the risk register. Conversely, decisions to make something internally might increase the project's exposure to technical risks or resource availability risks. By cross-referencing the make-or-buy decisions document with the risk register, the project team ensures that risk responses are adequately planned and monitored.
Insurance and performance bond decisions, as highlighted in the source material, are explicit risk responses. When a project requires a performance bond, it is essentially transferring the risk of non-performance from the project to a surety company. Documenting this in the make-or-buy log ties the procurement choice to a specific risk treatment, making it clear that the buy decision is part of a broader risk strategy. If the bond requirement changes later—say, the surety limits the coverage or the premium becomes prohibitive—the project can reassess both the make-or-buy and the risk response together.
Cost and schedule baselines also depend on these decisions. A make choice typically implies in-house labor costs and possibly capital expenses, while a buy choice involves supplier costs and procurement lead times. If the documentation is not kept current, the cost baseline might not reflect the true expense profile, leading to skewed earned value calculations. Similarly, the schedule can be impacted if a make decision requires ramping up internal resources that are not available, causing delays that ripple through the critical path. The integration with project baselines is one of the less obvious but most consequential aspects of documenting procurement choices thoroughly. When a buy item arrives late or with defects, the project schedule immediately feels the effect, and the documentation provides the context needed to assess whether the original decision was sound given the information available at the time.
Scope management also ties in here. A make decision that later shifts to buy may require a scope change request if the bought product has different characteristics or requires custom integration work not originally foreseen. The documentation serves as the bridge between the procurement strategy and the scope baseline, enabling controlled adjustments rather than ad hoc scope growth.
Practical Applications and Industry Scenarios
Let's walk through a couple of plausible scenarios to see how the documentation plays out in real projects. First, consider a large manufacturing project that needs a custom control system. The initial analysis shows that building the system in-house would take 12 months and require three full-time engineers, with a total estimated cost of $800,000. Requesting quotes from specialized control system integrators comes back with a range of $650,000 to $950,000 for a turnkey solution, with delivery in 10 months. The make-or-buy document would list the control system as a candidate, note the two options, and include a justification such as: "Buy decision selected due to lower average cost and shorter lead time, plus the integrator's proven track record in similar facilities, reducing integration risk. Assumption: external team will work on-site alongside our engineers." It might also note that a performance bond will be required to mitigate the risk of late delivery.
Now imagine a small software project where the team debates whether to license a mapping API or build a custom map module using open-source libraries. The license fee for the API is $500 per month, while building and maintaining a custom solution would cost roughly 80 hours of developer time upfront and 10 hours per month. The documentation might record the decision to license the API because it provides faster time-to-market and regular updates, even though the total cost over two years might be slightly higher than building in-house. The justification would highlight the strategic advantage of freeing up developer time for core features. Such a document might sit in a shared team drive, just a few lines in a spreadsheet.
These micro-examples illustrate that practical make-or-buy documentation adapts to project scale. A mega-project might formalize it as a signed decision memorandum with executive approval; a small initiative might use a running table in the project management plan appendix. The format matters less than the clarity and accessibility of the rationale. As long as anyone coming to the project midstream can understand why a particular sourcing path was chosen, the document serves its purpose.
In pharmaceutical R&D, a common make-or-buy scenario involves clinical trial management: should the sponsor company use in-house clinical research associates to monitor sites, or contract a clinical research organization? The documentation for such a decision would weigh the therapeutic expertise of the internal team against the CRO's geographic reach, regulatory familiarity, and the shifting demands of the trial. If a study faces an unexpected safety signal, the decision might be revisited to bring critical monitoring activities back in-house, and the updated document would capture the risk trigger and the new rationale.
Another example comes from marketing departments deciding whether to hire a freelance copywriter for a campaign or to use an internal writer. The documentation would note the creative style required, the turnaround time, and the budget. A short justification like "Internal writer, while proficient in technical content, lacks the campaign-specific tone needed; buy decision based on speed and portfolio fit" makes the reasoning clear and defensible.
Core Insights on Make-or-Buy Documentation
- Cost and lead time drive decisions
- In the manufacturing scenario, a buy decision becomes clearly advantageous when an external integrator offers both a lower average unit cost and shorter delivery timelines, rendering in-house development uncompetitive.
- Speed versus long-term expense trade-off
- The software example illustrates that a licensing model with a higher two-year total cost is often the prudent choice when faster time-to-market and continuous vendor updates deliver strategic benefits that outweigh the savings from building in-house.
- Documentation scales with project size
- Large programs require a formal signed decision memorandum with executive approval to ensure an auditable trail, while smaller projects can capture decisions in a running table placed in an appendix to the project management plan.
Ensuring Long-Term Viability of the Document
To keep the make-or-buy decisions document useful, integrate its review into the project's regular governance cycles. For predictive projects, this means including it in the agenda for phase-gate reviews or project board meetings. For agile projects, consider a brief review during release planning or at the end of every few sprints when the team discusses external dependencies. A simple check: "Are our make-or-buy assumptions still valid?" can prompt an update. Assigning ownership to a specific role—the project manager or a procurement lead—helps prevent it from falling through the cracks.
Version control is also important. Because the document changes over time, maintaining a revision history or a log of changes within the document itself provides an audit trail. Stakeholders can then see not only the current decisions but also the evolution of those decisions. This transparency is particularly valuable during post-project reviews or if a project encounters a dispute with a supplier. The documentation then serves as evidence that the decisions were made thoughtfully, not capriciously.
Integration with organizational process assets can further strengthen the document's longevity. Lessons learned from past projects often reveal that certain types of make decisions consistently overran because of underestimated complexity. By capturing these insights in the rationale section and referencing historical data, future projects can avoid repeating mistakes. Sustaining the document as a living artifact means treating it not as an isolated project form but as a piece of institutional memory. A new project manager inheriting the project can quickly get up to speed on why key sourcing choices were made and which assumptions might now be obsolete. That alone justifies the effort of keeping the document honest and current.
