 And here we go. Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager of DataVercity. We'd like to thank you for joining the latest installment of the Monthly DataVercity Webinar Series, Advanced Analytics with William McKnight, sponsored today by Matillion. Today, William will be discussing organizational change management and becoming an analytic organization. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them by the Q&A in the bottom right hand corner of your screen. Or if you want to share highlights or questions by Twitter, you can also do that using hashtag ADV Analytics. And if you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the bottom middle of your screen for that feature. And if you'd like to continue the conversation after the webinar, you can follow William and each other at community.dativersity.net. As always, we will send a follow-up email within two business days, containing links to the slides, the recording of the session, and additional information requested throughout the webinar. Now let me turn it over to Sean for a brief word from our sponsor, Matillion. Sean, hello and welcome. Hey, thanks so much for having me. I appreciate everybody taking their time today. I'm getting my screen all shared up. Hopefully everybody can see that. Again, my name is Sean Johnson. I'm with the company called Matillion. I've been in data warehousing for about 20 years now, last two years or so in the cloud data warehousing space. Today, as we talk about the complex concept or topic of organizational change management, one of the things that we really kind of want to focus on is creating a technology stack that reduces some of that complexity. And this is where Matillion provides a nice solution. We are simple. We have a really easy to use, no code, low code UI. We scale based on the cloud. We offer paid as you go pricing models. And then we provide you guys really fast time to market with your products. As we look at this, in our modern data analytics ecosystem, not much has really changed. We still see a lot of various sources over here. These are going to be very complex. But we see on our right side that things are getting a little bit more consolidated. And where a tool like Matillion fits into this modern architecture is through what I call automation, of source control management. And so we'll look at source control management a little bit and how Matillion can support you through that process. Built into our tools, you're going to find tools like the Git integration, a Matillion API. What these allow you to do is create data lineage and documentation so that you can understand your analytics ecosystem and then apply appropriate change models and methods that you'd want to utilize. Oftentimes within organizations, we don't necessarily always understand the process that we follow, but using a product like Matillion and ETL development, give us insight into how that data moves within our ecosystem and the different ways that we need to manage that from a change perspective. It also allows us to kind of monetize the various changes that we're going to go through. And then what we can do is we can apply automations to those processes so that we really generate solid documentation, which creates lineages within our environment so that we fully understand our data analytics environment. Also, as part of this, you're going to end up creating what I call operational reports. These are data-driven operational reports that run off of your Git integration and your Matillion API development so that you really understand which of the data that you're bringing into your warehouse adds value to you and which doesn't add value. And then we can apply change models to that so that ultimately at the end of the day, we end up with really high quality change practice through our data warehouse development environment. And the final thing that I would kind of say about best practices inside of Matillion is we're changing every day. Change doesn't stop. And so really what we like to do at Matillion is we like to build change into our process. We release about every 12 weeks and that gets us into this kind of cyclical continuous change process so that we're always manning change within our environment. And we find that this enables our organization to stay ahead of the learning curve in a lot of cases with the various vendors that we work for. So as William kind of dives into organizational best practices for change today, I want you guys to kind of think about automation tools that you can use that underlie these practices that William's gonna discuss to really enhance what you guys are doing as a business and generate much better outcomes for you. I wanna thank you guys for your time. And with that, I'll turn it back over to Sharon. Sean, thank you so much for kicking us off. And thanks to Matillion for sponsoring. If you have questions for Sean, feel free to submit them in the Q&A section in the bottom right-hand corner of your screen as he will be joining us in the Q&A at the end of the webinar. Now let me introduce to you our speaker for the series, William McKnight. William is the president of McKnight Consulting Group. McKnight Consulting Group focuses on delivering business value and solving business problems until problems utilizing proven streamline approaches and information management. His teams have won several best practice competitions for their implementations and he has been helping companies adopt big data solutions. And with that, I will give the floor to William to get his presentation started. Hello and welcome. Thank you, Shannon. Thank you, Sean, as well. Change is a key word today. Word of the day, you might say. Sean talked a little bit about how important it is that your technical solution embrace the change that's going to happen within the technical architecture, specifically for a company like a Matillion. Changes in the source that are required to get pushed through to the various targets that that data goes through. We all know data goes through many permutations throughout the organization. And I'm gonna talk a little bit about a different kind of change, organizational change, people issues, people change. Now, this is going to be the least technical of all of the talks in this series. And this is the, I believe this is the 18th talk in the series, Advanced Analytics. By the way, you can see some of the prior sessions out on YouTube, as well as here at the university. So feel free to browse them. And I also looked out on the roadmap of what's coming up. And yes, this is going to be the least technical one. But if I were to assign importance to the topic for your success out there, I would say this is possibly the most important one. It's not as sexy as some of the others and myself. And I'm sure a lot of you enjoy the technical aspects of our projects much more than this stuff. But it is absolutely required for success. So let's get into the topic a little bit. What we want to avoid is this. What we want to avoid is attention organization, enterprise, we are now in production. So start to change, start to use what we've built here. No, and let that be a surprise, right? And they expect that that's going to cut it and get people to use this, whatever it is. No, it should not be a thud out of the tree like this. It should be something much, much more gradual. And we have to account for these issues all along the way throughout our project. This is something I've learned in my practice leading consulting groups for 20 years. And we've incorporated it into our practice with a high degree of success. I'm going to share that with you here today. And I hope that it helps you become more successful. I'm sure you're building some great technical foundations out there. I'm sure you're building some great data. But let's get those users to actually use it. Let's get those application developers to actually incorporate our data into their projects. And so I'm going to be very specific with you and give you some tactics, some techniques that I suggest be in your project plans and be on your agile backlogs. Now specifically, we're talking about trying to lead an organization into the world of analytics, the modern world of analytics, that is. Because I don't find too many people say, oh, we're not doing analytics here. But if you dig, if you dig as I do, you find that, well, it may be some fairly shallow use of analytics. So let's know that we're talking about some mature, modern uses of analytics, which probably includes artificial intelligence and machine learning, probably includes big data as well. And these types of analytics are absolutely critical to business success today. Now, this isn't the data maturity talk, but I make that point loud and clear in that talk. I believe that was last month's talk. Predict what is going to happen without intervention and actually intervene. I actually had to talk about predictive versus prescriptive analytics, and that's what I'm talking about here. Prescriptive analytics, doing something about what you're learning about. It's great to learn about what's going to happen, but you have to know what you're going to do with that information. Don't just report on what did happen and then let that be it. That's great to see the sales figures from last month, but how does that impact what we're going to do on a go-forward basis? Get business representation in determining the analytic calculations and predictive models. Again, you find this as a recurring theme in all that we do in information management and analytics. It's integrating with the business and being sure that we have that business representation in everything that we do. We're not coming up with the analytic calculations or predictive models, but the business side is. And some of us sit real close in that, but I find that most people are either implementing the technical side or the business side of it. They may sit right next to each other and be on the same team, and that's great. And we're going to get into some of the business models, how we can form to make analytics most effective within the organization. But still, we want to see that integration. Determine the analytic data that will be useful to business strategy. And I might kind of, with a wave of the hand, say, well, that's all your data. And then some, your third party data as well. And at some level, maturity probably is. But maybe the key here is determining a priority of data that you can bring under management and get in the enterprise architecture, not sitting out in silos, not sitting out in someone decided one day that it's going to be this way and nobody understands it or believes it, et cetera. Not that, but inside your leverageable data warehouse, inside your leverageable data lake, inside your leverageable operational data stores. And yeah, of course, you're going to have some data marks for good reasons outside of that. But have a true architecture might be another way of putting that bullet. Involving analytics in every initiative and business decision. That's right. Every initiative and business decision. If there's an initiative going on that does not have analytics consideration, as part of it, that is something to be improved upon. And hopefully one of the models that we talk about right here is going to help with that. Because analytics, again, needs to be part of all projects. So we have to know what those projects are. We have to have the analytic resources eventually at some point, knowing what those projects are and involving themselves and the analytics appropriately. So we have different models here. Center of excellence. Now, the difference between the center of excellence and central lies has to do with the influence of that organization. So with a center of excellence, you get more localized influence from that center into the various use cases, projects, et cetera, that's going on throughout the organization. So in a COE model, analysts are actually allocated to the units to the projects. Activities are still somewhat coordinated centrally. But the analysts are residing out there, at least for a temporary basis out there actually in the projects. And this, by the way, is the model that I like the best, especially for an organization that is of low maturity or getting started with their analytics program, getting started with their rollout. So start here and keep some elements of this, I would say, throughout your analytics journey. Now, another one is decentralized. And this is kind of problematic in my view if you go full decentralized, because sometimes I find that that's like saying, we're not really doing anything about it. We're just maybe nominally thinking about it within our project teams. But there's no central coordination or central functions in that. Then there's centralized, which I talked a little bit about, centralized though, you're not going to allocate resources. Resources are not actually reporting up through the project teams. They're centralized. And the project teams have to dip out into that centralized group to get what they need. This is effective as well. And of course, every organization is different. And you should think about your organization and what works there as you go through that. But I think that you're going to get more powerful center of excellence, more power from a center of excellence approach. And finally, you have a functional approach where you may have to do this, where you have all the analytics are driven by a functional agenda, but there's no vision of getting this to go broader within the organization. And finally, some overlay on top of all this is you might use consultants to actually do one of the above functions, which can take on quite a different persona than what it ultimately will inside of your enterprise, once you incorporate. OK, successful analytic organization transformation efforts require much more than the right analytics and good planning. And it requires a lot. It definitely requires more than good technology. That mentality is still out there about, oh, yeah, we can just buy it. We can just buy fraud detection. We just buy predictive maintenance. We can buy supply chain management. No, it's not a buy. It's a build, but you buy things to support the actual build of the various projects that you want to have within the enterprise. Good technology. Just buying it will not solve it. And I've been doing a lot of these budgets. I'm actually writing what I think will be a very good, very big paper for our industry on the true cost of modern projects with machine learning and artificial intelligence. And as we know, some of us, the professional services, the FT costs, and so on, are definitely going to be more than the technology for the most part. And that's still true today. So keep all that in mind. And I'm actually going to suggest in this presentation that we allocate a certain percentage of our budget towards these organizational change activities. So we will encounter many risks that are people related. Yeah, many risks that are people related. I can't tell you how many times I've come in to analyze a data organization, a data infrastructure, and I've found that I really like it. I think they've done a great job here. But the business side does not seem to agree, or at least they're not showing any of that. And sometimes it's the actual reverse. So either way, we've got to bring up the people side of this. Now this is a slide that I think belongs on, if not your walls, in your project artifacts and something to pull out when there seems to be an issue. Because the issues usually come back to something in regards to this, at least at some level. At some level, if leaders are not aligned with the transformation case or change, if they don't get that, you know, the projects that we work on, we data analytic professionals, the projects we work on are highly transformative to the company. I'm not talking about building a report. If we're working kind of break six stuff or working off a queue, I'm talking about the projects. Talking about leveling up our supply chain management, doing that predictive maintenance, doing that fraud detection and so on. Modern projects, leveling them up. We're all doing that stuff, but are we doing them to modern standards? And a lot of companies out there today, even with the pandemic and the shutdown, are doing those kinds of projects. They're leveling up in terms of the basic functions or taking them into artificial intelligence and so on. But the leaders are not aligned with that. There's going to be issues down the road. If departments fill they have little or no input in the process, clearly that's going to be a problem. Employees are concerned about how new processes will impact their current jobs. And this has to be handled delicately. What can I say? I do find that most people will come along eventually with the new way. As a matter of fact, you know, it really is our job to level up our organizations all the time. And that's essentially what we're doing with our jobs. We're not, you know, quote unquote, I won't say we're working ourselves out of a job, but we're leveling up the organization. We're hopefully growing into the jobs that our organizations are going to need in the future. So corporate change might be resistant. Corporate culture might be resistant to change. And that's a big problem. And that's something that, you know, we're definitely going to need to work from the top on. But good news is in the plan I'm going to give you, there is some working from the top that we do. Interruptions and day-to-day operations. Yeah, it's okay if you build that data lake out there. It's okay, just don't bother me. And oh, you don't really expect me to actually use it once you build it. That is a formula for failure right there. We are going to have to appropriately interrupt business and interrupt day-to-day operations and get some time from the stakeholders. You got other things going on. Of course, the staff itself is not adequately prepared to execute new processes and technology. You know, one thing that you'll find in my speaking, I'm motivating a lot. I'm trying to motivate us in data and technology because I really believe that we're sitting on the gold of the organization to pull a sentence from last month's talk. We are sitting on that gold and we have to be bold. We have to be assertive about that in order to get the company to understand and offer their own good, our own good, all good. Change readiness in organization impact assessments can provide OCM leaders. OCM for organizational change management, by the way. You'll hear me saying that. With additional insight into the people risk. So let's look at some of the things that we do out there. We build data warehouses. We build data lakes. We build business intelligence. We build analytics, et cetera, et cetera. At the top level, what do we want when we build this thing? We want use. We have to have use. We cannot spend millions and let it sit there. We want people to use the warehouse, not the old ways to get the data. We want people to accept that the data in the data warehouse is great. It's what they need. Not question is quality or it's completeness or any of a number of other things. Think of other uses for the data in the data warehouse. Not the first use. First use is the only use. That's not a data warehouse to come to think of it. That's not a leverageable artifact that you've built there if you think of it that way. We want the users and the business to contribute derivations, calculations, summarizations for the data warehouse, not just, oh, it's okay that you built that, that data lake, whatever. I will come and get the data off of there as quick as possible and get it out here to where I'm comfortable in my warm pond of Excel. No, that's not what we want. We have to work that side of the equation as we build our data infrastructure. Master data management, I'll be quick about this. Not everybody's doing it, but you should probably, but anyway, you'll often hear me say this as I come into a company to talk about master data management, to build a project, to do an assessment, et cetera. At the end of the day, I want people to get their master data from MDM, not other ways. I want to be the single point of this. That makes it leverageable. But if they're still gonna get data there, they're old ways, then I have failed. I want people to contribute their master data to MDM. That's the converse, right? So get and contribute their data to master data management, not the old ways. We're creating a very efficient structure here. We're creating something that we're gonna build once, use many times. Now moving on to big data. All right, now, I don't know if it's okay that I say big data anymore. I get chastised for saying big data, like I said, that's an old term, but still a lot of organizations are breaking out of their normal, if you will, alphanumeric data that fits nicely into, or could fit nicely into Excel. Breaking into big data, sensor data, clickstream data, a full log, full call detail records, et cetera, everything. So we need to extend our business analysis to include big data, it's not okay. It's not okay to sit back and say, well, nobody's asking for it. So I guess I don't need to do it. I don't need to think about it. I don't need to motivate that. No, I say you have to motivate that. You have to motivate it all. If you know it's good for the company, you have to motivate it. Even if you're busy and it's not something you can handle today, it's something you can negotiate into your plate, somebody's plate, but the business absolutely needs big data, whatever that means to you and your industry. Every industry is a little bit different. We have to get them to trust the big data collection process. It's as good as it, that it is as good as it gets. It's not something that we just threw together and we're losing pieces here and there, and it's just bad. We got to get the business to also think big and think beyond what they're doing today. Really, the death knell for a company is everybody's still doing the same thing year over year and expecting that that's gonna be competitive. That is not competitive, absolutely. Okay, response to change. Now, I'm not taking us back to, I don't know, Psychology 101 here or anything like that, I hope, but this is true. These steps are true, not just in our personal lives. They are true in our corporate lives as well. I have seen this happen. I can almost read out where people are on this now, on my projects and on your projects. Starting with denial. A lot of people, everybody goes through this for everything. Some of us go through it a lot faster than others, so. So, when you know that the end of the road is down there at the end, maybe I'm spreading the word or this isn't bad, wherever your good end of the road is, knowing that you're going to get there should help you get there. I hope that made sense while I just said, but it helps me know that when I face resistance that there's hope. There's hope to get through this because it's normal, that's people for you. We will deal with people, right? So, let's go through this. The change won't happen. Yeah, you can, I'll pick on a data lake. You can build that data lake, but I just don't think it'll be, I don't think it'll be good. I think you'll probably fail just like the last one or two and it's another fad and blah, blah, blah. That's denial. It won't affect me. Well, you might build something, but I'm going to be able to keep on going with my life. I'm not going to have to spend time right now thinking about this data, I think you called it a lake, okay, that you're building over there. So, because I don't think it's going to affect me. And okay, well, it looks like you're going to production with something here, but yeah, it won't last. It'll be short lived. Oh, now I'm angry because it's kind of creeping over into my territory. It's got data that somebody expects me to use, but I've got this clunky old way of doing it and I spend three days a month doing it, but I like it and I'm comfortable with it. And I never bothered to learn, you know, what they're doing to build what they're doing. Okay, I'm going to kind of try to stop with the role-player, I can't help it. But you go through that anger, you go through the depression about it, oh no. And then how can I stop it? Then you start bargaining, okay. You know, maybe I'll use it a little bit. You know, I'll try. Give it a, give it the old, you know, baseball try here or whatever. I'm going to give it a try and use some of that data lake. And hey, hopefully you get to, this isn't bad and I'm spreading the word. But no one individual, if everybody is stuck at denial, if you allow everybody to get stuck at denial, and that's a really rare situation by the way, but people will look around, they will look around and see where everybody else is on this journey. And they will act accordingly. So if everybody's in denial, you got a real problem. If everybody's in, it won't affect me. You got a real problem there. So from the start, there are some hills worth dying on, on these projects. And one of those hills is you have to get the users involved. We cannot do this without, without their input. And yeah, because a lot of them are going to be, unfortunately on the right side of this cat, this bell curve, where they are skeptical. They will come in, but they'll come in late. We love the ones on the left. They're going to come in and adopt early. And yeah, we can take a few innovators on. Now the good news about all this is, this bell curve as you see here, that's about how people do shape out in an organization. So you're probably not going to have all deniers, okay? But it's your job to identify who your important stakeholders are and where they are on this curve and act accordingly. And, you know, you're going to have some skeptics. You have to maybe overweight in terms of how you are treating them, but not to the complete detriment of taking care of your early adopters, okay? It's a balancing act. And I'm going to leave a ton of judgment in there as I give you all these tasks to do here on your projects. I'm going to leave a lot of judgment out there for you as well. I can't take that away. And, you know, nobody from a teaching position as I'm in here today and frequently am can take that away from you, you know, to adopt that within your organization. Okay, let's get to it. The analytic organizational OCM strategy. OCM will focus on mitigating the people risk and enabling the realization of business benefits across these five areas, five areas for you here. Training the workforce. So they're not behind when it comes to what they need to be doing to be utilizing whatever it is that we're building here in analytics, addressing the organizational implications. Yeah, there may be some job role titles or descriptions that need to change. There may be some reporting changes that have to happen. I like to, just to make a point sometimes, I shouldn't say this because it's a strategy, a consulting strategy, but I like to make a big play about how the job roles are going to change as a result of this, just to get people to realize, oh, you mean they're not over there just writing some reports? Oh, no, they're actually doing predictive maintenance. We're not going to do maintenance the old way. We're going to do it a new way. It's a wake up call. So you need those wake up calls early and often throughout the process. Engage and communicate, lots of communication. No such thing as over communication. We have to have that as part of our plan and communication from your scrum masters and so on doesn't just go down to the team. All right, it goes across the organization. I want regular touch points with key stakeholders on this at multiple levels of the organization. Speaking of that, we have stakeholder management in the upper right, which is probably the most important one on here. And I'm going to give you specific tasks in each of these five areas. Again, to put on your backlog and to put in your project plans, change readiness means that the organization is ready for change. People have exhibited the behavior that shows that they're ready. We have the artifacts in place. We have the support team lined up, et cetera. Change readiness is important to OCM. Now, OCM can be embedded or it can be standalone. So we can put some of it into projects to support that project or it can be standalone sitting aside, kind of like the center of excellence model in support of multiple projects that might be in development or might be in production, but not fully in production. You know what I mean, it's in production but it's not getting used the way that it needs to be used. Data governance often has some Venn diagram overlap with OCM, that's okay. We can have a whole talk on data governance if that's not your vote in your organization. Okay, well, let's do some things with OCM and we won't worry about that except that we need it. So let's build our data governance separately. But anyway, recommended to orient it to projects and have short-term wins. OCM is not like the data governance programs of the 90s that sat on the sideline and did their thing and expected major business results as a result of what they're doing when they're not integrated. OCM needs to be integrated. Let's just do that from the start and let's get these tasks and specific things that we need to do in the projects. All right, how much OCM to do? Well, I suggest you do an assessment and these are your metrics at a high level. Are you making process changes as a result of this project? One to five. Do you have numerous stakeholders and do you have high potential for unsupported stakeholders apparently? In this example, we do. We got that out there at a five. Is there widespread organizational implications or is it departmental rate that? Are jobs changing? Or is the organization used to change? This is really important. Is the organization used to change? Have they successfully dealt with change before? Or have you wasted millions on projects that seemingly look good but didn't get anywhere? Now these five things obviously map to the five things on the left, all right? So as we go into it, that's your mapping. Let's go into the work products. Now this is a macro look at the work products. I'm not gonna go through all of these. Again, a slide you can take off and refer to as part of your project team. And I know that I have designed, build pre-production and deployment across the top. Like as if I'm doing some kind of waterfall and not agile. When I know that most of you are doing agile, I'm doing all agile. Okay, I get all that. I get all that. But just because you're doing agile doesn't mean you're not designing, you're not building. You might be doing it in smaller increments but you're still doing all this stuff. And so whenever you're doing this stuff for your project, you just kind of read down that column and you see some of the things that you might want to do. Again, the more, back on this graph, the more out, I guess, closer to five that you have rated the respective function, the more of the things you're gonna want to do. So stakeholder management, we thought that was a problem for this project or a potential problem, right? Not a problem if we deal with it. Let's read across stakeholder analysis, do a stakeholder management plan. We evaluate and update the stakeholder management plan at pre-production. We evaluate and update the stakeholder management plan at deployment. So you're doing a lot with this stakeholder management plan. It's coming up early and often when that is the case, okay? So we need to bake all of that into projects that have a problem with stakeholders and many do. Same thing applies to all of the other rows that you see here change readiness, engage in communication, addressing organizational implications, training the workforce. So as an example, we might decide based upon our spider grasp to do this. We're gonna do stakeholder analysis. We're gonna do a stakeholder management plan. We're going to do a deployment readiness assessment, except for what you see here. And I think that what you see here is actually bare minimum, for any project of any kind of scope whatsoever. You need to be doing this. Now you might say, okay, teachers say job roles definition, not much to do there, but you should address it. You should at least acknowledge that that's a possibility. That's a tool in your toolbox. And if you don't pull it out, then you are definitely hampered in your ability to take this where it needs to be because your success as a leader doesn't end when you put it in production and declare victory then. It's later. It's after you incorporate change. It's after you actually get a ton of usage and bottom line business value from that thing. It's a tough job. Okay, stakeholder management. Let me drill in, double click on a few of the stakeholder management. I've raised that that's a pretty important one, right? Okay, identifying your stakeholders, assessing your stakeholders and influencing the stakeholders. And many times here we're talking about stakeholders that are VP level or above. And when that's the case, you influence them on an individual basis. You are not creating a one-size-fits-all plan for the CEO and the COO and et cetera, right? Okay, you have to take into account their personality and their understanding and just what it is that they're gonna be able to handle. Again, it's not a one-time event. It must be reassessed. So stakeholder dimensions. Identify your key stakeholders. And I like to say people ask me, well, you know, there's hundreds. I got hundreds of users for this, okay? Well, identify 25, okay? Identify up to 25. And let's do an exercise within the team. We don't have to tell them. We don't have to tell them we're doing this exercise on them. But let's write them according to all of this. How are they? Red, yellow, green, ROIG, red, yellow, green. How are they to the project? And maybe you don't know, figure it out. But how are they to the project? And where do we desire them to be? No, but we don't desire anybody to be red, okay? That means they're completely opposed to the project. And that can't be if they're a key stakeholder. If they're in my 25, they can't be red. We gotta give them to at least yellow, okay? I say red's the yellow, yellow's the green. What is our project role? What role do we want them to have on the project? What actions do, can they do that manifest that they have moved forward or moved to where they need to be to be a successful stakeholder? So this is an example, a little plan here. I won't read it all, but we have a description. And then we have a plan of attack scheduling. We're gonna have a meeting, a one-on-one with that person at the beginning of each release. It's gonna be one to two hours. The objective, and this is for department as apparently, is to prepare them for their role. And here we have a sample agenda that we're gonna take through with them. Yes, we're going to do this, we're going to reach out. I have done some pretty weird and wild things to make sure that my stakeholders understand their level of involvement in the project. When they are elusive, I have looked at their calendar, their schedule to see when they're bumping from meeting to meeting. And oh, I just happen to be standing in the hallway when they're going from meeting A to meeting B and with a concise message for them. Of course, that's hard to do today when we're working from home, but you'll have to get creative about it in your own way. Okay, so let's move on to something else, the communication plan. I recommend a communication plan. So you're going to have scheduled meetings, face-to-face demonstrations, presentations, all hands meeting, yes, these are all at your disposal. And you can just take this slide and do it, right? Because this is kind of all filled out as an example. And I think it's pretty good. It's targeting all the people that you need to target, the project team, the business advisors, committees, project staff, et cetera. We're trying to slide everybody into kind of those little roles there. And you can see the frequency, face-to-face meetings and events and so on. Pull this off, put it on your backlog. So who's going to do all this work? Where's it coming from? Well, okay, I said earlier that I'm going to recommend a number. Here comes a number. I'm going to recommend a number of, it's a percentage of your budget that needs to be allocated to these types of activities. Again, for any media project, unless a 10%, 10% of the budget should go towards these activities. Now, there's different ways you can get that 10%, right? You can say, when you go to the budget committee, you can say, I need 10% for OCM. Okay, that's the good way to do it. That's the upfront way to do it. And that means that you're being very assertive and moving things forward and you're getting them involved immediately. Another way to do it is to bake it in to the project. These are just project tasks that need to be done. Need to be done. And I don't find that they get questioned too much. As a matter of fact, I find my clients are much appreciative of the fact that I'm acknowledging this stuff because it's very easy to see that these things go straight to the bottom line, go straight to acceptance. And if I had to say, what are my sponsors for my projects over the years? What are they most concerned about? They're most concerned about acceptance, acceptance of the project by the powers that be within the organization. Yes, of course they're concerned that we build it, right? But they're concerned about acceptance. Now, the bigger your project, the more you're gonna need these boxes in terms of being actual people. You may need a different change management sponsor than the project sponsor. Hopefully you don't, but not all project sponsors are right to actually lead change within the organization. We might wanna think about having a different sponsor just for change management. I've done that to success. I think that's a good idea sometimes. Change management lead. I'd say project manager. Now, I would love for a project manager to be so skilled and have such an abundance of talent and time that they can do all of this stuff and that the project is small enough to where they can do that. But that's not often the case. And so oftentimes I will have a different change management lead. Yeah, maybe they do some other functions for the project too. Maybe not for huge projects. When I'm doing multi-million dollar a year projects like 10 million dollar a year projects, you better believe I'm gonna have a dedicated change management lead on that project. And he or she is gonna be responsible for a lot of this. And I might even even have more. Look at the green boxes. Communication, somebody to do that. Training, somebody to do that. Organizational alignment. Someone to do that. Mayor may not need people specifically dedicated to those roles, but the bigger the project, the more likely that I do. But the main thing is that these things get taken care of. That we do a communications plan. That we do a training plan and we execute it. And we do look at job roles and we do change them accordingly. Okay, so when I'm sharing the task, you're wondering maybe, well, where's it all gonna come from? Well, it's gonna come from these roles right here. And let's take a quick gander at the change management lead. They're doing OCM strategy. They're doing the OCM plan. They're doing OCM leadership interviews, OCM leadership strategy and operational vision. They're mobilizing, supporting and coaching the change champion network, which is basically the network of people in the company that support the project. Coordinating the overall execution of the OCM program and all the development of the architects. So in conclusion to my part, and I do welcome your questions. You got a few minutes. You wanna throw some more questions into the Q and A panel for us. OCM is essential to organizational analytics transformation. So no matter what other niche crook or cranny that you are involved in in analytics, make sure someone maybe you is involved in OCM and making sure that what you're doing actually gets accepted by the organization. Choose the applicable work products. I give you the macro set. Maybe there's more. Maybe there's more that you can think about that will help you in your goals of OCM. Certainly I'm open to that. Certainly your project should be open to whatever it takes. Don't push OCM off until the very end. That's when you get the thought out of the tree. Don't push it off till the very end. Make it a part of the journey. Start people towards their change on their change plan from the very beginning. Insert work products into plans, be that an agile backlog, be that the project plan, whatever it is you're doing. I hope you're doing agile, but insert the work products into your plans. Focus on, these are the key ones. If you forget everything else, do these things. Stakeholder analysis, job roles, training, deployment preparation and communications planning. Again, back to my bare minimum slide, okay? They're on there. Make sure that you do all that for these projects because when it comes to analytics projects, when it comes to data lake project, data science projects, all the ones that I'm involved in that you're probably involved in, from a project perspective, these are going to be highly impactful to the organization. You might as well deal with that head on now as opposed to later. You might as well start getting the organization prepared for the success of your project long term, which is the only success. Make the soft, this idea that people need to change, people need to come along with the program. Make that real and tangible. And let's not blame them for being human, right? They're going to go through the steps that I showed you. They are, some slower than others. There is a point, I suppose, at which people are not coming along and that's going to be too bad on them, but I find that most people will, if given the chance, you have the opportunity, the great opportunity to give them that chance by creating this program. To bring them in, it's a win-win. Make it a real tangible part of an action-oriented framework. All right. Shannon, that brings me to the end of the formal part of the presentation. I turn it back to you for the Q&A. William, thank you so much for another fantastic presentation. Just to answer the most commonly asked questions, just a reminder, I will send a follow-up email by end of day Monday for this webinar with links to the slides and the recording of the session. And we invite Sean to join us back in with the Q&A here. So let me just dive right in here. What will the new roles be for organizations becoming analytics-led? Well, data scientists, for example, what skills will they have? Yeah, I'll start. And I know Sean works with a lot of data scientists and new roles as well. But yes, you hit on a key one, right, data scientists. We want to see more of that. That's a maturity factor for organizations in terms of analytic maturity to have that role. That role is hopefully going to be curating upon, not curating the data, but curating the science out of the data and gleaning insights out of that data and having a bit of a free hand to go where he or she needs to go but understanding kind of the bigger goals of the organization at the same time. So data scientists is big. But when I talk about role changes, I talk about, yeah, of course, there's the big ones like we're adding data science and so on, but there's also analysts that used to go to the file cabinet and used to go to the FAP machine and used to lob telephone calls to check on payments and so on. Well, there's a new way. We're done with what we're doing, right? And so we want them to go about their job in this new way and not resist and see the benefits of doing that. So job role changes are all across the board. Certainly analytics projects are bringing in the data scientists and so on, but they're bringing in so much more. We are all needing to change as a result of the changes that are happening around us with artificial intelligence, machine learning and advanced analytics. All jobs are changing and they're changing as rapidly as ever. And they're changing to new ways of doing things. And so it might not be a title change. They were talking about here, it might just be that the roles are changing and how they do their job is changing and they need to be more informed by data. So these are things I want to capture in terms of new roles. I heard a lot of that, William. You know, as a developer, I think I was probably in an active coding role for probably close to 15 years. And a lot of times change management is an impediment to a developer's job because you have all of this processing and you have all of these hoops that you have to jump through, you know, justify why you're creating code and all of these things. And as I've progressed in my career, I've really kind of opened it up to where, you know, I try to take all of the roles within an IT organization now and make them a part of effective change management. So in other words, you're not buying into a process, you are the process. And I think as companies move towards the web and cloud data warehousing and processing faster, people are gonna realize, oh, the best way to be a part of change is to be the change itself and not really worry about what process I have to follow to get my change to the end environment. Hopefully that makes some sense. Indeed. So I've had luck using these tactics in the past that my current role, my employer has approximately zero interest in spending any money on the additional cost, strictly seen as a speed bump suggestions on how to overcome that attitude. Sorry for the chuckle there. It's not funny. But yeah, there's a lot of that as well. And I get that. And I find that, you know, the first place that, you know, somebody wants to cut on a project budget is, what's this you got here? Organizational change management? What's this thought stuff? You know, and that just gets back to what I said earlier. It has to happen. You have to bake it in. And you're trying to get success. And you can get it in one of two ways. You can either bake it in and knowing that you'll be allowed to do it, or you have to, you know, kind of beat that tree with the club a little bit to get the top down support for what it is that you're doing. And frankly, you probably gotta do a little bit of both at least to make this happen. So, you know, there's, I also use the phrase in the presentation, he'll worth dying on. And only you can decide, only you can decide if this is gonna be that he'll worth dying on for you, if you're gonna stand up for organizational change management or not. But I think you can probably see based on your question that it's a good thing for the project, possibly a very necessary thing for the project. And so I think you've got some things to do in terms of, you know, working on that person. But also I wouldn't hesitate to put, just put it or put these tasks right in there. And that's why I give you the task to make it real. And you probably won't get pushback when the tasks are encountered in the project because they're just so obviously necessary. But good luck with all that. Yeah. So I would piggyback on that. I think William's absolutely right. And I'm gonna give you an example that's not IT related, but you know, change management is about managing risk. So one industry that we have in this country that manages a ton of risks is credit card companies, right? If credit card companies didn't manage their risk in their agreement with you, they would go out of business quite quickly. So when you sign up for a credit card company, they've already kind of prepared all of those costs associated to the account that you've signed up for. I like to think of change management the same way. And I'd go back to that supervisor kind of with that and look at the way that credit card organizations manage their risk. It's the same thing that we're doing with our software. We want our software to live beyond the average self-life. To do that, we have to invest in this daily activity called change management. And if we do that, we will be successful because we budget it for it. Perfect. What is the best way to figure out who the stakeholders are in these projects? Yeah, yeah, good one, good one, very good one. Okay, so I think the first five are gonna be obvious, right? They're the people that are going to be actually using this the most. And that might be actually your first 25. But I would start by looking at the users and I would go up the chain from there, meaning their bosses and directors, VPs, and kind of use your judgment and kind of find your way by starting with the users of this. Now, don't just stop with the users, right? Look at the user organization in the org chart or the informal org chart, as the case may be. Look around that box and see, okay, who does that box interface with? Like supply chain, if I'm doing a supply chain project, okay, they're gonna interface a lot with the product management team. Okay, they're gonna interface a lot with the transportation team, et cetera, whatever it is for you. So it's quite possible that I need stakeholders in my 25. I need some from those organizations as well. I almost always need one from finance no matter what I'm doing, okay? So yeah, so start with the users, branch out, branch out, branch down from there. And it won't take long until you're at your limit in terms of how many you can actually deal with in this process, but it should be meaty. And I kind of use the 25 as a rule of thumb, but it can be whatever it needs to be for you, whatever you feel like you have the bandwidth to manage in this process and you want them to also represent. So you're gonna have some stakeholders you're gonna find are gonna be red, of course, unfortunately, and some are gonna be green. And you hope that the green ones are gonna spread the good word out to everybody else who is maybe a more minor stakeholder. Yeah, I don't have your prowess and I don't work necessarily at your level, William, but at my level, when I'm working with different solution architects across different organizations and different teams, the people that I'm really looking for, the people that are out there really kind of cheerleading all the time. Those are the people that I lean into, that I tend to push more into kind of a stakeholder role. Now, I don't have this big organizational wide kind of responsibility that you do. My projects are short, but generally I will try to find the person that speaks the most and the happiest about that work and put them at the top and use those individuals as my kind of evangelist of the project and what we're trying to accomplish. I love it. And so what if you implemented the change before proactive planning? So what if you implemented the change before proactive planning? Is that the question? That is. Okay, okay, okay, I get it. So you've already done your project, you've gone on to production and you were not proactive about this stuff. Yeah, that happens a lot. Well, you're behind the eight ball and you're just gonna have to go back and pick up some pieces here. And realize that you now have another project on your hands, it's just the organizational change management, part of the project that you neglected the first time through. And hopefully you have a good asset on your hands that you want people to use. Sometimes it's easier to show than tell, right? When you have something you can show people, hey, here's what it is that you want to do. We want you to do. So just take advantage of that situation and show, don't tell and try to get people involved as users at that point, as stakeholders at that point, as people that are getting great business value out whatever it is that you built, unfortunately at that point, you did it backwards, but it may or may not be salvageable. It probably is if the horse isn't too far out of the barn here. And so I would just get about doing those tasks and I know your budget's all spent now, right? So that's gonna be another part of the problem. If it's truly a bad situation, a red situation, then you might have to seek budget for some of these OCN tasks that you neglected in the first place. Would you kind of into almost a continuous improvement cycle? And if you think about it, you've got great lesson learned from a project and now you've got some backup material and you can use that information from what you've already done to apply a lot of these lessons and then generate a different outcome going forward. At least you got something out there. Indeed. So I think we have time to slip in one more question. Uh-oh, broken up. Shen, you got a little choppy there. Hopefully I'll hold up here. I think we've got a few minutes for one more question. What are some of the most difficult? Shen and I heard you through difficult. I think I just need one more word. Well, maybe I can poke around in the queue and I can find this. I think it's, what were some of the most difficult OCN problems William encountered? Okay. Well, one time, I built a, it was a supply chain management project with analytics. It wasn't too long ago. And this company was unfortunately in the dark ages prior to this project and we made a tremendous step forward for them. But we were talking about droves of people at this organization that were doing things in a manner in which they were used to, which is Excel spreadsheets, literally phone calls and faxes and everything. Can you hear me? Hello? Hello. Hello, Shen and I, I'm just answering the question. Okay. Sean founded on the Q&A for us. So these people were doing things with file cabinets and all these really old style ways. And I found that by trying to bring them forward so far that there was, almost I would say the word is mutiny. But the good news is, you know, from the organization standpoint, they, you know, they were all going to stay in their jobs. They were just going to do it better and level up. And so we had to spend a lot of time, maybe the word is hand-holding, training, desk side sitting and so on with every level of that organization to make sure that they came along with the project and would use it and would make the whole thing successful. And so we did and everybody did come along, but it did look bleak at first because there was a lot of people in the red, a lot of people in the denial, but by following this program and frankly that project helped to hone a lot of the things that I talk about now in organizational change, and all of the things that we do. So good thing that project came before this presentation and made it a lot better. So there's help out there, even when people are in a bad way to begin with. So my worst situation I'll say is that with a lot of people that were rebelling against the project. Sabulous. Well guys, can you hear me now? I'm so sorry about that. I don't know what happened. Yep. Okay. So that does bring us to the top of the hour and just want to say thank you to Matillion for sponsoring and thanks to all our attendees for being so engaged in everything we do. Another great presentation and just a reminder, I will send a follow-up email by end of day Monday with links to the slides and the recording. Thanks everybody and hope you all have a great day and stay safe out there. Thanks all.