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, though, is often just making the time to do so.
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.
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 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.
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.
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.
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.
“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.
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.
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.
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.
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 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 willing to have an in-depth conversation about your needs, as this is a critical step in sourcing the most relevant choices.
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.)
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 customization.
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.)
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.
|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|