CFO 4.0 - The Future of Finance

246. Close Faster, Decide Better: Process, People, and the Right Tech with Grow CFO's Kevin Appleby

• Hannah Munro • Episode 246

Share episode

Send us your thoughts

Host Hannah Munro sits down with Kevin Appleby, host of the Grow CFO Show, to share hard-won lessons from finance transformation projects. From failed demos to faster closes, they explore how CFOs can avoid common pitfalls and deliver real value.

In this episode, you’ll learn:

  • How to approach system selection with scenarios and use cases, not just feature lists.
  • Why keeping solutions simple and phased prevents failure points.
  • The importance of engaging naysayers and building super users for adoption.
  • Why benefits come from people and process changes, not just technology.
  • Practical lessons for faster month-end closes and smarter procurement processes.
  • How CFOs can communicate with boards, influence decisions, and choose the right timing for go-live.

Links mentioned: 

SPEAKER_04:

Welcome to CFO 4.0, the future of finance. The CFO role is changing rapidly, moving from cost controller to strategic visionary. And with every change comes opportunity. We are here to help you take advantage of this transition to win at work, drive your career forwards, and lead with confidence. Join Hannah Monroe, Managing Director of Itas, a financial transformation consultancy, as she interviews key experts to give you real-world advice and guidance on how to transform your processes, people and data. Welcome to CFO 4.0, the future of finance.

SPEAKER_05:

Hello everybody, and welcome to this episode of CFO 4.0. You're going to have to give forgive me on this particular episode because we are trialing a new platform. And you know, if you've got any feedback for us on this particular episode, we'd love to hear it. So we are trialing a new podcast recording platform. So bear with us, guys, if we have any technical issues. And with me is my very friendly uh guest on this this uh week's episode, um, a familiar voice and potentially familiar face if you're watching on YouTube. I'd like to welcome back Kevin Appleby um to the show. Thank you so much, Kevin, for joining us.

SPEAKER_01:

Thank you, Hannah. And I'm rather pleased to be here this morning trialling this new podcast recording platform because by pure coincidence, I'm moving to the same platform as well. And I've got a very friendly guest book for a recording tomorrow. I don't know if you've heard of her before. She's called Hannah Monroe. She's very friendly and she's going to be quite good for experimenting with a new new recording platform.

SPEAKER_05:

Absolutely. It's always good to have a friendly guest for your first episode. And for those obviously that perhaps I don't know where you've been, if you haven't um heard Kevin's voice at our podcast before, you might need to go back a few episodes. But you know, tell us a little bit about Grow CFO just to get started, Kevin.

SPEAKER_01:

Well, it it is actually a long time since we last recorded together. It must be nearly two years.

SPEAKER_05:

Is it really? Oh my gosh. That that I I like I knew it was about 12 months, but two years is a very long time. So we definitely should leave it that long next time.

SPEAKER_01:

Definitely. We've got we've got to do something about that. But Grow CFO, for those of you that haven't come across it, you may well have heard my voice on a podcast because I host the Grow CFO show, which is the podcast angle of the Grow CFO business. Uh what what is Grow CFO? Grow CFO is a network and a learning and development platform for finance leaders. We started back in 2000. We were setting the business up just as COVID struck. And actually, for an online business, that was an advantage. When we first started, we found a lot of finance leaders, CFOs, etc., were coping with furlough, were coping with having to apply for government grants and all of those sorts of things. And nobody really knew what they were doing. So we started something called the Situation Room. Literally, we got people on the microphone just so they could talk to each other, share war stories and things like that. And we developed a community as a result of that. One of the real purposes of Grow CFO, though, was to teach people. So gradually, over that summer of 2000, we introduced our first online courses.

SPEAKER_05:

And obviously, today we'll be very much going to focus on your history as a consultant. So we we were talking about what we were going to cover in this episode. And one of the things I find that people learn so much more from is actually real life stories. So we're going to talk about, I guess, battle scars that we've we've developed over the years from our consultants. Our war wounds, if we're allowed to say it like that. So, because actually the best way to learn is from mistakes. If you look at any of the research and the science, we all learn through making mistakes. It's just nice when you learn through others' mistakes rather than your own, if we're being honest. So, so let's talk about, you know, when you think back in your consulting career around implementations, what is there is there one particular situation that really stood out to you that you learnt an awful lot from?

SPEAKER_01:

Oh gosh, there are there are several. And I think probably one of the big ones, uh, it was the last project that I did in PWC. We were implementing a planning, budgeting, forecasting system for a major package holiday provider. A problem we were solving was that a holiday brochure is in effect a PL account by itself. The team will go and decide what holidays they're running, they'll book the properties, they'll sort the flights out, they'll sell, they'll get the payments in, and they'll pay the providers. And there's a cycle of probably 24 months across there. And then they've got their winter brochures and their summer brochures. So every six months, new brochures kick off. So you're putting a 12-month budget together, you're cutting across all of these holiday brochures that are PLs in themselves. And we said, well, actually, what you've got to do to model the business here is model a brochure. So we're implementing planning and budgeting so that it would work to plan and budget one of these holiday brochures, but be able then to cut the thing in a different dimension to give 12 month trading of the company. And what did I learn? Well, one of the big pieces of learning was how to select a system. And we went into this project very much with a system in mind, a preferred choice, a partner we were working with in PWC. And guess what? It failed completely. So the first big lesson on that project was just don't assume that the project, the the vendor that you're used to dealing with will necessarily have the solution. They turned up for a demo at the client. The demo collapsed completely. They couldn't demonstrate anything. We gave them some scenarios to solve. They couldn't show us how they were going to deal with these scenarios. Another product that we'd not really dealt with much before, uh, which while we were doing the project actually got bought by Cognos and became Cognos Planning, managed to wow us with a demonstration, solve all the things that we wanted demonstrating, and was a fantastic project. So the first thing is be very careful and very objective in your solution selection. And don't go necessarily talking to the client about this wizzy, fantastic solution when that solution might not work.

SPEAKER_05:

Do you know what? I've learned that lesson the hard way. So we're we're lucky enough that we work across multiple, like we have some core, we're a Sagehouse, so we have our core platforms, but we have lots of partners to sit around the outside. And one of the conversations I always have with our crew that do the discoveries in the initial selection is don't talk product until you've understood the problem. Because you can end up easily down a rabbit hole before you've even gone into the requirements because it's so easy from like a profile of someone to assume that something's the right fit. You really have to understand requirements before you start looking at tech. It's it's that separation, isn't it, of process and problem versus tech. And I think everybody always leans into tech. And I say this as a tech person, right? I love tech. Um, and it's so important to make sure you're clear on what is the problem you're solving before you start picking a piece of technology.

SPEAKER_01:

Yeah. The other lesson we learned around that time was don't put the tech person in front of the client.

SPEAKER_05:

See, I disagree with that. You've got the wrong tech person, but then yeah, like from learning and experience. So one of the feedback we get is that and I purposely, when I pick consultants, I always pick people that I would put in front of a customer. Um, and and and that's not true. I can I can totally understand uh where you know why you might be that. But this is the thing that I think we we need to make sure that you know we're thinking about is is the people that we're dealing with on the other side. If we flip it as somebody that might be going into that process, make sure that you like and can communicate with the people that you're dealing with. If you haven't got that, then that's always going to be a challenge. You've got to be able to have a good conversation and they've got to be able to understand you.

SPEAKER_01:

And it's it's features versus benefits. Where I say, don't take the tech person and put them in front of the client. We had some fantastic tech people back then when we were we were looking at SAP and something at the time that was fantastic never caught on around around SAP, which was SAP SEM. It was the the management accounting bit, it was the data warehousing bit. Um the tech people loved it, and they'd wax lyrical about all the clever things that it could do. So you put them in a demo, they'd go and demonstrate all of these wonderful features of the product, but what they'd forget completely would be the problem and the that the client had and the benefit that we were looking to put in place. So, very, very important when you're presenting any tech solution, make sure that you understand the problem you're trying to solve and you talk about benefits of the solution, not the features of the solution.

SPEAKER_05:

So, Kevin, you've got a real history with um consulting. Tell us a little bit about, I guess, your your learnings and experiences. What was the um what was the one of the projects that's really uh well I won't say scarred you for life, but what's what's given what were some of the projects that really taught you about how to have successful implementations?

SPEAKER_01:

Okay. I remember the last project that I did with PWC. It's a long time ago, Hannah. It's probably getting on for 20 years ago now, but we were we were looking at solving a planning, budgeting, forecasting problem. And the the holiday provider operated thinking about holiday brochures. What was in the brochure? How do we sell how what prices are we buying at? What prices are we selling at? And then the business cycle going to actually selling the holidays, collecting the money, paying the clients. So a holiday brochure was a PL in itself. But a business cycle of probably about 24 months. Then you cascade summer brochures, winter brochures. So at any time, you could have probably about four brochures going that are six months apart each time. So four PL accounts. But for budgeting purposes, reporting purposes, you want a 12-month budget. So we started a very complicated project trying to work out how do we plan and budget for these 24-month business cycles, but at the same time successfully got a 12-month budget when we've got to. And we went into this, and I think key learnings, and lots of learnings for me as a consultant about software selection, but I think key learning from if you're listening to this as a CFO and running a project like this, an incredibly complicated problem. Try to keep right at the level of what is the essentials that's got to happen here. What is the business problem we're trying to solve? Okay, and be very clear with that as you go into the firstly the system selection, because there are lots of systems out there. Make sure that you're clear what it is that system's got to do. And in that particular client, that we we'd recommended as a PWC before we went in, uh a preferred supplier. Preferred supplier turned up for the demo and couldn't demonstrate the answers that the client needed to see. Which was quite embarrassing in some ways, but taught me to keep an open mind. We did find a solution that could demonstrate everything, but from the client point of view, very clear on your selection criteria. Okay, and I think having a good process to select a solution is one of those key bits of learning. That same project actually taught me something else because it was such a complicated project with so many moving parts. We actually designed too complicated an answer. Keep it simple is one of the key learnings out of that. And the the more difficult, the more complex you make the solution, the more points of failure there are to fix. And I would recommend to anybody going to a fairly complicated problem that you're trying to solve, bite it off in little chunks and get stuff working.

SPEAKER_05:

And there's so much in that. I think there's three really quick key points. And I think I just want to draw out one of your first points, which is around scenarios. I don't think people, I think people talk a lot about features, but not enough about scenarios and use cases. I see this all the time with people coming in, and that's one big shout out to everybody. You're you're better off being really clear on the scenarios and use cases that you have in your your AP, your AR, your reporting, then you and putting that and asking somebody to demo to that, then you are saying, show me this list of features. Because it's not necessarily do they have that capability, because a lot of um technology has similar capabilities. It's almost the how they can adapt it to suit your your particular needs where it trips up. And it sounds like that. That's what's happened with you, is that it's not that it wasn't a planning and budgeting tool and it didn't have great reports and et cetera, but it couldn't cope with the specific scenarios that were relevant to that business. Yeah.

SPEAKER_01:

And actually move forward 20 years. Literally, yesterday, as we're recording this, we we every quarter we choose a tech theme in Grow CFO and we run a demo day, a tech showcase. And we had yesterday afternoon, we had four vendors with us in the planning, budgeting, forecasting space. All of which showed us some fantastic solutions, all of which wanted to show us the features. Particularly at the moment, we've got lots and lots of change in virtually every area. People think they're doing some really clever stuff with AI. There was one vendor yesterday in particular who thought there were streets ahead on AI than everybody else and wanted to show us all these things, but they are features. Yes, the audience was probably wowed by them, but are they solving the problem you've actually got in your business? And once again, you've got we had four vendors in yesterday, but there are probably at least a dozen decent third generation FPA solutions. They're all solving a slightly different problem for a slightly different type of client. Um you've got to be clear what you want. There's no bad solution there. There's a solution that doesn't fit your requirements, though. So you've got to be absolutely clear. What do you require? What benefits are you trying to derive out of this? And ignore the features.

SPEAKER_05:

Absolutely. And don't get distracted by well, I call it shiny toy syndrome. Don't get distracted by this shiny toy. Focus on what is the value. Because ultimately it requires an investment, right? And and I think some of this comes back to people don't they spend a lot of time ticking off what features and functions are available. They don't necessarily spend enough time going, what's the value of the solution that I'm putting forward and what's the impact going to be on the business if I implement it? And and that for me is critical. Um, so we've talked a lot about, or certainly in the first few minutes, about the technology side. What about the people side? When you think back to your projects, was there any learnings you've had about how to manage teams within a project and how to get them, you know, help people with change?

SPEAKER_01:

That's the key thing, managing change. And we could probably talk for hours about managing change. And I I can think of the project where there have been the definite brick throwers, for want of a better word. People that want to rubbish the project, tell everybody in the organization it's not going to work, it's not going to do anything, it's a waste of time. Um they're always around. And I think one of the biggest pieces of learning that I've found is actually they're the ideal person to have in your project team. Right? The naysayer, bring them on board and get them involved in the new solution and really up to speed in it. The naysayer can suddenly become your greatest ambassador in the workplace in terms of getting people to accept it. Oh, Fred will always tell us if something's happening that's that's not going to work. If Fred's suddenly telling them, oh, this great new system's coming along, and it's going to be fantastic, we've got to be on board with this, you've won part of the change battle.

SPEAKER_05:

See, I remember a project, and and I learned this quite early on in my consulting days, where there was an individual, and I remember the conversation and thinking at the time, now this was in like my first couple of years of consulting. So I probably wasn't as direct with leadership as I would be now. And they um I remember CFA saying to me, um, oh, it's fine, that they they they're just gonna, they're gonna, you know, they're they're not gonna like the solution, but we're gonna do it anyway. So we'll just have we'll just deal with them on the other side. What you know, we'll just almost ignore, ignore their complaints was the always the conversation. And in the back of my head, you know, you've got to remember, this was like two years, and I was like, hmm, okay. Um, you know, like I'm not sure this is the right approach, but you know your team, you, you, you know, crack on. And and actually the challenge with that project back then was that that some of the feedback was really valid, right? And nobody would listen because that person was known for being really negative. And the and rather than getting hold of it and actually addressing what is it that you're concerned about, you know, and understanding that, taking that person aside, they just almost tried to bulldoze through it and it didn't work. You know, that that that was a really challenging project. We got there, but it was really hard work. And actually, there was some really valid input from that person. And I can still, I still remember it now. I obviously won't say the name, but I was like, my God, you know, like I if I if I could do that project again, and every project where I've had somebody say that to me, I just now I just have that conversation well up front and say, Yeah, you you've just you've got to get behind it because it's either two things, either they're gonna impact the morale for the rest of the team and change is hard enough without somebody adding that negativity into it, or they've actually got a point. And either way, you need to get behind that and deal with that situation ahead of the project. And and like you say, the best way to do that, I found, is just to get them involved in the choice, get them involved in the configuration, get them involved in the proof of concepts, all those kind of things, and take them on the journey.

SPEAKER_01:

Absolutely. And I think if you if you've got the team engaged into working out what the configuration, what the design should be, and let's face it, we're not just talking tech here. No, we're talking about the processes that take place around the tech. And get people involved. If they've put together the processes themselves or been involved in the process and understand why what is being implemented needs to be implemented, they'll be on board with it.

unknown:

No?

SPEAKER_01:

They'll have the feeling of yes, we do we designed this, this is what we want. Not, oh, somebody's inflicted this unworkable solution on us.

SPEAKER_05:

And I will caveat saying that sometimes change can be scary. So for me, have to get underneath what is causing that reluctance. Because sometimes it is a personal, you know, I a worry about a job or a worry about their standing within the business if this new solution comes in. Because very often I find like the person that knows the process inside out, you know, they don't want to be seen as the, you know, as they don't they like the fact that they're seen as the go-to person around something. So you've kind of got to give that same feeling with the new tech.

SPEAKER_01:

I think that's it's very important to go identify who that go-to person is.

SPEAKER_05:

Yeah.

SPEAKER_01:

That's not necessarily a senior person, as well.

SPEAKER_05:

Absolutely not.

SPEAKER_01:

Find out who who does everybody go to when they've got a problem at the moment. Whatever the existing system is. That person, once that system disappears, is going to feel incredibly disenfranchised. Because their kind of status within their peer group is going to disappear. So you've got to work out some way of putting something else in place for that person. How do you make them a go-to person for the new solution?

SPEAKER_05:

So this is why I'm a big fan of CPU users, because and I and I mean this in the nicest possible way. Not what I've learned over the years is not everybody is technically equal, as in they don't have the same technical skill set. And normally, if a person has that kind of experience, if they're the go-to person for another solution, they either have a really strong process and business knowledge or they're technically competent. It's one of the two, right? You've got to, you've got that. So actually leveraging that and using them as a super user, somebody to sign off what you're putting forwards and giving them almost an initial wave of training before you do the rest of the team and using them to kind of support the rest of the team kind of gives them that status feeling. Um, gives them that, you know, I won't say superiority is probably the word, but that feeling of being um needed and wanted is really critical. And then you've got them on board.

SPEAKER_01:

Yeah. And super user, I'd also say that I'm a great believer in train the trainer. Those superusers should also be the trainers that you train.

SPEAKER_05:

I think personally, I think you need to be careful with that. So this is experience as well. So a lot of people like the idea of train the trainer. Um, and it and it is a brilliant way to build knowledge, right? And I have seen that work really well for certain individuals. But you also run the danger of, you know, after a couple of days of training, you're sending that person out to train others. And they've not necessarily, you know, is that as good as having somebody that's been doing it for five years doing that training? Probably not. So my my compromise on that is we I would use them to do first line workshop and query support, right? So they would be taught first, and then the trainers would deliver the really good training, but those guys would be in the room supporting those that may be struggling a little bit, dealing with queries, testing queries post that. And that tends to work better because you get a really good standard of training for everybody, and you get to embed the knowledge in those super users.

SPEAKER_01:

Absolutely. And I think it's it's very worth remembering the point that uh train the trainer. You've got to have somebody who's got training skills. Yeah. And that's not necessarily the person with the deep knowledge of how the system works. Quite often a person that has the deep knowledge uh is is too geeky to teach it.

SPEAKER_05:

Yes. The deep and it's not necessarily deep knowledge, is it? It's user-level knowledge that we're imparting here. Um, and and like you say, training skills are incredibly important. I think a lot of people forget that as well. Like if you make training interactive, and and I, you know, I preach about this internally all the time. I'm a big believer in interactivity and um learning, understanding learning styles and making sure things are practical and hands-on. Um, I don't like it, it makes such a difference to how people engage with a solution if you have good training.

SPEAKER_02:

Yeah.

SPEAKER_01:

Yeah. I'm thinking of another another big piece of learning. And I can't remember the exact client to give here, but I I got involved in PWC in a in a benefits realization team.

SPEAKER_02:

Okay.

SPEAKER_01:

We were trying to implement uh a new benefits realization methodology as part of mainly ERP implementation. Um we were working on the Gartner stat that says, and there's similar ones floating around now. I think the one at the time said 65% of all ERP implementations fail.

SPEAKER_05:

Yep. I think it's actually gone up to 80 now, if that makes you feel any better. Anyway.

SPEAKER_01:

So there we are. 20 years ago, we come up with a solution to move that number down, and what happens? It goes up. But that's that failure isn't that the system doesn't necessarily technically work. It probably does technically work, but it's about the benefit. You put a business case together of why you want to do this project. The business case says that as a result of doing this, we will save X. We will be more efficient with Y. We'll have all this new information. Okay, there'll be a number of financial or quasi-financial benefits, and in fact, a number of non-financial benefits. What tends to happen on an average implementation is that stuff won't work as you're coming up to the switch on day. You put a lot of effort then suddenly into how do we get this technical product to work and do what we said on the tin? As opposed to, are we making sure we're doing all the right stuff around this system to make sure we realize the benefits? Most of the benefits don't come from the tech itself, they come from the people and the processes you put around the system. So are you doing all of the people change that you need to? Are you setting up the teams and the responsibilities that are going to deal with these new reports that might be coming out that start reporting to the business in a different way? No, all of that change around the system, you've got a tendency to lose track of because it's all hands on deck to make the system work.

SPEAKER_00:

Hey Google, what's the best accounting software for my business? Give it a couple of years, and I bet you she'll be able to answer you pretty accurately. But for now, it's still one of the few questions Google can't give you an answer for. But we can. Take our free quiz and find out which stage products is the right fit for your business. Just head to itsolutions.co.uk.

SPEAKER_05:

And I would also I think there's loads to pick in there. So I love that you brought this particular situation up. And how much because I find it fascinating that I wonder how much of that stat is based on people that actually have a good benefits case in the first place, as in they actually have a clear set of goals. Because a lot of people that I've come across, and I I have this conversation a lot, like they don't actually know what how to measure the output of the system in the first place. You know, and we can talk about how they get distracted as they go through, but almost the fundamental starting point is have you got a business case? What is it that you're looking to get out and how are you going to measure it? And and I have, I I think it's a real shame that people don't think about that more. It's almost what's the starting point? Like what's your benchmark at the beginning and then what's your benchmark at the end? You know, how many days have you cut your month end by? You know, what what's the impact of the team in terms of how that impacts their reporting and their ability to make better decisions? You know, almost those those key markers that you can assess whether you've actually delivered the value for the business.

SPEAKER_01:

Yeah. There's another one, Hannah. You talk about how many days does it take you to close your month end? I go back to my PWC days again, going back over 20 years. We were talking about fast closed clients all the time.

SPEAKER_02:

Yeah.

SPEAKER_01:

How come 20 years later, there doesn't actually seem to be any change. We're still talking to CFOs and so on about how do you close your month end faster. So we quoted back then Cisco Systems who did the virtual close. They closed on day zero.

SPEAKER_05:

Yeah.

SPEAKER_01:

There's very few people still today that close on day zero. It's not the tech that's the issue here, it's the people in the process around the tech.

SPEAKER_05:

Yeah. And and I actually, so so I think um was it last? Yeah, about 12 months ago, Sage brought out their sort of close analysis. So they did a piece of report and they did a report actually on the average close. And I think good was zero to three days. Yeah. So we're not even, you know, very few had that zero if we're being honest. Um average was five days, and I think 10 plus was in the, you know, there was a big chunk in that piece as well.

SPEAKER_01:

Yeah, we we did a back in earlier days of Grow CFO, we used to run a survey every week amongst members, ask them a question and see what they said. One of the surveys we ran was around month end close, and actually it it reflected that pretty exactly.

SPEAKER_05:

Really? Oh, that's good.

SPEAKER_01:

Yes, we we we gave them loads of options, and the the definite, there was a very nice bell curve around the five-day point. And then we said the final option was 10 days or more.

SPEAKER_05:

Yeah.

SPEAKER_01:

And the peak on the 10 days or more was as big as the peak on five days.

SPEAKER_05:

It's bonkers, isn't it?

SPEAKER_01:

We're the set of results.

SPEAKER_05:

Yeah. And and that's what I find fascinating. But I will say, as a somebody that has gone into customers and taking them through that process, it's not actually their ability to do the technology, it's decisions they're making about how they deal with data. So for instance, I'll have customers and process, exactly what I said. So I'll have customers that when I when we first go in, they'll be saying, Oh, we have to wait for all of our supplier invoices in before we close the month end. And I'm like, well, that's what accruals for. You know, having those conversations about each part of that month end to figure out why it's later. Um and and and so it depends on, I think a lot of this comes down to process with month end. Like tech does play a part with it. Don't get me wrong. You know, if you can't access a, you know, if you can't pull a recce out easily or you can't pull reports out easily, then of course that's going to impact it. But a lot of it is how you think about month end as much as it is how what technology you have within the business.

SPEAKER_01:

Absolutely, absolutely, yes. Yeah. And that just brings to mind another implementation that I end up doing. Well, I ended up working, it was my very first job as a self-employed contractor, having left all the consultancy firms, and I ended up on a working on a pair of coal-fired power stations that no longer exist. The changes that we've had in in green energy. But at the time, they were having huge reporting problems. And three-month project was set up to fix whatever was going wrong. Yeah. That it was set off by coming up to year end. Oh, we're on budget, we're on budget, we're on budget. Literally, three days before year end. Oh, we're gonna have to overshoot the budget by this huge amount of money.

SPEAKER_05:

Wow, that's not good.

SPEAKER_01:

And that huge amount of money was such that the parent company almost had to issue a profits warning.

SPEAKER_05:

Wow.

SPEAKER_01:

Because it the ripple effect. So the management said this cannot go on. Our project was to go sort it. What is going wrong with the forecast? Well, the accounting and the forecasting on these power stations. And actually, it comes back to that. Oh, we close off, we've got to wait for all the supplier invoices. That was the issue. Yeah. Think about it. You should what you said it. What are accruals for?

SPEAKER_02:

Why do they exist?

SPEAKER_01:

You should have visibility of the orders you've placed. And therefore, if you haven't got the invoice, you should be able to accrue for them. And that was our issue on the power stations. Now they they obviously you've got these great big assets, they're old assets. We're looking at assets that were built getting on for 40 years ago to have a 25-year life. So they were breaking down all the time. And the margins were such that what nearly every time, whatever the cost of repair was, was insignificant compared to the loss of revenue from not being able to generate electricity. So you had a culture amongst the maintenance team of, well, we've just got to get it fixed. Who are our contractors? Oh, that's broken. It's Sunday night. Something's gone wrong. Get the emergency team straight in here. Oh, we'll worry about the purchase order next week sometime. That was the problem. They got to the stage that there were so many purchase orders missing in the system that hadn't been created. And the the the way the budgets operated, they were all based around commitment rather than so. So you should have been able to see from all the purchase orders what was left in the budget. And you should have been able to flag very early that we're going to overspend this budget. But if the purchase orders weren't raised in the first place, you end up in quite a mess. And I think there are loads and loads of bits of learning from that project. I found that the relationship between the finance team and the maintenance team had broken down completely. They weren't talking to each other. One of the first things that I ended up doing was we we talk frequently in finance circles, particularly in our grow CFO circles, about finance for non-finance people. What did I end up doing is I went around every shift team on the power station teaching them basic commercial accounting. About 200 blue-collar workers. That was fun.

SPEAKER_05:

I bet it was. It would have been interesting.

SPEAKER_01:

Yeah. Yeah. And it comes down to it's not the tech, it's the process. And you've got to have the process in place. You've got to make sure people understand it and follow it. And yeah, we we solved that. We did actually put some tech changes in place to make it more difficult to get work done without placing the order in the first place and so on. But you know, that project told me it taught me an awful lot about well, A, how do you fix a broken relationship? And and B, how do you make a process that should work and doesn't work work again?

SPEAKER_05:

And I do know what that reminds me of a project that I worked on. So similar, it was to automate the AP process. And do you know what? The one thing I learned through that is don't underestimate the importance of a good UI for non-finance, right? Because I think in finance, because people understand the impact of what they do, right? Generally, finance people are reasonably technical and capable, you know, using systems, right? But then they will often, they will be the ones selecting like the PO system, right? Um, and what they're not, they don't normally do is get somebody that's actually going to use the system that is fairly non-technical to actually almost validate their decision. And my my rule of thumb, and I said this literally to somebody last week, is you want a PO system that is designed for the most is the simplest you you know UI that you can possibly get and is as easy to use. And if you make it as easy to use as possible, you have way more likelihood of success than anything. Because it's like with that whole, if you if you make it easy for somebody to quickly say, I've I've just I've asked the supplier and this is how much it's gonna cost, and somebody else can add more and you know, don't expect them to choose a nominal code, they're not gonna know what nominal code is, let alone which one is right. So actually getting the the initial entry and making it as easy as possible is one thing I have learned because I've had a lot of when we've gone to PO rollouts over the years, that's something I have always I've learned. It's why we have we don't just use like core PO systems. We have other partners that do the purchasing process as well that plug into like the core ERPs that we use. Because then you've got more choice around, particularly it's the UI that's the big one.

SPEAKER_01:

And that's exactly it. So that's part of how we solve this problem.

SPEAKER_05:

Yeah.

SPEAKER_01:

Make it as easy as possible for somebody at two o'clock in the morning, yeah, when they've got an emergency going on, to log that they've had a piece of work done.

SPEAKER_05:

Yeah.

unknown:

Yeah.

SPEAKER_05:

And and and I think for me that that's critical. So don't underestimate. So the lesson from this one is don't underestimate UI and how important it is. And you know, if you want to have good budgeting, forecasting, and financial reporting, you've got to get at the front end of the, you've got to get downstream, you've got to understand the flows in because otherwise you're in trouble. So two great lessons from that one.

SPEAKER_01:

And another one that we learned on that one. I really learned the importance of business partnering.

SPEAKER_02:

Yeah.

SPEAKER_01:

Yeah. We had to rebuild the relationship between finance and the rest of the power station.

SPEAKER_02:

Yeah.

SPEAKER_01:

And we did it by trying to put in place regular meetings with business teams, talking about what was going on, talking about, well, we would talk about the financials, but you've got to put them in as much of business context as possible.

SPEAKER_02:

Yeah.

SPEAKER_01:

Understanding what's coming up, what their concerns are, what they need to do. Um, talk to them about schedule maintenance as opposed to reactive stuff. And really, really build that business partnering relationship. Get folk out from behind their computers, out from their Excel spreadsheets, and talk to the business. It is so important.

SPEAKER_05:

I think we underestimate the power of good reporting and data literacy. And I and it literally, this we I'd I um we've got a case study on our website, Anchor Group, actually, and and they cut their month end down from six weeks to half a day to produce their end-of-month reports, to put that into context, right? Which was an amazing achievement. It sounds great. But you know what? The biggest benefit of that was the fact that when they served reports to their contract managers, their managers are now questioning, because they've got that drill-down capability, they're now questioning, well, hang on a second. Why do we need this many bottles of um, you know, polish, I think she mentioned in the case today? Like because they have access to the information and it's in context. Um, and now those those contract managers are able to challenge and budget more effectively and challenge what's been bought and get in and help with the margins because they've got it real, you know, faster information, but more importantly, information in context because they otherwise it's just a number. Like they they don't understand it, they don't get why where that number's come from, what it's made up of. As soon as you give them detail, they can make better decisions. But that's hard to put in a business case, right? How do you justify that?

SPEAKER_01:

Yeah, yeah. And I think back to that power station example again. Another thing that we learned was really listening to what people tell you. It comes back to something we were talking about before. Um, we had this massive problem with overspend. One of the things we realized, well, the budget wasn't worth the paper it was written on. And literally the budget had built year over year by, well, it's mostly last year plus X percent.

SPEAKER_05:

Yeah.

SPEAKER_01:

Yeah. So we said, right, we're gonna get this done properly. We're actually gonna implement zero-based budgeting here. We're gonna start from scratch. So huge, huge communication exercise out to all of these people that don't really understand finance. How do you do a zero-based budget?

SPEAKER_02:

Yep.

SPEAKER_01:

Now, of course, we we got the classic thing as well. Kevin, you're asking me to budget for all of these boiler tubes. I don't know how many I'm gonna need, it depends how many break. Well, hang on a minute. Do you have any history? You must know how many broke last year, how many broke the year before, and the year before that. Can't we have an estimate? Because we realized that actually having a decent estimate for some specifics was gonna be the way you flagged up when you were gonna overspend because you'd know when you'd exceeded the budget amount for that particular thing, and you have to go and ask for more money. Make total sense. Whereas up to then, literally the maintenance budget was just a big bucket. If it breaks, we'll take something out of the maintenance budget to go fix it. Well, actually, no, you've got this bit of the budget is for boiler tubes. You've spent it. Fine. Tell us we're gonna have to find some more money from somewhere. So educating people to do that sort of thing, that that was really interesting. But we did the zero-based budgeting exercise at the same time as the power stations had their major annual shutdown. Right. Because they're high pressure engineering resources, they've got to be shut down once a year, literally taken apart and rebuilt for safety basis. And it's a really intensive work point with the same people that run the budgets that you want to be involved in your zero-based budgeting process. Because we did lots of presentations to folk doing literally everything at the change management handbook we could think about to say, how do we get these people to give us what we want when we want it in the right format, the right level of detail. So we did lunch and learns and all sorts of things. And two power stations. Okay. Power station A seemed in through all of these meetings to be totally on board. Yes, we'll do that. Not a problem. Never. Power station B, everything we suggested, there was a problem. Oh, we can't possibly do that because we've got to be doing that at the same time. Oh, we can't possibly do that because we've got no idea where the data's coming from. And we thought there's no way we're ever gonna get this to happen on station B. And my learning was from that, it goes back to something you were saying about naysayers earlier. That actually, when it came to the deadline day, which station came up and actually gave us what we wanted? It was station B. Because they'd actually thought about what all the problems were and worked out how to get around them. Station A, who just nodded their heads in the right places, were way behind. They'd not got around to doing anything, because they'd never even thought of the problems and the difficulties.

SPEAKER_05:

And do you know what else? I think that's such a good point, is is you know, I always worry if I don't get questions. If I'm delivering a training session, I haven't, you know, I don't personally deliver as much anymore. But if I don't get questions, I know something's wrong. Right? If your team aren't engaging and asking you about stuff, then you know you need to make, you know, you've got to worry about what's going to come after. And actually, questions are not challenges, they are opportunities to make things better and to enable your users. And I think people get worried about questions and queries and challenges. But actually, for me, if you don't have it, I worry more. If if they're quiet during a testing period, I go, oh my gosh, we need to get behind this. Either they're extremely capable, and I mean extremely capable, or they're not doing it. And and I tell you what, when we in nine times out of ten, in fact, probably 99 times out of a hundred, they're not doing their testing. And we have to go back in and and and push them through that process. But like, don't like don't I think that's a really important part is don't see questions, queries, challenges, objections as a negative part, is part of the process that you need to go through. It's it's a critical part. And and and like you say, the one that challenged is actually more successful.

SPEAKER_01:

Yeah. And I I'd flip that to board level as well. So as again, we're back at the power stations. Part of what I did later in the project, because our three-month project became an 18-month project, Hannah. Um we looked very seriously at do we change the maintenance system completely? Because this is where a lot of the problems are coming from. Do we do we and the maintenance system was provided by a small supplier who were pretty much prepared to bend over backwards to give us what we wanted. Uh, versus a big ERP system that had a maintenance module. I'll not mention the name of the ERP system, but most people probably guess. Um so we did a big comparison exercise. We got another firm of consultants in who were experts in the big ERP system. And my job at the end was to go to the management team on the stations, effectively the board, no plant manager, the team of heads over around that particular person, very much like going into the board. So CFO position. And I had to present on the findings of the work that we'd done. And the big learning there is really know your people and who you're presenting to. And I spent days putting the presentation together. And every time I kind of I was running through it mentally and saying, Well, okay, I know the individuals here, I know the plant manager. What's he gonna say when I say that? Then there's the the head of ops, and in any team, there's always a first among equals. So there's the plant manager, who's always the boss, but then there's the five heads of. Well, the head of operations was the first among equals, theoretically all level, but uh he had the possibly the loudest voice, or possibly the the biggest sway in the plant manager's ear. So it was always, oh, what's he gonna say about this? And all the way through the presentation, I wasn't just trying to put facts across, I was trying to build it in such a way that I could direct the thoughts of the people that I knew were gonna be the biggest influencers in the room. And I think as a CFO, that is an incredibly important skill to develop. How do you influence people? How do you guide a presentation in the direction you want it to go? How do you predict what the objections are gonna be?

SPEAKER_05:

Because that is so critical, because there's so many things where people make the right decisions, but they just can't get sign off because they haven't communicated it well enough. And you know, ultimately the board are not in your finance team, they are not in the weeds with you guys, they don't see the day-to-day challenges and the impact, and it's how you get them to understand what the team are actually experiencing and how it's how it's impacting what they receive as well. And that is such a critical skill.

SPEAKER_01:

Yeah, very much, very much. Yeah, you you've really got to spend well, you've got two ears and one mouth. Use them in that proportion, you know gather I don't know what's the right word here, but certainly gather that kind of intelligence about the people around you. Understand them. Very, very important to understand what makes them tick, what problems they have. You can't act as a good finance leader unless you know the problems that are keeping the rest of the team up at night. Okay. Yeah, you turn up at the board meeting, you present the PL for the month and the cash flow for the month, and it's most of the people are just saying, okay, yeah, so what? No. What are the problems that are actually keeping them awake at night? They couldn't care what's in the PL most of the time. They they could care about what's happening with this particular customer that I've got this real issue with.

SPEAKER_05:

And I and and I think that's that's key. And it's also understanding not just like their motivation, but it's also their capacity. And you it came up in that conversation earlier, actually, when you talked about you decided to go through a zero-based budgeting when they had a big piece of work with all the key people involved in them in another in a like an outside project. And do you know what? I I can I I can think of a number of projects that I've worked on where they've picked the busiest time of the year to go live or to to work on a new implementation and not really thought about because it it meets another requirement, but not really thought about. Is this the right time? When when is the most, you know, when is the easiest time for us to do this? Like year end, everybody wants to go live at year end, but year end is it there's so much in it. You you're dealing with all of the reporting aspects, you've got auditors in, etc. Everyone tries to pick year end as a go live date. Um, and I understand it, it's clean.

unknown:

Yeah.

SPEAKER_01:

Because you want to be going in the new system from the the first day of the new financial year.

SPEAKER_05:

Yeah. But it's also in a lot of finance teams the time when they have the least capacity.

SPEAKER_02:

Yes.

SPEAKER_05:

And I think that's something we need to get we need to like as CFOs and as finance leaders, we need to think about it's it's not just when's the most convenient and when's when when do I think it is, but really thinking about the team and their capacity and when it's gonna make make it easier for the team. And and anything you can do to remove barriers is essential. Because, you know, the more barriers you hit, the harder, the tougher the change feels.

SPEAKER_01:

Absolutely. Yes. Make it as easy as you can for yourself. Don't give yourself unnecessary hurdles.

SPEAKER_05:

No, absolutely. Well, um, and I've just realized, and we always do this, Kevin. We are um we are out of time, and that's a really great point. Oh, we are.

SPEAKER_01:

I've just really been enjoying the conversation, Hannah, and and chatting. And I've just suddenly looked at the clock and realised how long we have been going. Yeah, you're gonna have to edit some of this out.

SPEAKER_05:

Potentially. There's been some great stuff in here. Well, thank you so much, Kevin, um, for joining. And and I won't leave it two years next time. It's always fab, and I love our conversations. Um, and if people want to learn more about yourself and Grow CFO, where's the best place to find you guys?

SPEAKER_01:

Uh you find me and Dan all over LinkedIn talking about whatever's coming up in GrowCFO, but go to www.growcfo.net. And one of the easiest things to do, you can join the GrowCFO community free of charge. Take out a free membership. And that at least gets you into the mailing list, the weekly newsletter that tells you about all the work webinars that are coming up and things like that. So that's that's probably the easiest thing to do.

SPEAKER_05:

And for those of you that um have listened to Bocus 4, you'll know that we always put those links in the show notes. So we'll make it nice and easy for you guys to go and have a look at uh the gross the AFO community. Well, thank you so much, Kevin. Thank you for joining me.

SPEAKER_01:

Um thank you, Anna. I've thoroughly, thoroughly enjoyed the conversation. It's been fun.

SPEAKER_05:

And we'll to all of our listeners, if you've enjoyed this episode, in those show notes is also a link with tell us your thoughts. I would really love to get some input on what you value from this podcast, what you'd like to see more of, so that I can make it as valuable for you as possible. So if you've enjoyed this episode, if you'd like to see more along this line, then I'd love to hear from you. Please leave me a note or send me a message on LinkedIn or via email, whatever's easiest for you. Um, I'd it'd be great to hear from you. So thank you to Kevin, thank you to our listeners, and we'll see you next time on the CFO 4.0 podcast. So I always find it really hard to explain to people why they should choose ITAS as their financial transformation or stage partner. So rather than me tell you how awesome we are, I'm gonna let our customers do it.

SPEAKER_03:

So we decided to go with ITAS because when we were looking for a partner, we felt that they not only took the time to understand our business and they knew the needs of everyone on the team or everyone that would be using the system, but they also were very transparent in kind of what they could do, what they couldn't do. And prior to having us, you know, sign anything or make any agreements, they held meetings with us to walk them through our processes and our business so that they really understood everything that would need to be done and give give us realistic timelines as well. And another thing was because we were so new and we didn't have a current system going, um, we were looking for something that we could implement rather quickly, but also do it correctly. And we felt that ITAS would be able to do achieve both of those in terms of yeah, understanding our business and and implementing it how we wanted it, but also doing it in our rather quick timeline.

People on this episode

Head Shot

Hannah Munro

Host

Podcasts we love

Check out these other fine podcasts recommended by us, not an algorithm.

CFO Bookshelf Artwork

CFO Bookshelf

Mark Gandy
FP&A Tomorrow Artwork

FP&A Tomorrow

Paul Barnhurst