We’ve shared before a high level process for implementing software but here I thought it worthwhile spending a bit of time considering how we select the right tool in the first place.
Over the past few years we’ve worked with a number of small to medium sized business implementing new systems. In many cases they have already selected a tool and are simply asking for help getting it setup and running.
It begs the question, if they don’t have time to implement it where did they find the time to choose it?
Choosing the right software is just as important as the implementation. In fact much of the work you do during selection is required for the implementation.
Our experience demonstrates this issue as when asked to implement, without selection, we often discover too late that the new software is missing some critical feature.
Here is our high level process for selecting the right software:
How it works
It goes without saying that a core part of this approach is the capture of process! But only once you’ve defined the objectives, goals, benefits (perceived and real) and, importantly, budget.
These things are essential up front. They may change as you learn more about the solutions you are reviewing but you need something upfront to frame the next conversation.
Work with a number of key stakeholders to capture and understand the current process. This allows everyone to get their concerns, hopes and desires out on the table and documented. In the context of what they do and what they are trying to achieve.
You now have a heap of really useful information that will certainly make your early selection easier. You can start researching potential solutions. Simple things like budget and a rough list of requirements will help you eliminate those that are too expensive or don’t deliver your basic needs.
Getting into the detail
Now it’s time to get hands on with your shortlist. Before signing up to any trials you want to create a couple more resources. Firstly create a list of scenarios. Work with the stakeholders again to understand what are some common and not so common scenarios they deal with.
Here are some example scenarios from a software company looking to implement a support desk system.
- User from a small customer calls in to say they have forgotten their password
- User from a medium sized customer calls in to say the system is unavailable, they are upset and losing money
- User calls in with a question about a feature that is detailed in the help manual
Discuss how these things are handled today and what rules are applied. I hope you are starting to see that you are gathering lots of really useful information here and keeping a track of all the requirements the team have.
It might be worth using Kano mapping to categorise each requirement in terms of ‘must have’, ‘nice to have’ and ‘delighter’.
This list forms the basis of your comparison chart. Create a matrix with requirements down one side and the shortlisted solutions along the top.
As you evaluate each solution against your scenarios mark each requirement with a score (1-10 typically works well) as to how well it met the requirement.
Once the evaluation is complete you can add up the scores. Don’t forget to make notes about other features you find along the way and the general experience.
Create a report
At the end you should be able to present your findings back to the team with both quantitative and qualitative analysis along with your recommendation for the product.
Explain how the solution stacks up against the original goals and objectives. It’s possible that none of the solutions fit perfectly, especially if budget is constrained. It’s up to the business owner to make the final decision.
I hope you find this useful. If you’d like any further guidance please contact us [email protected]