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!


Great article. A Couple of things that I would add: *In your evaluation, make sure you weight each of the requirements (which is another process altogether). You don't want to ding a vendor too hard because their software doesn't meet the accounting department's requirement for voice recognition of journal entry input. * I cannot emphasize enough that you MUST engage the rank and file in the entire process. That is, the users need to participate in the requirements gathering, evaluation and demos. If this is only done by the CEO (which is common in SMB software selection projects), not only do you run the risk of not capturing everything but you fail to get critical buy-in by the folks who will really determine the success or failure of the selection/implementation.


The closest programs that I've seen work are Synth Maker and SynthEdit.VB didn't work for me.How is an OS written?What computer could ever be fast enough to write an OS while in the RAM?


I share your recommendation to weight requirements. We believe that one should manage benefits by thoroughly understanding the sensitivity of the proposed financial model to changes in the proposed business payoffs. On every project there are only a few capabilities that deliver most of the benefit. In a service desk implementation, for instance, there is little differentiation among service desk offerings for incident and problem management function. And, little cost savings to be gained from any such differentiation. The value to be gained from an implementation such as described is from proactive change management combined with asset management and procurement. IT assets typically account for more than 50% of the IT budget - outside expenditures for up to 75%. A focus on the areas from which actual financial benefits can be achieved - real cost reduction / avoidance - seems prudent. As to "engaging" the rank and file - that may not be enough. We encourage our clients to apply three mutually reinforcing principles of leadership - engagement, explanation and expectation clarity - that can tap into the voluntary cooperation of your people by building their trust through fair processes and constancy of purpose.


I agree that this is a great article. Concerning the comment from another reader, my take is that while the rank and file need to be engaged, implementation of many a good initiative will fail unless the rank and file know which way the wind is blowing from the top. The fact of the matter is that many times the rank and file do NOT want to change. Indeed, not even top management generally wants to change, either. That is a natural human condition that we software developers face every day. If, however, senior management gives an initiative a "nod" and requests support from the rank and file, along the lines of communicating that the idea is to see what the implications are of the proposed initiative (not as dictatorial command), then a tipping point of rank and file support can be more readily found. In our deployments, we have found that the easiest implementations are those where an energetic and savvy "guy that writes the checks", thru force of leadership and respect from the rank and file because he really does know what is going on is seen to take the lead. Even then though, it will be dicy because groups of users can be finicky.