5 minute read: In this article I talk about my experiences of building checklists in the finance...
5 minute read: In this blog I discuss the methodology I have used in the past to choose new software for small businesses. Often, this is new accounting software but equally it could be any software solution that you identify as essential for the business. You can also download a checklist version here
Reasons to choose new software
Lets not waste too much time on the reasons for choosing new software but in my experience its usually related to the older system can no longer support the businesses requirements, or, the new software (giving the impression) it will provide better data and more efficient processes much better than the current systems. Shiny new software often gives the impression that they will be exactly what you need and so much better than what you currently use, so its your job to make sure that you believe that will be true.
Determine the Scope
Before you interact with vendors you need understand the broad scope and businesses pain points: the current challenges and future potential needs of the business. Early on you need to also agree the scope of the project to manage expectations. There is no point telling your colleagues your implementing something if it doesn't have agreement from the stakeholders that its necessary. Start with these five questions:
- Why is the change necessary?
- Who has approved this and who will be responsible for the project?
- What will the budget range be?
- When will the project be delivered?
- What will success look like?
Determine the Business Requirements
Next you need to collate all of these various requirements from the business users and compile it in a way that you can then easily assess and compare the options at a later date. You can do all or only some of the below recommendations depending on the size and complexity new software. This full list below is what I would provide for a new core software system.
Provide Company Background
This helps external vendors understand your business a little. Explain the general business and the industry you are in. Provide background transaction, or volume metrics (get an NDA signed if there is sensitive information) that are relevant to the software along with the project scope (you can choose leave the out the budget element for commercial reasons)
Document high level business workflows
This will help everyone involved to visualise the flow of your business processes. This would be more of a high-level walkthrough than a list of specific, definitive steps.
Document a list of requirements
This can be provided to potential vendors and their solution assessed against these needs. It also dictates to vendors what is important to you. Further, it allows your team to agree and sign off on the internal processes and on what is important and necessary.
Some existing processes may only be done in their current manner because of existing system limitations. Often, companies will review this as a separate project as process redesign may improve business needs and negate certain system requirements.
Remember also that very specific requirements will lead to less vendors being able to implement their ‘off the shelf’ features. This will lead to higher costs both to develop, and maintain a system. Ensure your requirements state your end goals and be open to how potential vendors would propose their system can address them.
Challenge and question the value of existing data and processes
Bringing over data from old systems can be time-consuming. This is often a challenge to migrate map the old data from the old system. As an accountant I've often wanted to bring over as much old and historical data as possible but I recall on one project an IT colleague reminding me that 'within 6 months you will have plenty of new trends and data'. That was true in that case as we rarely needed to look back too far. Seek to only include information that is valuable for future decision making (or required for compliance).
Set out expected timetable and resources
As part of the project scope you should set out the initial expected 'go live' date along with the various resources (internal & external) that you will require to get the job done. You will review this again when you pick your preferred vendor.
Compile a list of software vendors and options
Now comes the fun part! Hours of looking for potential replacements. You may already have a top contender in mind, and it could very well be the perfect system for your business. However, it's still essential to conduct thorough research and comparisons during this stage to further solidify your confidence in your decision. Even with a front runner this can help validate the choice and potentially lead to a more competitive offer if the vendors understand that they are in a tender like process.
Ask around for potential solutions
If possible, meet and discuss with ‘friendly’ industry peers, companies, associations, surveys, and other companies with similar challenges both your area. See which systems are popular in the industry and why.
- Are there any niche software providers to your industry?
- What are industry specific lessons learnt?
Shortlist your preferred options
Once the you have a list of as many options as possible you can shortlist preferred options to take to the next stage.
Request specific demos to showcase your requirements
You'll rarely get a sales person who wont want to give you a demo! That's why sending them your requirements list will help both sides and good sales people will let you know pretty quickly if their solution isn't the right fit so that both parties don't waste loads of time. Remember that vendors must spend time and resources in responding (this is what the requirements list should cover).
An important part of the process is getting to test the system and see how it operates to your business’s requirements. However, unless you provide some structure to the demo requests vendors will tend to show the features that they are most excited about rather than the ones you need to verify!
Based on project size, you should request that the demo responds to 2/3 specific features in your requirements and then allow the vendors to ‘show off’ their system in the second part.
Assess the implementation team
For projects that require an implementation phase, you should find out about the implementation team and their experience working with similar companies as yours.
- Do they have experience in your industry?
- For specific country requirements, do they have experience of your country rules and / or regulation requirements?
Award the Contract
Reviewing prices and commercials
A very low price may also indicate a misunderstanding. Scoring and choice should not just be based on price but include other factors such as the quality & experience of the implementation team, the industry fit, and how well specific Company requirements are met by the system.
For smaller projects the pricing is usually fairly straight forward. Make sure you understand what the monthly / annual costs are, the terms of payment, and if there are any implementation costs as part of the set up.
For larger projects you will need to standardise and compare . For example, compare on your own templates the pricing for the project based on 3 year / 5 year all in cost (i.e., implantation/capex + operating costs for that period). Confirm and clarify the unique assumptions that each vendor is providing in order to ensure that you are making sure you compare like-for-like.
Check references
Check if there are one or more implementers possible for the same system. Compare them based on experience of similar projects and understanding of the your market. Ensure that you talk to some reference clients of theirs (three is usually the ideal number).
Agree the Implementation Timetable and Resources
At this stage you need to return to your timetable and re-check what will be realistic compared to what you had hoped for at the onset of the project.
Have a project timeline
- Understand the migration deadlines from your current provider.
- Set a project deadline for implementation and ‘go live’
- Ensure that the project is on the agenda at regular management meetings so that there is a level of accountability if timelines slip.
Get your project team in place
Don't underestimate the level of resource needed - particularly for larger projects - and consider the need to temporarily add to the team with external consultants, project managers and other specialists if the project size merits it. Budget for enough resources to ensure an appropriate and high level of training and testing is available to staff.
Leave plenty of time for testing and training
Involve, communicate and train existing staff throughout the project. Have a strong testing period. Understand the ability of the existing staff to migrate to a new system and their onboarding pathway.
This is likely to be more of a challenge for companies that have existing staff that have been using the same system many years. Staff may be resistant to change or feel under pressure during the changeover. Conversely, these staff will have over 20 years of institutional knowledge which can contribute to the successful design of the system requirements.
Communicate, Communicate, Communicate
Project communications from the project team to staff need to be clear. Give as much notice of the changes coming (and reasons why) along with timelines and clarity on what is expected from staff during this time.
One last important note
Remember – you will never get it 100% right! Better to get it as close as possible and go for it rather than constantly delaying the project for fear of it not being perfect!
