CFO 4.0 - The Future of Finance

247. CFO 4.0 Revisited: Delivering a Successful Digital Transformation Programme with Phil Raynor

• Hannah Munro

Share episode

Send us your thoughts

We’re rewinding to where it all began. In the very first episode of the CFO 4.0 Podcast, Hannah Munro sat down with digital transformation expert Phil Raynor (now Lead Delivery Manager at the UK Home Office) to unpack what makes or breaks a transformation programme — and how finance leaders can navigate change with confidence.

In this CFO 4.0 Revisited edition, we revisit the timeless lessons that still shape transformation success today. From planning and communication to leadership and culture, this conversation remains as relevant as ever for modern CFOs leading digital change.

🔑 In this episode, you’ll discover:

  • The key differences between projects and programmes — and why that distinction matters
  • What defines a truly successful digital transformation
  • The most common causes of failure and how to prevent them
  • The CFO’s critical role in managing expectations and driving alignment
  • How to plan, communicate, and secure stakeholder buy-in for change
  • Why “slowing down to speed up” is the secret to long-term success

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 a 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_03:

So welcome to everybody to this episode of the CFO 4.0 podcast, a podcast where we help you prepare for the future and the changing world of finance. Today on the podcast, I have with me Phil Rayner, who is a successful digital transformation program manager. What a mouthful. Thank you for joining us, Phil.

SPEAKER_02:

Pleasure to be here.

SPEAKER_03:

Phil's been working for over 25 years in the digital sector. He's worked for companies such as Chloe, Jaguar Landrover, Perfume Shop Karen Millen, and Liverpool Football Club, just to name a few. So that's a pretty impressive uh CV, Phil. So how did you end up doing what you're doing now?

SPEAKER_02:

Well, well, I I started out as a copywriter, would you believe? Uh, because of my keen love of writing and like a desperate affliction for puns. Uh I thought, brilliant, let's do it. Let's go into advertisers. That's where I really started off. Um and then I was part of a marketing consultancy that some of the clients, when the web started to take off, started wanting to build websites and it was thrown to me. And so as a sideline, I found it was something I was quite good at in terms of uh building the websites and project managing and something I actually enjoyed. So that's how I ended up in in that side of things, and then I went to the dark side, so I had to put up e-commerce operations for Macklin and then for Austin Reed. Left years before they both went under, so it wasn't the result of my being there, but they uh but they went before it so and then I decided to turn uh poach or is it Gomekeeper, I'm not quite sure, uh, after some time and thought, you know what, I'd rather go and consult brands into how to do this rather than stay with one particular brand and do it. And that was a a good few years ago now, and so that's where I am. So at the moment I'm I'm taking six months off to renew all my qualifications because obviously they have a lifespan, and then also gain other skills. So I'm I'm also doing uh change management, qualification, software to development, and even memory training I'm doing. So uh because the trouble is when you're in the the muck and bullets of the program manager, you just simply don't have time to catch up on qualifications.

SPEAKER_03:

Absolutely. Program management versus project management. There's there's a lot of you know, people use this terminology quite quite often. But what do we actually mean? So what is the difference between a project and a program?

SPEAKER_02:

Uh okay, well it's I I could be church, and it's like people saying, what's the difference between you know a clock and Margaret Thatcher? It's just completely different. But uh I'll get what do you think about because I have people use them interchangeably, and you can't get heads up or frustrated because they're not in the business and they only come around on certain times, uh, so therefore they're not going to be familiar with it. But they're totally different. Ultimately, a program is a coordinated body of transformation activities and projects, so they're all they're all um within one cohesive strategy. So, in other words, it's not just lots of disparate projects, it's they're all with one aim to achieve a specific strategic benefit. So it's kind of like a a program organization is a sort of a transient organization that comes together, you've got a collective of of skills, uh, of skill sets and individuals that come together for the aim of the program, and then obviously once the program's been delivered, they're they're disbanded. And it's more concerned with like the overall direction of achieving real strategic change and growth, both mid and long term and the long-term benefits. So the thing also the major difference between a program and a project is that the the roadmap, the development map, uh is likely to be it's certainly not going to be linear, and in many case, it'll only materialize after the first few projects have been delivered. So deal with a lot of ambiguity as a program manager. There's an awful lot of unknowns out there, a lot of things that you have to find the answers to that don't exist at the present moment in time. So there might be an overarching objective from the business that actually it's almost an endeavour. They don't know whether that can happen, and there's a lot of questions that you need to answer very early on to understand whether that's actually a viable solution.

SPEAKER_03:

In terms of this one, I think that's a that's a really good point just to point out to everybody is that a programme is about an overarching period of change and transformation, which perhaps, like you say, is undefined. And I think one of the challenges is a lot of people look at change as one project. So implementing a software is just one piece. But actually, I guess the question is, is what are you going to do after you've just you've put it in? What is your long-term plan for how you're then going to move that forwards?

SPEAKER_02:

And I think that's the key thing. Yes, you're absolutely right. Because it's the the when it's when it's change, any change in the employees, sometimes it might be a digital transformation, but it might be a new CRM or contact management system. But actually, what that means for them from the day to day is it completely changes their work processes, procedures. They might need new skills, so therefore there's going to be a reticence there to learn it. There's going to be potentially a fear for their role, it might disappear altogether. So the clarity of communication and the management of stakeholders is absolutely critical from day one. I think that's where the program comes in. Whereas a project is more concerned with a defined scope of work. So you'll have a beginning and end, you'll have a specific timeline, specific costings, and it's much shorter than a programme. Usually in months, it's measured rather rather than years. Where a program is much longer, measured in years, and also it deals with, as I said before, an ambiguity. And therefore, it's crystal it's critically important that you move forward with the entire organization on board. So, in other words, it's about having them on board for what you're trying to achieve. Otherwise, it's likely to fail. And also it's not a set and forget. As you rightly pointed out, once the program management team has been disbanded, these changes, and don't forget that some changes might not materialize for months afterwards, need to be managed from uh from a business operations point of view. So therefore, your business change managers needs to be in place to be able to make sure that they're continually embedded uh in the organization and the training is done, the communications are done. So everything that our program did, uh it's not a question of saying, well, there you go, there's the piece of software, away we go. Uh it's about how you embed that change, what it impacts uh in terms of the culture, in terms of the working practices. Uh, and and does it actually derive the benefits in the medium and long term that you thought it would do? So uh it's it's a much, much broader scope than than a project.

SPEAKER_03:

So, what does a successful digital transformation program actually look like?

SPEAKER_02:

What does it suppose that like say how do you live a worthy life? Um it's it's quite um so it it depends on the business areas and the focus uh and the overall objectives. Um digital transformation is is a is a catch-all nowadays, you know, ranging from replacing a uh a legacy contact management system to moving your retirement IT estate to the cloud. So from an overarching perspective, uh it's a clear and unambiguous vision, so uh, or an objective in terms of what you're trying to achieve. And it it needs to have top-down sponsorship uh from senior management and also devolved uh decision making. I think far too often you'll see projects fail due to the fact that management might give lip service to it, or they might have an endeavour in terms of it's something that's quite amorphous. And whilst I say it can be ambiguous at the start, there needs to be clarity of vision of where you're going. So therefore, it could be misinterpreted. Because senior management of only giving it lip service, it's not taken seriously in the wider organisation, so therefore it becomes an uphill battle for the program team to actually engender change. I think an open and blame-free culture is critically important. Again, too many times you're you're set up on the wrong path, which is perfectly natural, and there's a reticence to actually put your hand up and say, actually, this is probably not the right thing to do. So if you have an open, blame-free culture, uh certainly in the early periods you'd expect to embrace failure because that's the point. Whilst you're kicking the tires and you're doing the discovery pieces, it's about refining and no one ever gets it right first time. So that's critically important. I think also from a senior management point of view, you need a clear understanding of the skills required, the resources, timescales and costs. Because we're not talking old school waterfall projects here, you know, where a sequence of tasks is completed to deliver an objective. We're we're talking, as the Americans say, kind of high curbs, wide boulevards. It's about having that frame with which you sit. So the fact that you can make sure that uh you have an overarching boundary, shall I say. And then I'd say we know you have births, deaths, and taxes. Well, I'd say programs encountering changes should be added to those lists because you're never ever going to have a program that doesn't encounter change. Many, many, many changes in various sizes, and that's fine. You know, you set up to be flexible. Um ultimately you need to have the skill sets and the tools and the authority to uh adopt uh it so you're not in endangering the overall uh goal. That's particularly important, I think, is you're having your eyes on the prize. Um and that's not just about focusing on that, it's also focusing on the threats to that overall objective, making sure you have the contingent plans in place. So it's it's really these are generic and deliberately generic, I'd say, because digital, I often say, is it's just a tool of change and it's about how you manage that change. So gets the success of the program or not.

SPEAKER_03:

So we've talked a lot about what does good look like. So there are there are huge, you know, huge numbers of stories of failure, particularly around big ERP and digital transformation programs. So in your experience and having gone in and rescued a few of them and have done what you have done for a number of years, where do you think those failure actually occurs? Where does it go wrong?

SPEAKER_02:

There there are there are many, many points of failure. I'd say it's kind of like a an airplane, really, and you've got 300,000 parts, anyone could go any one point in time, and therefore can have a catastrophic effect. I think you talked about ERP and digital transformation, you can talk about middleware, microservices, cloud migration, data migration. The list is endless. But I think aside from major unprecedented external factors, you know, be that legal, be that political, be that a new competitor coming in, I'd say it comes down to planning in in its many guises. So as my dear old father used to say, you know, measure choice, cut once. Um it's also about realism, I would say. So um it's the art of the probable rather than the possible. So it's very easy for a client to tell you that they want this, they want that. I you know, I want a Ferrari 812. I'd love one. I just don't have the 450,000 pounds to pay for it. So um you've got to be realistic with your expectations from the outset. Um I I'm often saying to clients, um, you know, I'm not telling you what you want, I'm telling you what you have. So, in other words, within the constri constrictions of resource, time scale, skill set, whatever that may be, this is what the possible is. I know that's what you would like, but uh unless we restart the program, unless there's a huge investment uh upsurge, it's not going to be possible. So, what can we do with what we have? So it's about managing that gap between the as is and the to be uh environments and and see what you can achieve. I'd say the third thing is probably clarity the overall objective. So if you don't have that from the outset, where's your North Star? How do you know if you're on track? There is a danger uh in this agile age that people mix up agile with actually just being reactive, and that's not agile in any way, shape, or form. That's just winging it, to put it bluntly. So it's about making sure that you can at any point in time audit and assess the health of the program in terms of the overall objective. You cannot lose sight of that. Yes, uh, in terms of how you get there, it may differ and probably will differ from how you thought would happen, but ultimately that objective needs to remain the North Star.

SPEAKER_03:

And you talk a lot about expectations there. And I for me that's critical, isn't it, in terms of setting those expectations both at the beginning and then reassessing as we go through. So what are your top tips for handling situations where you know it happens all the time? So a CFO knows what can be delivered, he's he's he's in the trenches with the team, and perhaps the CEO or the board don't quite have the same expectations that we say. What are your tips for how you actually approach that situation?

SPEAKER_02:

Well, this is where the CFO, as the senior responsible owner, I guess, in this situation becomes critical because ultimately they should have been given a mandate from from senior management that actually they're as part of the senior management group that they are to lead the program, they have the authority and therefore they're responsible. I think if you don't have that, these are where these situations occur where the communication and education from the senior responsible owner upwards is not working effectively. And this is again where programme management comes in. It's about educating the senior responsible owner in terms of how they how how they uh communicate, how they make sure that they escalate up the path. And it's because you have to understand that their day job is not this, you know, their day their day job is financial management, the financial health of the company, and therefore they're they're completely new to this. So therefore, you you really should be almost their conscience, I guess, from the outset. And this is a game where good program management and programme direction comes in, is where at the very, very start you need to ensure that there is buy-in uh from from the um the the absolute the very top. And if there isn't, then it then it's about resetting. So uh I always say that it's if it's bad news, it's not like fine wine, it doesn't you know mature with age, it's it doesn't become fine, that it is bad news and you need to communicate it straight away. I think there's a there's a almost I'd rather ask a forgiveness and permission, whereas I don't think that's the case here. You need to have the full backing of the organization. So this is where communication becomes absolutely critical. Now, if they are, which they should be, part of the uh overall sponsoring group, then they should be having at the very least kind of monthly uh get togethers in terms of communicating exactly what is going on with the with the with the overall project dossiers, the direction of the program, the health of the program, maybe new risks or issues. And so they there shouldn't ever be an instance whereby they are being hoodwinked by something. Now, if they come along and they suddenly say, right, there's been a change in in corporate policy, um, maybe I don't know, it's been a bad year, so therefore we're gonna have to cut back on budgets, or there's a new competitor in, or say, for example, if it's a retailer, we've decided to divert the budgets into opening 300 new stores or whatever, that's that's perfectly natural and that's fine. It all comes down to how you manage that. And and I come again back to it's about the art of the probable. So I always say ultimately project management is about a triangle, you know, in terms of quality, cost, and time. You can only do what you can do with those resources. So therefore, if there is a dissonance between what we think we should be achieving and what they've suddenly decided to do, then it's a question of resetting expectations and boundaries. And I think that's the danger that is people don't like delivering bad news. And I'm quite happy to be belligerent cop rather than bad cop and just say, look, this is how things are. I don't think senior management appreciates being left out of the loop. And again, senior management they have their own pressures and their own directions, their own strategic um inputs that we're not party to. As I said at the top of the call, it's it's about having the flexibility to be able to build in contingent plans and change direction if needs be.

SPEAKER_03:

So for me, one of the most important things about any transformation project is the partners that you work with. And whilst I'd love to list off a whole host of reasons why it's the perfect partner for your transformation project, why don't I let our customers do the talking for us?

SPEAKER_01:

One really good thing working with ITAS is it's dramatically reduced my blood pressure. Um, obviously, an account system is critical to uh anyone's business. So, innovation data, without that, like every company, we couldn't function as a company. So, you know, it's one of the most critical pieces of software. And any sort of vulnerability we have with that sort of keeps you awake at night. And now working with ITAS, I don't have any concerns about our account functionality and our account system and the usability and all of that. Working with previous partners, um, I've got some grey hairs and uh sleepless nights from that, as I say, because it's so critical. So been an absolute pleasure and yeah, long may the relationship continue.

SPEAKER_03:

So, in terms of you've mentioned the word plan and planning quite a bit. And so tell us a bit about the key things that we should be considering during that that initial sort of planning phase. So, what you know, what are the the key areas to focus on?

SPEAKER_02:

At the outset, I'd say, and this this will be an anathema, I think, is don't rush it. So make sure you've done your due diligence and your discovery first. So therefore you've got a clear and robust strategy. Now, I'm not saying run the program first. At the very start, you will have an understanding of what you're trying to achieve. And then it's about understanding the feasibility of it. Then therefore, there might be two or three different program scenarios that you might have. Taking that time, slowing down to speed up, as the Americans say, at the start is gold. The trouble is, with a lot of these programs, it's it's reactive, or by the time uh decisions have been made to at least start the first phases and release investment for the first phases, that they've already put in place an arbitrary timescale, which is just reducing and reducing and reducing, and therefore it's just about getting on and doing it. It really should be clear in your mind that when uh these initiatives are required and and also I think again, not being part of the program management culture when it's not your your day-to-day, is that there is a there is a a desire, there's a a tendency to kick the can down the road, I think. Uh when there's there's other more pressing day-to-day things, all the time the time horizon is is shortening. So I'd say the sooner that you can actually start to put together an actual plan and looking at uh the the due diligence of discovery, the better, because some organizations talk about being pure agile and saying they don't have to do this, but as I said, agile actually is just uh another word for masking the fact that they're just reactive. So to reiterate then it's it's don't rush it, it's plan properly in terms of what is your overall objective. Now, in terms of plan, I'm not talking a project plan. That's obviously going to come later on, but certainly you should have an understanding that your key aim is to be the foremost educational institution online within the next 24 months and so on and so forth. At least then you have your North Star, and then it's a question of how do we go about it and what's the feasibility of that. Second one I'd say, and I'm repeating myself in a as a broken record, is gain senior management commitment. It has to be from the outset. I think too many of these things emerge, which is again perfectly fine. Programs do emerge where you'll have several, say, projects that are coming together and and diverging, converging, should I say, into a single aim. So therefore they would benefit from having an overall program uh infrastructure around them. But too often these things emerge and actually never get the the senior management commitment. That there's an assumption that it will be fine. And then the only trouble is once it gets to the senior management, at best they'll be indifferent, at worst, they'll they'll just shut it down. And the other side of senior management management commitment I'd say is don't just pay it lip service. They've got to be seen to be leading from the front. It's absolutely critical. So that the messaging is on point from everybody within the programme, everybody to do with that program to the entire organization. Because there's an awful lot of people that will be affected, directly or indirectly, that need to understand clearly what the objectives are. Because in my experience, you'll have certain disenfranchised part of the organization, which is natural. If you're dealing with hundreds or even thousands of people, there are going to be people that don't necessarily buy into what you're you're trying to achieve, particularly if it affects their own area. So therefore, they can make things difficult. The key thing is to have um clarity of purpose and say, this is what we're doing, and more importantly, this is why we're doing it. So at least they'll have an appreciation of why it's being done. I think on that is change management often overlooked. So I've talked about communication, I've talked about stakeholder anxiety, because their job might change uh as a result that anxiety and the hostility, and you bring them on board so through clarity of communication and building up that trust. And it's about firing that message at them all the time in terms of it's for the common good, and this is why we're doing it, this is why we're doing it. That's absolutely critical. And then I'd say probably embrace failure early on. So to my previous point, is particularly in discovery, the whole point of this is to see whether your initial objectives are achievable. And if they're subsequently found to be flawed, you could say discovery's done its job. You know, you just reset and then you look at alternatives, as Confucius said. So was it when it's obvious the goals cannot be reached? Something like don't adjust the goals, adjust the action steps. And um clearly Confucius was one of the first uh program managers.

SPEAKER_03:

Yeah, I I wonder what they were managing back then, to be fair. Um and I wonder what they think of how we manage today. That's the interesting question.

SPEAKER_02:

I've forgotten something. I've forgotten something. I've just thought about it, sorry. Uh and most important thing I always say is smile. Yes. So far too often programs are they're stressful. You know, you're reaching into the unknown, it's it's it's ambiguous, you're facing a multitude of problems. But it doesn't mean you can't have an enjoyable environment. Because can you imagine, say, if it's a two-year programme, you're talking what 40 hours a week, 10 months a year, have two years, and it's two 200 I think my math is correct on this one, 200,000 hours. Um so you know, it should be an enjoyable experience, not dante's inferno. You know, you need to smile, you need to um make sure that people enjoy coming to work. Uh it shouldn't be seen as a threat, it should be seen as a positive.

SPEAKER_03:

And I guess a lot of that comes down to communication as well. So both uh I see one of the challenges one of the things that we see a lot is that actually those projects that are incredibly successful are those that have great communication and or great communicators helping with that project. So I think for me, you know, what are your sort of suggestions for good communication, both both going up and down the chain?

SPEAKER_02:

So you you've you've nailed it that it is about going up and down the chain. I think it's making sure because there's obviously there's different groups of stakeholders. So, for example, from a program, you need to make sure the communication between the projects is critically important from their interdependency point of view. The communication between each project and you is critically important. So, excuse me, it's about devolving um a decision making, about setting the the tolerance uh levels as well in terms of the tolerance of risks and changes and issues, and when that needs to be communicated upward to you and then maybe up to the the sponsoring uh board or the programme board, that's critically important. I'd say also communicating downward. So if there's a there's a temptation when there is a change in policy, uh it's about you just concentrate in isolation how you amend the program, whereas in fact this should go all the way down to the to the project teams uh at the coal face. I think communicating upwards to senior management should be clear and unfettered. As I said before, it's not about trying to couch bad news, it's about giving it them. I'd say one thing, giving them the the truth and and being very, very clear about what this is and what the uh the impact is. But where possible, it's also providing them with potential solutions based on your experience because I think senior management are dealing with problems all the time. Just giving them an extra problem is not going to help. You need to go there and say, this is what we've encountered, these are the potential solutions for your consideration. Communicating with stakeholders. A lot of people talk about stakeholder management when you look at say job briefs and and and uh etc. I think stakeholder management is uh is an interesting one. It should really be called stakeholder communication because it's for stakeholders, people often think, well, I'll do a program report or a quadra course on a weekly or monthly basis, lots of coloured graphs and pretty pie charts, and that's it. But then your stakeholders, particularly senior stakeholders, will think they're being managed, and it's not about that. It's a two-way dialogue, so therefore you you need to be having this this dialogue uh with the stakeholders and making sure that their feedback is coming back and helping shape the programme, not just you telling them what the program's doing. And I think also, as I mentioned before, it's communication with the wider stakeholders, those that are going to be directly and indirectly affected by the change, and making sure that you are constantly communicating because there is a danger. And I've experienced this uh in in certainly in in larger organizations, whereby if there's a vacuum in communication, suddenly the grapevine takes over and therefore rumour supposition suddenly runs wildfire. So it's about making sure that you communicate both both the good and the bad points of the program so that they engender trust. But it's also about communicating the key messages time and time and time again, never deviating from those messages. Because what they're looking to you for, and particularly senior management, is leadership and guidance. If you're ambiguous in what you're doing or unsure of what you're doing, then that's magnified further down the chain. But it's also about continuous communication. So it's not just about these monthly documents, it's about having the human touch. So having project seminars, having workshops, having town halls. It's about getting their point of view because if they don't feel that they can, and this is any level of stake on, if they don't feel that they can have an active input into what's being achieved, then they'll be disenfranchised and disengaged instantly.

SPEAKER_03:

And yeah, I I think I would re-emphasize that. And it's it's about and I would also perhaps say that it's about how you, like you say, how you communicate, because there is a tendency with a lot of people, you know, those that are new to project management to do death by email or death by report.

SPEAKER_04:

Oh yes.

SPEAKER_03:

Yeah. And I think that I think that's just the flag to anyone that is going into or you know, is taking responsibility for helping to manage a project or a program is just think about your audience, you know, your your you know, doesn't have time to read a 20-page document every month. You know, he just wants the highlights. But those that are actually actively involved in it, they may value that level of communication. And it's how you deliver it. And like you say, um, I think that's an incredible point around making sure that you have a two-way street and delivering on that change. So this has been a fantastic conversation, to be honest. And I think there's a whole there's a whole conversation that could come out of this in terms of communication and what does good look like. But just to sum up for those that um are about to start a program or looking at going through a tra you know or a project, what is your sort of top tips for those that are just about to start? What do you what what do you say they they must do and they must do nice and quickly?

SPEAKER_02:

Well, I can send it. I mean, it's it's slowing down to speed up. So it is it is not rushing, but first of all, it's it's it's putting sequential steps in. So it's from the top down. You need to make sure you get buy-in from the top down. I think you need to manage upwards and say to them in terms of expected costs and time scales and resource and skills requirements needed, potential threats and risks to their overall objectives. It's it's about making sure that when senior management sign off that initial investment. I've never been a big fan of just signing off a huge overall investment because actually things change. So I'd say the initial investment to get the first phases done is that they need to be doing that with an absolute open mind, but also with all the facts at their disposal. So that's absolutely critical, I think. Also, as we've just discussed, it's making sure at the other side that you have the stakeholders identified and on board as quickly as possible. As you said, different stakeholders have different requirements of you, they have different agendas, different worries, and ultimately you need to remember a stakeholder is not just a a name on a sheet or you know, plotted on a graph. It's a human being. So therefore, it's critical you get buy-in um from the start. They need to be able to see that you are a clear communicator, an open communicator, but also, and I use this not in the command and control type way, but you are a leader. In other words, that you understand what you're doing, it's in safe hands with you. That's absolutely critical. So that's from the outset is making sure that you understand the resources required, at least at an outline level, you get the commitment from the board, and this is not lip service, you get at least early communications out to and dialogue with the key stakeholders. Because then what you're dealing with here then is Everybody's on the same page. Everybody understands what's trying to be achieved from the outset. And so you start to build that sort of program management culture. Because as I said before, it's it's a transient organization program management. You get a a lot of disparate skills that come in. You get a lot of externals, such as myself, you get people seconded onto the program. And therefore, it's it's a completely new organization that you will have your own culture within that. So it's about how you can quickly meld that with the the business at large and making sure that you're all going in the same direction. Because I think looking it's easier to look at it from a point of view of why do why do projects fail. And I think it is because it's not commit clearly communicated at the start. I think it is because you're restricted in terms of what the overall scope is, in terms of the amount of resources you have, the skills that you're allowed to employ, and therefore a a a warning flag for me is when you're starting to cut your cloth before the main programmes even started, because you then have to say, well, hold on, this needs to be reset because we're already we already have unrealistic expectations or we simply don't have the resources with which to achieve that. It is human nature to just say, just do it, but that's unfortunately not the case. I always say, you know, I don't have a mid magic uh wand or a crystal ball, I'm afraid. I have looked on Amazon, they don't exist. So therefore you have to be realistic from the outset.

SPEAKER_03:

Actually, I think so. Just to sum up, I think brilliant point. So communication, get your stakeholders involved at all levels, be realistic about what you can achieve, and don't just jump in the deep end. Make sure you you know exactly what you're jumping into and how how high the diving board is, as it were.

SPEAKER_02:

And I could even bookend that and say, actually, if you do find yourself in trouble and there's a cognitive distance, isn't there? You say, well, we've got to carry on now. We've spent the money or we've burned the resources. Actually, you need to be brave enough to say, let's stop. Uh that is always the option. It doesn't help if you're going on, and I've seen programs, non-mine, not mine, I might add, where uh the program was already dead in the water even before they started to do any form of development because of a new MD and new technology that was available, but they still ploughed on with it. You should be brave enough to put your hand up and say stop. And stop doesn't necessarily mean throwing everything out. It might mean just uh amending uh the strategy, it might be uh reformatting what you already have, but ultimately it's it's being brave enough and also having the support of senior management to be able to do that.

SPEAKER_03:

Yeah, and that comes back to your your point right at the beginning, which is creating that culture where it's okay to raise problems, raise issues, you know, you're not hiding things under the carpet. So and I I think I would echo that as you know, the best projects that deliver well are those where you can address problems quickly, where everyone knows exactly what's happening and where the challenges are, and that you have the resources to deliver on that.

SPEAKER_02:

And the devolved, um, devolved responsibility to be able to make those decisions. Um, because ultimately, and I and I always stress this, we're all moving in one direction. We are one team. You know, I never say I, so it's always us, it's our team. We're not battling against each other here. We're all trying to achieve the same aim, which is the success of the business. So very much so.

SPEAKER_03:

Fantastic. Well, thank you so much, Phil. That was a brilliant, brilliant chat, and thank you for your insight and for sharing that with us. It's been incredibly useful. So if anyone could do with your help and guidance, either on a project or a program, how what's the best way for them to get hold of you?

SPEAKER_02:

Well, I'm just rebuilding my website as another thing I'm doing over these six months. Uh so probably the best thing to do is to is to contact me at uh fill at philrayner.com uh if they need any help or guidance, and I will do my best um to help them out.

SPEAKER_03:

Brilliant. Well, thank you, Phil. Thank you so much for spending this time with us going through this. You know, it is a key part of the CFO role. Um so thank you for sharing your experiences and advice. And uh hopefully all sleep. Absolutely. So thank you everyone for listening. If you want some like Phil said, if you want to find out more, send him an email or jump onto his website once it's all up and running. Please do watch out for the next episode of CFO 4.0 and we'll speak to you soon. Thank you. Thanks for listening, and I hope you enjoyed this episode. I actually have a favour to ask. Reviews and shares are incredibly important to the success of any podcast. If you could spare a minute to share this episode on your social network or leave us a comment to tell us what you liked, I would really appreciate it. Feel free to tell me what topics interest you most. I would really love to hear your feedback. Don't forget to check out our latest CFO 4.0 webinar on budgeting and planning in a volatile environment. Click the link in the show notes or visit www.itassolutions.co.uk and click on our events page for more info and great content. And if you want to reach out at any point to tell us what you like, to tell us what we can do better, then feel free. Just email us at cfopodcast at itassolutions.co.uk. Thank you and speak soon.

SPEAKER_00:

Now, for the one million pound question. What is the best finance software for your business? Is it A. Sage 50? Is it B Sage 200 Standard? C, Sage 200 Professional, or D. Sage Intact. An impossible question to answer without a lifeline. But we have the perfect lifeline for you. Our free quiz. Which stage product is right for you? We'll tell you which product is the best fit for your business in just five minutes. All you need to do is head to www.itasolutions.co.uk and answer a few simple questions.

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