Build vs. Buy: Seven Steps for Analyzing your Project Solutions
Build or buy? This is a question that Business Analysts (BA) must ask when determining what will meet the needs of the project or organization. Should a new business solution be built from scratch or can a commercial off-the-shelf (COTS) product be used? There are several things that you need to know with respect to analyzing your options before making such important project decisions.
Determining the right solution can be a difficult decision. The decision-makers must first understand the specific business needs and goals and take into account project stakeholders, timelines, budget, and resources.
The following seven steps may help a BA determine the age-old dilemma of Build VS. Buy:
Step 1: Analyze business requirements
In many organizations, it is critical to elicit and analyze key business requirements. Business requirements must be supported by the solution or else the project will fail.
To elicit the key business requirements, it is important to identify and involve the right stakeholders. Brainstorming, elicitation, and review sessions are important to the overall success of a project.
Step 2: Analyze architectural requirements
It is important to analyze the architectural requirements for a project. Identifying the industry standards and architectural requirements will help you determine if a solution is worth building in-house or buying off the shelf. Building in-house can lengthen timelines and increase the resources needed to produce a solution. On the other hand, buying a COTS product may be costly and change the scope of the project. However, buying a COTS product may also get your product on the market quicker.
Most companies have a set of tools and standards that they use for development projects. It is critical that a BA identify the architectural requirements of a solution before recommending an in-house or COTS solution for your project.
Step 3: Analyze current skillset
Analyzing the development team’s skillset is important when determining the overall success of a project as well. A lack of skills or managed resources can cause a project to fail. After the skillset analysis phase is complete and a skill deficit has been identified the BA can recommend either increasing the resources (training, hiring, consulting, or outsourcing) of a project to meet the skill set needs or looking outside the project for a COTS product(s) that will fill the skill set gap.
Step 4: Analyze the current technology
A good BA should be able to identify the key requirements and business needs of a project. With the help of a development lead or SME, a BA should be able to determine if the current technology, standards, and processes exist within an organization.
Analysts, stakeholders, and developers should not be swayed by the latest technology fads. Untested or proven solutions can often create delays in a project or extend the timeline of the overall project life cycle. It is important to identify the current technology and how it will fix the business needs instead of the business needs fitting the technology.
Analysts and key stakeholders need to analyze the technology to determine if current technology is worth using. It is a good practice to create an ROI report that will present the findings to the correct decision makers of a project.
Step 5: Analyze existing solutions
In many larger organizations, it is common that different departments are unaware of what programs, tools, or processes are used in the rest of the organization. An organization will often adopt a process without checking the processes of the other departments. This can lead to additional resource costs or duplication of effort for some groups or individuals. To prevent this from happening a BA or project management team should conduct an analysis or a survey of the various processes and tools used in other departments of the organization. Sometimes spending a few hours of investigation can lead to a huge cost and time savings in the end.
Step 6: Analyze alternative (COTS) solutions
COTS products should be analyzed if the project is on a short development life cycle, if you have limited staff and resources, if the skill set does not meet the current business or technology requirements or if you simply do not want to reinvent the wheel. Why spend the time and money to design a solution when a solution has already been created for you to use?
When analyzing a COTS product it is important for the BA to involve members of the development, design, QA teams, and other key stakeholders that can offer input and feedback around proposed COTS solutions. The more key people involved in a decision will often lead to the right decision. Be warned however that having too many people providing input may sway a decision if the product analysis phase has not been properly completed. People tend to stick to the technology they know or hear hype about even when that technology doesn’t fully support the requirements.
A COTS solution should be considered if it can meet the key business requirements without any major modification to the rest of the project or existing solution.
Step 7: Analyze the Pros vs. Cons
When you have finished analyzing the solutions and alternatives and you are ready to present your findings it is important to collaborate with your project team and stakeholders to see if your findings are relevant and accepted. One way to do this is to analyze the pros and cons of in-house solutions vs. COTS solutions. For example, a list of some pros and cons for buy vs. build is provided below.
• Developers are familiar with their system and can customize their solution to meet the business requirements
• Building a solution may be cheaper overall than buying a COTS solution
• Organizations may qualify for special grants if they design the product in house
• Building in-house can lengthen timelines and increase the resources needed to produce a solution
• It can be expensive to train employees on the job to learn new skills
• Adding or retaining resources to meet a skill set may be time-consuming and expensive
• Developers often stick to what they know instead of using something new
• Upgrading, repairing, or replacing a custom solution can affect the overall project life cycle
• Simple or off-the-shelf solutions can be overlooked
• COTS may help reduce production time and get your product on the market quicker
• Organizational resources are not wasted on trying to create a custom solution
• A proven COTS solution may perform better than a new custom solution and contain fewer bugs
• There can be a lack of documentation around the solution
• A vendor may change the way a product works
• A vendor may terminate support for a product or technology
• COTS can be costly – There may be additional maintenance and support fees
• COTS can change the scope or requirements of a project
• COTS products may not meet the key business requirements of a project
It is important to understand the business needs, short-term and long-term goals, key requirements, and available technologies and solutions on the market. The BA and key stakeholders must always consider the following and analyze all the options for each project and solution:
- Speed of implementation for a COTS vs. custom solution
- Cost of implementation of a COTS vs. custom build
- Functionality, flexibility, and scalability in a COTS vs. custom build
- Support for COTS VS. custom build
- Organizational best practices, current technology, and skill sets of employees
- Potential for upgrading, modification, and replacement or retirement of COTS vs. Custom build
It is important to remember that regardless of the company, industry, or project you are working on if you do the proper analysis upfront then you will have a better product as the end result.