Knowing When To Approve A Software Purchase
The CFO’s Checklist
ESTIMATED READING TIME: 6 MINUTES
If you’re a CFO and you’re being asked to approve yet another “this will solve everything” software tool purchase, you’re right to question it.
In fact, it’s your job to question it.
But as a finance person, not an IT person, you’re often on the back foot when it comes to understanding whether the software purchase is really the right answer to the problems your business is experiencing.
The problems behind the problems
If your business is living with the following kinds of issues, these are red flags that new software purchases should not be made yet:
- significant costs associated with obtaining reporting figures,
- huge risk mitigation costs,
- unsuccessful IT projects
- entire teams being burdened with manual reporting processes which impact their ability to do other value-added work.
In our experience, software purchases are not (or not yet) the right choice if or when a business is experiencing these types of issues and hasn’t investigated its business information foundations.
When these foundations are shaky, your software purchase isn’t likely to solve the issues. When they are strong, your IT staff are in a far better position to assess software options and request the purchase of the most appropriate software.
Software success depends on the quality of what you put into it, and the quality of how you put it in.
Information foundations form the structures around what goes into new software and how it goes in. Without strong foundations in place that ensure quality input, the software can’t be a success.
What are the foundations of business information?
Business information foundations are those business resources and rules that guide the way your company manages information.
It includes things like:
- your business language,
- the rules that govern information created from your data,
- the way you manage issues with language or information,
- the culture you’ve created around the value and management of information and
- how you measure your ability to aptly govern all of these.
Weak business information foundations exist when businesses do not invest in creating & maintaining these things well. Instead, businesses simply assume they don’t matter, assume they’re happening well, assume they’re happening in accordance with requirements – assume they’re happening at all!
Weak information foundations can go a fair while without being detected. The IT builders building on them find work arounds and band-aid solutions to solve the smaller, initial issues as they arise (often to meet project deadlines without consideration of the long-term effects).
Each issue is addressed as a stand-alone issue, because it’s often believed to be just that. But over time, the structural weakness of the foundations, and the work arounds that have piled up over time, create a very unstable landscape, unable to sustain information quality under the “weight” of a new software build.
So, identifying the quality of your business information foundations is vital.
The CFO’s Software Purchase Checklist
To help you determine whether you’ve got weak business information foundations, we’ve created the following checklist.
This checklist is meant to help you see whether those involved in recommending the purchase (or build) have done all the necessary investigation to ensure your information foundations are solid and that this purchase/build is really what your business needs in order to resolve the issues it’s meant to resolve.
(Check the following boxes if they apply)
Has the organisation previously purchased or developed software that will “solve” the same issues that this software is intended to solve?
This should be a red flag. Remember the definition of insanity – doing the same thing over and over again and expecting a different result. You should be given assessment documents that clearly explain how and why this software purchase/build will succeed where previous ones have not. If you’re not convinced it will succeed, don’t approve it.
Have IT, or the business sponsor, done a thorough (and we mean THOROUGH) assessment of the causes of the problems being experienced?
As a guide, this usually involves a deep dive into your data collection and usage practices for the data concerned, and will require a team that includes representatives from all relevant functional areas. This will take time, but will be well worth the effort. Decisions can then be make based on facts not perceptions.
Are business staff driving this purchase decision?
IT are often good at understanding whether software will work with the systems you currently own, and IT are the ones who’ll have to support the new software, so their opinion is important. But it is the business staff who know what they need, what they’re not getting from current systems, and must articulate their expectations of and how they want to use the new system once it’s installed. So, business staff should be driving the decision here. They should be accountable for considering all requirements. Take the time, make the effort to talk to business staff – not just the high-level managers – about their input into this decision and examine any concerns that have been raised.
Has a thorough review of all arms of the business been conducted to see how the new software change will affect each of them?
If IT hasn’t fully consulted an appropriate cross-section of the business, then the new purchase may end up causing more trouble than it solves. This consultation should include not only those requesting the new software but also all those who currently use any data that will be affected and those who will likely want to use the new data. We’ve seen this happen more than once. It’s easy for current data owners to not realise all the ways their data is used throughout the organisation and therefore not realise how changes that suit their immediate needs could have huge ramifications for others.
Have you clarified your language?
A core foundational component we see undermining the success of new software purchases or builds is poor management of language. This poor management can very easily lead to ambiguous specification in the new purchase/build. Do you have a corporate wide, enforced language that is used to assess every database and every build? If you don’t have an agreed language, meaning your business terms are clearly defined and unambiguous, you don’t have good foundations.
Period.
No further software purchase should happen before you do this language definition work. It will underpin all future purchases because it ensures both the requesting business staff and the IT staff determining a solution are crystal clear in their communication and understanding of what is being requested and what is proposed for delivery. In our experience, it’s the most vital part of building solid foundations for IT build success. And whatever software you buy will fail without solid foundations.
(As an aside, it’s this language work that most often identifies the true causes of the problems you’re trying to solve – so we can’t recommend highly enough that you ensure this gets done before approving purchases).
What to do if you recognise you’re living with poor information foundations.
If you’ve completed the checklist and you think you do have business information foundation problems, the obvious next question is “What can we do about it?”
When physical buildings have poor foundations, repairing those foundations requires experienced builders to assess the problems and work out what’s needed to address them adequately. Only then should you begin building any new structures on them
The process is the same with weak business information foundations.
Such structural repair work is not an appealing thought, we know. It can be a big and daunting task.
But it will save you a LOT of money in the long run.
One client of ours did just this, and saved themselves more than half million dollars by not purchasing new software that they simply didn’t need. Once they understood where their foundations were shaky, and defined what information was needed and how and when they needed to capture it, it became clear that a fix to their existing process (an excel spreadsheet) was all they required to resolve the reporting issues they faced.
They’re still functioning well using that spreadsheet 10 years later!
Terry Smith
Terry is a co-founder & Chief Education Officer at Intraversed. She spends her days helping information governance teams implement the Intralign Ecosystem, an award winning methodology that builds stable information foundations for reliable reporting.
Connect on LinkedIn