Depending on whom you ask, or what source you refer to, you can get many different answers. But you’ll likely find a common theme among them.
As guides in the software selection process, Factum takes a 7“phase approach, whether it’s selecting a warehouse management system (WMS) or highly integrated enterprise resource planning (ERP) software. Of course, we’ve helped organizations navigate the process from the beginning. But we’ve also jumped in somewhere in the middle, depending on which phase they were in when contacting us.
Keep reading to get a high-level overview of each of these seven phases below.
[And if you’d like a PDF copy of this article for referencing, find it here.]
Phase 1: Defining the problem accurately [problem definition]
This first phase is often skipped or missed by organizations and even some consultancies. There’s generally a rush to get through the process, which puts you on the wrong path from the start.
If you don’t accurately define the root cause of your organizational challenge, you won’t be able to select the right software, despite your best efforts. That means wasted money and man hours. And who likes to waste their time?
Phase 2: Determining relevant functionality [requirements analysis]
After defining the problem, you need to ask yourself How does the system align with the problem?
You’ll need to identify the business processes that are affected by the problem you defined. It’s also helpful to develop high-level use cases based on those business processes.
We wrote a piece on requirements analysis previously that provides additional detail about this phase, including a breakdown of the three main types of requirements:
- Functional requirements
- Non-functional requirements
- Organizational requirements
In the end, you’ll produce a requirements document that you’ll use to reference going forward. In addition, since this phase is still in the foundational part of the software selection process, it is almost as critical as the first phase.
Phase 3: Identifying potential software vendors [market research]
Next up is researching the market to identify potential software vendors. These are companies that may be able to solve your organizational challenge, whether in an out-of-the-box solution or with a customized solution.
Be open in your consideration of vendors. They don’t necessarily have to check every item on your requirements list from the publicly available information you find. You’ll narrow down your list later.
What you are primarily trying to accomplish is getting a sense of your available market options, so your list may be long.
Phase 4: Creating an RFI for identified software vendors [RFI]
After gathering your list, you’ll then want to create and send out a request for information (RFI). The RFI’s main purpose is to gather basic or fundamental information about each software vendor.
You’ll want to ask for essential info that will disqualify a large number of the vendors on your list. Of course, some may not even respond, which offers its own method for disqualification.
After receiving the returned RFIs, your team will review and narrow down your original list of software vendors until only a handful of vendors remain.
Phase 5: Developing an RFP for shortlisting software vendors [RFP]
Whereas the RFI asked for basic info, the request for proposal (RFP) requires a highly detailed breakdown of each vendor’s software solution. From approach to cost to requirements adherence, the RFP is your opportunity to ask for every detailed aspect you’re looking for.
This is the part of the software selection process where you’ll produce your shortlist of software vendors. Typically, your shortlist will include only three software vendor solutions.
Three tends to be the magic number. Having only two vendors does not provide you with enough room for comparison or error. In contrast, having four or more vendors can place a burden on your software selection team in having too many solutions to choose from, not to mention the additional time for demos.
Phase 6: Demoing with software vendors [vendor demos]
After producing your shortlist of solutions, you’ll invite each vendor for a demo. The demo is a prime method for determining a vendor’s potential fit with your organization. In fact, the quality of the demo can serve as a peek into the quality of the implementation.
To ensure you’re able to easily compare the solutions, and that each demo is presented in an orderly manner, you’ll need to develop a demo format and demo script for all vendors to follow. In addition, you’ll need to have a standard demo scoring sheet for your team while reviewing.
And remember those use cases you developed back in phase 2? Those come in handy here, as each vendor demo should have incorporated those use cases to be relevant to your organization.
Once the demos are completed, your team should meet to compare scores and notes, then ultimately decide on which solution is the best fit for your organization.
Looking for more hands-on guidance for software selection? Check out the toolkit we put together, including an in-depth demo guide.
Phase 7: Deciding between buying and building [buy vs. build]
Deciding on whether to buy the vendor solution you’ve chosen or build an in-house solution is the next (and possibly last) phase.
Now, most software selection teams, and even some consultancies, don’t consider this phase. After all, after spending time and energy on identifying the right software solution in the market, why just build a solution in house?
Well, the buy vs. build question is an essential one to ask. And you wouldn’t know the answer unless you went through the software selection process.
Here’s a few scenarios that may add some clarity to the buy vs. build dilemma:
- Your organization does not have the in-house capabilities to build a solution and must look to the market
- Your organization has the in-house capabilities to build a solution, but is not aware of what’s in the market that may be cheaper and/or faster
- Your organization just wants to make sure it does its due diligence in comparing market solutions to potential in-house solutions
In any case, deciding on whether to buy or build the solution to your organizational challenge is something that needs to be considered. And the more information you have to support the decision, the better.
Phase 7.5: Reviewing and negotiating the software contract [contract negotiation]
Essentially, this is only a phase if you choose to buy a software solution. In this case, there’s the additional effort of software contract negotiation.
As with any large, lengthy, and/or complex purchase, a solid contract is needed to formalize what will be provided by both parties. You want to answer the question What does this software purchase and implementation look like in words, and how can I protect my organization’s best interest with those words?
This is definitely not a phase you want to handle on your own. Getting help from software selection experts can be the difference between success and failure in the software selection process (as well as implementation).
Make the software selection process simple and headache-free. Let Factum help.
From beginning to end, Factum has helped organizations in every phase of software selection. Our consultants have worked in a number of industries and ensured clients chose a system that met their needs”thanks to our clearly defined process. We know what pitfalls to avoid to ensure the process goes smoothly.
Whether you need a guide for the entire process or just want an expert, external perspective before you make the final decision, we’re here to help. Schedule your free discovery call today.