1. WSATA = Buy vs Build Software
Prepared by: Paul Herzstein
Consulting Director, Applications
Info-Tech Research Group
Data: September 2017

2. Are You Going to Buy a House, or Build Your Own?
Building a new house is often more costly, but you have to shop around, decide on features that matter, and do a cost analysis to make the right call. The same applies to IT solution decisions.
Why This Matters
What Happens If You Don’t Have This
Enables organizations to confidently explore solution alternatives and prevent costly, sub- optimal build vs. buy decisions.
Facilitates the buy process, if the decision is to buy, to ensure that the acquired solution meets the business need and requirements.
If the decision is to build, ensures a clean hand-off to the specification stage.
Unable to accurately assess the pros and cons of build vs. buy, both in terms of cost and solution functionality.
Unnecessary purchase risks without a clear understanding of what the proposed acquisition must provide.
The burden of defining clear requirements shifts to the specification stage, meaning the wrong people are involved, and the risk of poor outcomes is increased.

3. Making Buy vs Build Decisions
At its simplest, the decision to build vs. buy should be based on:
Commonality of requirements – the more common your requirements are, the more likely that there is a solution available off-the-shelf that will meet your needs.
Constraints on “do it yourself” – if the expertise required to build the solution using internal resources is lacking, or of limited availability due to other commitments, it may be necessary to look at outside solutions.
When generic requirements and large constraints are involved, a clear “buy” decision can be made.
When very specific requirements are involved, and where limited constraints exist on internal resources, a clear “build” decision can be made.
Need more info to decide
Clear “Buy”
Clear “Build”
Constraints on “do it yourself”
Commonality of requirements
Other key factors may include:
Complexity of integration – highly-complex integration may make building more attractive than buying.
Budget and schedule pressure – tight budgets may mean doing the work with the resources you have; tight schedules may mean getting external help to get the job done.

4. Total Cost Ownership (TCO) Components
Remember that a TCO calculation can be just as important for deciding whether to pursue any option.
Cost Categories
Definition
Project Management
Costs associated with preparatory work and due diligence associated with the solution adoption.
Includes requirements gathering, training, and evaluation.
Hardware & Software
Software development or integration costs in the case of building.
The capital expenditure of SW licenses or equipment in the case of buying.
Maintenance and Support
Cost of upgrading and administering the hardware, application, and database.
The support staff labor hours and costs, training labor and fees, travel, support contracts and management overhead.
Opportunity Costs
Staff time allocated to the project (and not spent on other initiatives).
Time lost to schedule delays.

5. Buy vs Build Costs Buy Build Cost Components Project Management
Purchase and licensing fees
Implementation
Integrations
Training and support
Downtime
Long-term maintenance
Pro intellectual property
Product ownership
Future updates
Project Management
Research
Requirements gathering
Budget approval
Input data collection
Software evaluation
Software selection
Gap analysis
Proof of concept modeling
End-user training
Vendor management
Model/methodology development

6. Buy vs Build Costs – Cont’d
Software
License fees
Implementation fees (and/or internal costs)
Testing (integration, performance, user acceptance)
Configuration fees
Integration fees
Development - integration (if necessary)
Development - data mapping
Development - data migration
Customization fees
Annual maintenance fees
Software analysis & design
Development - client/server
Development - Web
Development - software localization (if applicable)
Development - integration modules
Development - data localization
Testing (code, integration, performance, user acceptance)
Documentation
Rollout
Maintenance & Support
Software upgrades (implementation)
Helpdesk (beyond vendor-provided support)
Ongoing maintenance
Software upgrades
Auto-update tools
Help desk
Issue tracking
Opportunity Costs
IT staff time
Business staff time
Schedule delays

7. Info-Tech Insights
One size doesn’t fit all: make sure that the cost of acquisition process rigor doesn’t overwhelm the potential savings that are available.
Buy vs Build decisions are not always made in a single step: make sure that provisional, early-stage Buy vs Build decisions are reviewed and approved before leaping into selection or specification processes.
Right-size evaluation of solution performance: small solutions may be evaluated solely on user feedback, while larger ones may be evaluated through various metrics. Whatever you do, do something.
Build where it makes sense, or is necessary. Buy when you can (and can afford it). Minimize the amount of internal effort surrounding operations and maintenance, and maximize opportunities for your most valuable asset, your staff, to add exceptional business value.
Build or Buy, simple or complex, organizational readiness assessment and clearly defined transition requirements are just as important – and can make or break project success.
Not all Build projects (or requirements) are equal: spend more time on projects and components that have the highest priority, business value, and risk, to get the most out of your BA investment.
Make sure that your buy processes enable real alternatives to in-house build solutions. If they don’t, you’ll be locked into a smaller set of options, limiting the potential for IT to add value.
The best technical solutions are a complete waste of time if they aren’t – or can’t be – used effectively.

8. Key Buy vs Build Decision Criteria
Key questions to ask:
What factors went into past decisions to build, buy, and/or integrate new technology solutions?
What constraints came into play for those past decisions? Are they still present?
What process limitations have contributed to tendencies to favor either build or buy approaches?
Past BvB Decision Criteria
BvB Decision Constraints
BvB Process Limitations
Total cost of solution
Budget
Onerous RFP processes
Schedule
Internal project mgmt overhead
Resource skills & availability
Lack of confidence in estimating
Availability of existing/COTS solutions
Integration complexity

9. Key Buy vs Build Decision Criteria – Cont’d
Key BvB Decision Criteria
BvB Impact of Each Criterion
Cost and budget
If budget is tight, can internal resources do more of the work to minimize out-of-pocket expenses?
Schedule and timing
If schedule is tight, can internal resources do the work in the allotted time? If not, acquiring a solution (or supplementing resources) may be necessary.
Resource skills and availability
Are staff with the necessary skills available to do the work? If not, acquiring a solution (or supplementing resources) may be necessary.
Availability of COTS solutions
Is an off-the-shelf solution available to meet most needs? If so, focus efforts on integrating that solution and addressing residual capability gaps.
Integration complexity
Are integration requirements particularly complex? If so, an in-house solution may reduce such complexity.

10. Info-Tech’s Selection Process
Solution evaluation and selection is a journey and a process. Skipping steps adds risk.
Success begins with a solid foundation.
Solution disruption is felt before, during and after implementation as everyone struggles to maximize the benefits of the investment.

11. Solution Evaluation and Selection
Why Buy?
Why Build?
Proven Solution
Proven Business Processes
No Internal Development Skills or Capacity
Implementation Timeline
Unique Functionality
Internal Development Skills
Solution Does Not Exist
Business Expertise
Key Points of Consideration:
Business Process / Requirements Validation
Common / Unique Business Scenarios
Development / Implementation Resource Needs
Integration Requirements
Organizational Readiness
Software Performance