If your company is at the point where you are losing pennies or even dimes on every dollar-earned due to inefficiencies in key businesses processes, there’s no time like the present to make a software change. The hardest thing about switching software,
This software selection plan 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 make an effective software choice without stopping the presses on your day job.
The plan is broken down to each of the key roles who’ll need to participate in your software selection process: project sponsor, project manager, technical lead, and user advocate.
This software review timeline won’t work for everyone, though. Larger enterprises or even medium-sized businesses selecting complex systems like ERP or SCM software will simply need more time.
But small companies and even medium-sized businesses targeting a limited application or two can rely on this approach to make an efficient and ultimately profitable decision.
Let’s get into the details.
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.
There are a number of exercises a project sponsor can undertake 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 you are in an expansion mode, how can the software contribute to that goal? Is the point of the project to create savings to fund expansion or do you need to fill 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 make more sense to also 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 of these exercises offers a different lens to focus in 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 what your key goals driving this desire to include decreasing budget development time, generating more accurate reports, and improving the readability of budget reports provided to investors.
Select the team and share the project outline.
Not every software review task requires direct executive participation. Assembling a selection team will prevent the process from monopolising executive attention. Inviting multiple perspectives into the review will also encourage group buy-in—an underrated success factor when rolling out new software.
There key roles needed for an effective software selection team include: a project sponsor, a project manager, a technical lead, and a user advocate. It’s, of course, possible for a single individual to 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 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
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. It tends to be more harmful than helpful though.
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-up 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 keys processes creates a framework for fleshing out key feature requirements. In other words, it’ll make it much easier to make sure you aren’t overlooking necessary features. Users again 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 a budget
With goals, processes, and feature requirements documented, important project benchmark 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. (For a framework to calculate potential savings based on efficiency gains, check out our ROI calculator.)
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 that has annual operating costs of $30k. The project sponsor, of course, will need to refine the budget further to make sure that it corresponds to available capital or to determine how to finance the system.
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. But a quicker review could mean that the best possible option might go unrecognised. 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 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. 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 offer an opportunity to move through your requirements checklist in a more efficient manner. Let it be the responsibility of your prospective vendor to then validate their feature support by providing screenshots, video, and product documentation. You’ll have enough on your plate reviewing the provided materials and comparing your possible options.
Once you’ve reviewed individual options, narrow the field down to a couple 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 not only allow you to make a back-to-back comparison of product functionality, but also gauge the possible improvements you can expect to receive.
After a demo of the software, return to the project goals you had established. 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.
(For more tips on getting the most out of software demos, check out our guide on the topic.)
Discuss implementation plan
There’s quite a bit involved in implementing new software. Generally, the process will include hardware preparation, installation, integration, configuration, data conversion, training, and possibly even customisation.
It’s time well-spent by your project manager and technical lead to discuss 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 towards. 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 issues like risk 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.
When you are comfortable with your preferred provider’s proposal and confident you’ll be able to generate a strong return on your investment, make your final selection.