The Software Selection Process (One-Month Timeline)

If your company is at the point where you are losing pennies or even dimes on every dollar earned due to inefficiencies in key business processes, there’s no time like the present to make a software change. The hardest thing about switching software is often just making the time to do so.

This software selection process provides a compact and effective approach based on the best practices we’ve witnessed helping thousands of software buyers over the years. The idea is to help you choose the right software efficiently without stopping the presses on your day job.

Timeline

The process takes place over one month, and the steps are as follows:

• Week 1: Define the scope, identify key goals, select your team, and share project outline
• Week 2: Review internal processes, capture feature and system requirements, refine goals, and set budget
• Week 3: Identify potential product options, review solutions, and speak with providers
• Week 4: Demo solutions, discuss an implementation plan, review proposals, and select software

Week One

Define the Software Scope and Identify Key Goals.

Tightly defining the scope of your desired software will establish an important compass heading to guide your review process.

A project sponsor can undertake several exercises when shaping the project scope. The approach to these steps will be the same whether the functional reach of your software is departmental or business-wide.

• Identify business execution obstructions. Look for big-picture items. Think along the lines of items such as “we have too much money tied up in inventory carrying costs,” “customers are complaining about late orders,” and “it takes our billing team way too long to get invoices out, and it’s disrupting cash flow.”

• Review strategic goals and initiatives. How will the software purchase fit into your larger business strategy? For instance, if your goal is to increase sales, how can the software contribute? Is the point of the project to create savings to fund expansion, or do you need to fill the functional gaps required to expand?

• Consider your existing systems. What are your key software systems? How well are they performing? What’s their expected lifespan? Often, it makes sense to bundle updates. Imagine you need to replace a point-of-sale system, losing vendor support. In this scenario, you’d want to consider any software adjacent to your POS system in your technology environment. It might also make more sense to replace a marginally effective inventory control system than spend the time and money integrating it with the new POS application.

• Think about what has changed since you last looked. Macro-level technological trends like the rise of cloud computing, increased mobile usage, and big data may have opened new opportunities or changed customer expectations. On a smaller scale, what’s changed with your business? A straight and short line often will connect the answer to this question to the specifics of what’s lacking in your current software.

Each exercise offers a different lens to focus on the shape of the missing puzzle piece to improve your business performance. Keep notes. You’ll want to be able to share your vision with others involved in the software review.

Also, make an effort to turn your thoughts on software scope into specific goals. It’s good to determine you need a new budgeting program that will enable collaborative budgeting. It’s better to identify that your key goals driving this desire include decreasing budget development time, generating more accurate reports, and improving the readability of budget reports provided to investors.

Select Team and Share Project Outline.

Not every software review task requires direct executive participation. Assembling a selection team will prevent the process from monopolizing executive attention. Inviting multiple perspectives into the review will also encourage group buy-in–an underrated success factor when rolling out new software.

The key roles needed for an effective software selection team include a project sponsor, a project manager, a technical lead, and a user advocate. A single individual can fill multiple roles; it’s just more work for that team member and one less perspective to act as a check-and-balance during the review.

• The project sponsor should be a top-level executive with true decision making power and the vision to align the purchase with larger company goals.
• The project manager needs to both understand the executive vision and possess project management skills.
• A technical lead will play their most important role after the selection process and during the implementation of the new software. However, they will need to be involved during the review to ensure that the implementation will ultimately progress smoothly.
• A user advocate can provide important input both on what’s working currently and what isn’t, as well as ideas about particular features to improve upon the status quo.

Following the selection of the project review team, the project sponsor needs to communicate the project scope and key goals to the project leader. Having the project manager create formal scope documentation is a good idea. Not only does it help the sponsor ensure that his vision is clear, but it offers a useful tool to get the other team members up to speed.

Week Two

Review Internal Processes

“What’s the most popular software?” “What’s the best?” “What’s the industry standard?”

It’s tempting to start a review process with these reasonable-sounding questions. However, this tends to be more harmful than helpful.

The problem with these questions is that pursuing a single answer is a red herring that takes the focus of finding the best-fitting_ software. Software quality is always contextual.

Before seeking out options, start by examining the key internal processes the new software will address.

If the scope of your search is to find a new CRM program that will help increase renewal/retention rates, begin by inventorying related processes.

Customer relationship management processes might include things like coordinating promotions to target relevant customer groups, sending regular check-in emails, conducting purchase follow-ups to ensure customer satisfaction, alerting customers to new offerings, periodically checking analytics to identify potentially disengaged clients, and measuring the effectiveness of individual reps to determine where additional sales training may be needed.

Capture Feature and System Requirements

Identifying key processes creates a framework for fleshing out key feature requirements. In other words, it’ll make it much easier to ensure that necessary features aren’t overlooked. Again, users should play a significant role in this part of the software purchasing process.

For example, a sales manager who spends hours every day interacting with the CRM software will best understand the current system’s strengths and weaknesses. The more detailed information he can provide, the better. The project manager can assist by encouraging this user advocate to brainstorm feature requirements through the use of Q&A’s, mind-mapping, or other time-tested idea generation exercises.

Similarly, the project manager should connect with the technical lead to understand system requirements such as deployment preferences, necessary OS compatibilities, and integration needs.

Refine Goals and Set Budget

With goals, processes, and feature requirements documented, important project benchmarks like expected savings and a workable budget can be quantified. An inquisitive approach is required to set these numbers.

Imagine a project aiming to generate cost savings via more intelligent purchasing. The project manager will need to work with the purchasing department user advocate to understand how much time new automation features might realistically save. The time-to-money translation is an important one. A projected 20% gain in efficiency might mean that a five-member purchasing department can operate equally effectively with four members. The project manager will need to gather estimates and verify how reasonable each individual savings or revenue estimate is to project the sum of the expected real cost savings.

Calculating expected return is tough work. There are always soft benefits that resist quantification. But it’s important to attempt to build a workable projection. It’s impossible to set a meaningful project budget without doing so.

A project manager who conservatively expects $50k in annual savings now has reason to understand that it’s a net positive to consider a solution with annual operating costs of $30k. The project sponsor, of course, will need to refine the budget further to ensure that it corresponds to available capital or to determine how to finance the system.

Week Three

Identify Potential Product Options

With potentially hundreds of individual products available, software buyers face a dilemma when trying to make an intelligent and efficient purchase decision.

Even a once-over look at all the available options would involve a prohibitive time investment. However, a quicker review could mean that the best possible option might go unrecognized. Fast and comprehensive appear to be mutually exclusive.

There is another option, however. Working with a third party who is familiar with relevant products solves the problem of quickly and comprehensively scanning the market. From a time perspective, it will likely mean the difference between spending one or two hours versus many more on this part of the review.

Many buyers contract with consulting firms for this specific purpose. Of course, there is a cost to taking this approach.

Another option is to use a free software referral service, such as our own. There are a number of different providers of these kind of services with varying levels of expertise and breadth of options. Ideally, you should pick a referral service that is willing to have an in-depth conversation about your needs, as this is a critical step in sourcing the most relevant choices.

Review Solutions and Speak With the Providers

One of the more frustrating parts of reviewing software is the tendency of product marketing literature to be long on promises and short on specifics.

Here’s a time-saving tip: Trying to hunt down every last feature requirement in the product literature yourself is usually an exercise in futility. In the best-case scenario, it’s inefficient. Once you have qualified the capability of the software to meet your core requirements, schedule a conversation with the software provider.

An initial conversation with the software provider will allow you to move through your requirements checklist more efficiently. Your prospective vendor is responsible for validating their feature support by providing screenshots, video, and product documentation. You’ll have enough on your plate to review the provided materials and compare your possible options.

Week Four

Demo Solutions

Once you’ve reviewed individual options, narrow the field down to a couple of providers whose solutions you’d like to demo. The project manager should coordinate the demo, but all selection team members should attend.

Take your time with demos. Make sure you are getting at least a look at all of the functionality you anticipate using. Also, ask your provider to provide an in-depth, step-by-step look at how their software would support a couple of your core processes. Doing so will allow you to make a back-to-back comparison of product functionality and gauge the possible improvements you can expect.

After a demo of the software, return to your established project goals. In light of what you’ve seen, how confident are you that you’ll be able to achieve the expected return on investment? Make any adjustments to your ROI expectations you feel are warranted.

Discuss Implementation Plan

Implementing new software involves a lot. Generally, the process will include hardware preparation, installation, integration, configuration, data conversion, training, and possibly even customization.

Your project manager and technical lead spend time discussing expectations for the implementation process with prospective vendors. The goal of these conversations should be to come away with a clear understanding of the vendor’s availability, the amount of time needed to implement software and any requirements that will need to be supplied to ensure a successful implementation.

For a more complete discussion of managing software implementations, check out this article.

Review Proposals and Select Software

Following the presentation of demos, most software buyers will have a strong idea of which product they are leaning toward. If you find yourself in a situation where it is less clear which product will suit your needs, return to your requirements documentation. Weighting the most important requirements and scoring possible options can be a helpful way to consider the choices from a different perspective.

More commonly, buyers struggling with their decision find themselves choosing between a higher investment/higher reward proposition and a less costly one, with a more limited expectation for strong ROI. Considering risks and scalability can help round out the evaluation and break apparent deadlocks.

Before making a final purchase decision, take the time to vet your vendor’s credentials. Asking for references is a good practice. Visit product support forums and online review sites as well, though, to access unbiased opinions from actual users.

Make your final selection when you are comfortable with your preferred provider’s proposal and confident that you’ll be able to generate a strong return on your investment.

Weekly Software Selection Tasks by Role

Job Role	Week one	Week two	Week three	Week four
Project sponsor	Define software scope & goals	Advise on budget setting		Demo top options
	Select project team members			Evaluate proposals & select software
	Communicate scope/goals to PM
Project manager	Discuss project with sponsor	Identify key processes to address	Identify product options	Demo top options
	Document scope & goals for team	Guide gathering of requirements	Conduct initial product review	Vet vendor credentials
		Analyze expected return & set budget	Speak with providers	Evaluate proposals & select software
Technical lead		Share system requirements		Demo top options
				Advise on implementation plan
User advocate		Share feature requirements		Demo top options