Make or Buy Analysis Template – Free word Download
Introduction to the Make-or-Buy Analysis
One of the most fundamental strategic decisions a project manager or business leader faces is the “Make-or-Buy” decision. Should we develop this solution in-house using our own resources (Make), or should we purchase an existing solution or contract a vendor to build it for us (Buy)? Enjoy this Make or Buy Analysis Template – Free word Download
This decision is rarely simple. It is a complex trade-off between control, cost, speed, and quality. “Making” it gives you perfect customization and control but often distracts from your core business and carries the risk of development failure. “Buying” it is usually faster and transfers risk to a vendor, but it locks you into a dependency and may force you to compromise on features.
The Make-or-Buy Analysis is the formal document used to weigh these options objectively. It prevents emotional decisions (e.g., engineers often want to build everything because it is “fun,” while accountants often want to buy everything because it seems “cheaper”). This template provides a structured framework to compare the Total Cost of Ownership (TCO), strategic fit, and risk profile of both paths.
This analysis is typically conducted during the Planning Phase, specifically within the Procurement Management knowledge area. The output of this document directly informs the Procurement Strategy (Template 35). If the decision is “Buy,” you proceed to issue an RFP. If the decision is “Make,” you proceed to resource the internal team.
The following sections will guide you through the qualitative strategic questions, the rigorous quantitative financial modeling, and the final risk assessment required to make a defensible recommendation to your stakeholders.
Part 1: Analysis Context and Scope
Before comparing numbers, you must clearly define the “Item” under investigation. A Make-or-Buy analysis is usually done at the “Work Package” or “deliverable” level, not necessarily for the whole project.
Item Description
Instructions:
Describe the specific component, service, or product being analyzed.
- Project Name: [Insert Name]
- Item Name: [e.g., Customer Authentication Module]
- Description: [e.g., “The software component that handles user login, password recovery, and multi-factor authentication (MFA).”]
The Trigger for Analysis
Instructions:
Why are we asking this question?
- Reason: [e.g., “Our internal team has the capability to build this, but we are facing a tight deadline. Several commercial off-the-shelf (COTS) products exist in the market.”]
Part 2: Strategic Alignment (The “Core vs. Context” Test)
The first filter is strategic, not financial. You generally want to “Make” things that are your core competitive advantage and “Buy” things that are commodities.
Instructions:
Answer the following strategic questions to determine the default preference.
Question 1: Is this a Core Competency?
- Definition: A core competency is something that differentiates you from your competitors. It is the reason customers buy from you.
- Analysis: “If we are a logistics company, our ‘Routing Algorithm’ is core. If we buy it, we have the same routing as everyone else. Therefore, we should probably Make it.”
- Analysis: “If we are a logistics company, our ‘Payroll System’ is not core. Customers do not care how we pay our staff. Therefore, we should probably Buy it.”
Question 2: Is Intellectual Property (IP) Protection Critical?
- Analysis: “If we outsource the manufacturing of this prototype, is there a risk the vendor will steal the design? If the IP is the ‘Secret Sauce,’ keeping it in-house (Make) is safer.”
Question 3: Is Speed to Market the Priority?
- Analysis: “Buying a solution usually takes weeks (integration). Building it usually takes months. If the deadline is the primary constraint, Buy is favored.”
Strategic Predisposition:
Based on the answers above, state the initial leaning.
- Statement: “Since this item (User Authentication) is a commodity utility and not a competitive differentiator, the strategic preference is to Buy, provided the costs are reasonable.”
Part 3: The “Make” Scenario (In-House Development)
Now, you must rigorously estimate what it would take to do this yourself.
Warning on Optimism Bias: Internal teams notoriously underestimate the effort. They see the “Happy Path” of coding but forget the testing, documentation, maintenance, and bug fixing.
Capability Assessment
Instructions:
Do we actually have the skills and capacity?
- Skills: “We have 3 Senior Developers who know the language (Python). However, none of them have specific experience with Multi-Factor Authentication (MFA) security protocols.”
- Capacity: “The team is currently 100% utilized on the main product. To ‘Make’ this, we would need to deprioritize Feature X or hire 2 new contractors.”
“Make” Cost Estimate (Internal TCO)
Instructions:
Calculate the full cost. Do not just use salary; use “Burdened Rates” (Salary + Overhead).
Table: Estimated Internal Cost
| Cost Category | Calculation Logic | Estimated Amount |
| Development Labor | 500 hours x $100/hr (Burdened) | $50,000 |
| Design/Arch Labor | 50 hours x $120/hr | $6,000 |
| Infrastructure | Server costs for Dev/Test environments | $2,000 |
| Tools/Licenses | IDEs, Libraries, Testing tools | $1,000 |
| Maintenance (Yr 1) | 20% of Dev Cost (Bug fixing/Patches) | $10,000 |
| Total “Make” Cost | (Initial + 1 Year Maintenance) | $69,000 |
Pros of Making:
- Customization: It will fit our workflow perfectly.
- Control: We can change it whenever we want without asking a vendor.
- Integration: Built directly into our existing codebase.
Cons of Making:
- Distraction: Takes focus away from unique business features.
- Maintenance Burden: We own every bug forever.
- Risk: If our lead developer quits, knowledge is lost.
Part 4: The “Buy” Scenario (External Procurement)
Now, analyze the market alternative. This usually involves buying a COTS product or a SaaS subscription.
Market Availability
Instructions:
What is out there?
- Option A: Auth0 (SaaS Provider).
- Option B: Okta (Identity Platform).
- Assessment: “Multiple mature solutions exist that meet 95% of our requirements out of the box.”
“Buy” Cost Estimate (External TCO)
Instructions:
Calculate the purchase and integration cost.
Table: Estimated External Cost
| Cost Category | Calculation Logic | Estimated Amount |
| License Fee (Yr 1) | 10,000 Users x $0.20/month x 12 | $24,000 |
| Integration Labor | 80 hours x $100/hr (To connect API) | $8,000 |
| Customization | Vendor fees for branding the login page | $2,000 |
| Legal/Procurement | Internal time to negotiate contract | $3,000 |
| Maintenance/Support | Included in License Fee | $0 |
| Total “Buy” Cost | (Initial + 1 Year Ops) | $37,000 |
Pros of Buying:
- Speed: Can be integrated in 2 weeks vs. 3 months to build.
- Reliability: The vendor has thousands of clients testing the code; it is likely less buggy than our v1.0.
- Security: The vendor is dedicated to security compliance (SOC2), which lowers our liability.
Cons of Buying:
- Vendor Lock-in: If they raise prices next year, we are stuck.
- Feature Gap: The product does not support our legacy username format (requires a workaround).
- Data Privacy: We are sending user data to a third-party server.
Part 5: Financial Side-by-Side Comparison
Bring the numbers together. It is crucial to look at the timeline. “Making” is often high CAPEX (upfront), while “Buying” is OPEX (ongoing).
Table: 3-Year Cost Projection
| Year | “Make” Scenario Cost | “Buy” Scenario Cost | Delta |
| Year 1 (Build/Launch) | $69,000 | $37,000 | Buy saves $32k |
| Year 2 (Maintenance) | $10,000 (Internal time) | $24,000 (Subscription) | Make saves $14k |
| Year 3 (Maintenance) | $12,000 (Inflation) | $26,000 (Price Hike) | Make saves $14k |
| Total 3-Year TCO | $91,000 | $87,000 | Buy saves $4k |
Financial Conclusion:
“Over a 3-year horizon, the costs are roughly equivalent (Break-even). The ‘Buy’ option is significantly cheaper in Year 1, which helps our immediate cash flow. The ‘Make’ option becomes cheaper in the long run only if maintenance is kept low. Therefore, strictly financially, there is a slight preference for Buy due to the lower upfront risk.”
Part 6: Risk Comparison
Money isn’t everything. Which option keeps the Project Manager awake at night?
Instructions:
Rate the risks High, Medium, or Low.
Table: Risk Profile
| Risk Category | “Make” Risk | “Buy” Risk | Analysis |
| Schedule Delay | High | Low | Internal development is prone to slippage. Integration is faster. |
| Feature Fit | Low | Medium | We build exactly what we want. Vendor might not have Feature X. |
| Obsolescence | High | Low | Our code becomes ‘Legacy’ instantly. Vendor code is constantly updated. |
| Supplier Stability | Low | Medium | Vendor could go bankrupt or discontinue the product. |
| Control | Low | High | If we buy, we are at the mercy of the vendor’s roadmap. |
Part 7: Recommendation and Justification
Synthesize the Strategy, Cost, and Risk into a final decision.
The Verdict
Instructions:
Select one:
- Make (In-House)
- Buy (Outsource/COTS)
- Hybrid (Buy Base + Customize)
Decision Statement:
“The recommendation is to Buy the User Authentication solution using a SaaS provider (e.g., Auth0).”
Justification Narrative
Instructions:
Write a paragraph defending the choice.
Example:
“Although the 3-year costs are similar, the ‘Buy’ decision is driven by Security Risk and Time to Market.
- Security: Building a secure authentication system is difficult and high-risk. A specialized vendor offers superior security compliance (SOC2/HIPAA) that would cost us $100k+ to replicate internally.
- Focus: Authentication is a commodity, not a core differentiator. By buying this, we free up our Senior Developers to work on the ‘Recommendation Engine,’ which is our competitive advantage.
- Speed: Buying allows us to launch the beta version 2 months earlier.”
Implementation Next Steps
Instructions:
What happens now?
- “Procurement Team to issue an RFP to the top 3 Identity Providers.”
- “Technical Lead to begin reviewing API documentation for the preferred vendor.”
- “Legal to review the Data Processing Agreement (DPA) regarding user data storage.”
Part 8: Step-by-Step Guide for Conducting the Analysis
Step 1: Define the “Unit of Analysis”
Don’t analyze the whole project. Break it down. You might “Make” the frontend but “Buy” the database. Analyze them separately.
Step 2: Get Real Internal Costs
Ask HR for the “Fully Loaded Cost” of a developer. It is usually 1.3x to 1.5x their salary. Using just the salary makes the “Make” option look artificially cheap.
Step 3: Define the “Maintenance Tail”
The biggest error in “Make” analysis is assuming cost stops at launch. It doesn’t. You need to budget 15-20% of the build cost every year for maintenance.
Step 4: Factor in “Opportunity Cost”
If your developers are building this, what are they not building? If they aren’t building the revenue-generating feature because they are building a login page, the cost of the login page includes that lost revenue.
Step 5: Check the “Exit Strategy”
If you Buy, can you get your data out later? If you Make, can you migrate off it later?
Step 6: Consult the Roadmap
Ask the vendor: “What is on your roadmap?” If they are planning to release the feature you need in Q4, maybe you can wait rather than building it yourself.
Part 9: Glossary of Terms
- COTS (Commercial Off-The-Shelf): Products that are ready-made and available for sale to the general public.
- TCO (Total Cost of Ownership): The purchase price of an asset plus the costs of operation.
- SaaS (Software as a Service): A software distribution model where a third-party provider hosts applications and makes them available to customers over the Internet.
- Core Competency: A defining capability or advantage that distinguishes an enterprise from its competitors.
- Vendor Lock-in: A situation where a customer using a product or service cannot easily transition to a competitor’s product or service.
Conclusion
The Make-or-Buy Analysis is a critical tool for efficient resource allocation. It forces the organization to be honest about its capabilities and priorities. By proceeding with a data-driven decision, you avoid the trap of “Not Invented Here” syndrome (where teams refuse to use external tools) and the trap of “Hollow Corporation” (where teams outsource everything and lose their expertise).
This template ensures that whether you choose to build or buy, you do so with your eyes open to the costs, risks, and strategic implications.
Final Checklist for this Template:
- Did you assess strategic alignment (Core vs. Commodity)?
- Are internal labor costs fully burdened?
- Did you include maintenance costs for both scenarios?
- Is the Time-to-Market difference quantified?
- Have you considered the “Opportunity Cost” of internal resources?
- Is the final recommendation supported by the data?
Meta Description:
A comprehensive template for Make-or-Buy Analysis. Learn to evaluate Total Cost of Ownership (TCO), strategic fit, and risk to decide between in-house development and outsourcing.
Discover More great insights at www.pmresourcehub.com