Software selection: How to develop a great process

We've talked about the importance of a software selection process and a few ways to get one adopted at your company. This post will focus on the process itself and ways to make good software selection decisions while streamlining the process.

We've talked about the importance of a software selection process and a few ways to get one adopted at your company. This post will focus on the process itself and ways to make good software selection decisions while streamlining the process.


For SMBs, the decision-making and purchase-approval process is different than it is for larger companies. The red tape, the sign-offs, the week-long analysis sessions of larger companies are daunting. But for these larger companies, the price for software they're typically looking at could be the entire annual operating budget for a small or mid-size company. So that level of process should be required. For the SMB, the principles still apply, but the process can be abbreviated significantly.

When you get your first software selection opportunity (and for simplicity sake, let's assume that it is at the beginning of the process), the first thing to do is understand the challenge that is being addressed by the proposed software. These challenges can be classified four ways:

  1. A need to streamline an existing process.
  2. Introduction of a new process or responsibility within that function.
  3. Creating a new capability that is very different from what the company or the group has done in the past.
  4. Satisfying a new regulatory requirement.

The majority of software selection will be focused around classification #1 in an SMB. This typically results from general growth where a department has grown from one or two people to 20 or 30. The spreadsheet that used to be able to keep track of things and communicate changes has become more work to manage than it's worth. These types of projects are some of the more lower risk projects as well. The requirements are generally known, so the trick is in the capture.

Many of the folks that have worked with the old way of doing things are thinking in the way of the various workarounds, patches, and expired/unnecessary requirements that had to be put in place to make that spreadsheet work. Doing straight requirements capture at this point can lead to introducing a lot of restrictions, siloed operations and unnecessary steps in your final product. The trick is to get them out of this frame of mind, have them focus on the process itself and think outside the box. Otherwise, you just end up with a more expensive spreadsheet that is even more difficult to maintain.

An exercise that has helped me is to interview the various folks in a room together and do a rudimentary flow chart of how things actually work. When you start putting the process in a picture, some really obvious re-work steps, workarounds and unnecessary steps are magically revealed for everyone to see. Asking probing questions and challenging the existing assumptions will help the group focus on the important steps and allow you to get at the really important requirements.

This can be a long process and it's not always needed. Many times, employees within that group who have come from other companies have already worked with a process that can be done more efficiently or effectively. Finding these folks makes this step a lot easier.

Comparing an employee's former company payroll process or accounts payable process with the current company's processes in a flow chart saves time over process re-engineering. Additionally, many small companies are willing to fully toss out their process and adopt a best practices approach as prescribed by a vendor. Once the flow is agreed upon, you can usually pick out the important requirements yourself and then have the group validate them.

Now there are a couple of things you can do to begin the vendor search. You can issue an RFP, you can look around at trade shows within your industry, you can ask employees who have come from other companies what they used in the past or you can use your own network of CIOs/IT leaders to get a short list. Frankly, for SMBs, avoiding the RFP approach and using one of the others listed will save you time and keep the list quality just as good.

Have a conversation with each vendor as to what you're looking for. Tell them a bit about the process you're looking to improve or replace, give them the gathered requirements, and give them the your level of flexibility (i.e., are you willing to totally toss your existing process or are there requirements that you must keep it and tweak it?). This flexibility also extends to IT requirements. Are you willing to have it hosted or do you have to have the application in your own data center? Pricing should also be discussed. Are you looking for the Yugo or a Cadillac? Will a Buick do?

Next step is to set up an opportunity for Q&A with the entire group. Some vendors won't require this, but others may. This makes sure that they can tailor their solution to what you need. they can take real-world examples and use them to demonstrate how their solution would them.

Vendors are also a great source for finding innovative ways to solve problems. They have implemented their solution (ideally) at other companies within your industry. They have learned a lot of lessons and come up with innovative ways to deal with certain challenges within your industry. These Q&A sessions can be a two-way information exchange that can be very valuable. Once complete, you can take the information form the Q&A and other initial information to narrow down the field to two or three vendors. Take into account the number of implementations, applicability of their technology to what you need, etc.

Soon after the you narrow down the vendors, it's time to set up the dog and pony show. This is where the vendor will come in and demonstrate their software, taking into consideration your requirements. Having all of the vendors do their demonstration within a two-day period is the best approach I've seen. Granted, it may be tough to get the group together for that period of time but do what you can. Provide lunch and do it offsite if at all possible.

Create a checklist for each vendor with a 1 to 5 scale. Does the vendor meet this requirement? (Y/N) How well is the requirement addressed? (1-5). Include some free form fields as well. At the end of the dog and pony, tally up the checklists and begin your IT requirements process.

  • Is the solution hosted?
  • Is the facility SAS-70 Level 2 certified?
  • What is the redundancy/high-availability architecture?
  • How well is it supported?
  • Review disaster recovery plans and how often are they rehearsed/tested?
  • Who are the vendor's implementation partners?
  • How many of them are their?
  • How proprietary is their solution?
  • Is MySQL and Linux an option?
  • What are the open source long term plans?

Test support by calling with different problems at different times during different days and include weekends. Go through their customer lists and call their reference account and some accounts they don't list as reference. When you talk to the IT leaders at these companies, validate the claims the vendor has made and find out who else they were looking at when they made their selection. Why did you choose the vendor that you did? Review the vendor financials to make sure they're going to be around for a while. What happens with our data at the end of the contract? What format will it be provided in? How quickly will that be turned around? etc.

One final meeting to review the business scores and the IT scores should reveal the winner. Good luck!

Editor's Picks