 And welcome, everyone. My name is Paul Diaz. I'm the Webinar Production Assistant from Dataversity. We would like to thank you for joining the latest installment of the Monthly Dataversity Webinar Series, Advanced Analytics with William McKnight. Today, William will be discussing why organizations don't change when they need to. 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 via the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we certainly encourage you to share highlights or questions via Twitter using hashtag ADVAnalytics. If you would like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the bottom right corner for that feature. 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 introduce you to our speaker for this series, William McKnight. William has advised many of the world's best-known organizations. His strategies form the Information Management Plan for leading companies in numerous industries. He's a prolific author and a popular keynote speaker and trainer. He has performed dozens of benchmarks on leading database, data lake streaming, and data integration products. William is a number one global influencer in data warehousing and master data management, and he leads McKnight Consulting Group, which has twice placed on the Incorporated 5000 list. And with that, I'll give the floor to William to get today's Webinar kickoff. Hello, and welcome, William. Thank you, Paul, and welcome, everybody, to the last Advanced Analytics Webinar of the Year. And I am pleased to let you know that we'll be continuing through next year, so keep this spot marked on your monthly calendar, and we have a very exciting set of topics next year, and I'll introduce those at the very end so that you can plan ahead. But today, I thought I'd kind of wrap up the year a little bit by talking about why organizations don't change when they need to, because I have heard that you've enjoyed the ideas presented throughout the course of the year, and of course, you're getting ideas all over the place and forming them into projects for your companies that we would like them to take up. And I hear frustration at that point. I see frustration at that point. I have frustration at that point, and so I want to help you out with that part of it. So once you have a data-oriented project, okay, we'll get into some terms here, but once you have a great one formed for your company, one that will take them forward, one that they ought to do, at least in your view, there is definitely some time and skill involved at that point to actually get it taken up. And truly, that is a skill, and if you can get behind some great things that happen for your company, that is all but good for you and the company, and so we want this. It's no good for us to learn all these things, and then we never get to apply them within our company. Now, if you're going to learn things you can't apply, there's no doubt about it, but if it's 100% of the things you learn, then it can be a bit of a problem. And truly, you are focused in the right direction. You're hearing about data lakes, you're hearing about artificial intelligence, you're hearing about streaming data, et cetera, graph databases, and you want these things in your company. You see a place for them, and truly, at least if you're a mid-sized or up company, I see a place for all that and more, referring back to my maturity talk. I talked about that, I talked about master data management and the need for all of these things somewhere. There's no one size fits all, but not to go back into all that. Let's talk about why organizations don't change when they need to, and first to let you know I've helped justify some pretty large projects in the past few years, and these are some of them. And while you may look at the big numbers there and say, wow, that's a lot of money, of course there's been more, there's been higher ones in the past. The thing is today, I don't get this kind of budget, and I don't think really very many people get this kind of budget. These are just earmarked numbers in terms of how far the project's going to go over the course of years, and that could be two years, that could be four years, it could be five years, but an initial like first year budget is probably on the order of five to ten million for something like this. And then it might ramp up to say 15 million in the second year if the first year went well, and you taper down at some point as you get more into maintenance and settling mode, and you've done most of what you can do. But a couple of these have actually completed the budgets that you see here over the course of years, and maybe three of them are still on the journey, but it looks like they will continue on the journey all the way to the earmarked number successfully. So how did I do this? How did this happen? I want to share some of that with you, and first to let you know, I had to wear my architecture hat and my business hat at the same time, and that's really a skill there that you need to have if you're going to be the champion of these great projects that exploit the number one asset of your company, which is data, enterprise data. You've got to be able to wear both of these hats, and you have to understand who you're talking to and what kind of hat that they expect that you have on at that moment. If you're talking to an executive, you better have your business hat on. If you're talking to someone in technology, you better have your architecture hat on and be speaking to their needs. And so it's a balancing act. It's a delicate act, and I want to give you some skills here today or at least expose you to some ideas that you might want to look into further. Some things that you may or may not have done for the great projects that you thought of for your company, or you may not be the one thinking of the project. You may be the one helping the champion behind some of these projects. And so these are some things that you might be able to share with him or her so that you can get these great projects going. You can exploit the technology that you enjoy and want to. Let's say you come up with a great idea, and the organization responds with a no. Now, I don't know that I've ever gotten a hard and fast no, maybe a few times in my career, but most of the time it's a soft no, okay? That's how it works. It's a soft no. It's a, well, what about this? What about that? It's sort of, you know, chase down some things and hopefully, you know, from their perspective anyway, hopefully it dies away. And I'm not up to two standards, but I try to be and I want you to be. And so that's sort of the genesis of a lot of the material today is to get past this, to answer those questions upfront because most of them are good questions that I should have answered, you should have answered. And so if we come in with the right perspective, we can kind of jump head a little bit in the process. And by the way, I don't ever expect that when I offer up one of these, one of these, you know, to a company that it's going to be a straight up. Yes, yes, you have answered all our questions. It's a time consuming process. It's a back and forth. You have to bring a lot of patience and I feel like a lot of times great ideas don't come with enough patience for a corporate machinations to actually accept that project. And so that is something that we're going to talk about here. Now, so why? Why don't organizations accept your great ideas? Why don't they do what they need to do? Well, these are the top four in my view. One is ROI concerns. So not everything's about ROI, you know, hard number and so on, but oftentimes, oftentimes projects are and they are from the very start. We're trying to save money here. We're trying to save on fraud. We're trying to, you know, get better uptake on our promotions. We're trying to save on maintenance costs, et cetera, et cetera. These are all hard dollar items. And in moments like this year, the world has kind of come back to some of these hard dollar items. So there is definitely going to be room for the strategic and I'm going to acknowledge that for sure. But oftentimes projects start as, oh, it's strategic. It's, you know, a new market we got to break into and so on. And I'm all about that. I'm gung-ho about that. But when you start applying dollar figures to the cost of the project, then the question starts getting asked about, well, where does the dollars get returned for this project? And that's where your ROI skills can come into play. So the more you can bring into that negotiation, if you will, the better. So I'm going to give you some skills here today. We're not going to get deep into the math, but we're going to do some credibility. Do they feel like you're the one that is right to be championing this project? I often say that, you know, all these great ideas that we come up with that organizations could actually use that most executives would, yeah, they could snap a finger and have that project in production running the way you say it's going to run tomorrow, even for the dollar figure that you are asking for. The answer is yes, but they question the journey. They question whether you're the right person, whether your team is the right team, and some of the other things on here. So I want you to be constantly building that, and I want you to understand about the patience part of it and how education is very important. That brings me to my third bullet, terminology. Our industry has not done a great job at standardizing terminology, you know, the data industry in general. So oftentimes you're on one set of terminology. The counterparty is on a completely different set of terminology. I mean, I feel okay in these webinars to talk about data lakes and data warehouses and graph databases and stuff like that, and not then pause and take five minutes to explain what I'm talking about, unless I'm getting into a certain level of detail. And then I do, because then all our definitions that are kind of all forked off from one another, we have to be on the same page in order for me to take you to that level of detail in a webinar or in a consulting session or whatever. So the same is true for you as you're championing these projects. You have to be on the same page in terms of terminology that does require some education. And the organization, the person you're presenting this to, the champion, or who would be the executive sponsor or offer up the budget, get behind it from an executive perspective, et cetera. That person is concerned about his or her peers in the organization, and really it's the rest of the organization going to do their part, and it's just going to make priority for them. So we'll start addressing these four things as we go along here and see if we can break through, break some ground for you here. Okay, first, let's talk about ROI. Let's talk about acknowledging the strategic, okay? I'm not saying everything has to be our dollars, ROI. There's no room for projects that don't have an ROI associated to. I'm not saying that at all. There is definitely a place for learning, a place for innovation. There's definitely a time for the unknown upside, you know, breaking into a new market. I'm pretty sure Elon Musk isn't saying, well, let's go to Mars and what's the ROI of that? Okay, but we're not all going to Mars, you know what I mean? We're all doing projects for mostly major companies and mid-sized companies that, you know, they care about their dollars. They care about the bottom line, and that's okay, that's business. And these things are important, but oftentimes it comes down to the hard dollar. So we're going to acknowledge the intuitive thinking that will still need to be employed by the highest person, the highest paid person's opinions. Yeah, that's going to stay there a little bit. All right, we have to divide up what we're doing into workloads. So what's a workload? Well, there's a skill involved at dividing up the workloads and determining what it is that you're actually talking about. Oftentimes we're in larger corporations, we cannot possibly be talking about projects that incorporate the whole organization, at least not at the very beginning. And what are these sheets that I'm putting behind fences here? What am I talking about? Well, it could be data, it could be users, it could be usage, it could be availability of the system. There's a lot of things that can go into the workload, but ultimately you need to be presenting great workloads to the organization and trying to get momentum around that. Now is it going to be the perfect workload? No, never. Is it going to be good enough? Is it going to be great? Is it going to be something that takes the organization forward? I hope so. That's the kind of workload that we need to be ring fencing here, if you will, and presenting back to the company. A lot of the things that I talked about in my maturity talk a few months ago. So if you're not doing those things, those are things that you need to start presenting appropriately into your company. Now, let's talk about ROI some more. Ordered benefits. What makes it difficult? Because very few of us are creating, let's say, a data warehouse and selling subscriptions to the data warehouse. And we can say, well, cost is much to build the data warehouse, sort of the easy part. And we're going to sell this many subscriptions and they're going to pay this much, and it's going to more than pay for the cost. So when you want to do that, we're not doing that. That's not anything. I've done that once, okay? But once out of so many times, we're probably not doing that. We're probably in the second or the third order of benefits that accrue from building that data structure, that data artifact, all right? And we have to understand the full chain. Yes, we. We're the ones that come to webinars like this to learn about technology and architecture and data projects. We are getting more and more behind the projects of the company and the companies move towards data leadership as the companies move towards being quote-unquote data driven than more of the focus for the complete justification of the project falls on those of us with those skills. So we've got to get our arms around all the ordered benefits. And yes, the first order is easy. The second order is hard and the third order is harder still because you are now reaching out into different pockets of the organization and understand what they're going to do with the data and how that's going to translate. So let's talk a little bit about terminology as we talk about ROI. Because again, you've got to be on the same page. Are you justifying, I'm just using data warehousing as an example. Could be data legs, could be maps, could be any of these things, streaming data, graph data, whatever. Speaking from a technology perspective, that's kind of a problem right there. I don't really want you doing that. I want you to be justifying the predictive maintenance project that, oh, it happens to use the data warehouse. That's what I would rather you be justifying. But many of us speak in these terms, so I'm leaving it here for now, but do know that these projects should really be casted as business projects to the organization. And, oh, by the way, we're going to do it the right way. We're going to build a data warehouse for it. So are you justifying a project or a program? There's a big difference here. A project does something for the organization, something specific in support of a usage of that data warehouse, like predictive maintenance or targeted marketing or fraud detection or customer churn management. It's one of those things. You're justifying that project and, oh, by the way, it happens to use the data warehouse, which is a great way to do it in a bad hole where it can't support anything else. That's inefficient as you go forward. So that leaves me into justifying a data warehouse program. Maybe you have three or four different projects. They're already running, but they're running with their own quote-unquote data warehouse or database. The market and database over here kind of resembles a data warehouse if you squint your eyes and that sort of thing. Maybe we got to be getting those databases and unifying them so that they're all not only singing from the same hymnal, but we're also saving money in the process. So that's a data warehouse program. So be sure when you're talking to someone in your company about the data warehouse you're on the same page in regards to this fact. So a little bit more here. An information management program, which will store data for several projects. So therefore the question on the table is why should we use the data warehouse architecture? Why should we use architecture at all, which may today include a data lake and other things, versus I'll just build a database for my project, leave me alone. That's the question. Why use an architecture versus something that's more independent that I have more autonomous control over out here in the project and so on. That's the question you have to address. And typically we like to address that with TCO. Now, total cost of ownership that is. I'll get into that a little bit more. Or is it a project that will use the data store like my predictive maintenance example. That project needs data. If you look down the list of the projects your company is working on, which one of them doesn't need data? Doesn't need analytics. I have a hard time finding any important project to a company that doesn't need both of those things. And so that leads me to justifying a lot of data with health projects. So this is the question becomes on that. Why do the project? Why do predictive maintenance? For example, I'll leave that to you. I'm sure that can be done separately, but do know what question that you're trying to address and what question that counterparty has in his mind. They're always asking questions and being appropriately skeptical I guess of your statements. Oh, you want to do this, you want to do that. They're trying to say no. They're trying to get to the end of their day. You've got to get their attention by addressing the questions that they are formulating in their heads without telling you. The inclusion of new projects into an existing data store program. So let's say you have a data warehouse and it's moderate maturity according to most standards and a new project pops up that needs satellite data. Well, should they roll their own? Or should they come into the family the data warehouse family and start using the data there? Well, hopefully you've built the data warehouse in such a way that they're welcome and you know how to handle it and get them involved and so on and no other party that's in the data warehouse is going to have any heartburn over that. But maybe those are things you have to work on in order to get that program rolling. Now return on investment. I've been building up to this. It's just simply return minus investment over investment. It should always be supported with a time period. So if you're going to tell me you're going to give me a 301 percent return, my next question is when? Tomorrow, that's great. I'll take that deal. If it's 10 years from now, well, breaking that down to an generalized percent return it's not that good really. So it all has to do with the time frame. So you have to add that. And by the way, if you're doing these things, don't get carried away here. I never go more than three years. If it can't justify itself in three years, my goodness. The projects today need to be in the black. I would say these ROI projects not the 10 percent strategic ones, but these ROI projects you better be getting them in the black in about six months. Two a year. Okay. And if you can't do that then you need to sharpen the pencil. And you need to look at the things in this bullet here by source system, subject area, business problem, solve users levels of summary and or amount of history data. This probably can other things I could add on to that list. But you get what I'm saying how you how you break up this ocean of possibilities here is it's infinite really. How you build a data work house the different ways it's infinite. How you build an MDM hub the different ways are infinite. But it's up to you as the champion to formulate to craft something that is going to return quickly and on an ongoing basis. Because today even if you were to take even longer even if you were to take longer to do it quote unquote right. If you cannot return in six months to a year you're not going to get that project or you shouldn't get that project of course not going to have legs to go beyond the six months to a year when things start getting tighter. And so therefore even though it may not seem to be the right thing to do to get a great project up and running in your company that does deliver. Moving on information management program justifications. I mentioned before that I use TCO for this total cost of ownership. So this is somebody questioning the data itself or somebody questioning the MDM hub or the data lake or the operational hub or what have you you know why do something in an architected fashion versus not versus the independent way of doing things. Now this would seem to be kind of an old argument that haven't got past this no we haven't got past this. We have not got past this in my in my clients this is still top of mind we have not rolled out the education we've not rolled out the learning all the way in the organization to where this doesn't come up. This comes up all the time. And so there's different things you can look at operational systems impact okay you're only pulling the data out once. One way of doing things gets gets you great at that one way makes you more efficient tools confidence yeah same kind of thing also tools budget alright you can get going get a better deal with a bigger deal with these vendors consolidating your expense holding having to maintain I don't know five different quote unquote data warehouses those have one but the biggest benefit to me is the enterprise subject areas. Yeah you get it done once and you create data as a service that's what I think a data professional really needs to be doing today creating data as a service to the organization yeah I love that concept where you can would you as an application owner or as a user can subscribe to data and get the data that you need to do your job and you can believe in it you can trust it it performs well okay it's organized very well and so on these are the things that you know you should be doing with an eye to the usage but also an eye to the longer term and it's great but that's the biggest benefit of a information management program or you might say an architected approach to things now these are some of the domains some of the artifacts that we build as data professionals right see data warehousing data lakes master data management analytics CRM stream processing there's probably a few more that could go on here but these are some of the approaches that I recommend for these and I think you can find your way between ROI and TCO appropriately for the domain that you you were thinking about so if it's a data warehouse I've showed you that it could be ROI could be TCO data lakes today largely net new something in organizations ROI master data management a lot about TCO a lot about that build once use many concepts and analytics analytics provide ROI to the organization projects need analytics and again I'm going back to that list of projects that's important to your company that your company is going to do over the next couple years look at that list which one is going to be successful without analytics which one is going to be successful just doing it the vanilla way or doing it with very shallow quote-unquote analytics like well let's look at what state the customer lives in and do something in regards to that you know we've got to get more focus and analytics to do that for us we've got to get the data together first CRM I don't do a lot with that but that would be ROI or TCO stream processing that's a lot about ROI it's somewhat about TCO though it's somewhat about well you know if you can't keep up with the incoming data you're not going to have the data available you're not going to be able to do the things that you want to do with that data etc etc so you can see that what I'm looking at here is the knock on effect of not doing it this way and I'm doing something that's counter to that so that it isn't an architected way and we can we can argue here we can debate about architecture you know what's the best architected approach but at least we're in the realm of architected approaches we're not in the realm of well whatever happens happens and too many organizations still have a lot in that category and there's a lot of opportunity there and frankly I feel like a lot of those organizations that keep living by that motto are not going to be around for the future when we're going to have to have a solid data and analytics foundation under every company in order to get into the artificial intelligence future and so on but I don't want to get ahead of myself too much in terms of architecture I want to get back to ROI ROI comes in many forms there's payback period analysis which is how long does it take to recoup the initial investment well that kind of implies something doesn't it implies that there is an initial investment and you might be saying well we're doing it the agile way we're doing it the cloud way yeah cloud kind of muddles the picture here because with cloud you pay as you go usually I shouldn't even say usually so many companies now are getting the one and three year commitment kind of deals but they're still paying as you go but anyway doing things the agile way makes it hard to say what the upfront costs are but they're still there and they're still there and a cost is a cost is a cost and it's a dollar expended on the project in one way shape or form it's it's all people costs it's all the consultant costs it's all the hardware if you have any it's all the software it's all the cloud etc all those costs and they're either upfront costs or they're ongoing costs that's it and if they're ongoing they go into the ongoing buckets maybe by month or what have you and then they have to be offset by the counter revenue that's going to be coming in as a result of your great project so how many if you're in retail for example I used to say how many more socks do we need to sell here to pay for the project you know can we do it I remember one client we did a data warehouse for and this was over the course of a couple years that we matured that warehouse environment our goal was to sell 2% more coffee in the concept and we did it and you can say well William how does the data warehouse sell more coffee well that would be another webinar entirely right there but we suffice it to say we attached ourselves to that idea from the very beginning and we so when it happened a lot of that value was attributed to the data warehouse as it should have been the problem is so many of us build these great data warehouses we build these great analytic data analytics or what have you and somebody somewhere along the way loses sight of the fact that wow that was a pretty important part of this overall journey that we took to get to where we are and then it kind of becomes devalued and so on but anyway I digress there could be return on investment yes return on investment is a return on investment measurement I'll show you that net present value and internal rate of return now all of these all of these all ROI comes down to cash flow you're not going to get away from it if you're trying to do ROI so when you start to champion the project that you want the organization to uptake you need to start thinking this way and start to back at the envelope at least be understanding how much it's going to cost and where that value is going to come from sometimes I will be invited into organizations I'll be interviewing people and I am just still amazed I guess at I can ask so many IT professionals and technology professionals so this project you're working on is it about getting some more revenue for the company or is it about saving some expenses of the company and they don't know they lose sight of their project at a very kind of low level and that is a problem I think everybody should know what the project is going to do for the company and keep that in mind if you make your decisions because we make decisions every day every one of us practically on our project and knowing that goal is just helpful and somebody somewhere and I think it's even worse an even worse problem when the director of the group or the project leader of the group or whatever does not know that answer let's know that and none of us are Nostradamus here not that he actually got everything right but none of us know the future entirely so I always suggest to come up with three ways there is the best case little goes wrong it goes dang busters it goes the way that we would like there is a plant case in the middle and there is the worst case most everything goes wrong and guess which one of these that the finance group will gravitate to and say well that's what's going to happen it's the worst case there is some art I guess involved in the presentation of this as well but it's only honest to present the different possibilities especially around the returns the expenses we better pretty much nail that okay but the returns you know how many stocks we're going to sell how much coffee we're going to sell how many returns we're going to avoid how many how much fraud we're going to limit with what we do how much maintenance we're going to save on you know all that sort of thing that's that's the best you know the best guess by those who should know it's still hard and by the way one of the hardest parts of ROI is getting the people who should know which is largely not us to cough up those numbers because they're going to have to stand behind them and therefore a culture of ROI in that company is very helpful to me or you as we go forward with these projects because they'll be predisposed to offering up some numbers some tangible returns some returns you decide to measure not the ones you decide not to measure those are the intangible returns and they're great we love them we love to give webinars and talk all about data quality I know I do data integration I love to talk about it I love to talk about the graphing data and how fancy we can make this and on and on we love to talk about that but we're not completing the conversation at least from a business executive's point of view as a matter of fact they don't even want that conversation they want the conversation that we just had about the ROI so in order to do the ROI and I'm not going to take us in deep into the math here we don't have time for that I'll introduce it a little bit and some of you will need to you know study more and take this forward but use this as an idea to help the organization do what it should do the discount rate this is the cost of money in other words ask the CFO office by the way always get the finance team or the finance people in your sphere get them get them knowing what you're doing if you're coming up with an ROI so they can give you guidance as to what's going to work for them because ultimately they're going to see it and so they might say well William around here we like to do internal rate of return so do that all of it comes down to cash flow whether you're doing payback ROI internal rate of return all of it comes down to cash flow and then it's just a matter of an Excel function really to come up with whether it's an IRR or payback period or whatever so got to get those cash flows going for example let's say in this example you're doing cost savings you're you're not going to save anything in the first year because well you're building it in the first year the second year you're going to save 60 the third year you're going to save 80 we like to get we like to get more excited I guess about the possibility of this time goes on and that's why I want to cap it at three years because yeah we don't want to be showing ridiculous numbers on here keep it real keep it real as you go forward as you can see let me do some quick math you're still you're you're right at the right on the border here aren't you yeah 140 equals 60 plus 80 so at the end of year three you're breaking even from a straight up perspective first year you're negative 100% ROI because you didn't get any returns because you were building the second year negative 45% yeah you're still trying to recoup that initial investment in third year yeah you're breaking some ground here because future dollars are anyway it has to do with the total cost of money and that's being applied here as well and the ROI comes out to 16% so is that good I don't think that's very good after three years but I'm just giving you an example here let's take that example forward the cash flow which you saw on the previous slide carries over to here in the in a given year you in a given year it was negative 100,000 because that's how much cost you build the thing then it was 50 positive and then it was 70 positive because this is offset from the actual returns you see the cumulative cash flow which tells you you're breaking even you're breaking even in the third year not so hot the internal rate of return you see it changes year to year yeah that's why you have to do it by time period net present value negative negative and finally positive in the year three if I'm looking at a project like this for a modern organization and it's all about ROI there's nothing else involved this is probably a no go I could just let you know this is not good enough projects need to show that they're delivering quicker and better now here's some other well here's taking this forward into the probability distribution so we just showed you the first one the second one shows a more pessimistic approach alright so we're still at negative 33 ROI after year three the third one is a more positive approach we're going to I forget what this thing was about I didn't even say well we're going to sell more stocks whatever it is we're going to sell more stocks those stocks are going to be flying off the shelf so by year three it's going to be 116 percent now if I'm looking at that going 116 percent yeah I'm going to go for that that's actually pretty good as they go now I can't speak about your company because here's the other thing that I'm not showing you here is that there's competing projects for these dollars right there's only so much a company can do now I wish a company existed that every and maybe they do that every time a positive ROI project was formulated they would do it wow what a company that would be but really what happens is that you're competing with other ROI's out there and by the way if I put probabilities on ROI one two and three let's say 40 percent 30 30 and I weighed that out the net weight weighed out ROI on this project is 31.67 percent after year three and I still I still think that's not good enough to win the day for the project but if it is what it is that's what we say and that's the number that goes on the cover of the business plan and then the rest is detail how you came up with all these numbers the cost are easy that's a few pages the returns a little bit harder and again doesn't come from us so we need to have our interviewing skills at the ready so do you use ROI in summarization get that discount rate know the revenue generation and cost reduction dollars by year for the next three years yeah and this includes the cost they're going to include labor reduction by resource person to rate so if you intend to reduce labor which is not a thing that you know I get asked about it a lot but I don't think I've ever really been involved in a project that drastically or even materially reduced a lot of labor in an organization just doesn't seem to work that way now some labor gets repurposed other places in the organization and I'm all for that and people step up to higher levels of contribution to the company and I'm all for that but just flat out this project is going to reduce 100 people that's more miss I think than anything else know the cost to implement and these are just some little bullets here but you know there's a lot of work involved in this a lot of work involved in this estimate the cost and benefits expected low and high and the probability of each scenario that adds up to 100% and there you go knowing what to do helps you do it right so you're not scrambling around in the dark and going down raffles and wasting time so how do you get that business quantification that I keep talking about we need here I said it's hard I said business people don't want to cough it up well usually it's a matter of the best estimates of those who should know yeah okay so let's talk about a data warehouse as an example if it's enabling the new product or service the data warehouse justification is tied into the new product or service justification volop you just got to get them to commit to doing it in a data warehouse way and oh by the way according to your industry standard here we don't build data warehouses for single projects we build them for multiple projects so be sure that is understood at the beginning so if I can tie into a project and by the way doesn't cost more to do it right it's going to cost you more to do a midsize or large project it's going to cost you more to do it the wrong way the wrong quote unquote quick way then it is to do it the right way but in order to do it the right way you have to have a commitment to doing it the right way and you have to know what that right way is and I'm not saying I know what the right way is all the time by any stretch I am just saying that you need to have an architected approach and it needs to be based on real education out there and real thought not just you know one vendor one vendor that has something to sell you getting in your ear and you rolling with that get yourself some vendor neutral education as you go along here but I digress these are some other examples of things in my background things I'm sure some of these are in yours as well increasing revenue per customer increasing customer acquisition etc etc yeah all these are directly related to ROI and by the way I don't like to go it alone don't go it alone you're coming up with numbers these are highly subjective numbers when it comes to the returns at least get yourself on the corporate governance committee or form yourself one to help you do this and making sure that you are bringing people along with you as you go now I'm a simple person I'm a simple person when I'm formulating 10 projects for a client in one of our action plans I'm looking at things like this what's the ease to do it I like easy nothing super easy okay but relative to other things I like to find things that are easy to do I like to do things that are going to set up other things so prerequisites if you will like to work on those and I like to work on things with great big ROI to them and that's probably the overriding factor by the way the ROI and sometimes you have an experienced team you're behind the eight ball as a company you're behind the eight ball in terms of architecture maturity but here you've got to do the project that's going to basically save the company and deliver the high ROI that the company needs to survive and that's a big risk position to be in so you want to have those little wins going right now so that when that moment comes you're ready to step up to the plate okay so we're making all this change in the organization to see impact of transformational change that we're doing to our companies have to always be like this the dawn of man just falling out of tree thud unfortunately we make it like this for too many of our internal clients we have to stop doing that we got to warm them up got to let them know ahead of time and then remind them several times because you know how it is in terms of all the things that are pulling the people's mindshare in an organization successful organizational transformation efforts like the ones we've just been talking about require much more than the right analytics and good planning and good technology that's all necessary but it requires taking care of the people remember at the very beginning I talked about the four big categories of risk of why organizations don't change people with one of them organization so talk about managing change in the organization and this is a program you want to bring along with all of these projects if you do that you're going to really help out that executive sponsor to say yes for the project because this is something that you it may be out of your you know realm of scope is being an issue it's squarely in his or her realm okay so let's let's bring it to his attention to actually do it it's not only going to help him or her out to justify and support the project all along the way it's going to help us out in terms of getting these projects accepted no more build it and they will come we're asking them for little things all along the way until we get to the point where we're giving them something big so these are all reality I'm not going to read all these these are all realities of the organization today employees concerned about how new processes will impact their current jobs oh yeah oh yeah that's a big thing I'm interviewing companies about formulating a master data management project and we're going to streamline this process and we're going to do this and do that and people are there wondering well I do all that now manually what am I going to do well before before I take on the project you know that's something that I talk about with the leaders I talk about you know this is going to raise the standard of the company what do we tell these people what are they going to do and let me help you come up with some of the ways that they can continue to contribute and I find that if we do these OCM things organizational change management if we do these things that we bring people along and that way we're meeting our goals for the company and our human goals I guess to the people involved staff not adequately prepared to execute new processes and technology and switch staff I'm really talking about here I'm talking about the technology staff I find that in trying to justify these projects that it is much more so the technology group that wants to drag things back and hold things together the way that things are then the business group I get much more resonance with the business group than the technology group and yeah that's just a fact and we'll just move on from that just know it change readiness and organization impact assessments can provide additional insights yeah doing some assessment work of the organization so let's look at some key areas of change by information management discipline let's say you're building a data warehouse the data lake or data hub or you can fill in the blank probably three more categories belong here but one of these shared artifacts of data today we're talking you know terabytes to petabytes of data here's I'm a simple person once again I want people to use the data platform not the old way is to get the data not not whatever they home group not not asking people and waiting days and getting frustrated but having it at their fingertips I want them to accept the data in the platform not question is quality or completeness because it is a sufficient quality and completeness etc why because we built that way and I want them to know we're building it that way we're not doing what the last regime did we're not doing what that whatever that old project was it was a failure we are doing it in a more modern mature way that accounts for all these risk factors and most organizations are at that point right now this isn't all net new stuff to them oh you know building a common database that's not net new to any organization what might be net new is doing it successfully and that's where your credibility comes think of other uses for data in the platform and contribute data derivations calculations summarization for the platform not just take data off the platform and run off to excel no too many times and I'm trying not to be very cynical here because I can be and I can have a lot of fun with this but too many times these data hubs are built data warehouses data lakes etc they're built and the user just can't wait to grab data out of there and run off to excel with and I might look the other way in the first month or two of the of the rollout but that's not something that we can look away from for very long because that is not using this intelligence tool which have much more capabilities it's not doing it in a shared way and it's just really not getting to deep levels of analytics no matter how big that excel document is and I've been in several organizations that have excel documents that are at the very limit I forget what it is but at the very limit of what an excel document can be and wow what a risk factor that is to the organization anyway I'll save the excel spiel for another time now master data management again simple guy here I want the organization to get their master data from mvm not some other way not adding to spaghetti code but get it from mvm I want you to contribute your master data to mvm that's so hard you come up with new master data I'm going to give you the definition I want if you come up with new master data in your processes I'd like you to give it to the mvm help I want you to buy into the new business processes to generate and update master data because we're going to create some new processes here to do that we're going to show you how good they are and how solid they are and I want you to contribute to that effectively use the new business processes to generate or update master data yeah I want you to use these new business processes response to change now this is not related not solely related by any stretch to data projects and organizations we go through this for everything the small lights that we feel on a daily basis sometimes we go through this even to big things that are life altering we go through this and I like to say that knowing that you're going to go through this and you've gone through it many times before maybe not at this level but you've gone through this process many times before it's a human process in the modern world hopefully that helps you get to the the levels the extended levels here to where you're spreading the word you know quoting quote spreading the word about the change that you've accepted it so this is modified a little bit from the one that in the acceptance alright but this is about project acceptance within the organization and you have users out there they're going to go through this denial the change won't happen people are stuck in their ways they like what's happening today most of the time you know they might get some lip service too I wish this were better but then when they start to get a little bit better it can be a little bit unnerving let's say and it's only normal the change won't it won't affect me it will be short lived oh no I'm angry I'm seeing some green shoots here of maybe progress oh I'm depressed it's actually happening how can I stop it now now I see something I have to stop I start bargaining with the organization well yeah okay I'll use your data warehouse a little bit maybe for this but not for these things you know or I'll try and then this isn't bad hopefully you've created an experience where it's not bad and finally I'm spreading the word now not everybody's going to be in the bottom level here in the green zone if you will a lot of people are going to be in red and yellow and you have to have a plan to bring them forward and that's part of the OCM plan by the way I'll get to that in a minute we want to cross the chasm yeah people are all over the place on this know that going in these are the focus areas of OCM training the workforce addressing the organizational implications engaging in communication making sure the organization is ready for the change to come and managing the stakeholders now you can do this either embedded in a project to support that project let's say I don't know it's an ERP project put tasks in that plan put path on that backlog that have everything to do with organizational change make sure that you are addressing organizational change issues for that project all along the way or you can do a standalone you can have a separate OCM group you can have an OCM SWAT team if you will that goes around the different projects and does this making sure it happens and being a part of it and this could be in support of multiple projects could be part of data governance yeah if data governance let's not get all let's get things done in the organization that we need to have done and if you have a committee sitting there that is capable and they're already meeting you can add on to it by all means do it whether the data governance manual or the book or whatever says to do it or not if that's what's going to work for you go ahead and data governance let's face it the end of the day it's a group of people a group of people that do things for the organization based upon their unique skill set and an organizational change in regards to data projects could be part of that so I recommend that you orient the OCM to projects and have short-term wins so you orient OCM to how to to making sure that every project out there is taking care of these people issues not doing something kind of general on the side for the whole organization I don't find those projects or those approaches do very well and last very long and have an impact in the organization and be looking for short-term wins maybe you move the set of people from from yellow to green and you have some material ways to show that they got more interested in the project before it's even built this is great maybe you did some training about what's to come maybe you had some chalkboard sessions some lunch and learn I know that's kind of difficult today but some you know whatever that looks like to you in the COVID area so you're getting the word out people are becoming more accepted of data as a specific layer of the organization not a drag along to applications not just something that oh yo by the way we need data for this project no it's all about the data the data should be screaming out what you need to do with it for the purpose of that project so how much OCM to do well you can look at your organization you can assess it and you can determine along these lines how much you need to do how much is the organization used to change well that impacts how much change readiness you need to do how much is the organization used to process change or how much process change I should say are you going to have as part of this project that impacts how much you're going to train the workforce etc stakeholders are they numerous and is there the potential for them being unsupported in this case in my spider graph here looks like that's true that is true so we've got to do a lot of stakeholder management etc are jobs changing are there widespread organizational implications the more of that the more OCM you need to do and so to recap today if you take care of the people issues the terminology issues the ROI issues the organizational issues and the credibility issues are some of the things that I find that they're hard people don't have the skills for and they ignore them at their peril when they're trying to get the organization to do what it needs to do and needless to say you need to be formulating great projects that drive the organization not only to ROI but to the future now speaking of the future that being said as I wrap up here and I will welcome your questions and allow a lot of time but I'll probably get a question or two in I want to expose you to the advanced analytics topics for next year and I am excited about these topics all the way from trends in enterprise analytics to measuring data quality return on investment these are the projects for next year I look forward to having you back every month and for now I'll turn it back to Paul to see if we have any questions thank you William for the wonderful and very informative presentation so William can you provide some examples of OCM tasks or deliverables I find people talk about OCM but often don't really know what it means oh yeah wow I've given a whole presentation on this that's full of tasks but anyway like for example when it comes to stakeholder management listing out your stakeholders assigning them our red yellow green how on board are they with the project assigning people from the core team to be to be their their buddy if you will and to make sure that they get the word in many different forms and as for like for example communication I've talked about getting a page on the internet getting into the common messaging that goes out to everybody so they know what's going on with the project and they know what they can expect and how they can be involved you got to hit these people with the message 3, 4, 5 times remember we're all one-barbit in organizations can't just tell them once they've got to find different venues I even said I think in the presentation that one time I put a billboard of sorts in the lobby of the company with a picture of the team myself and the team that built this it was an MBM hub and I had a little Q&A on there here's what it means to you here's what we're doing here's what's upcoming and here's why we're doing it and people would stop and read that you know get the word out communicate in various ways sometimes you have to be creative about it but yeah there's a lot more where that came from but yeah the questioner is absolutely right we'll do talk about OPM but they don't put it into a task and that is that's a problem so yeah you want to know your task here and William how do you what would you recommend for addressing credibility issues how should a person go about something like that oh wow well I one thing that you always have to keep in mind is that everybody's going to assess your credibility based upon their own criteria and so a business executive is going to address your credibility based upon your ability to drive to his or her strategic goals and ROI and so if you're talking all about you know third normal form and referential integrity and whatnot to them then you're not you're not building credibility at all you need to be building credibility by talking to them about how the things that you do apply to them and if you're on but if you're talking to technical architect that's you know making sure you know what you're doing in regards to I don't know what stream processing or what have you then you have to show demonstrate how you've been to webinars you've talked to people you've actually given it some original thought you've read a lot about it and you know this all comes out so you have to have a constant program of learning in this space I'm learning every day and you really got to be learning every day in this space well thank you once again William for the great presentation and Q&A but I'm afraid that is all we have time for today's webinar why organizations don't change when they need to just to remind everyone we will be posting the recorded webinar and slides and we will send out a follow-up email with the links to the recording and slides thank you to everyone for attending today's webinar and I hope you all enjoy the rest of your day and stay safe out there