Introduction
When companies are planning a project there are decisions on whether to make or buy products or services for their project. A make or buy decision is done by project managers and their team to decide whether they create their own product or buy one from an external supplier. This is not limited to just one decision as they can implement a mix of both or buy something like software and customize it to their companies needs. This decision is made through a comparison of the costs and advantages of each decision. This requires many calculations meaning it is cost and time intensive for teams. The major benefits to keep in mind for agile projects are the value of the decision to make or buy to the user and cost and time effectiveness for the team. In a traditional approach this is done by a make or buy analysis and many of the tools and techniques from it can be applied to the agile methodology.
Traditional Make or Buy Analysis
The traditional waterfall approach to the make or buy process is a difficult decision that can take many months of analysis and documentation before a decision is ever reached. Many calculations must be made to ensure the financial benefit of the decision. This is commonly done by comparing the cost daily of creating to product versus the upfront cost plus the daily cost of operation. This can create an analysis that is just as time and cost intensive as the actual development of their project. This is even more cumbersome to the agile approach and will result in hindering the development of the project. Instead, it would be more beneficial to find a dynamic approach to move the process as quickly as possible and react to changes.
Agile Make or Buy
The following comes from an article, Using Agile for Buy Vs. Build Decision by mike Register and Tod Golding. Their company applied agile methods to their decision of make or buy for a company called Airlines Reporting Corporation (ARC). This will give insight on how agile teams can better fit make or buy decisions into their methodology.
Beginning on applying agile concepts to a buy vs. build decision it is effective to create not only a backlog of requirements for the project overall but also a backlog for the steps needed to reach a buy vs. build decision. The product backlog allowed for the team to understand what a good candidate was functionally to be purchased and what was specific to their company and would need to be built. It can also be used to estimate cost and various implementation options. Lastly, it allows for teams to use an epic/user story form to get an estimate of the schedule and cost for the various options available. Whereas the buy vs. build backlog allows the team to see major activities in the decision and group them into sprints. Separating it into sprints allows for a team to review progress, share results with stakeholders, and adjust when conditions change.
Other Techniques in Agile
There are many tools and techniques that can be implemented in the make or buy analysis. These can also be used through agile methods. These are just two that the team at ARC found useful to their project, but many others could be used by other agile teams depending on their goals and project. These include:
High-Level Architecture Diagrams
This is used to explain the architecture that is used to develop the system.
Using the product backlog, the team can create high-level architecture diagrams to show major modules of the solutions
This helps teams understand the product backlog and view the information in a visual manner.
It also makes it easier to separate areas of functionality that can be bought and what is going to need to be built.
Figure 1- HLAD example from Using Agile for Buy Vs. Build Decisions
Scorecards, RFPs
Known as Request for proposal scoring
Assigns numerical values to responses provided in vendor’s proposal
This allows for teams to view how the vendor product addresses the system requirements from the product backlog.
Figure 2- RFP example from Using Agile for Buy Vs. Build Decisions
The difference in the approach and use of these tools is how the team uses agile techniques to populate the tools. This allows for a more efficient and productive collection of data.
Conclusion
Make or buy decisions are important to both waterfall and agile approaches as it helps teams deliver to greatest value to their stakeholders and make the most cost and time effective decision for the project. Though in a traditional approach the make or buy analysis can take a long time. This analysis can be as time and cost intensive as the project itself in some cases. Applying an agile approach to build vs. buy decisions can offer a dynamic approach that progresses quickly and allows for changes as they arise throughout the project. A great way that a team can implement this is through creating the typical product backlog and create a build vs. buy backlog. A build vs. buy backlog will show the activities involved in the decision and allow for teams to separate those into sprints. The separation into sprints means that the team can review progress, share results with stakeholders, and adjust when conditions change. To add to this teams can implement tools and techniques typical of a traditional approach but apply agile techniques to information gathering to stylize them to fit their needs better. Agile teams can implement many of these tools and can make decisions on which ones they can best use. This all shows how agile teams have many options on working through make or buy decisions, just they must work to find what is effective to them and adds value to their product for their users.
Citations
M. Register and T. Golding. (2008). Using Agile for Buy Vs. Build Decisions, Agile 2008 Conference, pp. 259-264, doi: 10.1109/Agile.2008.23.
Schwalbe, K. (2019). Information technology project management (9th ed.). Cengage.
Comments