Beer & Butterfly

Season 1 - Episode 2: Building the backbone of change

March 03, 2021 Ian Kingstone & Jonathan (JP) Parnaby Season 1 Episode 2
Beer & Butterfly
Season 1 - Episode 2: Building the backbone of change
Show Notes Transcript Chapter Markers

Ian & JP check in for another week at Beer & Butterfly where they explore the foundation of change management - the all important change impact.  Our hosts begin catching up to talk about pitching a tent in 36 degree C heat, letting your kids slide into swamp water and also checking in on what films we've watched lately.  They continue to explore the importance of understanding change impacts to truly ensure that impacted stakeholders are positively taken care of through change.

  • 00:00 - Intro
  • 01:19 - What have we been up to?
  • 03:59 - The problems when change impacts are not understood
  • 08:56 - What is a change impact
  • 12:40 - Change impact analysis
  • 18:55 - Exploring the data of change impacts
  • 31:17 - The different categories of change impacts
  • 49:00 - What's coming up next?
  • 49:43 - Question time

Ian Kingstone  0:00  
Well, what you having then Jonathan?

Jonathan Parnaby  0:05  
A pint please mate

Ian Kingstone  0:06  
Two points, please landlord 

Jonathan Parnaby  0:08  
So Ian. Where's our audience sitting then? 

Ian Kingstone  0:11  
Over there? sat at that table over there? 

Jonathan Parnaby  0:13  
Oh, yeah, I can see them. Okay, well, before we go over there, what we're going to tell them, 

Ian Kingstone  0:18  
we're just gonna tell them it's a relaxed environment where we can discuss, you know, all stuff around business transformation. 

Jonathan Parnaby  0:23  
Okay, cool. So who's actually over there? Who have we got?

Ian Kingstone  0:27  
some executives, some professionals, a few consultants. 

Jonathan Parnaby  0:33  
Cool. Fantastic. Well, let's crack on, lets get over there. 

Ian Kingstone  0:35  
Welcome to the Beer and Butterfly

Jonathan Parnaby  0:37  
a podcast where we talk transformation.

Ian Kingstone  1:03  
I'm Ian Kingstone. 

Jonathan Parnaby  1:05  
And I'm Jonathan Parnaby. 

Ian Kingstone  1:06  
And we're your host. 

Jonathan Parnaby  1:08  
In today's episode, we talk about the problem that we don't understand what the change actually means to people. So we're going to cover the change impact and how it's the backbone of organisational change management. 

So Ian good to see you again. So what you've been up to 

Ian Kingstone  1:23  
not vastly different than probably what we're normally up to really think I think I watch more movies. I watched the movie you recommended The Old Guard. 

Jonathan Parnaby  1:33  
Oh, yeah. 

Ian Kingstone  1:33  
Yeah, thought that was brilliant. Good. Love that loads of action. Loads of fighting violence in there. But obviously, but no really, really enjoyed that really loved the idea of the story and kind of almost immortal but not totally immortal Highlander. But in the new generation. Yeah. I really enjoyed that. Watched also another film The Gentlemen. Yes. Yeah. Really, really enjoyed that as well. Nice kind of London. gangster, type bit more nice to the latest kind of thing with in fashion and music and so on. So that was really good. Really enjoyed that as well. So the so from a movie front, certainly been doing that other than that usual stuff this time of year. The gardening bit of stuff outside, you know, just just enjoyed myself out living in the country, but of exercise. Nothing too major. Yeah.

Not not doing anything untoward. But we're here. Yeah. So,

Jonathan Parnaby  2:31  
that's all good. Sometimes, keeping things simple is good. 

Ian Kingstone  2:34  
Yeah, no, no, that's certainly been keeping things simple, recently, 

Jonathan Parnaby  2:39  

Ian Kingstone  2:40  
So what about you?

Jonathan Parnaby  2:41  
Yeah, I just come back from our camping trip. So yeah we are three days up in well near Stratford. So we kind of visit that neck of the woods because it's kind of a halfway distance between where we used to live and where we currently live in the southwest. So we just meet up with old friends. Picth up all next to each other. Beers come out and generally do camping things. 

Ian Kingstone  3:06  
Do you go on walks and stuff like 

Jonathan Parnaby  3:07  
yeah, all round where you are. Yeah, it's mainly exploring around where we are. There's a little weir literally five minute walk, the kids just slide down that I say into the nice clean water at the bottom. It's probably halfway between clean water and a swamp. So who knows what infections we'll get.

But it's all good. And then yeah, we frequent the pub on on the Sunday they were cracking Sunday roast, but was painting a tent up on the Friday. And it was 36 degrees. heat and oh my god, I have never, it's like being on holiday heat without having the pool. So the kids are all running around with water balloons and having water fights and things. And every now and then I'll just ask them to dunk it on my head as i'm pegging pegging the tent up. So yeah, it's been it's been good. I really enjoyed it nice to have a break away. 

Ian Kingstone  3:56  
No, it's good. Yeah, good. Good stuff. 

Jonathan Parnaby  3:59  
So we have you had that situation where you've been on a programme or project where the team has, you know, delivered or released a new solution to its users or the business. And they haven't actually considered the impact to that business. And then obviously, until it's too late, 

Ian Kingstone  4:18  
yeah, probably quite more More, more often than then I would want. But I would say, mostly on projects and programmes I've worked on in the last 10-15 years. It was the early ones that that happened more so, obviously, I've considered that more so in the later projects, but certainly early on in ERP, in many aside or full ERP implementation, where we've got to training in a new solution into new IT solution. And we've sat down with users and said, this is the way it's, you know, you've got to do things here and the system to do that. And we've not really taken them on a change journey. So then that's not going to work, you've got that's not going to work for us, because you've missed out doing this and do now or how do we do this now, or, or whatever. And I think that that's led to the fact that they haven't realised that we need to change the way they're currently working. So they're, they're living in, in the in the reality of today rather, the weather we need them to go to, and that's why it's transformational. So, so I've seen that a lot, where we haven't taken people on a change journey got then in a training room, or even testing. In some places, we found that the we don't want to work like that. Well, actually, we do want it to work like that. But we perhaps didn't educate the testers in how the world was an early on in SAP implementations back in the early 2000s, is when we start the change that from my sense, it started not just in change management. But I mean, you could say it's as part of change management. But it might be something we started doing, which was process education, as well as teaching people how to train people in using the system. And it's then when I started the change management piece started to become not just a big visionary change, but what does it mean for me down at people who are doing actual processing levels within systems, and their process changes? So I've seen it loads. And, and, yeah, it can really, it can really, demotivate a team in the new solution, because you haven't got their, they're not in the right place with where, where these solutions go in, and what the change that really needs to happen and why.

So how about How about yourself? I mean, 

Jonathan Parnaby  6:39  
yeah, all the time. Unfortunately,

but one one project springs to mind, it's not actually what I was working on, but it was, it was a project that was happening and the company I was working in, and they were looking at trying to digitise the incoming mail, to kind of scan it all and allocate it to the different departments in the head office. And and it's just a typical case of

there's like a project manager and kind of a technical architect, technical expert, who have got together found as a solution in SharePoint,

that would work and they kind of got very excited and then try to roll this out. And they hadn't engaged the reception team, and they got in the mail, and they haven't engaged the the finance team, you know, the accounts payable team and all the teams that would actually be impacted by this change. And they got massive resistance, because it actually transferred the volume of work to different people, you actually would generate a lot more effort and work to the reception team, because they're the ones that have to do all the physical scanning of those documents. 

Ian Kingstone  7:50  
I guess they didn't open it before, I guess that I had this in when we're talking about the example I had in my mind that's kind of envisaged of the you know, the old mail trolley.

Jonathan Parnaby  7:58  
 Yes, exactly. 

Ian Kingstone  8:00  
Does anybody told that person that they no longer needed? Yeah. Well, they may be doing something different. Now there may be scanning. 

Jonathan Parnaby  8:06  
Exactly. So they just pushed up, you know, they're like, well, we can't take this on. And as well as all the other duties that we do, because no one has sat down and once they educated but make them aware that changes to their roles were needed in order to make this change a success. And, and it's just that that miscommunication that whole not considering the impact for those individuals, they just didn't know they've got technology focus, they wanted to deliver it. And it's a failure. 

Ian Kingstone  8:34  
Yeah. And I guess in that scenario, as well, it if they don't understand what's the advantage of doing this way? Certainly Why? Why are you giving them a work all of a sudden, now scanning this, so so whatever they hear, they were asked to do, and understand the benefits to the organisation or the whole they get it? Yeah. So yeah, that's good example. Yeah.

When we look at change, and we're looking at, well, how do people know the change and understand that, I mean, I would always start a programme with, you know, business case, and what change has got to happen and what value it's adding, and through the value process or benefits and value mapping type exercise, you would see where the real big changes needed to happen, you know, the why the big stuff, and then we're gonna talk about that more in a future episode. Definitely. But But how do we get into the real detail, you know, that the Change Impacts you talk about change impact? Well, let's start with explaining what is a change impact? 

Jonathan Parnaby  9:30  
Yeah, I mean, in my mind, kind of a definition of a change impact is it's a it's kind of a tangible description of how an organisation a team or individual will be impacted by transforming from AS IS state to a TO BE state. So let me elaborate on that because that's very dictionary textbook, speak. If I was to take a I don't know a random project, pulling out my head, where we're going to implement a new procure to pay, you know, application

In our system, and we're going to completely revamp the whole process. So let's just say this company currently does all of its purchasing manually, they've got purchase order physical pads, where they are writing, you know, physically, all the stuff that they want. And they hand that pad to the line manager to kind of validate and, obviously process that purchase. And then we're going to go to a world where we're going to put in like any ERP solution where,

you know, they've got Purchase Requisition forms, they've got to fill out before they even raise the purchase or purchase order, and then they've got purchase order, which has to get approved before it's gets distributed to, you know, supplier, and then I've got a goods receipt here when it comes back in. And, you know, then therefore, the the whole three way matching for accounts payable to obviously pay that supplier. Now, these are drastic changes to an organisation but not only for the finance department, where currently, that all the approvals are happening at the back end of that process where actually they should be the front end before any money is committed.

Also to the individual has to write on that purchase order pad. So you know, there AS IS state is very easy for me, I can just pick a pad up off the desk, fill it out and send it to the line manager. 

Ian Kingstone  11:13  
Yeah, and I guess also the to the change impact would capture the dip what's actually changing. So it's no longer a pad, it's now a purchase request made by that person within the system. Yes, but but it also might, I guess the change impact might also have change impact in the individuals doing different parts that process.

I think he said that the the the, you might receive the goods and we automatically three way match what that might have been done by different personnel or it might be automated to completely correct. Our key suppliers might even be automated, you might have preferred suppliers in the system. And your purchase order just says you pick one of these three suppliers rather than you go and select one. Exactly, which is a big change for a lot of older organisations that may not have those processes in place. So the change impact would capture the probably many in that process, there would be many changes. 

Jonathan Parnaby  12:06  
Absolutely, you could in a whole P2P transformation, there probably could be 50-60 change, and perhaps maybe more depending on the the level of scale of what is changing, you know, even to the point where an operative at site maybe doesn't have the computer skills, 

Ian Kingstone  12:25  
right. So so it's not just about what's changing, but it's what capabilities or skills or, or technology or whatever is needed to allow that to that change to the essence of enabling that change. Again, and before we get into the detail of what we capture in a change impact, although we talked a little bit around it, but maybe some of the types of things you capture, when's the best time I mean, in my view, the best time would be I said early on business case, you know where the major changes are going to be. But actually capturing those change impacts, I would see that coming out of design, the kind of process change or design, even if you're going to let's call it a vanilla ERP, a it's a set process that you're moving towards, that needs to be captured, when you go through the world, the AS IS s here and the TO BE's are going to be over there. It's not going to look, that's where you pull out those impacts. 

Jonathan Parnaby  13:22  
Yeah, just to rewind a little bit, though, you know, your change management framework should absolutely dictate or help guide you of when those impacts will be created. So actually, it doesn't come as a surprise. So it's really key that the change management effort is intrinsically linked into that programme. So if your programme is going for a huge blueprinting exercise and design and then build and test or whatever, is that your your change management efforts are running alongside in parallel, at the right time. So you're getting the right information. But yeah, for me, the ideal time is design  blueprinting that whatever you want to call it, is because you've got the hood open, you're talking about TO BE processes, or you're mapping and putting post it notes on the wall or whatever they are you talking about what the future may hold, and you've got typically business stakeholders in the room who will generally voice their opinion going, that will work, that could work, but we need to change these kinds of things to make it work or that won't work. 

Ian Kingstone  14:20  
So you just in that conversation alone, you could pull out other impacts that you may not consider. So who who would normally do who and we will get into the detail of what you capture. But before we go there who what types of people would capture those impacts. 

Jonathan Parnaby  14:34  
I mean, there's no hard and set rule in my book. And it depends on how your programme is set up. So for any ERP implementation I've worked on in the past, we had Business Analysts, yeah. Because they they did all the capturing because they were in all the blueprinting sessions. And actually there were so many of them. The change team couldn't attend them all just wasn't enough of us to get around. So we kind of worked with the BA Team

And and we got them to kind of flag them and put them into a change in our log. So basically like a form they filled out, and we're collate them and then meet with them and check with them and go, Well, what do you mean by this and that, ideally, you'd want to change member of the change team in those sessions.

And because they know what they're looking for, they're looking for, you know, the specifics, so they can actually help pull the Change Impact Assessments together. And generally, if you kind of outsource it to someone else, you're gonna get gaps, and you're gonna have to spend effort filling those gaps out. But there isn't a hard and fast rule. It could be anybody. You could be that you you kind of put the responsibility on the business to flag those impacts as well. So it puts an onus on the business to 

Ian Kingstone  15:42  
Yeah, I've done that. Yeah. In a place where you capture them on a board. Yes. As you're going through workflow, new process, you have a parking lot, and you capture those change impacts. Yeah. Because you hear them in the room. Yeah, you don't mean, I've done this as a project manager? Not as in the sense of I've heard them and we've captured that. Yeah, we agree. So it becomes a wider responsibility of that, that team. So you get engagement from the business people as well. 

Jonathan Parnaby  16:08  
I like that method, because we'll cover as part of, you know, what's the metadata of a change impact you should capture. But for me, you know, having somebody from the business kind of being responsible for that, it gets that engagement and buy in right in the beginning, rather than you trying to transfer that responsibility midway through the programme, which is always difficult.

But sometimes you have to because like, it's depends on the setup, there is no black and white answer that says this role should be the one that always captures changing backs, and no one else should touch it. Because it never works. We've all been in programmes, how many of them have been the same in terms of their organisation structure, none of them? 

Ian Kingstone  16:49  
Well, even if you're implementing the same system with the same standard vanilla solution where they're coming from is never the same. So the change is always different. Exactly. One organisation they might use manual purchase order pads. Yeah, in another organisation, they might have already had a procurement system, but you're changing the system. Yeah. So it's more integrated. Yeah. 

Jonathan Parnaby  17:09  
So the leap isn't as far yeah, but the leaps still there. The other thing to kind of highlight is, design, in my opinion, is the best time to capture them. However, if you are on a programme, and you're in build, or in test, and you just suddenly realise you maybe listen to this podcast, and you go, Oh, God, we should have done a bit of that, we should have done some change impacts, it's never too late to do it until it's too late. That makes sense. So you implement it. It's it, that's usually when it's way too late. 

Ian Kingstone  17:39  
So you probably find someone you think you've captured everything in design. You had a bunch of people in the room and you've done some design work. And you're you're often build and configure or configuring the system. But but you actually get down the road and somebody else in the business says, Well, I don't do it that way. Yeah, I knew that. And, again, there's another area, you've just found another impact. 

Jonathan Parnaby  18:00  
So I'd rather people do it later in the process than not bother. Yeah, that's all and also, you know, we're talking a lot about kind of waterfall approaches there with the ERP's which we know that you know, majority ERP's have been waterfall delivered. But we know agile actually lends itself really well to kind of change management practices and principles, because you're always in, you know, sprints, and scrums, and you're talking about design, build, test within a sprint cycle. Yeah, on shorter, smaller pieces. So actually, you can kind of embed that change impact capturing during that process as well. Yeah, so that's very cyclical. And, yeah, that can work really well, too. So it's all coming out at the same time. 

Ian Kingstone  18:47  
Okay, so, so got a really good feel for all of that. But what, what specifically was the what's the the important information to capture about a change? You know, what's the metadata? What's the? 

Jonathan Parnaby  19:01  
Yeah, I mean, the first thing is that you should log it somewhere, they should have a home, my it's fine that they live on post it notes whilst you're in sessions. But for me, I'm always comfortable when I've got the data, because actually, I think Change Impacts as a cube, like a data cube that you'd report off of any other kind of business data. And the reason for that will cover I think, more than you know, later in this episode, or the next one, where when you're doing the assessment, you kind of want to look all the information in a holistic way and you kind of spin it around look at it from this lens and then different lens but, but in terms of that data in though you should be capturing in kind of my opinion, where you got to give it a name. 

It's gonna be called something just so you can identify it usually an ID as well. So always have an ID number of some description there.  The description of what is the change impact. So again, if the AS IS state the TO BE state, whats changing.  So you can easily identify and that way.

Also, what project or initiative is it aligned to. And that's very useful if you're a change team that are working across multiple projects, multiple programmes, work streams, if you've got like a change management office that's supporting the wider business, you might want to pull all the Change Impacts together in a centralised location where you're then looking at maybe what impacts this project is causing against that project. And do they have any overlap, because that can happen. You know, we talk about change fatigue, which is another term of a department going through too much change. And maybe you've got three programmes hitting that department and the same month. Yeah, and that change impact analysis is really going to bring that out.

The process a BA is my background, so I'm very up on a process decomposition and process hierarchy, I love organising all processes in that kind of hierarchical structure, right from you know, an end to end process, like Procure to Pay, Hire to Retire, right down to, you know, filling out requisition sheet.

And everywhere in between. So I like to link the impacts to those end to end processes, and what level it depends on really what you want to do. And again, it's just useful to know, pending, if your process centric organisation, its this good to know what impacts are going to impact in that, especially if you're a process owner,

because they'll have a vested interest in stake into

the business function itself. So that's kind of looking at it, rather than end to end processes, looking at human resources, finance, operations, northern region, whatever. So again, it's just another lens that you can kind of look at

the stakeholder group and team. Again, very important.

Ian Kingstone  21:52  
And just and maybe we should write is when you've gone through a complete list. But if I've seen your change, that change might impact many different stakeholder groups, as I capture one change, or what I have many changes, one for each stakeholder group, does it matter,

Jonathan Parnaby  22:09  
it doesn't matter as long as you got the relationship. So if you're pulling this stuff into Excel you might have you know, a bunch of columns that have all your stakeholder groups, and you put in text or x's again, so you can kind of model it that way. Or if you put it into, you know, an online cloud based system, which I've used in the past, you know, depending on their data models, and how they set up, you might have to do a separate change impact per stakeholder group. But the point is, it doesn't matter, we're probably getting technical there, it's making sure that you link it to those stakeholder groups, and whatever you how, however you want to break them down wherever your stakeholder groups and teams are more executive level, senior management level, managerial level, operative level, or wherever it's literally teams within functions doesn't matter. It's it's, it's understanding that in as, like I said, on the earlier example, about the the digitization of scanning all the incoming mail reception team is a stakeholder group, which got forgotten. So they should exist there on on that changing impact log.

Yeah, type. So a change impact type

is also quite important. And I've got kind of four definitions of different types. And what I mean by that is, when does this change impact need to be dealt with in relation to the transformation that's happening? So I kind of classify a Type 1 being kind of in needs to be dealt with before the transformation happens. So it's likely that it's a readiness exercise. And it's likely that, you know, a team needs to either get educated or change themselves to get ready for when the change happens. So this could be again, the procurement example where we're going to have procurement hubs set up across the whole UK, because of the way that the the roles work in the ERP system. And that's not a technical thing. That's an organisational thing. So we need the old teams to get ready, we need to know who's who, who's going to be managing what, where all the requisitions go to sort of a kind of mini procurement hubs across the business. And that's something that needs to happen as a change before the system goes live. So that's what I'd classify Type 1, or Type 2 would be during transition. So something that will have to happen in the process of you literally transitioning from as as to to be using during cutover or some form of deployment, Type 3's our post transition. So these are changes that can only happen once the enabling technology or enabling changes is implemented, because you can't do it before hence why needs to be there. A lot of them are usually change impacts that kind of fall into that category because generally that's what's going to give you the value those changes post. implementation is what in locks or unlocks the door.

Are you there? Then you get those Type 4's where they're not really dependent upon any transition at all. They're not really tied to a time box, and can be done whenever and they use just helped add support and things like that, and generally on the lower priority,

and then when date went, when does it need to be done when there's a need to dealt with? 

Ian Kingstone  25:19  
So and that must be aligned with the plan of sorts 

Jonathan Parnaby  25:21  
correct? Yeah. So generally, it helps you to do your plan. Because at this stage, you're thinking back at design, you don't know what your plan is yet, because you don't know what your changes are. But you do know that, you know, Change Impacts needs to be definitely done on August of 2022. Because we know we are putting the system and then October 2022. And of course, that'll never change.

We've always on projects, they always change. But, but yeah, it's kind of giving you a guide. And that kind of helps review your types there as well. Number of people is a good one to record. So it does the impact impact five people 50 people 500, 5000, 50000 scale scale of that change impact. Because how you deal with that, from a execution point of view. And again, kind of dipping our toes into future episodes here will depend on the size of the crowd that you you need to deal with. So you know, dealing with a team of five people, your initiatives that you put together are going to be very different to dealing with 50,000 employees across our company. So good to know, my favourite change ownership. Yeah, who owns this change? And the answer is not the change team. The answer is not the programme team, the transformation team from a

kind of IT technical focus. So we say, for me, it's who's in the business going to inherit this change? 

Ian Kingstone  26:52  
Yeah, who owns it? Who owns the process or whatever? 

Jonathan Parnaby  26:55  
Yeah, and I'm big on RACI, I love RACI to thats your responsible, accountable, consulted and informed. And I, I love that kind of model to try and, you know, nail ownership to the right people. So you might have a HR director as an accountable party, but who's responsible? Is it the recruitment manager? Is it the HR administration manager, etc. So just getting a name there, and they know that their name is in that box and that these impacts are coming, and then know that you're organised to capture them is really good.

benefits? I asked one of my favourites Yeah, it's not that important is it

Ian Kingstone  27:33  
the thing I've always found with the benefit side of things, change impacts is actually you find benefits you didn't know, you get into the detail of design, obviously, you find these but through change impacts, you then find where you're making changes. And yeah, sometimes you find that that things are moving around a little bit. So maybe when you actually come to the detail and the devil in the detail, you find that

it wasn't exact efforts moving, yeah. Not necessarily going away or whatever. But it's where you really find out from, like I said, at the beginning of this conversation, where the value, you might map out where may lots of kind of value could be, this is where you really get into how do you unlock that value? And I think I think you've got value and benefits. Along the change impact. People can also see how important the wrong word I'm looking for. But where it fits. Yeah, where it fits in the transformation. 

Jonathan Parnaby  28:26  
Yeah the important bit about benefits, it's, it's at the micro level. So it's at the, you know, what's the benefit to that stakeholder group has been impacted? Yeah. Yeah. Because if you can't answer that, you've got to, you've got to kind of ask yourselves, why is that? Why are we making the change? 

Ian Kingstone  28:42  
Maybe there could be a benefit to another part of the organisation. It could, yeah, so take the the reception team, and maybe this is another way this one went, but to the reception team used earlier, then there might be a dis benefit in that they've got to do more work now. Yeah. But there may be a massive financial benefit or a massive time benefit further down the road, to to the organisation wholly, that can be challenging in selling that change to that particular stakeholder group. But you're right, this understanding if

Jonathan Parnaby  29:12  
You're right I didn't I didn't kind of cover that. But yes, you you can capture impacts where they have no benefit to a specific stakeholder group, because they benefit the other part of the business.  You need to understand that, because again, you've got to deal with it, you know, yeah. And that kind of leads on to the next one, which is barriers, which is kind of like if there are barriers or dis benefits, log them. Yeah, so let's 

see, so positive and negative. Yeah, all of the impact there. Which is, which is kind of very important. So yeah, and log them understand them because again, you're gonna have to translate all this information into proactive initiatives, i.e. activities that are actually going to do something, whether that's sitting down with the reception team as we use that example. And explaining that yeah you are going to have more work.

And you might have to employ another part time person to come in and help you

as long as the business case stacks up right, yeah, but it's going to enable X, Y & Z in the organisation and having the right people in those conversations.

And then dependents, so dependencies. So just like any like Project Plan was dependent upon this and that. So, again, what are the enabling factors, which will will cause this impact? So you're tying it. So wherever you've got a programme that's going to deliver, I know, four phases of deployment. You know, phase one has got, you know, module x of this system, or phase two is now changing the organisation, operating model, whatever, you're linking those impacts to those dependencies, as well as just another another way of modelling 

Ian Kingstone  30:45  
I guess, and some change, it will change changes will be dependent on other changes, like you said earlier, you might have some you do pre transition. Yeah. And so we do post transition, the can't do the post transition runs without the pre transition ones. Yeah. And so on and so forth. I guess. 

Jonathan Parnaby  31:03  
So yeah, it's, um, they're the core things that I would capture. 

Ian Kingstone  31:06  
You know, when you've got that in place, and the cube or whatever, you captured that. Yeah, you've captured that information, that data that then you can look at, and I guess you can look across that in different ways. Do you categorise that? 

Jonathan Parnaby  31:18  
Yes. Yeah, absolutely. So. So kind of going up a level slightly. I like to kind of categorise it in eight different ways, just because that's how I do it. Really, it's not, I'm not saying that these are the only eight ways you can do this just kind of my view, in my opinion. But changes can typically fall into the these kind of categories are the first being policy, there's a policy change that needs to happen in the organisation, and policy a to policy B, so the governance and rules of how your organisation behave, are going to change. And that means it's going to impact people. Yeah, no doubt. So that's one process, which is probably an obvious one, we talked about, that we're changing the way you work, you know, your handoffs, the different departments are going to change the what the way you do things is going to change, that kind of stuff. Organisational design, we kind of covered that as well with the her 

Ian Kingstone  32:07  
that to me, organisational design has always been the tricky one to me, massively most of is, I can't think of the right word really sensitive, yeah, sensitive, probably a word that I would use that you've got to manage that in your programme. But also in managing the change. It's probably the one that's got the biggest behavioural type, or challenges for the organisation, when you're looking at what that means with organisational design change, you know, in it, people's roles or jobs or changing what they're accountable for? Yeah, well, and I think that, to me, has always been one area that we've we've on lots of programmes struggled to manage? Well, unless you've got good change team working with HR and, and so on and so forth. 

Jonathan Parnaby  33:00  
Yeah, the, and you mentioned, I'm glad you mentioned the the links to HR, you know, if you're going through some, you know, large scale transformation, one of the first things you need to do is no doubt gonna hit somebody some role some team is together, HR representative is going to help support you because the, you know, change team will know,

you know, the kind of practical applications of what they need to do, but they're not HR law experts. Typically, unless you've got one in your team. Fantastic. If you don't you need to get that skill set in. 

Ian Kingstone  33:31  
And I've seen mixed, I've seen change teams that have come out from HR. Yeah, because they're used to doing organisational type changes. Yeah. But then they've not been so skilled in process or, or some of the more systematic, like you say, type changes happen.

I think in an ideal world, what you just said, I think, a blended team, change team, is this great. 

Jonathan Parnaby  33:55  
Yeah. Because then, you know, HR is involved now. Yeah, involved in what's going on what the impacts are right from the beginning. So they can prepare themselves and organise themselves to, to help, let's face it help the employees who are going to go through this change. No one likes to be the last to know and, you know, leaving HR to be the last to know about what's changing is this disaster. 

Ian Kingstone  34:15  
Sorry, I segue away from that. Point three, I think you I'll bring you back. 

Jonathan Parnaby  34:23  
Yeah. So when I say org, org design, I kind of mean hierarchical structures and reporting lines that have to change. And then kind of moving on to the other point for roles and responsibilities. So this is now my job is changing. Specifically, I still have the same line manager, I still have the same team that are reporting to but what I'm doing now is very different. And therefore my Yeah, just kind of what I do, you're going to change and in my job description, shall we say, is no longer valid. So therefore needs HR support. 

The fifth one, workload management. So again, these are that reception team as an example, the volume of work is shifting on the process somewhere. So it could be all the roles are remaining the same. Everyone's reporting in the same way, but the volume of work is now being transitioned from point A to point B. So it's going to impact a team in a different way. And actually, can they take that volume? Is there gonna be capacity issues? Are there any bottlenecks in that process that will, Creek if you suddenly pipe in, you know, an extra 300 invoices into this team to process versus the other team. So things like that can definitely get missed. 

reward and recognition. This is very applicable if you're working with sales teams, put in their CRM systems, and then suddenly their incentive, the way their incentive schemes are being managed, measured and tracked, are changing. People get very sensitive about their bonus. Slightly reliant upon that as part of their for salary. But again, you've got to be very, very clear that if that is changing, how is it changing? Why is it changing? All that kind of stuff? And also in some industries? unions? 

Ian Kingstone  36:04  
Yeah, yeah, I've been there. 

Jonathan Parnaby  36:06  
Yeah. me too? Yeah. Yeah. Gotta get the unions involved. And you know, they're a stakeholder group, that should be part of your changing paralog? Because you've got to manage them, right. Number seven skills. So are there any changes to any capabilities that people will need? competencies, competencies? Yeah, to deal with things, sadly. So I'm, I'm an operative, who's never used the computer before my job and my whole 40 year history. And now I need to spark this transformation. Yeah, how's how's that person, and I get supported, you know, that's an impact. And then last, and certainly not least, is culture. So the cultural changes in your organisation, which could be, you know, if you're talking about operating model changes, and you, you know, you're going through for digital transformations, where you're literally changing the services and the products that you provide, and it's shifting gears, and it's going left, rather than it's going right, the culture might shift along with it, especially if you're getting new CEOs involved, and, you know, the messages in his business, and the absolutely massive, you know, people about used to behaving the way they behave, and then something that started to change. And I know that a lot of the culture is is made up of it;s existing kind of pool of people, behaviours and other things. But, you know, transformation can literally change a culture of a business, and a need to understand what that actually means translate into tangible, for the better, quite often, rather than Yes, well, let's have a look. Otherwise, why are we doing this? Yeah, those are kind of the categories I like to kind of put those impacts into, as well as obviously recording the different data. 

Ian Kingstone  37:42  

Jonathan Parnaby  37:43  
so we have talked a lot about change impacts, and you know, the detail that you can go into, but, you know, have you got any kind of

Ian Kingstone  37:54  
what we do with it? 

Jonathan Parnaby  37:56  
Yeah, you've got all this data? What do you do now, wisdom? Do 

Ian Kingstone  38:01  
you talk to talk a little bit about it, and through the process, and you need to assess those changes, and not just look at them across? You know, we talked about lenses, and looking at across four stakeholder groups to the head, when do they hit when would those changes need to be, you know, done by and, and all things we've captured, but looking at and looking across the different stakeholders and process, and how they hit. But you've also got to translate that I'm hearing to the right type of information that the business can understand, I guess. So you're doing an assessment of all of those changes, and bring that together, and then better communicate in the right way with the right parts of the business at the right time. And in how much and in some areas, you might have a lot in some areas, you might not have so many. And it's the way in which you present that. And I think

that's where I've always relied on some change managers I've worked with who and the good ones who really understood different parts of the business as well and tried to develop how they might communicate that and

this moment is assessing them. Yeah, looking through them. understanding where the big changes are, where the big groups of changes are, like you said, the size, all the stuff we've captured all individual change impact. And then within a group that and really,

I suppose process that data to understand where the change is and where it happens. 

Jonathan Parnaby  39:24  
Yeah, I mean, it's kind of, as you said, about translating it brings up a memory when I was changed manager on an ERP implementation, and, you know, I, we are, we had over 800, maybe even 900 change impacts on that programme, you know, is far wide and reaching. And I remember kind of feeling how daunting It was like how we're going to turn all this information and package it up to sit with a regional director of his area and make him understand what's coming.

And then I did the usual thing, I cut the data out. And I remember sitting down with him for the first time. And I learned the hard way that actually just putting a filter on a spreadsheet, and then sitting down going through one by one, it's not the best way to do it very quickly realised that, no, you should not do that.

And it's, you know, as a regional director, I knew fairly well, and it was kind of, we used them as a bit of a testbed, because he was very close to the programme physically, he's in the same building. And we used to kind of run a lot of things through him before we kind of rolled them out to different parts of the business.

And the feedback that he kind of gave me, you know, early on in my career was, you know, we've got to try and tell story with it and bring it to life, you know, and, and I knew that I think after sat down for five seconds, 10 seconds, do anything, this is not the right way to do it. So I went away, and I kind of packaged it all up into a PowerPoint. And I grouped up those impacts into the what are the key things that it's telling me? What are the core kind of high level impacts, that those change impacts are kind of translating or rolling up to? What's that story that needs to be told. And then when I went back, it was a much more visual overview of what's going on. And and I just just hit the nail on the head there, and he kind of got there. 

Ian Kingstone  41:20  
So it's not just oh, there's a lot of process change here. Now, this, what processes? are we changing and bringing it to life? Yeah. And really bringing that to the business's understanding that this is this area is going to change a lot. Yeah. And why 

Jonathan Parnaby  41:35  
Yes. Yeah. And actually don't panic as well. Because, you know, he, usually this is a situation where maybe the, what we'd refer to as the change ambassador, is their first experience or exposure of what's to come? Yeah. And that can be quite overwhelming, when, you know, depending on the programme you're working on. So you've got to be very reassuring to say no, at this stage, we're very early on in the programme, we are understanding what we want to try and move and, you know, what we want to kind of transition to, and we're gonna put with you,

you know, a change management plan of how we're gonna work together and actually help. 

Ian Kingstone  42:14  
Yeah, that that really falls back. So you know, in that assessment, and that kind of bringing it together kind of falls back, and then I will talk about in a future episode again, I can't help them, bring them bring this up now.

If we sold the vision, right, yeah, we've done the business case, right, where we said, we think there's lots of changes here and the sort of changes, then we've done the design, and we've got down to these change impacts. And whether we were right or wrong about the amount of change or where that's where we can create that relationship, that conversation you have that with that Regional Director can be along the lines of Yeah, not just giving the spreadsheet of changes, and doing what you did. But it can be when we set out to do this, we knew we probably have changes in these areas. Now we're into design of this, we now know, either those are the changes, and these are the types of things. So you they can relate back to that vision. And that that business case, or that actually we're finding out more, and that we've learned this, or we've learned that so they can relate it back to the business case of vision, even if it's slightly different than we expected. 

Jonathan Parnaby  43:18  
It is easier. When is when that conversations happen at an executive level. 

Ian Kingstone  43:23  
That's my point. Yeah. Yeah. If that had happened prior got it and why that's so important on programmes for the change journey. Yeah. And why that's really rather than just going doing these, I'm working out what's changed, and then just rolling it out here. Yeah, your vision, your vision, you, the business case might be slightly changing, which is why you're reviewing the business case all the time. But, but it's really getting into the detail then to stack that up behind and making sure it is going in the right direction to the right vision. 

Jonathan Parnaby  43:54  
Yeah. And also, you know, having that we said earlier, having representatives in that design process to help either capture those impacts or have involvement in helping to capture those impacts, then ideally, they need to be referring back up to their own business levels and teams that they you know none of this should be new. I should be sitting down the Regional Director go, you know, your business is going to change in these ways. And I've just told you about it and you don't know anything about it. That's not a good place to be. 

Ian Kingstone  44:22  
That's what we started this conversation off with, wasn't it? Yeah, with, you know, have we, you know, this whole change piece. We've talked about this earlier on in the episode, not understanding it's all about the people and the change in having tried to assist them in and not having that set up and ready. So you've got your assessment. So you've done this assessment that say you've you've, you've brought it to life a bit and you've you've started to work out with, you're starting to work out with people what that means for the organisation. Is that is that is that the end of the end of this stage of Change Impacts what's was it

Jonathan Parnaby  44:59  
can be a bit so cyclinical because suddenly you become a department or team that suddenly becomes the most knowledgeable team about what the change means.

And usually what I find is, you know, other parts of the programme or even the business, wants to know, wants to cut that data up into different lenses and different viewpoints. What I'd want to know, as a project manager, let's say, programme manager, Well, okay, we know the change is going to happen. Let's say it's a pre transition change. I want to know when when can we get this done by start planning now? Exactly, because I'm going to want to start to understand this this change, and we, you know, what, we obviously had a high level plan before design. I mean, are we still? Yeah, I think at this stage within assessment, it's not going to give you a plan. Yeah, can are very important, actually. Because there's a kind of step that kind of follows the assessment, which takes the change impacts and converts them into what the hell are you going to do about it, then that bit will cover that next episode. 

Ian Kingstone  45:59  
And that's great, because that's the bit that speaking, selfishly, want to know 

Jonathan Parnaby  46:04  
me too. That's To me, that's the probably the most fun and exciting bit 

Ian Kingstone  46:10  
What you are telling me is you can't and I agree with you, and I know this, really, but you can't just then take that. And so right now, we can plan this and know, you know what we're doing? 

Jonathan Parnaby  46:18  
There's too much. 

Ian Kingstone  46:19  
There's some other people involved, right? Yeah, 

Jonathan Parnaby  46:21  
it's too It's too much to handle on your own. And, you know, it's a group effort. It's a team effort. But But yeah, it's really just becoming like the oracle of change. That whole that process of getting information, understanding or validating it, packaging up to make people understand, or different stakeholder groups that understand what's coming. And then you've got a solid foundation. So I always refer to the Change Impacts being the backbone of OCM. And it really is because without it, how do you know what you do is going to satisfy those impacts. If you don't record the impacts? you're guessing? You're literally guessing you're throwing a dart into the wind and hopefully hits the bull's eye? Or maybe it doesn't need someone else.

But yeah, it's for me so important when people miss that step its like, nooo

What you doing???, 

Ian Kingstone  47:13  
which I guess is why you don't? I don't see that mind. But but it's why, ideally, you would do it the other way through the programme, because if you pick something up later on, doesn't matter. It's better to pick it up. Yeah. Or if you didn't catch her stuff early on, and you've got to pick it up later on. Yeah, at least it's better to be doing that than just sound and get to that. So it's not worry about it. 

Jonathan Parnaby  47:32  
And obviously the effort that goes in probably sitting listening, going that;s a lot of effort, isn't that? Well, it is yeah, it is a lot of effort. 

Ian Kingstone  47:40  
You say that though. But if you're doing it, let's say to go back to design, yeah, if you're doing design process, your talking through so many things, no harm in capturing change impact. Now, you might have to do a little bit of work afterwards to try and tidy up a little bit and only understand it. But But actually, the time it's going to save you the distance it's going to get you and the success is going to get you far outweighs 

Jonathan Parnaby  48:02  
it depends on any effort depends on the programme of change that you're on as well. Right. So if you're doing a full blown, you know, business transformation enabled by ERP touching every part of your company, yes, you're going to have a lot of impacts, right. But if you know that you're phasing that over three years, two years, whatever. And then you can do that in stages. Yeah. So you structure it along the programme plan again. Yeah. Well, it could be that it's a project very small. It's very targeted to a particular team, or you think it is? Yeah. you should, though, in my opinion, still do this process? Because actually, you know, for that kind of smaller project won't won't take too long. Yeah. Because it's more localised. It's more targeted.

Yeah, no, it's, for me, I'm passionate about it. And I think, you know, again, backbone of change its your foundation, you wouldn't build a house without a foundation. And you wouldn't do a change management plan without change impact. 

Ian Kingstone  49:00  
Right. So we've, we've we've got to change impacts, we've started to do this assessments, we've started to understand where the changes, have, you know how that's how it's going to look, we really need to start thinking about their next change plans, who needs to be involved? Change network, and how that works, both of which are items we've scheduled out for future episodes, completely, I think next time we're looking at change plans, or Yeah, and so on. And I think we will get into change networks and contract set.

Jonathan Parnaby  49:44  
Well, I think we've got our first ever question on the podcast, which is amazing. I'm actually really excited.

Because, you know, getting questions is a big part of what we try to do, right, trying to get 

Ian Kingstone  49:56  
Yeah, that's good. Yeah, right.

Jonathan Parnaby  50:00  
So really, really? Yeah, I'm really excited for this. Our first question comes from Andrew James. He's asked, What is the difference between business change and business transformation? Great question. Start with what you thoughts on that? 

Ian Kingstone  50:14  
Okay, well, to me, change is about changing something that you've already got it. So I look at it from a value perspective. So I say, well change is around, something you already do getting more value out of it. So changing things in the organisation for the better, but aren't the things that are already there is where it could change. Whereas I look at transformation as being creating new value. So creating something new, something different. So it's, you've transformed it, you've not just changed it, it's gone, you know, into something different. So, and I often I often use that

George Westerman term to explain this when somebody asks me, you know, when digital transformation is done, right, it's like a caterpillar turning into a butterfly. When it's done wrong. All you have is a really fast caterpillar. Yeah. I love that quote. Yeah. So do I, because that really does to me explain the difference between change? Yeah, faster Caterpillar, or beautiful butterfly completely different. In what you've done. So for me, it's about changes about

looking at something and creating more value of what what you've got, whereas transformation is creating new value.

That's, that's it for me.

Jonathan Parnaby  51:41  
Yeah, not much more to add, I think you've hit the nail on the head. Anything I probably would add is, you know, I kind of see business transformation, changing the the operating model of how our business works, how our business functions.

Yeah, yeah, it's kind of just sprinkling that in there. But yeah, generally, that the catterpillar and the catterpillar quote is great. And I think that just sums it up for me. 

Ian Kingstone  52:05  
I think the other thing on on on, on that is that if you're going in I but I suppose slightly different from the question, but I have a viewpoint that if you are going to do any major change, why not be transformational? So because if you're going to spend money, time, effort, and if you want,

you know, create that change kind of thing, why not be transformational now, in doing transformation, you need change management, because it's still changing stuff. But But yeah, if you're gonna go about doing

anything sizable, why not look at why not be transformational? Why not look at how you disrupt your industry changed, like you said, change your business model, to a more modern business model that you may now now need

rather than just small, lots of small changes that don't really drive any new, anything new for the organisation or its people.

Jonathan Parnaby  53:10  
Its last orders at the bar. So thank you for listening to the Beer and Butterfly. As always, we want to encourage participation.

Ian Kingstone  53:17  
Yeah, so you can contact us at the website that's There you'll find show notes on everything we've talked about in today's show, or any links to anything we've discussed. And also you can leave comments, get engaged or get involved through the website. So that's 

Jonathan Parnaby  53:39  
Yeah, and we look forward to seeing you at the table next time.

What have we been up to?
The problems when change impacts are not understood
What is a change impact?
Change impact analysis
Exploring the data of change impacts
The different categories of change impacts
Building the change impact assessment
What's coming up next?
Question time
Last orders