Delivering Success: The Blueprint for Effective Transformation

Stott and May: Hello, and once again, welcome to the Stott Exchange Podcast. Today, we are speaking with transformation and delivery specialist Emma Banks. We will be discussing Emma's top tips to focus on throughout your transformation. Emma is a highly proficient delivery professional with 20-plus years of corporate and six years of NHS experience across retail, utilities, e-commerce, automotive, telco, healthcare, and gaming sectors. She has significant experience in program leadership, team management, operations, and strategy in large multinational environments, delivering change through over 20 geographies. 

Her specialism is in transformation startup with control. She has a background in finance, business, case production, spend control, and global spend process, and has completed a master's in Major Program Management from Oxford University in 2017 with a Class Achievement Award for team Management and Inclusivity. 

So welcome Emma. what have you learned from this vast experience?

The formula for an effective delivery approach

Emma Banks: Hi Joe. it's really nice to take part today, so thank you for asking me.

So apart from delivery scars that you pick up along the way on delivery, I think I'll focus today on the delivery approach. So what I've seen, despite the sector, so I've worked in several, as you've said, and the program size or budget. So I've been in big teams and also just me. No organization is actually unique, and no project is either. So normally somebody has done something very similar before, although everyone feels unique. The formula and skills that you need to drive successful delivery are actually quite transferable. So it's not necessarily product dependent; it's how you work. 

So in overview, I think this delivery approach can be divided into three main stages, and they're the ones we're going to talk through today. So the first one is around managed setup, with control, productive delivery, and then managed close down. And all of this is underpinned at the heart of the program on people to deliver the change, which is critical.

Stott and May: Perfect. Well, let's go through it in order, then.

Ensuring the outcome is clear is critical in any program

Stott and May: Let's start maybe on set up. So if we think about setting up the program initially, what do you focus on?

Emma Banks: So the first thing I'll focus on is being sure of the outcome. So this sounds completely obvious, but actually without clarity - a clear view of the tangibles. So things you can touch and feel and measure or sign off criteria right at the beginning agreed as consensus, which is critical at the start of the program; you can never really reach the end with satisfaction, so you've got nothing to hold. 

What does good look like? And people aren't necessarily comfortable to accept the program. And part of this is the managed end. So making sure that the outcome is clear is critical. And also assumptions on that outcome, you've got to eliminate those from the beginning. And actually, readdress those assumptions several times from the delivery process because things will change; they always do. And if you go too fast at the beginning and just jump into delivery mode without clarity and consensus, it will definitely bite you in the end.

Stott and May: Yeah, absolutely. And have you got any examples of the impact of assumption, maybe things that you've seen previously happen?

Emma Banks: If I just take an abstract view. So if you've got a brief, documented brief, that says we must make a chair to enable comfort for 8 hours. So a very specific sentence, but if you think about who needs to interpret that, if these assumptions aren't aligned, the outcome is going to be very different. So from a customer perspective, they focus on comfort. They might think, well, I'm going to have four legs for stability, and I want a bit of cushioning, and I think it might be pink. So that's their view, and that's what they think they're getting at the end of the program. Then you've got a design team that might think, well, people are different heights. we're going to design this comfortable chair to fit various leg heights and people's widths. So they're thinking more tech capabilities.

And then a supplier might think, well, safety first. We're going to add a seatbelt to this seat. and the chances are you're not going to get a pink four-legged up-and-down chair with a seatbelt unless you align on how do you assume the brief? What does it mean? How are we going to measure that? We're done. 

And without that step to clarify, you're never quite going to meet anyone's expectations. It'll end up being a mix.

Start with control from the beginning of your program

Emma Banks: So another clear need as well is to make sure that you start with control.

Stott and May: Okay, so control, I'm assuming here you mean governance. Why is that important from day one? And what would happen if you made a start and then went back and implemented governance retrospectively?

Emma Banks: Okay, without control from the start, you'll definitely run into a number of issues. So part of it of course is governance to make sure that people are involved in the program, they feel accountable, and they're engaged in the right way. But actually, if you drive towards a managed kickoff, you're able to raise the program as a professional brand at the same time. So something that's living and breathing, people can take part in, but it gives you a chance to showcase what it is you're doing. Reiterate yet again the outcome that you're driving in case there's opposition. From a stakeholder perspective, this starts the program with confidence as well, because you're publicly telling people, this is what we're doing; this is how it's going to work. 

These are the control measures and governance that we're going to adopt. And it makes people feel engaged right from the beginning. And also, it actually reduces the risk of non-compliance. So if you've got some people that are only allocated to the program part-time, so they're internal, for example, if it's already been discussed at a wider group in front of their potential bosses that we're doing this, and this is the timing, and this is how it will work, they're more likely, to be less reluctant to contribute. And also another aspect of this controlled start is the transparency and visibility that we need. 

So there'll be big promises that the board expects they want you to sign up to as the program leads in order to approve the budget. But then, as a delivery person, you need to incorporate the views of everyone in that program so that we can understand the constraints that will define the plan. So is there a product launch in the business? Is there an announcement that things need to be delivered by? Is there a commercial date when things need to be delivered by? That will be what the board, sign you up to. Even though the program is constructed of several, objectives, and by making sure that that's visible, we create a level of urgency that we need over the plan. And all of this is encompassed in a managed setup.

Stott and May: Yeah, perfect. I think that's a really good overview of the setup piece. and I really like your metaphor of the chair. it almost reminds me of, I don't know if you've seen it, but the viral video of the engineers drawing a picture on someone's back, and then it being translated across the chain, and it kind of Chinese whispery gets diluted, and changed.

Emma Banks: It happens all the time.

Stott and May: Absolutely.

Emma Banks: It's worth doing the admin for sure, and having those conversations.

The consideration of delivery: Things always change

Stott and May: Okay, well, let's go on to the consideration of delivery. Considering delivery. you've made reference to ‘things always change’ - how do you best adjust to significant change within your work streams?

Emma Banks: So as part of, productive delivery, change will happen. Everyone expects it, and you would have the standard change processes that cope with getting the approvals. But actually, the key to it for me is making sure that we've got visibility of the risk. Now, one of my bugbears is that people see the risk register as an Excel sheet that they need to fill in and tick boxes and it's done, or the program lead will get on their case. Actually, as a delivery leader, it's one of the most critical tools that I have, because you've got people focusing their skills that you're bringing into the program to deliver certain things. But my accountability is making sure that there's an overview of where things overlap, where there might be gaps, and what's going to go wrong in the program. 

So what I need to do is look at how can I mitigate those risks going wrong or understand the impact of that risk early on. And I focus in a program pretty much 70% of my time on risk because they're the bits that are going to need my focus, attention, alignment with stakeholders, throwing in tiger teams to recover it, and looking at different ways of running solutions?

And at the risk of a risk register is that people write everything down and then it's is too long and it's onerous to manage. So you need to have some really simple tools. So have you got, like, a show stopper column that you can put a tick against so that you can filter on the thing are gonna stop the program completely or which ones will affect the critical path further down the line so that you've got time. Everybody's really laser-laser clear on on what those risks are. And part of my management approach every single week with a leadership team within a program is to make sure that people are openly talking about their risks to other people because they shouldn't be a surprise to anyone. And keeping things contained and on an Excel sheet and not discussed at leadership level is a wasted opportunity for sure.

Productive delivery: looking at alternate solutions to achieve goals

Stott and May: What else do you mean by productive delivery?

Emma Banks: So not it's not only aligning the approach which is important because people need to know how they work and how they interact sometimes if I ask a team to say what's your approach, they'll give me a plan or a timeline, then that's not what I mean. So I want to make sure that we're looking at how we operate. So that's something that is an active part of productive delivery.

But actually for me, sometimes it's looking at quick wins to safeguard any risks we might have on the timeline, but really, it's looking at alternate solutions than expected to achieve the goals.

Stott and May: Have you got any practical examples of this?

Emma Banks: If we look at a board objective to, exit a data center, they've got a massive contract. It's gonna cost a lot of money, and we need to get all of our solutions out and moved by a certain date. The project team can respond to that by thinking, well, we need to move all of these items out of the data center and in summer else. Now I would think how do we minimize that risk?

Actually, it's moving less. So how do we achieve moving less? We look at an alternative solution. So is there something else within our capability list, within that organization that does the same job? So actually, we get to not move something, and we delete it, decommission it, and focus use on the other solution. 

Do we need it all together? Can we deliver it in a different way? Sometimes, it's less disrupting for a business to adopt a new solution than it is to move something that's actively used. And that creates quite a lot of tension. From an operational perspective, if you're moving something because people are quite nervous that they don't come up again. So that's what I mean by alternative solutions. You've got your outcome, which is clear, the data center, and then you need to think about, how do I achieve it? What's a different way of doing it? 

And I've actually saved a lot of time and money in different organizations by finding a solution that already exists that they just didn't know about within their organization before. It just wasn't used properly. So, that's something that I'll always examine to ultimately reduce my risk and deliver the promises in the most effective way.

Stott and May: Absolutely. And that sounds like a really important takeaway from that.

What other parts of productive delivery are important to know and focus on?

Emma Banks: So it feels like admin, but it can drive the program that comes So from a communication perspective, you've got to establish it immediately and involve everyone. So there'll always be people that are interested, but there'll be people that can influence and part of the project management toolkit is to create a little stakeholder matrix, but I'm talking about realizing actually doing something about it.

And there's different ways of doing this. So, I would normally adopt a targeted newsletter. So that gives us the opportunity firstly to control what we're saying, and present it in the project brand.

You can reuse the project language, which is quite important if you're trying to drive consistency and delivery, and you can deliver little sound bites as you go. So you might have a piece describing something that you've delivered, or you're going through, but add sound bites in there such as our target is to do this by then, or we've achieved one of five items that we're delivering, and it delivers small bits of information into the reader's brain that I will continue to keep pushing. And ultimately, if you see the same things, and the same data points again and again, it's gonna land. What I don't want is surprises for anyone at the end of the program, so you reiterate again and again what you're doing. What are the assumptions, what's the data that supports this, and how do we present it from a language perspective?

The other thing that I've always done that seems to be quite effective is have an open forum, usually, weekly, which would focus on a different project every time or an aspect of different projects.

Not only does it enable superstars within the individual projects in a program to talk about what they're doing. It enables, the right recognition for the people within that team and to give them the opportunity to explain This is what we're doing. This is why we're doing it. These are the risks. This is the help we need.

And again, reiterates the project language from from within the program.

It gives learning to people within our program on other projects they're not involved in and helps people under to tell you why things are important and why they might be chased by their colleagues. And also, it's a really great forum for the target customer or BAU organization to drop in and listen, and they can learn as well. So these meetings or virtual meetings are always open to whoever would like to join, whether it's in the team, out of the team, or suppliers, because the importance of comms is really critical, and it enables people to ask questions as well, which is important because again, a question asked reduces an assumption, or a risk that could bite you later in the program.

And then the only other thing I think that's important, but still feels admin y, but critical to the program is around the cadence.

So I would quickly establish, a calendar. So these are the things we're gonna do on each day to move the program forward, and these are the people that are involved in each area.

And it's really critical to help people, particularly at the beginning of a program where they probably think, oh, where do I start? It helps, move the work forward because there's levels of accountability that need to come through the the cadence calendars as they deliver through the week.

And it's also a massive opportunity to exploit the BAU governance if it exists If not, we create one to keep the pace of the program. So if you're looking to get a technical solution signed off, have you got an architecture forum how can you exploit the use of that? How can you make sure that the customer organization knows what's coming and they've taken an active part in that decision?

Because they'll be the ones that are using that solution in the future and the same for business, where could we get the decision? How can we involve others that are accountable for this in the future?

And even if we do the running in the program of setting it up, getting all the material presented, we wanna make sure that that accountability on the decision is really clearly shared, and we help it along as much as we can.

Again, it gives us a chance to focus on the project language so that people are saying the same things again - repeat diagrams, repeat updates, so people, you know, manage, the messages consistently.

Stott and May: Yeah, perfect. Nicely covered. And I think some of the conversations we've been on, Emma, with customers of ours recently has been around that comms piece, hasn't it you know - the branding journey, bringing people up to speed on the past, present and future of what's going on in the organization, and that internal comms is very important.

How do you manage a lack of visibility on delivery progress?

Stott and May: So I'm glad you've mentioned that. Now, a question that I'm always eager to hear from people in your position, from your experience and working with the many organizations that you have in the past, have you encountered a lack of visibility on delivery progress from any of the partners you've engaged with and if so, how do you manage that?

Emma Banks: Yep. I think it's a risk on every every program. So lack of visibility is always there. So therefore, you need to be prepared for it. So partly it's, it's the fault of the, either the organization or the program for not engaging with the suppliers properly. So, back to the chair, analogy on assumption.

If there's no lack of or if there's a lack of clarity on scope, how can the supplies ever achieve what they need to properly? They will always focus on their own dependencies.

They'll always focus on their own outcome that it's not their job to check what everyone else is doing. They'll deliver what they think they need to. So, the program needs to make sure that there is absolute clarity on on what's being delivered. Give them the governance.

It's another tool. So don't let the burden of producing their own, you know, look and feel of weekly reports, for example, that needs to be translated, let the suppliers focus on what it is they're there, and they're being bought into deliver, focus on the tech, focus on the change, and give them the governance to save time on recreating the wheel and translating everything, and also it keeps the language consistent. So there'll be a lot of delivery people that accept reports from supplies in all different formats, people calling things different wording, and it's really, really tricky to get it all turned around and coherent on a really short-term basis, and you end up focusing on language rather than focusing on the actual work.

So, by providing governance upfront and clarity, it reduces the risk of all of that stuff and enables focus on the topics, which is, you know, what we're delivering and and how it's coming through. That's really important. The other thing is to always include suppliers in all of the forums. So, There doesn't need to be some hierarchical special program board where only certain people get invited.

The suppliers are part of the outcome, and they need to have their voice in those program boards. So it encourages accountability from my perspective, so if you've got a supplier actively taking part in where they are on the program.

That means they're taking accountability to deliver and taking part in some of those uncomfortable conversations that come up sometimes if people are behind the timeline for whatever reason. It also promotes dependency management and dependency discussion because if a supplier does have a dependency on someone else, they won't care. They'll just focus on, you know, commercially what we've asked them to do.

And a forum like the program board would give them their voice in the room and help reduce the risk for the for the program lead. It’s critical.

Stott and May: Yeah, perfect. It seems for this piece, this 'considering delivery' piece, visibility and clarity are very important, aren't they, with this area? So now let's go on to the close elements of deliveries. So how to close effectively? You mentioned earlier the importance of a managed closure. What do you mean by that?

How to manage closure effectively

Emma Banks: So a managed closure for me is almost a repeat of the managed setup. So you readdress what were we supposed to do? What was the outcome we agreed at the beginning? What were the assumptions we agreed? And effectively tracking where we started to where we ended because, as we've discussed, it won't be the same.

And you need to have visibility of changes that's been adopted by the people that are gonna remain once the project team have left to deal with those decisions that they actively made.

It also produces a traceability for internal audit. So generally in the programs that I'm involved in their big budget, big spend. And at some point, there'll be an internal audit team that looks through the program.

And it could be that the project finishes mid-year and then the audit function kicks in towards the end of the year. So there might be no one from the program around to answer those questions.

And some of the people in BA will feel fairly exposed, and unable to answer those questions unless they feel like they're included and there's a proper a proper handover to that team.

And I think for me, there's an importance about really finishing as well because often there's some residual work, based on on decisions that are made.

Stott and May: Yeah. Can you give an example of really finishing? What's a real finish to you?

Emma Banks: So, if the program is moving to a new, let's say, data center, which is an example we've used, or a new CRM system, often the buzz around the program will be about adopting the new way of working and the new solution, and everyone's training and the focus and all the buzz data points will be, you know, we've got X million customers in the new solution, aren't we brilliant? But actually, you need to look at is there any residual? So we're all looking towards the party, but we can't forget the sweeping up after. So if you go back to the board objective, which is close that data center, it's no good if the program and the operational team are singing their own praises by moving, you know, ninety-nine percent of the solutions. From a board percent from a board perspective, if there's just one left, they're still paying for that data center. So it's like reserving a tanker and paying for a tanker with an envelope in the corner.

And what I mean by really finishing is making sure that there's a plan or there's an agreement of what to do with the envelope in the corner, and that for me is around really finishing because although the business might be, you know, celebrating and jubilant that they've got this new way of working, the board won't care because they'll be looking at duplicate operational costs of something not quite being completed even if the business make a decision to say ‘yeah, we're fine you know, we're comfortable with ninety-nine percent’, you know, it doesn't achieve the objective, so it needs looking at properly.

Stott and May: Yeah, that makes sense. And I've never really thought about, ah, that, of that, 0.01% of things actually being completely wrapped up. It does make a difference, doesn't it?

Emma Banks: Absolutely, yeah.

Managing closure: ensuring the BAU team feels fully back in control of change

Stott and May: Anything else on managed closure? Any other tips or insights?

Emma Banks: So I think there's only a couple of things, really. So making sure the BAU team feel fully back in control of the change. So do they know what they're getting? Which is obviously what we've discussed already. Do they know what they need to do? And if there's any residual work, do they feel empowered to achieve it? 

So sometimes, if we're on this final 1%, do you need a really expensive program team to keep running? No, you don't. You get to a point where there's a managed piece of work that you could hand over to a supplier to finish without the whole governance piece, but you need to make sure that that's documented widely everyone is engaged, and everybody knows what's happening, and it's documented and they accept it formally.

The other thing, as a professional, what I would do is also have the opportunity to say, we've delivered the program. You could consider this or this as a future efficiency program. Based on what you've seen, you've had an opportunity to dig deep across the business and tech functions. So it's always a nice thing to do - to close off with. And actually, there's more you could do if possible, leaves the door open for sure.

Stott and May: Yeah, absolutely. Okay. And then on to the people element of successful transformations. So this is, to me, a very important topic, and I'm sure it is for you as well, Emma. People carry out programs of work, projects of work, and portfolios of work. Why do you think people are so important to your outcome within delivery?

The people element of successful transformations

Emma Banks: Because you live or die on the performance of that person. They might have had a good day, a bad day, they might have been off sick and missed something. They might have a political agenda, but your project can fail on the weakest member of your team. So you could have a tester somewhere that's off-color one day, and they've missed a massive design flaw that means you get to a point of product launch and you can't go live even though it's publicly expected, on the view of that person. So making sure that they're safeguarding, duplicate testing, for example, is a way that you can reduce that risk, but it's definitely on the skill of that person. 

Also, the other thing that can impact a program is, I don't know, a senior exec within the organization might have their own personal battle. They don't want the program, and it's not clear why, but they'll railroad or not make decisions or not turn up to forums that you really need them to. And there can also be quite severe attitudes or cultures within different organizations, which means that people delivering programs can be viewed both positively as someone to help, but also negatively as an outsider. And again, it's all subjective to how people feel, what the culture is, and whether they've had a good breakfast or how they slept last night, but all of their perspectives can impact a program.

Stott and May: Yeah, absolutely. And it still amazes me. Someone like yourself, Emma, from your background and some of the matrix-managed environments that you've worked in and the number of resources that you may have allocated to an overall initiative, how do you manage this? How do you ensure successful delivery of this with people?

Emma Banks: So if someone's in your team, it's easier to manage because you've got more of a personal relationship with them, and you can understand if there's an issue or a problem or a suggestion that's not been taken up or some reason that's driving a problem.

It's more difficult if you've got an opposer, within the organization, specifically if it's someone of influence, which is obviously where we've talked about stakeholder management, you focus on your influencers. So what I do is try and give space and inclusion, specifically inclusion, to people who can influence the outcome. But I would go and talk to them or see them individually or have a way of working with them individually to understand why there might be political behavior, and the driver behind it. 

So I've got direct experience of this. So they're concerned that the project is going to make their life harder on other person. Once all the project team are delivered and gone; they feel like they haven't got enough say in what's happening and it's all right for you, you'll be gone. I've got to deal with it type view, or it's going to reduce efficiency to their team. So there might be a measure, a throughput measure that this project would directly impact. And for them, it's a pain. So they might be feeling under threat that their throughput measures are going to be impacted and it's going to change their performance. It might drive more costs. And I've had examples of all three of these where the program will directly impact their PNL. Therefore at a very personal level, it might impact their personal bonus. So they don't want the project to land, or they want it to land at a later date so that they can feel more prepared for change. 

So you need to recognize that in the stakeholders and give them the credit that they deserve around why they're feeling, or being opposed to the program. And I think also, you've got to recognize the skills from different members of the team and what they bring to the table. So, you can't replace the knowledge, of a BAU person of how they operate. So use it, exploit it, ask their advice, make sure that they're feeling included. But by nature of their work, they're operational. Therefore their skills aren't necessarily transitional, which is where the project team comes in. So you need to find a way to mix and match both. So bring people's opinions in, take it away, replay it to them to make sure you understood it, and then manage the transition in the program - checking back with the operational person every now and again to make sure that they're comfortable. You’ve got to find that balance ultimately.

Stott and May: Yeah, okay. So something that's come up in conversation with quite a few of the customers that we work with is the current trend of organizations being separated by products. Does this then make transformation obsolete? I mean, for example, an organization that's already set up for swift, agile delivery.

Myth-busting in product-based organizations

Emma Banks: I get this all the time. So, we are organized by product now. We don't need transformation help anymore. And actually, it's a massive myth. It actually drives the need to have transformation completely separately. So if I quickly explain the difference between traditional organization and product-based. So some organizations are still traditional in the demand-deliver-run approach. So you've got a team of people that work the business to get, you know, what do you want? How does it fit your strategy? How can we help? They hand over to a delivery team that has quite a wide scope of work, not necessarily specialists, but lots of capacity to deliver projects. And then once they've done their bit, they hand over to a run team who keeps the light ticking over, etcetera. 

So, there are handover point risks because you've got three separate teams working on the same thing and there's no end-to-end ownership. So I can see the reason why people convert to, a product organization. 

But then if we focus quickly on what does a product organization mean, so it focuses people to have specific product knowledge. So you might have nine teams, that know their product in and out, their businesses are actively involved, the ones that need to be as part of that product.  They've got, their roadmap defined, so demand is built in, they can do agile delivery, as you've mentioned, Joe, which means that they're getting deliveries faster, and they've got a focus on run. They can deal with problems effectively because they know their product. But actually, for transformation, this creates a huge problem because they've got very limited capacity. 

So, generally, a product organization has very fixed capacity. You'll find project managers disappearing or being made redundant because you want product owners, which is fine if you reach your target solution and all you're doing is turning the wheels of that product. But the minute something comes along, that's transformation, that organization starts to creak. 

So my definition, and someone else might see it something differently, but my definition of transformation is a wider impact and inclusion of more than one area of the business. So, it's several teams, it's several products, and it needs its own separate and inclusive governance to manage a change. Because a product team will only be focused on their products. They won't care about left or right. And we get back to the assumption risk that we talked about earlier on. So BAU teams generally in a product environment, they don't have time for unusual change. So often I'll talk to teams, and they'll say, yeah, we got 5% capacity for other projects which won't cut it. If it's a legal change that involves changing all the products that the organization has to deliver in a certain time frame, it will fall apart really quickly. So you get a lack of progress because you're dependent on different teams. You've got huge dependencies that aren't being focused on, and it drives overruns all the time. So you need a dedicated set of people with a specific focus on that transformation. And it's temporary; it doesn't need to be permanent, and I don't think it ever should be, but it drives the need for external people to come in, drive that change, and then hand it back to BAU again. So BAU change should happen still on the products, but they need to, understand as an organization you need a transformation layer sort of on the side. So it dovetails out, change happens, and it goes back into BAU again at the end. So hopefully that explains what I think is the fallacy on obsolete, transformation. I hear it all the time.

Stott and May: Yeah, I'm glad, you've gone into detail on that because I completely agree with you. In my eyes, agile is a way of working. Transformation is the movement and change of something. So when people have said that to me, I've been slightly confused as well in terms of it's not one for one or one or the other. They coincide. You can transform and do it in an agile way to get somewhere quicker and more efficiently, but it's not a replacement.

Emma Banks: No, definitely not.

Stott and May: Perfect. Okay. You've got a great tagline, Emma, that I've heard you say a few times in our, many conversations, and it's ‘engaging the best’. It's a very simple tagline. How does a transformation director like yourself go about engaging the best?

Engaging the best: managing and mitigating risk 

Emma Banks: So there's a couple of points, really. So one and first and foremost is around a trusted partner. So a trusted partner for me as a delivery leader is pre-interviewed candidates who can do the job that they're there for only. I've been in lots of scenarios where people send in candidates, they send multiple CVs. You waste time in interviews. So clearly a trusted partner like Stott and May would send me someone that's ready to go. They've been pre-interviewed, I know they've got the right skills. We can get through a simple introductory interview and then get on with the job. So when it comes to transformation, you haven't got time for multiple staged interviews. You want to feel that you've got that trust to get the right person. You've been listened to, they've got the right skills, they're available. Let's go. We don't get the luxury of time, unfortunately, in a program, so that's important.

The other thing to think about is, you need to encourage the companies that you're working with not to fall into the SI risk thinking they can manage it all. And I've seen that so many times. And that's where you get into a recovery program. So often, big corporates, they'll have a systems integration contract with an individual supplier and say, brilliant, we've handed over delivery; they can do it all. And all they need to do is send in a weekly report to someone in BAU and job done. It doesn't work like that at all. And what you need to mitigate that risk is a delivery layer above that SI from a trusted partner to enable, the delivery to continue and that SI risk to be reduced.

Stott and May: Yeah. Okay. Is there an example that you can give on risk created by the absence of an independent layer?

Emma Banks: Yeah. So if you think about, the big, system integrators, they've got their application management services, and they are completely different from, say, their delivery services and they don't talk to each other. 

You might have several hundred thousand people in that organization. The corporate customer might think, well, if we're talking to this organization, of course, they'll get their application management people to talk to their delivery people, but they don't; they're different people in different teams. They fall under different structures. A run structure will fit into a run director, a delivery structure will fit into a delivery director. So you could have two different teams working on the same thing at the same time. That's, uncoordinated. And without understanding, how that works, you're going to run into risk. And also by nature of their commercial structure, there's going to be gaps in accountability. So as I said before, the SI isn't interested in the other suppliers, and they will actively use the lack of coordination as a really valid reason to be delayed. 

So you might have a commercial contract with a big SI and in their terms they say, we won't be doing this, and we're dependent on you, the corporate customer, to get this delivered by them for us to achieve. And it's not up to them to chase the other organization; why should they? But this delivery layer sort of gives that level of cushioning and safeguarding to really rod through the implications of delivery, and make sure that you're avoiding really costly delays because it will happen and it will be delayed. And it's not just, oh, it's a week delay. You've got your run rate per day, per week, and it can be frighteningly huge sometimes for these big, massive, organizations.

Stott and May: Yeah, perfect. Okay, well, I think the best question I can probably end this on, unless you've got anything to expand on, would be for you to describe to us the best delivery environment that anyone should aspire to.

Tips for the best delivery environment

Emma Banks: Okay. So obviously positivity would be great, but not everyone views change as positive. You've got to understand what you're walking into. Are you looking into a company merger, which some people will be delighted about, and others will be devastated because they're losing their jobs? So understanding, being able to emotionally read the scenario that you're going in is the best way, firstly to understand the environment that you're walking into. So you need to be empathetic, get people's views on things, and understand what works well, and what doesn't work well. People like to be listened to, and they should be. This is their organization; we're helping to enhance it. But there's a lot of knowledge there. Understand the history, what went well, what didn't go well, and from there you can create a clear role for people. So where do they fit in the organization? How can they feel motivated around where their skills and experience will contribute? 

Sometimes a person is doing a job, but actually, their key skill might be something else. You need to put the time in to understand people in the team so that they feel, really clear about where they fit in. And if there's a problem and they need to be listened to in order to keep that environment positive, you need to listen to them and let them vent. Anyone can raise a risk as well. Doesn't need to be someone in a leadership position, and everyone in my team will be listened to. I think people need to respect each other's skills. So if you go back to the comment I made earlier around, how are externals viewed? Badly, not badly -  people that are externals need to be really sensitive to how if there's a load of redundancies coming in and then you've got an external person coming in, why, are they there when someone else is losing their job? And the reason is because they've got a specific skill that's required for the program. So that needs to be clear so that people haven't got these wild assumptions about people taking their jobs. 

They're here to do a job for X reason. And this is how it fits in. Within the program, I really like the wingman approach, so look after each other. many, many times in my leadership team, as I've said, we'll always focus on risk and get people to talk about their own risk. I would ask another leader to say, what do you think about their problem? What would you do? Can you go off and talk to each other and maybe combine a view of how you could resolve that problem? And encouraging a bit of pollination means that when the chips are down, and people are up against deadlines, they're more likely to jump into each other's team, even if it's temporarily to get through the work. And that happens, and I've seen that a lot because people know that they're valued, and they're adding value to this particular objective. And one of the lovely points is celebrate together as well. There's nothing like that feeling of getting to the end, and everyone knows where they've contributed, and there's a happy time. Tricky in covid, obviously. But you could celebrate in other ways. But it's really important to celebrate success, to keep people m motivated, and enjoy the change, and look forward to handing m it back to BAU and wish them luck and be ready for the next one.

Stott and May: Absolutely. Well, I suppose if success isn't acknowledged, other than the success itself, there's not much motivation for people to do it again, is there? So that's important.

Stott and May: Okay, amazing. Well, I think that has really well covered, transformations and your tips and your approach. I really like how you've structured it out and given us a start, middle, and end to everything. So I would encourage anybody to get in touch with Emma if they've got questions on anything that's been discussed; I'm sure Emma, you're happy with that, is that.

Emma Banks: Absolutely. Yep. You've got my details through Stott and May.

Stott and May: Yeah. And I think, you know, especially this topic of transformation and innovation, it's a very important time to be discussing this. We're speaking to a lot of people in the industry who are looking to innovate and transform their businesses in a variety of ways in 2024. you know, it's a good time to be speaking about this.

Emma Banks: Thank you. Thanks for having me.