Lessons From 70 Implementations: What We Know About Making Process Work

In this first episode of Working Process, Liam O'Neill and Sam Lewis introduce themselves and explain how bpmd evolved from a three-person startup operating out of a Surrey attic with a single client, into a specialist transformation partner working with global organisations including Sony and the BBC.

This is a candid conversation about what it actually takes to make process and transformation work land as real business change, not just activity.

They discuss:

• How bpmd found its identity after years of muddling through general project work
• Why they moved away from preaching process toward asking better questions
• What they call the process migration trap and why moving 2,000 models into a new tool rarely adds value
• How data analysis has become central to the work, and why accessibility is no longer the bottleneck
• The reality of change fatigue in large organisations and how a multidisciplinary change maker function can fix it
• Why adoption is consistently the harder problem, not the technology
• How they helped Lego's process team go from lacking purpose to being pivotal in one of the group's biggest ever internal transformations
• Where AI fits in, and why strong process context is becoming more critical, not less

This is an honest and grounded conversation about what good transformation work actually looks like from the inside.

If you lead process, transformation, IT, enterprise architecture, data or operations and you are accountable for turning strategy into execution, this episode is for you.

Host: Liam O'Neill, Managing Director at bpmd
Host: Sam Lewis, Director at bpmd

Transcript

SPEAKER_02 0:00

Welcome to Work in Process, a BPMD podcast.

SPEAKER_01 0:03

We are Liam O'Neill and Sam Lewis. This show is for leaders who are responsible for improving how their organization actually works. If you lead process, transformation, IT, enterprise architecture, data or operations, and you are accountable for turning strategy into execution, this podcast is for you.

SPEAKER_02 0:24

Across the organizations we work with, we see a lot of investment in teams and tools, in programs, different softwares. You get dashboards built, processes modeled, programs launched, but that doesn't always translate into real business outcomes, into bottom line results, into something you can point your finger at and say, yeah, that's worked.

SPEAKER_01 0:46

In each episode, we will speak to the people building change capability inside complex organizations. We will explore how they structure their teams, how they use data to understand how they actually work, how they drive adoption, and how they ensure insight turns into action.

SPEAKER_02 1:02

As this is a guest-based podcast, we have a guest today. And in this first episode, we introduce ourselves and explain how BPMD evolved from a small startup into a specialist transformation partner working with global organizations.

SPEAKER_01 1:17

We talk about what we call the process migration trap, where organizations become consumed with the moving thousands of legacy models into a new platform without first questioning whether that content still serves any meaningful purpose.

SPEAKER_02 1:31

We reflect on the reality of change fatigue inside large organizations where operational teams are repeatedly asked the same questions by different teams, yet see little structural improvement as a result.

SPEAKER_01 1:45

We discuss the difference between implementing a tool and realizing value from it, and why adoption consistently proves to be the real bottleneck rather than technology. And we touch on why process context is becoming increasingly critical as AI and automation move to the center of transformation agendas.

SPEAKER_02 2:01

If you are serious about building a structured, data-led and outcome-focused approach to change, we're glad you're here.

SPEAKER_01 2:09

This is work in process. If you get any value from this episode, please subscribe. You will get a brand new episode before anyone else. The views and opinions of our guests are their own and do not represent those of the company.

SPEAKER_00 2:21

How did each of you first get involved with the business?

SPEAKER_02 2:25

Go back about 10 years, I was coming straight out of university, and I had no idea whatsoever what I wanted to do. I was applying for just about every job that popped up on the jobs portal. And I didn't know whether I wanted to be in a corporate world, be in some kind of crazy manufacturing local space. And because I didn't have an idea, I wanted to try so many things and get a little flavor for what life's like. And I wasn't a very corporate person. I wasn't very polished. And startups really appealed to me working in a smaller organization. So I ended up looking for a startup consultancy. I didn't care where it was in the UK. I was looking in Manchester, Oxford, and then there was this one in London. And I just popped down for the interview to London for the day. I met Peter, the founder, and uh the rest is history.

unknown 3:10

Wow.

SPEAKER_02 3:11

It must have changed a lot in the 10 years then. Yeah. So I mean, when I started, it was three of us in his attic. Um, it said it was London. It wasn't London, it was middle of Surrey. And yeah, back then we only really had one client. We used to go to Copenhagen, work with Mersk a lot. I was barely ever actually in London. And really, we're just getting by. Whatever kind of projects came along, whatever kind of work it was, we just did those. A lot of it was just project management. I spent about two years taking notes, and there wasn't really an identity though. We knew we wanted to be in this process and transformation space, but exactly what it was that we did that was unique, that wasn't crystal clear. And yeah, over time we've grown, we've shrank, we've grown again, and we're on a really nice upwards trajectory now. But we're, I think we're in a different space. But we know who we are, we know what we do. It's not a generic improvement, it's not a generic let's do process. Instead, it's working with companies to actually build out this really specific skill, this really specific capability in a really tried and tested way. And yeah, I think knowing yourself as a company is a really interesting space to be in from infancy, kind of muddling around and just trying to get by to where we are now. It's a really big step in a different direction.

SPEAKER_01 4:20

That's really cool. And how about yourself? How did you get involved? So after I graduated from uni, I went to Austria and worked as like a shallow host, snowboarding and cooking and cleaning. And then I came back from there and kind of thought, well, I should probably try and use my degree to uh yeah, to get a graduate role. So I took the interview with BPMD, and so this is about seven years ago, and yeah, I was really impressed by Peter and the being sold the idea of working for a smaller organization rather than joining a massive corporate and being a really small fish in a big pond. Smart call.

SPEAKER_00 4:53

Great. Well, you were speaking a little bit about the specialism and how that's evolved. I think that's a real strength of BPMD. It's very specific. I mean, how has that evolved? Is it through failure? Is it through we need to go in this direction? Is it more a success that we're gonna double down on this thing, we're gonna double down on this thing? How's the narrowing of your specialism more played out?

SPEAKER_02 5:15

So I think at the outset, we've always been called BPMD. It's always been about establishing a discipline in organizations around how they look at, manage, and essentially take care of the processes in the company. But it started almost dogmatic. Used to go to companies and preach at them why they need to take process serious, why you need to model everything out, why you need to be sitting on top of it, good governance, be managing that. And it was always us pushing. And look, there's a lot of benefit you get from doing process work, but people don't really want to be preached at. To instead, what's the challenge that you're facing right now? What is that problem? Does it actually make sense to look at the underlying way your business works to solve that? And in some cases it doesn't. One of my clients, they have a challenge in one of the business units, sales isn't high enough. Look, you could look at the processes around sales, you could look at you know what they're doing in terms of finding ops and translating those and going through the pipeline, but that's not really going to solve the dial. That's not really gonna solve a problem for them. You know, the big challenge there isn't that they've got a bad sales process. So the that specific business unit is in a really difficult market right now. And a lot of the big clients are moving away from that kind of model that they used to work on. So you can do process all day though, but you're not solving the problem. So we've really moved from that kind of dogmatic do process because XYZ to tell us your challenges, tell us what's not quite working in the business, what's happening around transformation, what's happening around getting people to work in a certain way. And then we can suggest how some of the trends, practices, and kind of new technologies in that process, in that transformation space, might be able to help solve those problems. And then the other big thing is it's moved from a very, I'd say, manual and kind of 2D view of process. You'd have a model, you'd have information behind it, you do some cool reports, fine. But it's just a picture. You just at the end of the day, you're drawing out the way you work, the way you want to work, and what's a gap between the two. Fine, okay, cool. Anyone can do that. You can do that on a cool tool, you can do it on PowerPoint, you can do that on a big piece of brain paper on the wall. Right. You're not bringing anything too different, too specialized there, as much as it might help with reporting and that quality management side of things. Um, increasingly what you're seeing is data playing a much bigger role to a point where almost all the projects we run now, yeah, there's a modeling element, but there's a big data analysis element. What's the actual underlying data saying about a process? Was it actually a bit broken? Where do you actually need to focus? You know, we did an improvement workshop a couple of weeks ago and we came up with this fancy little acronym for uh spotting some data trends. And I think it was something like stop it was. And we showed it to people in the workshop, and everyone was going, But we don't do that. You know, we don't have too many approvals, we don't have it broken at this point, we don't have too many touches. And we brought up the data, and we bloody well did. You know, there's some there's one where it was like 28 approvals for this one little claim. And the general trend is you know, this is the way I feel my process is working, these are problems I think I've got. But when you look at the underlying data and it might be completely different to what people are feeling, but it might be pointing towards a real problem. So we've moved towards always using this data arm and always moving it towards this quantitative kind of analysis piece. It really just helps bring a lot more depth to that discussion.

SPEAKER_00 8:13

Yeah, yeah, that's interesting. So people will have some resemblance of a process and some understanding of what the problem is, or an initial version of I think this is the problem we have. And my experience anyway is they often have a lot of conviction of like we have this problem. And then your initial consultative conversation is to say, let's look at the data, and then what does the data tell us? And then make decisions based on that. Delving into the data has become a bigger part of the last five years, last 10 years, the overall.

SPEAKER_02 8:40

Definitely in the last five years, uh the technology's trended in a way, but it's made it way more accessible as well. So um, there's different flavors of it, there's things like task mining, but really what you try to do is look at your system, see if things are actually done. And that's become so much more accessible in the last few years. It's been around for years and years and years, but it used to be a pain in the ass to use. And it's got to a point now where it's pretty accessible. So, and you're seeing that accelerate. It's getting easier and easier and easier and easier. So it's getting to a point now where you don't need really heavy data engineering, really heavy data science capability in your team. It's a skill you can learn. You don't need to spend 10 years building that experience, building that really technical skill. But you're still seeing this big gap in the market where it's getting easier to set it up, to look at the data to get into it. But then there's this massive gap in terms of setting up and looking at it to actually getting people to do stuff with it. So even though it's accessible, loads of companies are not making the progress they need with it. Lots of companies get into this space, they invest, they build dashboards, they do the setup, but then they get absolutely nothing back from it. And it just sits there unused because there's this big gaping gap between, hey, something's a bit broken, someone picking that up, taking ownership for it, and actually doing something with it. So as much as I love that it's getting more accessible until that whole gap of not just setting up with data, but taking it through to an actual change gets bridged, it's not something that companies are going to get value from. And that's kind of increasingly becoming our role, bridging that gap and helping companies bridge that gap. That's interesting.

SPEAKER_00 10:06

Sam, do you guys operate as the accountability element or the trans how would you describe it? Is it is it accountability that you provide or is it more translation of the data and an action plan? Or what role do you serve there?

SPEAKER_01 10:20

I think it depends what capabilities the organization that we're working with needs. So in some cases, the client wants help. They can do the technical setup. They've got quite a straightforward technical setup for the process mining. So they don't actually need help with that aspect. It is purely the can you translate this data insight into some form of change or some form of improvement. Whereas in other cases, they're really set in that and they've got a team that manages that and they have really good connections between, you know, with people on the shop floor. So order managers in South America, if they want to change how they're working, they have a connection to that and they can do that. Where they want help is doing the data analysis and finding the things to improve. So it's either a little bit before the improvement or, you know, during it. So it really depends.

SPEAKER_00 10:59

Yeah, yeah. So regardless, they need yourselves or internal team or a combination to turn that data, which is ever more easily accessible or ever more easy to mine that data and turn it into an actual plan and then accountability to make sure that plan actually solves the problem they thought it would. Makes sense. And then the shift again is to SAP Signavio. So how did that come about? Like where did that specialism come from?

SPEAKER_02 11:22

Yeah. So uh what we we've actually just done a little bit of a rebrand, a reposition. We've always been BPM generalists. We're in the process space, we're in the transformation space, and we don't favor any specific tool. In reality, we've done about 70, 80 Signavio projects now, and we're not anywhere near that count on any of the other tools. And they all do basically the same thing. Some are more competent than others, some are really polished, some less so. But it's the same core concept of draw it where you want to do, analyze how you're doing it, bridge the gap. Same, same stuff, different wrapper. Um, where it kind of started was years ago. Signavio was just a startup. It was a cheap, lightweight tool. It was a really pretty process modeling tool. And Mersk just happened to get it for that project I mentioned that we were doing 10 years ago. And it just kind of snowballed from there. We just built a really good relationship with a Signavio team in the UK. And then there's just a lot of projects that came through that pipeline, came from Signavio. I mean, at one point, I'm pretty sure we did every UK implementation for it in the year 2017, 2018. So we've got this massive Rogues catalogue of um Rogues Gallery of all the different companies who've helped get going on it, from you know, 200 people, little government functions to you know your BBCs and your Sonys of this world. And I think what's really nice is we've got this really good partnership with SAP, but especially with the business transformation management, the Signavio team. And there's this trust. Well, it's not that hard a software to implement technically, but to get companies to implement it and then get value from it, that is hard. It's for different capabilities, you know, the data, the soft kind of quality side of things, and the actual making change happen. And because we've proven we can do that, because the 20 or so companies we helped implement it for, and all the other ones we've done since then, have been really good users, really good advocates for it, people who are actually getting value from a platform, then what you build is a trust. So Signavio, they'll work with us and we can help more clients get onto that platform and do it successfully. And I should say we we work extensively with Signavio, but for our others, with Solonis, it's also a really strong tool. That's got a similar challenge of bridging the gap between data and actually doing something. And we're increasingly helping some people on that journey as well. So yeah, I think it boils down to trust. It's hard, but they trust us to get it done.

SPEAKER_00 13:27

Yeah, that's great. It's really good. So as you have found your specialism, one of the challenges is always taking a step back and keep staying general because inevitably you will get inquiries for the thing you used to do, the more broader stuff. And the discipline of a consultancy when choosing a specialism is to commit to the new specialism and the new focus long before they've got a full pipeline of opportunities to do that. And it's really challenging because there's there's always people that want you to do the thing they know you for that you did five years ago. Has that been an experience you've had as the discipline of specializing?

SPEAKER_01 14:00

So, in one aspect, yes, in the sense that we speak to people in large organizations where their position is that they are, say, leading a process practice or you know, they're the head leader of governing the process models effectively in the organization. And they want support with, hey, we really we're struggling to get the business to buy into this. And what we want to do is just model loads of processes in a particular area. And we all we want, we want you to come in and make everything look a bit prettier in the modeling environment. And we are trying to push them, you know, basically reframe the question in well, but what's the purpose of your role really? And what's the purpose of the team that you've spun up and the the tools that you have around process management? Because until they answer that question, we can help them model processes, we can help them um try to optimize. But if they aren't really trying to answer the strategic questions that the CEO or the CFO are bothered about, then they're not going to succeed. But they sometimes have the fear of, I suppose, trying to answer those big questions because they're not used to doing it and they're more used to getting on with the process modeling work in their own little silo and then calling that a successful year because they've got coverage of 80% of the business with process models. But then if you challenge that and dig beneath the surface, has that affected the bottom line in any way? The answer unfortunately will be no. It might have served some compliance purpose, but they could have done more. So it's trying to sometimes push the conversation to be actually, have you looked at the bigger picture, you know, rather than the smaller thing that you're trying to aim for?

SPEAKER_00 15:25

And I guess by having those kind of conversations, the leadership team, the C-suite, are typically more bought in or more or happier with the direction or the results. Is that your experience? Absolutely, absolutely.

SPEAKER_01 15:37

It's just that the process specialist that you're talking to, it's completely understandable because that's the way the industry's been for 30 years, that that's a this difficult pivot for them to make. But they're obviously massively grateful that we probably challenged at the start. And maybe they'll go away for six months and be like, you're talking too strategic, too big a picture. And I just want help with making this process look more pretty. Um, but then in six months' time, they'll realize that, yeah, that didn't get me anywhere. That wasn't beneficial. You're right to have challenged that.

SPEAKER_00 16:00

Yeah, it's interesting because that's a conversation we have with consultancies a lot, especially with inbound inquiries, where it wasn't that they didn't do a lot of work to get the opportunity. And normally those inbound inquiries come with a really specific ask. Can you help us do this specific thing? And as the expert or the consultant, you often look at that and go, we could do, but I'm concerned why you're asking me that, because I think you've made some decisions that I don't know are the right ones. And so there's a kind of two schools of thought. One is that we'll just do the thing and then we'll help them adapt their strategy later. Then others will choose to do what you're describing, which is to go, well, hold on, let's figure out why we're doing what we're asking, whether it's the right thing at all. Is that have you done both? Have you always done the latter? Have you found an advantage to one?

SPEAKER_02 16:42

Yeah. So historically, we took anything that came our way. And that's definitely a misstep because ultimately you can make a pretty landing page, you can model an error, you can do whatever you want to do. Solve that specific request. But if it's not going to affect the overall goal, you're not going to actually work towards reducing the overall cost, increasing the overall sales, ticking that box that sits on the CXO's actual objectives. It's a wasted investment. They might have a really good experience working with you, be really communicative, have a really good collaboration, deliver what you agree to deliver with a plomb. But if say you go to a doctor's, you know, and they you've got a cut in your arm, also brought your Fibia, and you get this amazing doctor, super friendly, puts an awesome bandage on it, have an amazing experience, but then you've still got broken fibia. You know, it's it's still broken. So increasingly, what we're doing now is pushing back. And people say they want a nice UI, a new landing page, a new model. Yes, why? Why do you want that until you get to the underlying root cause? A real example, some we're working with a company on some enterprise architecture, which is more systems modeling, that's less Signavio, that's a tool called Lean IX. You draw your systems, you can see how they touch each other, how they move. And there's a challenge around adoption. They want to do certain reports, let people see things in a certain way, certain audiences. But if you peel it back a few, a few layers, you know, why is that happening? Comes back to adoption. It's about making sure the business are actually looking at it. But why do you want to do that? Well, it's different for different audiences. We've got a senior acquisition landscape, we've got more junior landscape where people, we want people to proactively engage in software decisions. So it's different root courses. So you can make these pretty reports, fantastic, you know, makes it easy for people to engage, fine. But really, what you're talking about is making sure it's a strategic item in the kind of acquisition and merger landscape. And there's a separate item about having a mechanism for getting the broader business to engage in IT decisions, buying new systems, getting people to adopt them, getting people to work with them. So it's two very different use cases. You know, the ultimate projects to solve those objectives. It's not about creating a nice report, it's about education and adoption in the business.

SPEAKER_00 18:35

Well, that's great. Well, credit to you to move in that direction as well. And I guess the short-term pain is you'll get clients say no to working with you initially because they just came for the shiny object thing they're excited about. But have you seen the benefit of clients' return six, three, six months later going, can we? Can we have the actual conversation?

SPEAKER_01 18:50

Yeah, definitely, definitely. And I think you you see it more in the where they've listened eventually, and then you you follow through with probably the more strategic approach and it's better. I mean, one of the really classic examples is that a company is on an old process management tool and they have bought SAP Signavio and they are really stressed about the fact that they've got 1,500 or 2,000 process models in an old tool. And they're like, guys, we need to move these over into the new system. I mean, big job of that. Like, yeah, it's a lot of content. And what we try to do then is reframe it, you know, they'll say, okay, PPMD, how can you help us to get all those 2,000 over? And reframe it and say, well, number one, what are those process models doing? What purpose do they serve? Why do you have them? And number one, that could affect really, do you actually need them all to be moved over? And the bigger question, if you move them over, are they still going to add very little value to your organization? So do you need to actually reapproach the way in which you do process management entirely? And then we've had really cool conversations with clients where in the end, very little of that old content is moved over and the project actually becomes a refreshing their approach to be focused more on all the things that Liam talks about, like solving the business problems as opposed to just creating content for the sake of it. And they're really cool because then they go from having this big thing to do, this horrible, you know, like they're really stressed out about it, to actually, okay, this is exciting. We can start afresh with more purpose and do it in a way that's solving a problem with standardizing the way in which they manage expenses or standardize the way in which they do procurement rather than for the benefit of reducing cost or et cetera, rather than just, yeah, creating pictures for the sake of it.

SPEAKER_00 20:15

Yeah, big time. We had exactly the same with a client where they had a bunch of contacts in a CRM system and we recommended a slightly different one. And they said, Well, how are we going to move the 3,000 names across? That was the question is, well, this is seven-year-old contacts. They haven't opened an email in seven years. Why move them? So yeah, that was the decision eventually. That's great. So with the clients that you work with, are they the first consultancy of your type that they've worked with, or do they come to you after they've worked with somebody else that's not gone quite right?

SPEAKER_02 20:41

Or combination, or yeah, I don't think there's too many consultancies who are in as explicit a niche as we are. The kind of process space, especially in the UK, wasn't massively mature a few years ago. And thinking's evolving, it's growing in that space. In the UK, you've seen a lot more, a lot more companies are trending to this, uh, wanting to establish this capability. Netherlands, Nordics were a little bit ahead on that front. So it's not that these companies have worked with a process consultancy before to set up that process, that transformation team. But we do work in obviously working with enterprise organizations. They're not new to consulting. A lot of programs we do know with Signavio is SAP is doing a big S4 transformation, but changing ERP, changing the whole way the business works. So you've got one of the big consultancies in, you've got Deloitte, KPMG, TCS. And, you know, we talked back to that segmentation about different types of consultancies before, you know, the transactional, the strategic and the middle of the technical delivery. And the very much technical delivery projects, maybe with a little bit of a strategic front end. But a lot of those companies don't have that specialized skill in getting the process team, the transformation team, set in and set up to be sustainable with the right tools. You'll find this S4 project being done. And what we've done is we've created a ton of content. We've got loads of models, they've got some dashboards, they've got stuff that tells you how you're going to be working. But then there's this appetite to say, hey, okay, we've got all this content, we've got this tools, we've got this ability to Make ourselves a bit better, work on our company. How do we then take that forward and set up so we can do that ourselves, do that sustainably? And that's really ideally where we come in. So either as part of the S4 project working in tandem or off the back of it, take those assets, take the team they've got, take the people who are um showing a propensity for it and put them into a place where they can then go and model their own processes, analyze their own data, make their own business work better without having to rely on us, without having to rely on a Deloitte or another third party in the long term. They can stand on their own two feet, that kind of thing? Definitely, definitely, yeah, yeah.

SPEAKER_00 22:30

From all the conversations we've had, it seems like those that are trending consultancy overall seems to be towards implementation and allowing the client to stand on their own two feet. Those that are leaning into that and going, we don't need to be here forever. We want to help them implement initially and then stand alone, um, seem to be succeeding. Has that been your experience too, of moving in that direction and actually clients respect that, appreciate that self-sufficiency that you're creating?

SPEAKER_01 22:54

Yeah, totally. And I think that realistically what it tends to mean is that they move into more advanced spaces more quickly. So the maybe the level of support from us is lower, but it's more advanced stuff that they wouldn't be doing otherwise. So you build them up in a ladder. So, you know, they become independent at modeling their own processes. That's excellent. And then we move them into a space where they lean on us more for the improvement design and uh, you know, defining a new way of working that's better than the old one and doing the data analysis that informs that. And then they become independent on that because they learn that skill. So it's sort of like a ladder that they can go through. And then by the end, you know, they call upon us when they're trying to do something brand new that they've never done before is when they'd call upon us. Otherwise, they're really good at delivering independently.

SPEAKER_00 23:35

That's great. I mean, a lot of the consultancies that I see that get really good at helping the client stand on their own two feet, what the benefit is that maybe is not obvious before you make that strategic decision is that they still will want to work with you if you've been of great value. And what they want to work with you on is the difficult, interesting, profitable work that isn't the day-to-day running or maintaining of the machine. It's not the MOT, it's the I want a new spoiler or whatever the analogy is. Are you finding that that actually the long-term relationships where you've provided a ton of value, they still want to work with you and they want to work with you on the most interesting kind of work?

SPEAKER_02 24:08

Definitely. Yeah, I think there's two angles to it. There's the external angle, the market angle for working with organizations where you're doing this interesting work, they're proud that they can do it themselves. They speak at conferences at shows, they're showing to be leaders in that space. So, you know, that's fantastic. You know, you're setting them up, they're happy, and you're still pushing the bones. The other side is the internal side. So we've got a team who's you know all very highly educated and they're really capable people, right? So if we have to do the same transactional work, the same boring legwork again and again and again, we're gonna end up getting disengagement. We did have a big project that was uh earlier this year, and it was very repetitive, to be honest. A lot of heavy lifting. Yeah, it was yeah, it was a lot of box moving. And look, it's great. It's good for good revenue and you know, it's good sustainable structure for a business. But it's not interesting, it's not exciting for my team. So we do move into a space where we're pushing bones, doing more weird, more wonderful, more wacky projects. Fantastic. Means that really intelligent, but really engaged, she might have can stay engaged and have a lot more fun doing more challenging work, solving more challenging problems. So that's really a dual motivation for us to not only help companies set up the ability to do the routine work themselves, but to also make sure that we have that space for us to really stretch ourselves.

SPEAKER_00 25:19

Yeah, that's interesting. And so getting down to the actual work that you're doing then. If I understand you correctly, you're often working across IT operations change teams. Correct me if that's not right, but how do you keep things joined up when everybody has their own agenda? It's just those three teams, for example, have all got incentives and motivations that overlap but not be the same. So how do you tend to manage that?

SPEAKER_02 25:41

Yeah, I'm actually writing a white paper on this right now at the moment. And what you find is in organizations, yeah, there's IT, there's change, and there's a million of one different little teams all working to affect some positive change into the business. Not just IT, and it's not just your project management teams, it might be your process teams, your data teams, your customer experience teams, and then a whole host of other ones that can have any name under the sun. And what you can find is for all trying to pull in the same direction, which is making things better, but it's not a coordinated effort. We had a project quite a while ago now of an infrastructure infrastructure company. We did a process analysis, we looked at the data, we shaped a really cool approach for how we can improve this infrastructure build uh program that they run. And what we got to was a ton of really good pointed improvements. Uh, one of the really interesting ones was this com step that got missed sometimes, saved about two days. But there's this massive likelihood then that it gets caught in a legal challenge at the back end, which then adds about six months on. So there's a lot of really interesting pieces that you wouldn't get from a traditional improvement approach from just talking to people. But when it came to actually putting the changes in play, there's a different team, a continuous improvement team, who they want to be the ones to define the changes. They want to be the ones who are shaping the future way of working. So we end up re-treading a lot of the ground we'd already kind of broken for them. So the whole project, instead of moving seamlessly from here's a problem we can fix, let's go and fix it, became here's a handover point. And then there's a massive disconnect, and they're going to go four steps back and then try and do it themselves. So you end up with this real disconnect between the change makers in an organization. Increasingly, what we've seen work well, what we push with a lot of our clients is to try to recognize these different disparate capabilities. And instead of having them sit as separate teams with these hard handover points, try and bring them together into a change maker function. And then when it comes to programs, projects, change, what you end up with is rather than having the data intelligence team doing their piece, enterprise architecture team doing their piece with these hard handovers between them, try and form a multiple discipline pod. You take people from, you take someone from enterprise architecture from data, from continuous improvement, from a bit of everything, and form that multidisciplinary delivery pod. So that you end up having some continuity into the project. It sings a little bit better. You don't have these million one hard handovers. And then the other really big angle for that is business ownership. So you've got this kind of behind the curtain, the change makers. They don't necessarily sit in a function uh in the business, they'll sit separate. But then you've got the actual business, ones who are actually gonna have to change their way of working. And what you don't want is a million one, you don't want it to be an onion. You don't want everything to go through another layer, another layer, another layer, another layer, another layer. By the end, it stinks. Um, what you want is this really nice structure where if you're gonna affect change into the business, you want to be able to say who's responsible for that? Who's responsible for the way of working? If something needs to change, who's it who's gonna sign that off? But one person. We don't need a million people. We need a really fat kind of organizational structure where we don't have that too many approvals because that'll slow everything down. So who's gonna take ownership of my way of working, my business process? I mean empowering those people. So you've got this nice structure of process ownership, not heads of function, but in the business with streamlined approvals, with this really integrated team of different change makers sitting behind the scenes and making sure things sing a little bit nicer.

SPEAKER_01 28:42

And another benefit of that is the uh change fatigue and the like conversation fatigue that a lot of people have that, you know, they're they're um, I don't know, procurement specialists, and they basically they just need to get stuff that the business needs for a good price at the right time in the right place. And they want people to help them do that. They don't want to have the same conversation with the data intelligence team, the continuous improvement team, the project management team again and again to in a six months' time, a year's time to eventually get to a solution. They want to have that conversation once, that diagnosis once up front, and then those people behind the scenes go away, come up with solutions alongside them, and then you're speaking to one party, engaging with one point of contact. And that's massive because there's honestly in these big organizations, there is a bit of a culture where I think a lot of the people that are trying to get the business moving and get the real work done, it gets sick and tired of speaking to people that represent a change team that are asking them the question that they've answered a week ago to someone else.

SPEAKER_00 29:34

Yeah.

SPEAKER_01 29:34

Talking about getting to the work.

SPEAKER_00 29:36

Absolutely. And then with that, then I'm curious about the way you work in that how do you balance your process? Because of what you do, inevitably you're going to have a strong process for the way that you approach everything. How do you balance the way that you approach working with a client? Which I would imagine, maybe not, but I would imagine is is really pretty structured with the flexibility of implementation and what the client is asking for. And the not every client will be cookie-cutter in what they're asking. So, how do you balance your process with flexibility of the client need?

SPEAKER_02 30:04

So, one of the things we do is right at the outset of any project, we list out all the key meetings for the entirety of that project. Not necessarily agendas, but what's the objective, what you're gonna get out of that session. Now, to get to the objective, the way you get there, the people in the room, the actual structure of it, that can change massively. And it's a starter for 10. Those meeting lists change, they change a hell of a lot. But it's good to be able to start to ring fence on that resource. So we at the outset, we try and do this this little piece to make sure you've got the resources you need. You can be proactive with what you're gonna do, focus on objectives, what you get out of it rather than specific agenda items. But there has to be flexibility. So one of the improvement projects I ran recently, we found out about midway through, there's another vendor they're considering for the key software for this process we're looking at as expenses. There's another vendor they're they're considering. Let's let's have a few sessions with that vendor, understand what their software does, how that might affect that future way of working. So there is a degree of flexibility. So that nice upfront view on what you need to do, what the objectives, how do you lay that out? Cool. Carry on being objective-led, not agenda-led, what you actually want to get out and think about the end goal and work backwards. But we do make sure that on projects we do have that little bit of flexibility to go and hit uh that additional talking point, that additional data set, that additional piece of information you need to actually deliver on the overall objective of a project. One of the big things we push is that we, as Sam was talking about value before, a program at a project shouldn't be based on what deliverables do you get? What's the specific thing you can hold at the end of it, right? It should be based on the objectives. What are the business objectives, business outcomes? What's the success criteria behind that? Have we, you know, cut a million quids worth of cost out? Have we put it so that our quote dropout rates halved and we get much more successful wins? What is the specific objective? What's the specific criteria and work towards the outcome, as opposed to being dogmatic about let's tick a box on how many models we create, let's tick a box on how many bits of data we analyze?

SPEAKER_01 31:52

Yeah, I think the way to look at it is you're bringing skills, experience, and principles to the party. Ultimately, we're working alongside a lot of the time, the internal team, to try and solve the problem with the business. So they might already have a way of working that works for them in terms of how they approach projects, the order in which they do meetings, the way in which they engage with the business and the principles that they have for that. So you don't massively try to change that if it works. You know, you don't bring your, hey, we take it in these eight steps, and each eight steps has these different agendas that you have to cover and blah, blah, blah. And we don't move on from this point until we've got all of this data here. You're just being practical and trying to work to the solution rather than just bringing a PowerPoint slide with an approach on and saying this is what we follow and that's what you're paying for. Absolutely.

SPEAKER_00 32:32

We worked with uh consultancy a couple of months back, and they had multiple different ideal clients that they worked with, verticals, and also different offerings within those. And so it's relatively complex what they offered. And therefore, they had back-end teams. Their team of consultants and associates was very mixed in terms of what their abilities were. And the way they had learned to articulate it was in missions. So they said our team is organized by mission. It's not data mining or it's not this other thing, it's not this other thing. It is what is the mission here? What is the outcome of what we're trying to achieve? And we will worry about the people that we need to organize behind that to serve this mission as well. So I think that's a different language of what you're describing of. We focus on the result and any means necessary is the methodology with our tried and true steps that we know work. Um, from all the clients that you've worked with, Liam, what's been your favorite?

SPEAKER_02 33:18

So I really like working with this logistics company. So we started and it was a really typical uh kickoff. It's a company we were introduced to by the software partner, and they said, look, they bought the software, make it a success. And what you can do there is you can do a little tiny implementation, set the tool up, get them taken along, and you know, give them a boost up the arsenal, get start going. But that's not going to be enough for them to be long-term sustainable with it. So what we did with that company was it was about a two-year program of going in, yeah, setting the tool up, but building the team out. So we set up a real process excellence team. We ran some analysis of some of the core, really important business processes, looking at order to cache, looking at the core of the business. And what we did is we were looking across Audit Cache, we found some savings, we found some improvements. What we also found was a couple of really fantastic people who were in the Auditor Cache functional teams, but they had a real propensity for the process work. So we ended up doing was taking those out of those functional teams, bringing them into that process excellence team, and then training those guys up. And now we've got two fantastic BPM managers in that organization who come from the business. So they speak fluently and kind of a nomenclature of that company. They know the problems, they know the way of working, and they've taught them the process side of things as well. It's got to a point now where they've got a fairly modest set of services. They'll do modeling, they'll do improvement, they do continuity planning. It's not anything that's massively groundbreaking or ambitious, but it's really good, valuable work that they create for the organization. And they're in this place, no, they're sustainable. They don't need us. Down the road, if they want to do something a bit more outlandish, develop a new capability, bring in a more data analysis aspect, sure, we'll be reengaged. But right now we've got them in a place where they are speaking at conferences, they're doing a fantastic job propagating process into the business. And honestly, those two people are two of the most successful process managers I've seen in an organization. So really proud of that company.