I have been involved in software technology in and around the Finance Team for over 20 years. During this time I have been on both sides of the fence; as a customer and as a vendor of software and related services.
The software market has changed
If we go back a number of years, there were fewer solutions on the market and the finance software space was dominated by the large players; offerings from the likes of IBM (or Frango as it was), Oracle/Hyperion, SAP, Comshare etc. Given the development and release cycles process, functional change happened slowly. As a result, these legacy products had a distinguishable level of functionality between them and each worked very differently.
In recent years a number of vendors have entered the finance software market, many on the back of newly developed solutions that leverage cloud technology and related agile design principles. These products are undergoing continual development and update (such is the world of cloud) and, in respect of core functionality, have diverged in terms of capability. Differentiation often only occurs at the complex end of requirements, high data volumes or large user populations. Of course, cost remains a potential differentiator as vendors employ different pricing metrics and license models.
Use of software features and functions
There is empirical evidence to show that only a limited number of software features are used frequently (20% has been mentioned), with most used infrequently (circa 30%). This means that most organisations use less than half of the features and functions available.
In my view, the amount of unused functionality is only likely to increase in the future as more features are added at the edges. An organisation often implements a solution utilising those features that are available at the time of development. Subsequent ‘new features’, whilst being made available in a cloud deployment scenario, are most often left unused unless they are absolutely vital i.e. if it ain’t broke don’t fix it.
Vendor differentiation
Whilst working on the vendor side of the fence, I have experienced numerous purchasing processes (RFIs, RFPs etc.) across many industries. One of the first things I look for is how the prospective purchaser is planning on differentiating between the vendors. This is a very good guide to me of the thought that has already gone into the proposed project, the sort of relationship being sought and, ultimately, the chances of the project being successfully delivered.
Let’s take an example relating to the Finance Team – an organisation looking to replace a spreadsheet model (the most common situation) with enterprise budgeting and planning software. Most of these organisations will be looking for the same key features and functionality; Workflow, Excel integration, Browser delivery, Multi-user involvement and collaboration, Integration with data sources, Reporting capability etc. If you were to look at the software market, there are at least 10 vendors I could name off the top of my head that can deliver these core functional requirements. Therefore, any of these products would work for your organisation. So, unless there are more complex requirements, how will you differentiate between the vendors? Price potentially, but what does it say about a project when it is based on price alone? This is not an appetising proposition for a prospective vendor and may impact their desire to respond.
Put more emphasis on the delivery
My experience is that, during the selection process far too much time and effort is being spent on the technology and not on the implementation and delivery. If there is a scoring guideline in place, it is often heavily weighted towards the Technology.
Make sure that you put enough emphasis on delivering the project. Use the selection process an opportunity to form an opinion about the people you will be working with. In my opinion, you should be looking for a ‘software partner’, an organisation and individuals who you can work with for, what could be, a number of years. This opinion will be subjective, a gut-feel rather than a definitive rating. Perhaps this explains why some organisations place such a high tariff on the Technology as RFI/RFP guidance often champions removing individual subjectivity.
In our experience, one of the common reasons for not achieving the desired project outcome is a failure of the implementation process itself. Two major contributing factors to under-achievement are project governance and commitment of internal resource. Ensure that both these aspects are comprehensively covered and carry sufficient weighting in your final decision. I am a great believer in the theory that ‘a bad idea implemented well is better than a good idea implemented badly’.
Finding the right software partner – the key questions to ask
I am sure you will have your own idea as to how to assess the suitability of a vendor to partner with. Ultimately, this is subjective. However, some of the key questions which will provide you with some insight are:
Who will you be working with?
Ask for CVs/consultant profiles of the proposed implementation team. Are they employees or contractors – vital to ensure on-going continuity. I would also recommend a face-to-face (via internet meeting if necessary) with key team members at the appropriate juncture of the selection process. This should include as a minimum the vendor Project Manager and Lead Consultant, the two main points of contact for you and your staff.
What is their implementation methodology and ethos?
It is essential that the Finance Team are self-sufficient in the future. Ask the vendor how might this be achieved? How does the vendor implement – what project methodology do they follow (e.g. agile, waterfall)? What level of commitment will they require from internal resource?
What Project Governance is in place?
The vendor should be experienced in delivering similar projects and should be able to advise an appropriate level of Project Governance.
Who provides post implementation support?
This is important regardless of whether you are working with a business partner or the software vendor directly. Who will be providing support and what level of support? How do they ensure continuity from the development team through to the support team?
What makes them different from the others?
This question will provide the vendor with the opportunity to identify anything that sets them apart from the competition. This could be specific expertise, an implementation approach or an innovative solution.
In conclusion
Selecting the right technology is important – how is it delivered will determine the success of the project.
Leave A Reply