There is often a complex and necessary period of analysis required to replace or upgrade a piece of software or computer system. However, when determining whether to build from scratch or buy an off-the-shelf product, the best bang for the buck is not always as obvious as it may seem.
Josh Karstens, outgoing project management officer from Maine, recommends using the 80/20 rule for this process of evaluation. The 80/20 rule means that 80 percent of end users use only about 20 percent of the features. So the focus should be on those features that comprise the 20 percent. This means an agency undergoes an honest examination of most-used features, versus less used/needed ones.
Start with MoSCoW
It’s important for agencies to go through this exercise so they don’t buy or build more than they need. To determine what provides the most value for the company/department, and what features could be added later, the state of Maine uses the MoSCoW method to prioritize functionality for each business unit.
The MoSCoW method helps to divide needs into the following categories:
- M – Must have
- S – Should have
- C – Could have
- W – Won’t have or don’t need
This process is a good way to determine if the agency:
- Has an existing application which could be re-purposed
- Wants to buy an off-the-shelf product to meet the need
- Needs custom built software
Usually this process is done in conjunction with agile software development. Doing so means that development milestones can be assessed and the priorities re-addressed as the project progresses. When using the agile approach to development to create software, the product owner prioritizes a backlog of functionality using this method to build the must haves first, then the should haves, and so forth.
Create a project brief
As with any project, having a plan in place for the primary objectives, and who the end users will be, helps guide development and the changes that may be necessary to manual processes. Check out Four Cs for Flawless Agile Business Requirements for how to make a complete, compliant, clear, and concise project brief.
It’s easier to evaluate the effectiveness of the project and make adjustments as necessary when the objectives are measurable and trackable. If some features don’t meet the documented objective or audience, then they can be discarded or added to phase two of development (moved from must have to should have). Most important is to keep the scope small and focused. Think minimum viable product.
We used the MoSCoW method recently in the implementation of a smart chat agent (chatbot) for the Missouri Department of Conservation (MDC). By determining the audience for the pilot chatbot, and its ultimate goals, we began to shape how this software would look. We helped MDC limit the number of objectives to just a few essentials for this pilot. One key objective was to “Reduce calls to customer support for hunting permit costs.” For details on this process, see Key Steps to a Chatbot Pilot Program.
COTS or custom?
If there are no re-useable systems available that meet the customer’s needs, then a cost/benefit analysis should be conducted to determine the most appropriate solution for the agency – COTS (Commercial Off the Shelf) versus custom software.
The decision to build custom versus buy a COTS solution often cannot be determined without research. This is done by probing key departmental personnel to scope out the actual needs of the end users and problem(s) the software needs to solve. The primary questions to ask:
- Does a COTS system meet the customer needs?
- Can you modify the COTS solution?
- Will building from scratch be economical?
When considering a large piece of off-the-shelf software, it’s important to be honest about how much of it will be used. Sometimes it may be cheaper to buy off the shelf and live with having extra/unused features, or features that aren’t an exact fit for the department.
Other times it may be possible to find an off-the-shelf product which could be modified or integrated with an existing system to meet the business unit needs. In the governmental sector, the most efficient approach is to look at what other departments are already using, and whether these systems could be re-used or modified, perhaps by adding a few more user licenses instead of buying or building from scratch.
Custom considerations
With custom software you get to chose exactly the functionality you want, but it may be at a higher price. Other considerations for custom software include:
- Custom software is often essential if the department has unique needs/challenges that don’t fit a COTS model
- Newer cookie cutter software may not integrate effectively with older existing legacy systems (common for many public sector entities)
- Governmental regulation and funding requirements may mean that a custom solution is the only feasible option
- A custom solution may be the only option to unify disparate systems or departments
It’s well worth the time it takes to determine if the best fit is custom, COTS, or modified COTS.
Integration
It’s also important to check that a new software/system fits into the overall OIT strategic plan. This prevents money being spent on something that doesn’t mesh with the longterm direction of state technology needs. Part of any due diligence may include a well framed RFP. It will help to determine whether new software meets the functionality required, and if it has the best ROI for both the business unit and tax payers.
Occasionally, a department may need to adjust their process rather than bending the software to meet the existing processes. Sometimes building a new piece of software/system will not be the most cost effective solution. However, it can prevent expenditures down the road (such as cybersecurity investments, or additional software to meet regulatory needs).
Final thoughts
When I worked in law, I had a boss who always told me to slow down when preparing for court. His motto was, “Proper planning prevents poor performance.” This statement rings true for software development decisions as well. Essentially, agencies must make project planning a critical element of each new considered system. Without effective project management, and planning, it doesn’t matter how capable the technical resources are. Executing a poorly planned vision will still lead to project failure.
Using techniques like MoSCoW to find clarity at the beginning of a project can help ensure successful outcomes. Without sufficient visibility into a project ?s progress, and the ability to effectively direct resources, projects can veer off course, resulting in cost overruns and disappointed stakeholders. It’s well advised to engage in early, upfront decisions regarding COTS versus custom, and determine whether outside consultants/experts could help reduce project risk.
Learn more
- Contact us about how to use MoSCoW for your next project
- MoSCoW Prioritization Handbook from Agile Business Consortium
- Buy or build? For IT, it’s custom vs. COTS by Brian Robinson for FCW
- When to Choose COTS from 18F
Author bio
Ravi Jackson has a background in law, finance, and policy, with 10 years of experience in the Maine state government. A witty Brit with a gift for discourse, he welcomes further discussion on this topic. He can be reached at ravi.jackson@govwebworks.com and @RaviJacksonGWW on Twitter.
