Welcome to another episode of our podcast. Today’s topic is organizational change management, which is the counterpart to the previous episode of “Management of Change” where we spoke with Caspar Jans. This episode covers the “people side” of changes that are planned in your architecture and implementation projects, and we are covering the why, org design, communication, and enablement topics.

In detail we are talking about:

  • Org Change Mgmt vs. Management of Change. OCM is not the “feel good stuff” but a management practice
    • Reasons for resistance: fear of loosing authority, security, capability
    • Valley of Tears concept
    • Three areas of a successful implementation: content, governance, and adoption
    • The “why” of change
  • Org design
    • Disconnect when creating org designs
    • Typically no connection to architecture group or solution designs
    • Org design people need to pick up new skills
  • OCM is a Management discipline
  • Stakeholder identification, Net-Map concept
  • OCM strategy and plan
  • Communication
    • Content, frequency, mediums, assessing effectiveness of communication (feedback and measuring behavior)
    • Building a change organization
    • Get feedback and adapt communication material
    • Communication is the long tail of transformation. Don’t stop communicating after go-live
    • Celebrate success
  • Enablement
    • Curriculum
    • Stakeholders, strategy and plan
    • Develop material, setup infrastructure
    • Conduct training – Role of client personnel (train-the-trainer, super users, first level support, etc.)
    • Feedback
    • Measure behavior changes
    • Adapt your strategy
    • Support
    • Knowledge Management

Please reach out to us by either sending an email to hello@whatsyourbaseline.com or leaving us a voice message by clicking here.

Ep. 17 – Organizational Change Management – What's Your Baseline? Enterprise Architecture & Business Process Management Demystified

Additional information

  • Change curve / valley of tears
Organizational Change Management - Change curve
  • Three areas of successful architecture implementation projects
Organizational Change Management - 3 Areas of Successful Implementations

Credits

Music by Jeremy Voltz, www.jeremyvoltzmusic.com

  • CP1 (Welcome)
  • Airplane Seatbelt (Interlude 1)
  • RakeBeatChords (Interlude 2)
  • Be Loved In Return (Interlude 3)
  • South Wing (Outro)

Transcript

(The transcript is auto-generated and was slightly edited for clarity)

Roland: Hey, J-M, how are you doing today? 

J-M: Not too bad, Roland. It’s been a crazy month and it’s only February 15th, so oh boy, we’re halfway through and it’s crazy already, but I couldn’t be happier to be here with you today to record our podcast. 

Roland: You mean halfway through the winter or halfway through this episode, or what? 

J-M: Oh my goodness, it’s been crazy, but you know. I just did a webinar this morning. It was such a fantastic experience. We had lots of great folks on it, but it was all about the theme of love. And I gotta say, there’s only so many ways that I can pack the idea of romance into dashboarding and visualizations. 

Roland: Then I have some heartwarming content for you, which is actually very close to my heart because today we’re going to talk about organizational change management. 

J-M: Yes, but specifically in the context of architecture, projects and implementations. 

Roland: That is true, and I don’t know if you knew that. But I started my professional career in change management services. So that’s something that’s very close to my heart. As I said before.

J-M: I thought you started your professional career in the change management of which shell went into the main cannon of the battle tank. Is that not the change management you were managing?

Roland: After my toy phase. 

J-M: OK, after your toy phase. So obviously it’s very close to your heart. Often on the show you’ll hear me talk about the people – I care a lot about ‘people’ and I feel particularly like it in architecture implementations and in large scale change in the way in which organizations operate. The people often struggle to adapt. They struggle to get the resources they need. They’re not really brought along with the technology. I say this in the podcast; I say these meetings all the time. You know, real change is the change in people, process and technology in that order, and I feel like oftentimes those people get left at the back. They’re not at the front of the line. They are at the back of the line, so tell me a little bit more about where you started your career and why you thought change management was such a passionate place to go from a professional start? 

Roland: Well, that’s a very good question, and maybe I’m a little bit special here (like all of our mothers say that we’re all special). As you know I do have a masters degree in education, so that’s obviously something that’s relatively close. You deal with people. I always joked that this is just because the German armed forces are the country’s largest kindergarten and they need some adult supervision. In some cases obviously you learn something, and I started way back when on that topic because I found it, just like you – interesting to see how people are affected by systems implementations and by changes overall. Because at the end of the day I think you can put as many ‘wallpaper processes’, for example, on the wall as you want, and you can put as many black boxes in your basement or your servers if you want. If the person in front of the screen doesn’t want to do it, they won’t, and that is how large implementations fail because people just refuse to contribute. 

J-M: Yeah. I read a really good quote from a book that I’ve been reading, called “Our Iceberg Is Melting” by John Kotter, and it was talking about how change needs to be self-sustaining. What does self-sustainment mean? Well, first and foremost, you need to get the first class of change agents bought into the change. You need to build an engine that gets going and that first part is really hard. The starting inertia of change is incredibly high, but once you have a critical mass of people who believe and understand and are equipped, then they become your biggest advocates. They are truly heroes. 

Roland: Yeah, and I think it’s a misconception that people think when they talk about organizational change management versus the management of change that we discussed with Caspar in the last episode. This is just a “feel, good, touchy, touchy. We’re all happy people and get a participation trophy” exercise. It’s not the focus is on management and you alluded to this. It is something that needs to be managed and needs to be set up. It needs to be sustained to be successful.

J-M: Exactly, and I want to jump straight into this. We have sort of the three sections we go through in every episode but at the beginning we’re talking a lot about the ‘WHY’ and Roland, from your experience of what you’ve seen, let’s talk about why we’re doing this, and let’s first start with the negative. So talking about risks. When you’re looking at implementations and change and transformation, what are the risks that are posed when you neglect the approach of a change management discipline or a structured way of doing things to build that consensus to build that acceptance? And I mean, I think you mentioned it right at the beginning, but those projects simply, they fail. But tell me why? What are the risks? How are they realized when you don’t put change management at the forefront of your strategic vision.

Roland: The risks that might occur when you don’t do change management are that your system implementation or your restructuring might fail. Because at the end of the day, it doesn’t matter how much wallpaper you put on the wall, you know, your new processes or how many black boxes you put in the basement, your new servers and all that stuff. If the person who sits in front of the screen doesn’t want to do it, they won’t. And the reasons for that, I think, is as you said in our pre-recording very eloquently, it’s basically three reasons, it’s authority, its security and its…

J-M: Competency. 

Roland: Really, yeah, or capability, if you will. Yeah, so let’s dissect those three things. What’s the authority? So a typical scenario that you see in system implementation is that you have changes in the role, changes in the org structure. You know, you might not be the head honcho anymore and have as many people reporting to you, right? You have a lesser degree of organizational clout, if you will. That might bring you to a point where you don’t want to have that new role and you resist this. The second point that I see might be pure security when you think about Maslow’s Hierarchy. Maybe you’re afraid you’ll lose your job. Because it’s a rationalization, and we discussed this in the task mining episode as well. You know, Big Brother is watching you. And what does it mean for my job? And then the third one might be a complete personal activity. The internal capability that you have, the competencies that you have. Maybe you’re just afraid that you’re not able to do the new stuff in a new system in a new org structure following new processes, and psychology tells us that will create stress. And then your fight or flight reaction might kick in. Both cases are not good because you check out. 

J-M: Yeah, we were talking before about this idea of expertise and the idea of becoming sort of disconnected and complacent. It was in a different context, but I think that organizational change management around transformation is a big part of that because people have come to expect that their expertise is valuable and that their expertise can get rooted in the way that things are being done. The systems that are being used. So, the technical clicks that are required, or just even how those systems interact with each other, both integrations and from a business value and meaning perspective. And a threat to that is an existential threat to our knowledge experts. We talked about this in other podcasts, with this idea of the replacement of the knowledge worker. There are a lot of people who are worried that their competency is going to be worth less because organizations are going to change around them to make that competency less valuable. And I think the biggest part that we’re looking at in this episode is talking about strategies to make people feel valued nonetheless. To get that complacency gone that’s driven by routine and to showcase the value that they bring to the organization, regardless of whether or not they’re using the same tool with the same clicks. 

Roland: Yeah, there is a concept in change, in org change management to be very specific, which is called the ‘valley of the tears’. So when you think about a line chart where you have the time on the X-axis and you have a stable level of competence, a stable level of output that you produce. So when change is introduced you might go – in the beginning – a little bit up and you say you’re all excited. Hey, we’re doing this new thing, you know, and at some point in time you realize this is harder than you thought. So your mind changes in general and it goes down and actually productivity sinks below the original level, interesting, right? And then on that lowest level, at some point in time, people might check out. People might say hey, I picked this up as a personal challenge and whatnot, and then people start adapting to the new system with your idea, and then you see the curve climbing up to a level that’s higher productivity or competency wise than it has been before in the ideas. Obviously that once that is out, you have a new stable horizontal line in your competency. 

J-M: Right, so now we talked a little bit about the why, and I think that’s really good. And we’ll talk about some other sort of impacts as we go through this. But I wanted to center this in the areas of implementations and how they are affected by change and change management in implementation and in transformation. And Roland, I know, pitch for the website as always (whatsyourbaseline.com), you’re going to have a really great graphic for this.
But we have the three areas we wanted to focus on today in our first section, “why”, which is all about content, adoption and governance. Now let’s go through each one at a time and Roland, this is something that I know you’ve got lots of experience with. So tell me more about the first of these three. Let’s talk about the content. What are we doing with that? 

Roland: Yeah, so the graphic that I’m going to put up on the show notes, as you said, think about a Venn diagram, and all those three circles are somehow connected to certain degrees. What I’ve seen when we come to architecture implementations is that you need to balance all three of them. And depending on who you ask, clients might have different ideas of where they should start.
Some of them say, hey, I just want to create content. I need to create architectural models. I need to be able to analyze it. I need to be able to create solution designs or whatever, right? So they just want to have a tool that helps them do the work. Another group might come and that might be the traditional view of EAs, which hopefully is almost gone. Those are the guys, the committee of ‘no’ and all, you know, the ARB, who say “no we need to put up standards. We need to define the services that we provide to our users. We need to build a center of excellence.” So those are the two areas that I typically see when clients approach us with the idea: “Hey, I think that architecture thing or that process management thing is a good thing. I want to have this.

J-M: So wait, their whole idea is just to make stuff and force people to use the stuff they made? Yeah, that seems like it’s missing that third piece that interlock we talked about, or you’re going to say a little bit right now, which is the adoption side? 

Roland: In my 25 years that I’ve been doing this, nobody has approached me to say “hey I need help with that adoption”. And when we pitch it, I typically draw a diagonal line through that Venn diagram and say, yeah, that’s what clients are willing to pay for. But what’s on the adoption side is actually what makes it sing. And this includes things like communication that we’re going to talk about in a later segment in this show here. It includes things like publishing your results and making that as easy as possible or dashboards. Or have your enablement  aligned to roles which we’re going to talk about in a later segment as well.

J-M: Yeah, and I feel like there are lots of interlocks in between these three pieces. I mean, the Venn diagram does have a nice overlap. Things like between content and adoption. How are you going to make content accessible to your users? And we’ve talked about in a previous episode the idea of standardized languages and easy-to-understand good user interfaces serving it up on a platter. We’ve also talked about content and governance because if you followed in previous episodes, you’ll already be familiar with the idea of process governance and being able to do automation and low touch, low hassle but high compliance monitoring and management of documentation and standards application. The thing that really fascinates me is this interlock between adoption and governance because that’s going to be the ‘soft touch / hard touch’ approach. Like, how much are you using the mandate of governance to drive a forced adoption? So that’s the sort of high level thing. Versus, are you talking about the grassroots acceptance and collective community support of an idea, which is sort of the opposite. Like the community governs itself, almost like I talked about before this self-perpetuating machine. 

Roland: Yeah, I think the key is communication, right? If you just put up a set of rules and you say “hey, you all must abide by those rules, and if not, I pull out the big hammer and you’re in big trouble.” That won’t work. That creates resistance. And I think communication and also enabling users. So training them that they are capable of doing what you have defined in your governance is super crucial. 

J-M: One of the things that I feel very strongly about is explaining why. If people don’t hear why we’re doing something, why this transformation matters, why changing their processes is better. If they don’t feel a personal connection to the mission and the purpose of a change, then a change might as well have been random. And it’s much easier to fight back against something that’s random. Because you can say well, wait a second, “this doesn’t feel like it’s purposeful. This just feels random. I don’t feel connected with it. I’m not going to do it because what I do doesn’t really make a difference.” 

Roland: And you mention it in a half-sentence. It’s not only explaining why it’s important so the company can make more money, or we’re going to be more efficient, or we’re gonna gain market share compared to our competition. That doesn’t matter to the individual. They couldn’t care less, right? Except, of course, you’re the CEO and your compensation is dependent on your market performance, so there are some outliers here. But for the regular person working in an organization, it really doesn’t matter. What matters is more like, how does that change affect me? How am I affected by this? Do I need to change in a way that I might not be able to succeed? Let’s move on a little bit on this. When I think about org change management, I typically see it in the context of architecture and process implementations. I see three big areas that I would like to talk with you about over the rest of this show. The first one is org design. That’s something that people might forget. As a part of change management or change management. The second one is communication and the third topic I’d like to talk with you about is enablement. So let’s start with the org design. J-M, what have you seen on your projects, how org design was done or was not done? 

J-M: Well, I feel like one of the things that is a hallmark of organizational design from a lot of the projects I’ve worked on in companies that have experienced, I’m going to say a medium amount of success, is that it’s kind of done separately. The conversation around architecture is the technical side of the work and there is someone else thinking about this in the transformation. Even if it’s in the same program, it’s definitely a different silo. It’s reorienting how the rules work. We are reorienting how management is done, and it’s not connected into the actual architecture and the structures that you’re building underneath it. It’s driven by ownership. But ownership is also a very sensitive conversation. I always say this in meetings to people. I know that process ownership is a hot button topic because there’ve been a lot of people who have gotten their hands a bit by having that conversation. And sometimes it’s just other people dictating ownership or dictating spans of control and things like that. Oftentimes, outside of the context of the people who are actually doing the work to change the architecture to do the transformation itself, and that disconnection, means that by your very design it’s only a factor of luck if the alignment is very tight. Does that make sense? 

Roland: Oh, it does for sure. What I’ve seen is also the same observation. Separate groups of people doing some magic things that have nothing to do with the architectural work. But one thing you should not forget about this, you also need to talk to all those ‘nasty activities’ like talking with unions and negotiating with them, so there might not be a silver bullet solution. You know, we want the process to run XYZ and therefore we need to do these changes. So you need to keep that in mind as well that you have what we like to call in Germany “Realpolitik”. So that’s not just the ideal thing, but you need to take reality into consideration.

J-M: I’ve also seen some interesting factors when it comes to people protecting themselves and their community. Now I understand that everyone wants to be loyal to those who are giving their trust in them and representing their teams and things like that. But when you come to the table and you’re given the privilege of being part of the conversation around org transformation as part of the transformation program, I found a lot of people advocating for what their group needs, and because they feel like they have to, without seeing the larger picture of what the organization needs. Because really what the organization needs is for you to become part of the new puzzle rather than for your little wedge to stick itself somewhere in this new puzzle. And it doesn’t look like any other piece, so everyone needs to transform together, and the stronger you advocate for your own way of doing things – there’s two real options. Either it becomes a standard and everyone does it the way you do it, which is very unlikely. Or you’ve just wrecked somebody else’s puzzle by shoving something in there they’re going to have to carve around. 

Roland: Yeah, I think this brings us to the question: what is the better way of doing it? I think when we start with that, the first disconnect is you typically see people doing org design that are not part of the architecture group or who are not connected to the architecture group. So in this case, it basically means that they make their org design decisions on a completely different foundation. And my recommendation would be to talk to your business architects because those are the guys who define the future state. And obviously when you then see the roles and what those roles are supposed to do and how they’re supposed to do it, then start thinking about what is the most optimal way of organizing those roles into org units that then would take into consideration things like span of control and all those other things. 

J-M: Yeah, absolutely. And the other thing is that remember, you have this in documentation. Solution designs, a part of your solution lifecycle, should help inform those changes in roles and org structures. I mean, you’re already doing this; you’re having this conversation. Why not use the things you’ve spent money, time and expertise building to inform one of the most crucial parts of this transformation: how it’s going to be run. 

Roland: But that also means that your org change management people need to pick up a new skill. They need to, at least on a very rudimentary level, understand basic business architecture development. Which might be completely alien to them. They also need to learn and understand the foundational concepts of EA. How are things wired up? How do you connect the dots? So that they can take the outcomes of the designs as an input for their work and then create, ideally, the org view of the architecture. So your org change management people actually become something like business architects.

J-M: And being business architects, maybe you could even teach them the platform that you’re using to document. Because if they can see all the relationships in that tool set, they can now leverage the work you’re doing. And so now once again, you’re bringing them in. You’re making them stakeholders in your reusable collateral. And when you have that business architecture tool that allows for it now you’ve made a friend. You made an ally. And most importantly, you’ve enabled someone to be excellent.

Roland: And you make their life easier.  When you can run a report in your process tool that gives you a list of, oh, these are all the activities that a role does, and they’re using this system for it and those transactions. Guess what? Creating a curriculum, for example, becomes super simple, so there are additional benefits there. One thing that I would like to stress out again is when we take a step back on organizational change management. I think I said it before. It’s a management activity. So what you want is to see not only the feel-good stuff and everybody is happy, but you wanna see ‘changed observable behavior’ in people. So that’s the other thing. You need to come up with not only ‘what do I ask people to do and how do I organize them,’ but you also need to define ‘how do I measure that? How do I know that people actually have changed, not by just them telling me so, but by actually looking at it and seeing that they do something differently’. 

J-M: And that’s how you know you’ve gotten there. And that’s going to lead us to our first question for this afternoon’s podcast. Number one is what changes have you seen in your organization through implementation and transformation? Maybe talk to us through Anchor? Where were those changes centered? Are they process technologies? Are they technology changes? Are they structure changes? How were they built and how did those parts interact with each other? And most importantly, how did this change personally affect you? The good and the bad, and what would have made that easier? We’ll give you a couple of seconds to think about it. We’ll come back with our second section, the ‘how’. 

Musical Interlude: “Airplane Seatbelt”, Jeremy Voltz

Roland: Welcome back, and I hope you had some time to think about that single question that J-M asked you, even though I had like 35 in my mind, if I’m not mistaken. But anyways, let’s go to the ‘how’ section of this episode and I would like to talk with you about stakeholders and communications. And how that fits into the bigger picture of org change management. So maybe let’s get started, J-M out of your experience. What is a typical starting point for org change management? 

J-M: Well, the first piece of the org change management is: we need to figure out who we are impacting, right? So that’s going to involve stakeholder identification and then building a plan to reach those people. And never forget that sometimes those people might be one desk over, but they’re very far away, and that ‘far away mentality’, that far away needs to be set; we need to bring that into the analysis. And so the first piece of the puzzle is we’re going to take a look at who we have and plan to get in touch with them. And the next thing we want to do is we want to figure out each of those stakeholder groups like you would a persona for a customer journey. First and foremost, what are they looking for? What’s going to move the needle for them, and what are their goals as part of their role as part of their organization? And how do their organizations relate to each other? How do their roles relate to each other? Do they have things like handoffs at mid-process so you have end-to-ends where they have to interact with each other? Are they consumers or producers of information for each other? Do they compete with each other for resources? In some cases, like there’s also organizational politics, we tend to consider these cases so we can end up drawing a big relationship map, kind of like a ‘net map’. And I know we’re going to put a link to the ‘net map’ in the show notes so people can see what that kind of concept entails. 

Roland: I will definitely put a link below. The ‘net map’ concept is actually looking at individuals. This is John Smith. And John Smith is that guy that always throws a bump into every meeting and blocks everything. Oh, there’s Jane Doe, and she’s good from the bottom of her heart. And she enables all those guys. Unfortunately, the first one is the boss and has more organizational power than Jane Doe. So what that ‘net map’ concept means is it shows not only those hierarchical structures that you definitely will need as part of your org design. But it also maps out the influence of stakeholders on each other. Because maybe the bad guy has a buddy in another org unit who he gets along with. Maybe the only guy in the organization he gets along with. So maybe you could recruit him. That second guy could help change the behavior and that net map concept allows you to map this out. Obviously, you shouldn’t leave that on your table when you talk to your stakeholders. But it gives you clarity about how you go around personal roadblocks if you run into that situation, that you have a stakeholder who doesn’t want to play ball. 

J-M:  The ‘net map’ will be kind of the abstraction level, almost like the analogy would be process mining to task mining getting to the level of the individual actors, whereas the mapping of stakeholders and organizational structures is more at the higher level of how the organization operates. And I’ve also seen, as much as individuals have influences, we also understand the impact of organizational structures on each other. And who’s beholden to other organizations? What are the power dynamics? Not just individuals, but also at an organization level? So I think those like work nicely together and I’m excited to see how you put this into strategy. ’cause particularly when you take all this information now we’ve got it. Where do you take it from there and do with it? 

Roland: So what we’ve done by now is we’ve defined our personas / our stakeholders? We’ve captured their objectives. Where do they want to see the ship go and their needs that they have. And then you’ve defined the activities that might help with those needs and objectives. And on top of it, you should think about the measurement of those activities so that you know that you’ve made it and that you came to that point. So, like I said, a couple of times before, it’s management after all. So what I’ve typically seen in projects is creating a two-phased approach.
The first approach or the first half of it was creating a strategy right where you put all those things in writing and you put all those things on a piece of paper and say OK, this is how we’re gonna hold ourselves accountable for. And then the second half of that sprint was actually implementing all those things that you’ve put into your strategy. All the measures. And see if the organization really changes, and that’s where the observable behavior change comes into play. So having said that, the first deliverable that I would create is an org change management strategy document that includes your stakeholders, the objectives, the needs, the measures, the activities that you do, and so on and so forth. And don’t forget that you wanna socialize it, right. You wanna have the buy-in of the stakeholders? Everybody should give them the nod there. So one thing that I would do is put the collection of those objectives, needs, activities, and so on and so forth as an appendix to the strategy document. So that people say, “oh wait, I think we should do this, and now I see that J-M guy and he has completely different needs. Well, I actually have the same needs, but I didn’t think about this.” So that it goes into iterations. But at some point in time you have to gain consensus from every involved stakeholder that this is the thing that we should go forward with, or in the worst case you’ve identified a stakeholder who doesn’t want to play ball right? And then you need to see how you deal with that situation. 

J-M: Yeah, and I wanted to talk about sort of the buy-in and approval side of things ’cause I’ve seen a lot of people struggle in this case. Remember, when you’re collecting information validating the veracity of that information, that is at the point in time where your stakeholders have the ultimate power to say yes and no. That’s when they’re actually doing the approvals. They’re validating the veracity of the information you’ve collected from them. When you go back to them with a strategy document, the time for them to have objections to your assessments of their needs has passed. Now it’s time to socialize and gain consensus, and if you’ve done the first part right, the approval is a rubber stamp. Because at that point in time, you’ve already done a lot of work. Now this idea that failing earlier is cheaper does come into play here as well, because once again we’re doing the strategy document, but the idea, hopefully, is that all the changes and updates that need to have been done were done prior to this. Then from there you can take that strategy and develop an action plan that has their inputs and their consensus to move forward with, but doesn’t require the big conversation approval at that end time. So if you’re looking to make a giant Excel file or Notion, what does an action plan look like that comes straight out of your strategy document? 

Roland: Yeah, so first of all, it’s a second deliverable, right? I would not put an actionable plan into a strategy document. I might put in some high level things. Think about communication, oh, we’re going to have a newsletter that comes out at this time in another generic newsletter that comes out at that time and what not. But it doesn’t say “oh it goes to org unit A on this date in that medium, with that reaction.” So first document strategy document, high level socialized everybody buys in. Based on that, you create your org change management plan and that org change management plan typically has different aspects. And there are four things that come to mind.
In this case, the first one is, what’s your communication content? When you think about a systems implementation, you typically don’t have the big rollout where everybody gets the same information at the same time. You typically have more like a staggered rollout. And now in your plan you might think about what’s the first type of communication that I have to send to those groups? Oh, it’s a welcome message. “Hey, congratulations, J-M. You are affected by our change. How do you feel about this?” And then you might have a second content communication where you say “oh by the way. So this is what we’re gonna do, step one, Step two, step three, and this is how you’re involved.” And then according to that you might have a 3rd, 4th, 4th, 5th content communication to your end users up to the point where you are done. You’ve rolled it out. People are trained, everybody is happy. So that’s the first one. Communication content in the plan.
The second one is frequency. Is there a pattern of communication for a specific stakeholder group? So think about the end users that I spoke about. I think about some high level stakeholders where you would do fireside chats or whatever with it. Think about big organization-wide communications. Before the pandemic, you would have collected everybody in the auditorium and people would have given big speeches, right? So you need to define your content. You need to define when to communicate, what’s the frequency and how you get to this. 

J-M: And also some stakeholder groups will need certain types of frequencies based on their own existing communication strategies. So the more you can integrate into their expectations, channels, and mediums. If you could integrate what you’re doing into what the expected conversation is that’s happening between the organization and their people, then you’re a winner. Because it feels like it’s their own. It feels it’s got the right smell. That’s what you call the stable smell, and it’s perfect. Now they’re going to be more likely to accept it, open it, read it, and do what you’re asking.

Roland: Yeah, and then the third thing that he wanted to look at, and I totally agree with you, J-M, is to have a look at your communication mediums. And what we see nowadays, and that’s unfortunate in our digital times, is that we have things like emails that nobody reads, newsletters that nobody signs up for. You might have forums if you’re old enough. You remember those days where people went there and did this? Or you might have your Internet and or wiki or whatever, right. People try to communicate digitally, and that is, in my experience, a lot out of touch. Yeah, right people don’t feel valued or individually addressed. Think about if you also wanna do some physical things, and I’m not only talking about, hey send a T-shirt with a project logo to everybody. That’s not great.

J-M: I mean, I like free T-shirts. Don’t take away free T-shirts. 

Roland: In the late 90s I worked on a project with an Internet company. Big Telco and their Internet branch, and we did an implementation of a billing system. Completely new. High tech. The latest and greatest at that point in time. And what we needed to do was migrate about 40 million customers on the fly to that new billing system. So the telco sent out physical invoices every 20 days. So you couldn’t do the migration during the [billing] day; you could just do it when that day was done for them. So what we did is we had a big plexiglass tube, like 8 feet tall, and we filled it with little pebbles. That was showing the progress of our migration. So when you went into the building you walked past that big tube and you literally could see how the pebbles filled up that tube and you could say, “Oh Gee, we have 10 million migrated, 15 million, 20 million”. And at some point in time, obviously the tube was full, we were done. We all went home. That’s nice though, right? We also created a little book. A physical book (in dead trees) that then had photos of all members of the teams right in there, and it had whatever the system modification requests and all that stuff that we did there. And that was basically the leave behind. It was a nice way of documenting what we did. And when you think about the medium for your communications, don’t just think about electronic mediums. People are analog individuals, and think about having something that is tangible for them, and also think about what it’s going to do for them. 

J-M: The pebbles you mentioned, that’s inspirational. That’s telling the story of everyone doing their little bit. And together we’re making something bigger. We’re filling up our cup. But you think about asynchronous versus always available versus notification. Like when I send an email, you may get a notification, but it’s also asynchronously available to you, whether or not you open it. Versus creating a Wiki or creating a poster board or something that you can just access whenever you want so you can walk to that physical location. Or you can go to that website. So it’s on demand, so you’re never left wanting for information because it’s at your fingertips, but you may not see it ’cause there’s no notification. So remember to think about what each medium is going to do for you and how it affects the people who are involved. Because that’s half the story. 

Roland: Yeah, and pro tip. If you think about something like filling a plastic tube or a tube with pebbles, have a chat with the architect of the building first. Those things are really heavy. 

J-M: Well, then, here’s a question for you. How are we going to figure out whether or not what we’re doing is effective? Because that’s the last piece of the puzzle. We’re going to track the effectiveness of our communications, and ultimately, of our change. 

Roland: Yeah, I think it’s two aspects here that you should think about. The first one, as in every good communication, you should establish a feedback channel. So it should not just make your life easier. As the communications person, it should make the stakeholders life easier to get in contact with you. That could be an email address, that could be forums that you set up, that could be open office hours that you set up in your building.

J-M: Because we’re not looking to make the transformation easier. We’re looking to make it easier for people to transform. 

Roland: And if they build up enough trust with you, they will tell you the truth. Which might be uncomfortable for you if somebody is yelling at you, but at least you got the feedback that you wanted. And then the second thing you want to have a look at is how do you measure the behavior. Do the people do what was planned? Do they find shortcuts in the execution of your new processes or do they avoid things? So that is something you might want to have a look at. You obviously could use technologies like process mining for this, but it also might be the occasional chat in a coffee kitchen and just asking them how they’re doing. 

J-M: Yeah, that’s a question for you. How often do you come down on people? How soon after the transformation? What’s this sort of rule of thumb for you? Because obviously as people change, I know they’re going to slip up and make mistakes. Compliance might start out pretty low. How do you guide with a gentle hand, but also a firm hand?

Roland: Well, one thing that we haven’t spoken about is how I set up my org change management organization. And you alluded to it – you obviously have the people who do the org design and the people who do the planning that we just spoke about and whatnot. But then you have obviously the people who execute that might be your trainers. That might be your change agents. Which could be something like super users in your new tools. So they get an earlier training, they’re involved in the development of it, and they just know more by definition. And a good thing that you would think about is if you make those change agents / super users also be your first line of support, then they will get all that feedback. Why doesn’t that thing work? Why is it so hard to do X, Y and Z? And maybe they can ease out those troubles that people might have in the beginning, but definitely they will capture the feedback that they get. Because they have angry support calls in the worst case. 

J-M: So I’m hearing like a pure lead compliance strategy. 

Roland: I wouldn’t say compliance, but yeah, at the end of the day, you wanna have support. 

J-M: You wouldn’t say compliance, but you do mean compliance. 

Roland: What you want is you want to have your users obviously follow your new processes. You wanna have your users use the systems that you implemented in the way that you’ve defined it. 

J-M: Use another word for that besides “you want them to do the thing you wanted to do in the way that you wanted them to do it”.

Roland: No, I’ll just leave it like this

J-M: But I get what you’re saying and I feel like that’s such a great strategy for making people responsible and giving them the power to help each other. Because those are the people you’re ending up trying to serve – part of it, at least. 

Roland: Yeah, and then the other thing is maybe a piece of humble pie. If you get the feedback that you don’t want to hear, which is actually the best that you could get because people have built trust with you, that they dare to tell you that well, you should go and adapt your communications material, your change management plan, your change management strategy if you want. It’s not a failure if it doesn’t work, and I think that’s the biggest misconception. People are different, and what works for one might not work for another. So what has worked in a previous project where you did this – that doesn’t mean that it works for your current project because people are different. So just take a step back and don’t be upset if somebody tells you that you are the stupidest person they have ever seen and that this is the worst stuff that they have ever seen in systems. And why is it just half-baked and all those wonderful things that you get. But reflect,  and think about what you have to change.

J-M: Yeah, and one of the other things is to remember that communication is really the long tail of transformation. It’s the one that goes for far longer than a lot of the other parts of a project. After go-live, you need to try and reach a steady state and you’re going to know that you get there from a couple of different things. You want your target group to be self-sufficient. I talked about how a change that is self-sufficient is sustainable. You want your target group and your organization to have reached your business objectives. And you want to, for the most part, have overcome resistances that are being experienced along the way. You want to make it easy to get started, easy to love the change, and easy to live in that new space that has changed too. 

Roland: And just to make it clear and repeat what you just said: don’t stop communicating after go-live. I’ve seen so many projects where you had your go live and you maybe have enabled the first user group, which is like maybe 5% of all your end users and then the project team gets disbanded. And people just go elsewhere, leave completely, or be assigned to different teams in the next release or whatever. What you might see is that resistance might come up after the go-live. When you open the floodgates to the other 95% of your users. Because like I said before, people are different, and I think it’s very, very crucial to communicate throughout the whole lifecycle of your project or your program and not stop after go-live. But, J-M, what do you do when you’re done with your project? The big tube of pebbles is filled, and there’s actually not more to do than to remove the cobwebs and put your computer back into a box. 

J-M: You put your head down and you trudge back home…. I’m just kidding. You celebrate! And that’s something we should do together. Remember, people are involved in your project in very different ways and not all of them have visibility to the great achievements that the project has been able to get to. Some of them were seconded for part of the project, and some of them were in one very small business area. So bring them together in the same way you do a kickoff where it’s so important that you get all the people in the room, you have to do a celebration, a closeout, and a recognition of the amazing work that’s been done. It is the privilege of human nature to want to enjoy success. Give them that catharsis.

Roland: And it also might lead to very interesting situations. To stick with that example that I mentioned earlier, at the telecommunications company, we had a big party afterwards. Everybody was invited and whatnot up to a point where we put a Smart car in the room and you had the C-level guys filling the smart car. And the exercise was how many people could fit into a smart car, you know, and then think about the CEO hops in and the CFO hops in, and then they try to fill it. And I forgot how many people they fit in, but it was definitely more than the two that were allowed. 

J-M: They fit in four HR violations, excellent. I’m kidding, I’m kidding, no. But so summarize this for me. Because we’ve been talking about it a lot. What is communication? Why is it important and how are we seeing people do it so it’s successful? 

Roland: So one thing you should not do is you should not see communication as an afterthought or a second thought. “Oh, that’s something that I have to do.” I think this is the critical success factor in any project. And just remember, changing people and changing people’s behavior is the most difficult thing to do. So, dear audience, let me bring you now into our second pause into our show, and I have a couple of questions for you. I don’t pretend that it’s just one. So within the next couple of seconds, think about the time you had to socialize or change. Which of those things that we mentioned, did you do? Which of them didn’t you do? What worked and what did you struggle with, and what could you have done better now that some time has passed? We leave you alone for a couple of seconds. Listen to the wonderful music of Jeremy Voltz and when the music’s over, we come back and go into our third segment.

Musical Interlude: “RakeBeatChords”, Jeremy Voltz

J-M: All right, folks, thank you so much for taking a couple of seconds to think about how this might work for you and where it hasn’t been in the past to really communicate well with folks during a change, but there’s another part of this puzzle. Roland, I would love to dig into that – it’s beyond just communication. It goes beyond just developing a plan for talking to each stakeholder and getting that right message. It’s also about the content . And Roland, I know you’ve had to do this a million times. Talk to me about enablement as part of org change management for programs. 

Roland: Yeah, and we briefly touched on it already. Enablement is the third large change management topic in programs, after org design and communication. You should use your business architecture design for your training designs. You have your processes mapped out, you know the roles that do stuff in there. You know the systems; you know the transactions and all that stuff. 

J-M: And if you have a tool that does connect with things like training material, development tools, and learning and development systems. Oftentimes they’ll be an interface. Just saying, kind of useful. 

Roland: This is not for all the SAP users here. They all know that already.

J-M: [Rimshot]

Roland: So, J-M, talk to me a little bit about the phases that you go through when you develop your enablement program? 

J-M: That’s a great question, Roland, and we’re going to obviously put this as a part of a transcript on whatsyourbaseline.com. You don’t have to take notes as you drive, but let me go through them one at a time. So the first one we’re going to talk about is curriculum, so you’re going to figure out what curriculum you’re going to need to teach. And as a note, you would probably want to have different sets of curriculum as well as different training methodologies depending on your stakeholder groups and their particular needs. You’ve done that work; you’ve identified them at the beginning, so you’re developing sets of curriculum. 

Roland: Agreed, and when you do training, don’t make the mistake that I see way too often when people do this in the fact that they just show how a tool works. In my opinion, good training has three components. The first one would be governance / rules of engagement. How do we run the show here? What is expected of you? The second part of your training might include concepts. When you think about implementation of an architecture tool, you might wanna talk about what BPMN is as a notation. What does that actually mean? Or how does accounting work in SAP? And then the third part of it is actually then the tool enablement – which buttons do I have to press to do this or that? 

J-M: And I feel like a lot of people developing curriculum only ever focus on the third. They’re thinking: “OK, how do I get someone the shortest path to being functional in the tool”, but being functional in a tool doesn’t mean being functional in the business. It means being able to click buttons, but you never know why. Or, in the case of any sort of variation that comes up every single day, how to handle daily life as someone working in this new org and infrastructure change. So that goes hand in hand with enablement strategy, right? 

Roland: Yeah, that’s the second part of it. So we spoke ad nauseam about strategy and a plan as separate documents in the communication part. But that’s also true here. Do the very same thing – identify your stakeholders or your target groups that you have to train and then think about how to train them? What’s the content that I’m going to train them in? What is the frequency that I will interact with them? And that obviously goes hand in hand with your communication folks, which sometimes is a different group, where you bring your input into their communication material. So even within the org change management team, don’t have separate workstreams, they’re all tied together.

J-M: And one of those work streams is going to be the people actually developing materials, so that’s the third piece besides curriculum and enablement strategy and plan is actually making the material. So going and writing the documents of various different flavors of documents and setting up infrastructure. So remember that as part of enablement, you’re going to want to give people access to sandboxes and test environments and places where they can get their hands dirty at no or low risk. 

Roland: But it’s also the basic thing when I think about infrastructure – you need somebody who sends out invites. You need to make sure that somebody is there with the key to open the door to the training room. You need to make sure that somebody brings refreshments for breaks in all those types of things. 

J-M: Yeah, that’s where your executive assistants and office managers and training coordinators work hand in hand to build an inviting environment for people to be involved in. Every sort of barrier to entry you place makes it harder and harder to execute on the strategy. 

Roland: Yeah, but be honest with them. Don’t do cheesy things. I’ve seen that where people set it up as if a 35 or 40 year old participant goes into the training room and it looks like kindergarten. That instantly removes credibility from what’s to come over the next 6 to 8 hours. 

J-M: And that’s going to tie into the fourth piece of the puzzle is conducting those actual training sessions. Roland, I know both of us have done so many training sessions. And to me, what makes a training session really successful is first and foremost a clear organization that’s laid out and told to the participants so they understand what they’re going to learn, what the expectations are of that session, and then having those pieces in place beforehand. Good curriculum, a good plan and strategy that fits into the larger picture; an infrastructure that supports the execution of the training plan and the sessions themselves. As well as technical infrastructure that people can work on. You’re going to run these training sessions with experienced trainers (people who are good at speaking) but you want to make sure those people have a good knowledge of the business and the systems. So it’s kind of this ‘Goldilocks Zone’ of someone who has all three contexts. And there are people who are experienced specifically at this. There are people who are really good. I would say that it’s probably easier to be able to train somebody on the business context than it is to train them on the very difficult skills of corporate training in an organizational change context. So I’d rather get a very good trainer and teach them how this particular organization runs than to get a really good organization member and try and teach them how to train people. 

Roland: And that also might be a thought when you think about how to set up your change management group. We’ve seen client personnel being super users and doing first level support and all these types of things. You might want to think about a ‘train the trainer’ program so that you as the external person stand back and don’t do the training, but have somebody who’s part of the organization and who comes with the organization clout to give the training, because they have by definition the higher credibility. 

J-M: That’s a good point. So let’s say I’ve done that fourth thing: I’ve conducted a training session. Now what do I do, Roland, and what are the after effects of training? 

Roland: So what you should not do is what every training that I’ve attended does. Have a questionnaire that asks: how was the training? Did you like it? Did you like the material? Did you like the trainer? Were they competent? 

J-M: “Give me 5 stars”

Roland: Yeah, exactly that thing. Because at the end of the day you will see social expectations. For instance, you just got a three, J-M? That wasn’t good training, was it? So don’t do this, but I’m saying that with an open mind, because obviously it’s nice to get feedback. If somebody really screws up, you might want to replace the trainer. Sure, if the feedback is, I haven’t learned anything in the last 8 hours, you might want to have a harsh conversation with the person. But I think the more interesting thing is not to see what people feel about the training 8 hours after the training, but it would be interesting to see if they learned something six months after the training, right? So did productivity go up? Do we still see people struggling with using the system? Or did we train them well enough and provide them with enough support? Things like Wikis and all that other stuff. Have they actually succeeded in using a new system? 

J-M: Yeah. I’ve actually had this conversation with numerous clients back when I used to do a ton of training. They would buy a training package and that training package would be a five day training. So there’s me coming in for five days and I do two basic days, two advanced days and one specialist day. And so after those five days, a bunch of folks would leave the classroom and be like: “OK, I know how to click the buttons. Cool, thanks goodbye.” But the really, really invested people in the organization would say, “why aren’t you coming back next week?” I would respond “no, you already did the training.” And they would respond “no, we want to practice. We want to get into using the tool.” And so I often find myself recommending for clients to go through the training time required to know the clicks and then having a coaching period of decreasing support from that enablement team to help sustain that training into long term memory. Because otherwise it’s just going to go away. It’s like, you know, carbohydrates, you eat them, and then you’re hungry again in a couple of hours. 

Roland: Yeah, and it’s also critical that you find the right point in time. It doesn’t make sense to trim somebody today when you know that they’re going to use the new system three months down the road. You know, they have forgotten everything.

J-M: That’s the worst. When I’m like, “when are you going live?”, and they say April. It’s January. Don’t train your users now! Oh boy. 

Roland: That brings us to the next point, because getting feedback is obviously one thing that helps you measure change. The other one is literally measuring behavior, right? So six months after the training, go into the organization, look over their shoulder, look at your process mining / your task mining analysis. See something really has happened. See where people still struggle, right, and then drill down and see whether it’s a matter of the process that’s not designed right? Or is it a matter of the person who still doesn’t know what to do in the right way. You want to figure that out, so again, it’s change management and you’re looking for behavior change. That’s crucial. And then the last point is to adapt your strategy. Adapt your plan, adapt your material as needed. The fact that you spend so many hours creating this doesn’t matter, if it doesn’t work for the people. 

J-M: Yeah, so to summarize all these things, it’s curriculum enablement strategy, developing material and infrastructure, conducting training and coaching, capturing feedback, and adapting, planning and creating sort of the iterative cycle as our seventh piece of the puzzle. That’s a pretty good piece of information for folks who are looking to do enablement, and this can look a bunch of different ways, right? This can look different for everyone. You want to be adaptable with this, right? 

Roland: Yeah, for sure, because at the end of the day, people learn differently and you should accommodate those different or multiple learning styles. That obviously has some follow-up activities that you might not like. If you’re an external organization and you have to write a statement of work for your training, you assume there’s a certain effort, right? And mostly you have a ‘one size fits all’ approach because you don’t want to put so much effort in there that you price yourself out of the competition. But at the end of the day, to be really effective and to accommodate the fact that people learn differently, well, you will have to produce different sets of material. And that could be maybe a book that you write or you assemble it into an ebook. You give your users a reference guide. And I don’t know how many people in the past have seen manuals that come with their software. I think that went out of style like 20 years ago. That might be one thing, or you might have the actual training material and you make that available on this. Or you have articles on your Wiki that explain those things. Where people can interact with you and ask questions and all that stuff. 

J-M: Yeah, actually, I saw one of my clients do something really clever. They had a specific style of monitor in their offices in the before-times. They had a specific style of monitor and they had a clip on the monitor and they printed out and laminated a bunch of quick reference guides on how to use the architecture tool that I was consulting on. And they just left them out for people and they would just take them and they would go and they would slot them into their monitor like side by side with it. Like another screen. And so they would just be working and looking and working and looking. And it was just sort of an organic aid – like, oh, this was meant for me. This is perfect and it makes my job easier and that’s an ongoing support that I have that was just made. It didn’t take very long to make this, but it made a huge difference in their lives and that’s perfect to make that training stick. 

Roland: Oh, absolutely, and the worst thing is obviously when your laminated cards cover over the post-it where you have your password. But in all seriousness, I think what you have to produce is not just your training material. You also think about the support for your learners. The support for your end users. Make material available to them or have activities that you do. Think about things like online forums, where you have the big meet and greet on your forum. Or think about in person events (if we’re allowed to do that at some point in time), things like office hours or fireside chats, or all those things that we all desperately are missing these days. Bring them back into your training program. 

J-M: And you also want to make that training program continue to be relevant, right? And the only way to do that is to establish and maintain a knowledge management principle in your organization. The idea is you want to keep content relevant, you want to know what’s there, and you want to groom that content as you continue to evolve so that your material remains relevant. Because remember that the change you’re making now  – think about it an ERP change – that may reverberate throughout the organization for the next 5 to 10 years

Roland: But this is starting to get into the topic of knowledge management that we can talk a whole episode about, and I think we will. I have an idea who we invite for this.

J-M: Excellent! So, Roland, I’m going to call it for this episode. It’s been unbelievable so far. I have one last question for all of our folks at home. Think about what you are doing to help the changes stick in your organization. How have you been involved in the enablement, how have you been involved in the promotion of change? And when the next change comes to you, how are you best going to adapt to both support the change, help it grow, and also help yourself make that change really stick. We’ll see you in a moment.

Musical Interlude: “Be Loved In Return”, Jeremy Voltz

Roland: Welcome back. I hope you had the time to think about the question that J-M asked you: how to make change stick and how do you adapt to the change as it comes. What we spoke about in this episode was basically (if I do a little summary here) was talking about why change / why is change crucial? What are the three areas of successful implementation when you think about standing up your architectural practice. Think about content governance and adoption and how critical adoption is. And then we dove into the three main areas of org change management in this content. First is org design. Remember, don’t have a separate group. Make your org design people little mini business architects so that you work on the same thing. We spoke about communications and how you get consensus with the strategy document and that org change management is management after all. If you think that way, you wanna see behavioral change. And then we spoke about enablement and that people are different. People learn differently and the seven steps that you hopefully did not note down while driving (public service announcement). The seven steps that you might want to go through to plan and stand up your enablement program.

J-M: And speaking of all of you, thank you all for listening. And Roland – this was incredible. I really enjoyed chatting back and forth with you about this topic, particularly since we live in a time of great change and organizations are struggling to adapt and change to meet those needs. And so everyone on this line: you’re going to go through this, if you’re not going through it right now, you’re going to go through it soon. And we’re hopefully here to help you understand how to make it a little easier, a little better, and to make it really stick and count. So you can give us some feedback, help us change how we do things.
We talked about feedback as a really important mechanism. You can hit us up at hello@whatsyourbaseline.com or leave us a voice message on Anchor. If you happen to like using that platform, we’d love to hear your wonderful voice telling us all about stories just like ours. Now, of course, we would love to get a review from you, and of course a rating in your podcatcher of choice. So please go and do that. It really helps us as we try and grow this podcast to meet everyone else in the organization and in the world who’s doing what we’re doing. And of course, all of the things you’ve heard today are going to be available on our website at whatsyourbaseline.com as a full show notes at whatsyourbaseline.com/episode17. Well, once again, I’ve been J-M Erlendson.

Roland: And I’m Roland Woldt 

J-M: And we will see you in the next one.