People frequently seek solutions to problems they don’t fully understand. They may have a preconceived solution bias and seek to justify it. Or they may look at only parts of the problem, like cost. Technology selection, especially when looking for the foundation upon which to build your product, is a problem that you need to fully understand. If this isn’t done well, your organization will suffer unnecessary pain, and, worst case scenario, you could go out of business. Therefore, you need a detailed problem definition before you can jump into selecting new technology for your organization.
Ten Mile Square recommends an approach where you step back to see the bigger picture and create a problem statement. Based on the problem statement, you conduct a market survey to determine your options. Only then can you zero in on the best solutions to the true problem.
Understand the Needs
What do you really need? This seems like it should be an easy question to answer since it is tempting to go with what you already know. But fully answering this question will provide benefits beyond your technology selection exercise. At this early stage, you need to:
- Understand the problem domain you are addressing (see How to Build a Domain Model for details on this exercise).
- Assemble a list of use cases that describe the activities the important actors will execute.
- Derive the functional requirements your product needs to support (such as CRUD-related activities, search, etc.) and how well they need to be executed (the non-functional requirements).
The output of this effort is a distillation of your needs in implementation agnostic terms. This is a checklist of what your target technology needs to do.
Determine the Options
Once you understand your needs, you can determine the players in this solution space. Googling is a good first step, but you will also need to consult sources written by people who have already done this kind of research, such as Gartner. One of the best free sources for analyst reports are the vendors who offer free copies of reports that mention their product as well as their competitors. You’re not making value judgments yet, only assembling a list of all the options that could be a solution to your problem, in part or in whole. You want to be thorough. Include the market leaders as well as up-and-coming options and open source solutions. Anticipate that a stakeholder will ask you about an option, so you should have a ready response.
Narrow the Options
The list of all possible options can be quite long. You will likely not have the time, resources, or inclination to deeply evaluate each one. Instead, make a number of passes to cull the list to a manageable number. There will likely be a number of options that obviously would not work given your deep understanding of your needs. Do NOT remove these from the list, just mark them as rejected. If you still have too many options, reject the ones that, while they do meet some of your needs, their drawbacks would require too much effort on your part to make them work. Keep doing this until you get down to about 6-10 options, which is a reasonable number to conduct a deeper evaluation.
Rank the Options Against the Needs
This is where the hard work begins. Given the information you have gathered so far, you can start to apply qualitative assessments on how well each option meets each of your delineated needs. You are going to need more information, though, so reach out to the vendors with a request for information (RFI). Ask them to provide you with additional details on how well their product meets each need, demonstrations, and anything else about the product that will impact how you use it. This will likely lead to another narrowing of the options. At this point, it is time to run a bake-off with the top 3 options. This allows you to simulate each in your environment to determine the best fit. This requires a fair amount of effort by your technology team with support from the vendor but will allow you to thoroughly understand how well each of the remaining options fits your needs. Only now can you select the solution to your problem.
Clearly, the cost of an option is a factor that you will need to take into account, likely among the most important. Excessively high costs may rule out an option early in the process. Beyond that, though, you should wait until you have a set of candidates that meet your needs before you rank them by cost. Just because an option is cheaper than another doesn’t necessarily make it a good choice. You’ll also need to take into account hidden costs such as training your staff on that technology.
The Final Decision
Or is it a final decision? Just because you have selected an option doesn’t mean this process is over. You still have to negotiate terms with the vendor. Hopefully, the true price became known before this point, but some vendors have complicated pricing formulas that may balloon the cost beyond acceptable levels. Also, the vendor may reveal licensing requirements that you find unacceptable. This is why you put the effort into a bake-off with more than one option. You have one or more backups that you can turn to.
The process we just described is one that you can follow each time you need to select a technology. This repeatability allows you to not only select the best technology for your product but also to learn and improve as you go so that the next time you do this exercise, you will be more efficient and effective than the previous time. At Ten Mile Square, we have helped dozens of clients through this process. Contact Us so you can leverage our expertise.
Atul Gawande’s book, The Checklist Manifesto, is a good read in general but is particularly useful for technology selection. The process he describes ensures consistent evaluation of each option.