 Okay. Good morning everybody. My name is Sean and I'm the CEO and founder of Dataversity. It is a pleasure to have you with us here today for the Dataversity Webinar Data Strategy. Plans are useless, but planning is invaluable, which is the latest installment in our monthly series called DataEd Online with Dr. Peter Aiken. As many of you would have attended these sessions before and be expecting to hear, my colleague Shannon, I'll just mention that Shannon is otherwise occupied today running one of our online webinars, online seminars, rather. So she's asked me to fill in. I have a few introductory points to get us started. Due to the large number of people that attend these sessions, you'll be muted throughout the webinar. For questions, we'll be collecting those in the Q&A section in the bottom right corner of your screen, or if you'd like to tweet, we encourage you to do so to share the highlights or ask your questions by Twitter using the hashtag data. If you'd like to chat with us, Peter and myself or with each other, we certainly encourage you to do so. Just click the chat icon on the bottom right of that particular feature. And to answer the most commonly asked questions, as always, we'll send a follow-up email to all of you within two business days, which will change links to the slides. And also, yes, we are recording this session and we'll likewise send a link to the recording of the session, as well as any additional information which is requested throughout the webinar. Now, let me introduce you today, Dr. Peter Aiken. Peter, as I mentioned earlier, I've known for many, many years and it's always a pleasure to work with him. Peter is an internationally recognized thought leader in the data management space. Many of you would have met him or heard him at our conferences worldwide. He has more than 30 years of experience and has received many awards for his contributions to the profession. He's also written dozens of articles and 11 books, the most recent worksheet, called Your Data Strategy. So today's webinar is right on top, Peter, with your latest thinking. I welcome you to the stage today and thank you for leading us in this discussion. Certainly. Thanks for a great introduction, Tony, and welcome, everybody. It's a pleasure to be here. I am in Central Virginia and the weather is nice and warm for a January. So hopefully it's pleasant wherever you are. Let me set the context on data strategy for us all just a little bit, however. First of all, strategy has to be an inherently repetitive process, one that you actually need as an organization to develop some muscle memory in order to take full advantage of. Secondly, there are some dependencies involved. Data strategy exists to support the organizational strategy. And a lot of organizations kind of get off track on that, that there should be a evolution of your approach to using data strategically. And at the earlier maturity phases, the process is more important than the product because everybody is learning and you will find what works best for your organization. The output, the plans are of limited value almost in all cases and they always discount obstacles that are encountered and that results in challenges that we've had. We've measured many different ways over time, but people and process challenges are the much greater portion of the problem rather than the technology piece. And yet for some reason we concentrate overly on the technology piece. To get to Nirvana, you know, one says, how do I get to Carnegie Hall? And the goal with data strategy is to practice, practice, practice. And I'm going to relate that to a musical analogy. Some of you know I'm a musician as well. I like to play bass. It doesn't mean I'm any good. I'm certainly not comparing myself to Bruce Spring. Now, if you hadn't figured out what song that was, that was the Bee Gees, Staying Alive. And I want you to think to yourselves for just a minute. Does anybody out there imagine that this is the first Bee Gees song that they wrote? No, this was actually closer to the 150th song that they wrote. So they have been practicing writing songs, but there's another element that is reinforced by the practice dimension here too. The band has only played this song three times according to this particular set list and just a little personal note here. I graduated from McClain High School in 1977. And if there was a song that I hated more than any other song in the world that year, it was Staying Alive by the Bee Gees. Now, the nice part about this is we grow and we learn things and look from different perspectives. Well, I sure like this song, but probably I like it because of the arrangement that Bruce Springsteen has brought to this by the way, this phenomenal performance here. And one more piece of it. Bruce kind of announces these sort of things to the band on the plane on the way to Australia. So he says, we're going to Australia. Let's do something nice for the Australians. And I hope we could do, oh, he didn't use to do this old disco song. Maybe if we do that as a rock and roll song, that'll be fine. Well, it was a lot of fun. It's a great deal of fun, but you can't just spring that on a band that isn't practiced. On the other hand, the E Street Band, as you all well know, is a band that spends lots and lots of time practicing, practicing, practicing, having been playing with this individual for many, many years. So the goal of this and the goal of this as it relates to strategy is that we need two parts to strategy. We need a good plan, a good song, if you will. But we also need to practice around this a lot. We'll see how that works out. Data strategy specifies how data assets are to be used in support of the organizational strategy. So we'll take a quick look at what is strategy and how does it relate to a data strategy, how do the two of them work together? And we'll focus particularly in on data governance because if you just are governing data without a strategy, it's hard to tell whether something is more important or less important than something else. So we need to look at this from three perspectives, improving your organization's data, improving the way people use their data, and improving how people use their data to support the organizational strategy. Because if we don't both improve the data and the way people use it, it's really hard to get to a good data strategy that will help the organizational strategy. There are a couple of prerequisites. We'll cover them. Lacks of organizational readiness, failure to compensate for the lack of competencies, and eliminating the seven deadly data centers that I described in this. There's a phase two set of things, though, that once you get started with strategy, it becomes an iterative process, literally lather in some repeat in that type of a context, that repetitive. But what you'll see is that there's a balance that is required in order to do that. And we'll talk about that balance and then get to the part about an hour from now where I really enjoyed as well, which is a Q&A, because you guys are always full of really good thoughts and ideas. So let's move on. What is a strategy? Well, we didn't even use the word until about 1950s when the business people picked it up and thought it was a good idea to apply to business. But it really did have a military background. It's just not used that much outside of the military background. And again, the definition here is that it is a thing, right? Well, it's also a process as well. And again, there are lots of definitions here. My favorite definition is one from Henry Minnsburg that says, strategy is a pattern in a stream of decisions. In this case, it changes the focus from the thing to an outcome. And that's really a more effective way to do this. Let me give you three quick examples of just business strategy. It doesn't have anything to do with data per sale, though you'll see all these organizations are heavy users of data in different ways. Very straightforward. Probably you all know this. Walmart had for many years guided by a strategy that said every day low price. These four words are drilled into every associate, every vendor, every customer. People know and recognize this. And it's something very simple. And if you make a decision at Walmart and your guidance is how to guide the customer to the best everyday low price, very few people will say you've done something wrong, even though it might not produce the outcome. They understand and they make good use of strategy in this instance. A second one, a sporting example here. Some of you may know of Wayne Gretzky's wonderful record, but not as many of you know his strategy, which is that he escapes to where he thinks the puck will be. Now, that's kind of obvious when you think about it and yet many people don't. So he plans his time on the ice by spending being available to have a puck come to him so that he can help his team score. Again, something that you can get a pattern in a stream of decisions. Here's our third example. This is a complex one. So we're going to go to a wartime military example. So the question is, how do I defeat the competition when their forces are bigger than mine? The answer is divide and conquer. And remember our pattern in the stream of solutions. This is one that is still taught in military strategy classes to this day. The lines of supply. This is Napoleon in blue here. The British and the Prussian are facing him. British in red, Prussian in black. And what Napoleon observed, we'll call it supply line metadata, was that the British troops are supplied out of Ostend on the Belgian coast. And the Prussian troops are supplied out of Leech. Now, those two places being different, if you are a soldier and you are forced to go backwards, are you going to run toward your food or away from your food? Of course, the answer is towards your food. So here's the divide part. First of all, what Napoleon wanted to do was throw the forces at the larger force, fast enough and large enough that the two would separate. If that worked, then the second step, divide and then conquer would be, first everybody turned to the right and get the Prussians, and then everybody turned to the left and get the British. Kind of important. So let's look at this more complex strategy here. First, hit both armies hard at exactly the same spot. Then turn right and defeat the Prussians. And then finally turn left and defeat the British. And oh, by the way, do this while somebody is shooting at you. That's a tough strategy. And by the way, this one didn't work, even though it's taught as a good example of strategy. It's also pointed out that they failed strategy. You see, strategy is something that you should be adapting towards and your organization absolutely is, as well as your data strategy. So you're going to use a different strategy if the good guys are on the left and the bad guys are on the right and the train is relative to the level. However, if the good guys, us happen to be up on the top of the hill and the bad guys are down there at the bottom of the hill, we're going to employ a different strategy and still different. We're going to employ another third strategy here if we have the position at the bottom of the hill and the bad guys have the position at the top of the hill. And again, there's lots of other factors. But what I'm saying is nothing that I've invented or in this general Eisenhower said in preparing for battle, I've always found that plans are useless, but planning is indispensable. And the discipline of going about data in a disciplined manner is much more important than it is to have a wonderful strategy that winds up on somebody's shelf because it really doesn't produce utility. Or at least if you take measurements and determine whether you're doing it better or worse, that's good, but how many of us have time for that? Everybody has a plan until they get punched in the face, according to Mike Tyson's famous quote, and that brings us back to, again, a pattern in a stream of decisions. Now, given that, the data strategy in this case should very much be the highest level of guidance that is available that focuses on data activities, excuse me, that focuses data activities on business goal achievement. We're pretty good in data and in IT on saying this data thing happened and that was really good, but we're less good at saying this data thing happened and this business thing happened. So by focusing the data activities on business goal achievement, we can achieve the alignment that is sometimes proven and lucid on this. Again, these things, the data strategy provides guidance when faced with a stream of decisions or uncertainty. Now, if you look at some of the books, there are only a couple of competing books out there on the marketplace. Oh, by the way, we do have some special pricing for the books today too. You'll see that at the end. But the books will say that your data strategy should be a combination of your data governance strategy and your BI and your warehousing and your data acquisition strategy. And I won't read you all the rest of them. And of course, I don't think this is really correct. The problem is, first of all, who has those documents and do you know any organization that actually manages to maintain continuity between these various parts? I have seen many fine organizations die on the process of trying to be over precise around that. So when we talk about how to do this, another way to think about it too is also looking at our DIMBOK. Now, the DIMBOK just tells what are the parts of data management, but in many cases, a strategic approach to using the DIMBOK looks like this. We might say that our first iteration on it through legged stool, for example, but we're really not using the DIMBOK well unless we use three parts of it at the same time. So here you go. A strategy might be a combination of attempting to do a data quality management flavored activity that combines with the data governance around that that combines with the data warehousing or the BI type of intelligence. Think about it as you're trying to get better at these three activities and you're doing it by practicing it in one area with a defined outcome as well. Our second iteration then might look like this, a little rethinking of the process. And maybe instead of focusing on data quality management, we focus on metadata quality for the second set of activities. Nothing wrong with that. It doesn't say one is right or one is wrong. But notice what we have done is gained 2x experience in the two that we've done twice, whereas we have 1x experience in the one. All of these are good measures of how we're doing on this. And of course, by the time we get to iteration three, hopefully we're getting better at some of these things, particularly the data governance and warehousing parts, because we've been through them three times now in order to do this. So it's really the combination of a smaller number of things that works as opposed to one individual thing that does this. When we're looking at planning options, then we can plan the entire process before beginning it. You know, I've got 1 attempt, so I've got to get it there. Perfect. This requires numerous upfront assumptions because things change. Think about last year to this year, even this time of year, we'll get tired of saying that at some point. But instead, if you use these iterative strategy cycles, you can incorporate corrective feedback based on your initial assumptions and get better. And strategy helps your whole program because as you do it in this fashion, particularly repetitively, over time your capacity increases and your capabilities improve and your focus can change from reactive to proactive types of activity. So within a data strategy, you might look at different things in the organization, forcing understanding of it, creating a vision, identifying specific imperatives. These are all things that can go into it. What it really should be is we're going to do these things with data that are going to make these things that happen in the business. And that will help us get a step or two closer to our organizational strategy objectives. I'm very much opposed to a couple of the strategy measures in the sense that, you know, again, many people weigh them in volume and they look at them for their complexity, right? Everybody agreed that the data strategy should probably be just not a whole lot longer than the organizational strategy. I've seen the longest one I've seen so far as a couple hundred pages, but to be fair, that was wrapped up with somebody's dissertation as well. There should be versions of the strategy. As soon as you put out your first version of your strategy, make sure that you label it as version one. Because if you don't, when you put out version two, people are going to say what was wrong with version one. Whereas if you label version one, version one very obviously, everybody will expect that there will be a re-sequence, a focus as we go forward on this. And finally, there's got to be common agreement on what can actually be measured around this. So measuring data with guidance here, how should data be used, where are these are all great questions. But the real question is what order should I approach them? So one of the things that's very problematic is that we've done things historically according to certain ways. So our organizational strategy is typically followed by an IT strategy. This does seem normal and reasonable after all the organization wants to go here. Here's how IT will help. Where we have gotten into trouble in the past is trying to attack a data strategy onto the bottom of the IT strategy. Again, this is just wrong. So how should we go correctly? Well, your data strategy is separate from, but more importantly, it actually is, in many cases, requires a lot of dependencies. The type of data that you're going after should dictate particular IT investments. And more than this too, I've seen these things counted as data strategies. Big data, data science, analytics, and not strategy, right? SAP, great software, but probably not your strategy, right? Microsoft, Google, Amazon. I mean, it goes on and on and on. So let's just take a quick recap here. A data strategy specifies how data assets are used to support the data strategy. We've talked about what is a strategy, what's a data strategy, and how they work together. Strategy works periodically. So again, we're faced with this situation. I'm not going to explain it. It's just a representation of the situation. But our strategic focus here is on getting, reducing space. So we go about, and maybe you don't want to eliminate it altogether. Maybe we want to reduce it by 50%. But this is the focus that we start on. Then we go on to the next thing and do those things well. Otherwise, it becomes very difficult. Again, let's move on a little bit. Data strategy is absolutely critical for effective data governance. I do a lot of talks. And one of the more popular ones these days is restarting your data governance program, which is a little bit problematic. Here are seven definitions from seven very good sources, including our own Denbach here. But I don't really like them because just imagine the elevator speech problem that we all face sooner or later back when we can get into elevators, right? So, you know, the elevator problem for those of you that are younger, would be that you get on a particular floor and a senior executive walks on and looks over at you and looks at your dad and says, Peter, you work for me. I've always wondered, what is data governance? And if I was to say to that individual, that would be the exercise of authority and control over the management of data assets. It's not really going to help them on this. So, here's a more helpful, I think, way of describing governance around this. And I think you'll see this actually plays right into where we're going with strategy. So, managing data with guidance is a really good definition because, first of all, it implies that would there be somebody that would say we shouldn't when our data manage with guidance? And the further up you go in management land, the more data governance is not just about managing data with guidance, but it's managing decisions about data with guidance. Because most people are very unaware that data assets are very special. I was going to say very unique, which is a redundancy, right? Data is your sole non-degradable, non-degrading, durable strategic asset. Compared to other data assets that can be used up, that can be great, all sorts of things can happen, data is a good investment for most organizations. And yet the way it's spoken and treated is wrong, just plain wrong. Again, oil is a production fashion. You take it out of a place and you use it. You never, ever think of reusing it. So, the entire way of thinking about data is not correct because you invest much more strongly in the data on it. So, I like to replace that oil with word soil. And there's two things here that are particularly better at describing this. You don't just take seeds and throw them about the yard and expect good things to happen. You carefully prepare the soil. And that same type of preparation is required in the data world. And also, you don't plant things on Monday and expect to eat them on Friday. We all know that it takes time. On the other hand, some people need to sell the sizzle and when I call it the new bacon, that's okay too. If we're having a conversation about it, I feel better than if we're not. So, as such, data does deserve its own strategy. It deserves attention on par with similar organizations and it deserves professional administration to make up for past neglect. Because while we have no real problem pointing to a lot of good organizational assets, pointing to data is still a challenge for us. And there's another aspect of this as well. That is that it's really important for us to understand the role of good data versus data. So, let me just start off with a premise. How to articulate the value of managing data. And that's pretty simple. If somebody says, you know, I don't think, I think data without being organized is as valuable as data that is organized. I would ask you to take the cover off of a book. Sorry, the heal off the book there. And have in these pages and take the page numbers off of them too. And you'd be surprised how quickly the value and more importantly, the knowledge that's associated with this disappears. So, data that is better organized in value increases. I'm trying to get data that is better organized increases in value. There we go. Consequently, practices that are substandard are more expensive than they should be. And the only argument I ever get on this number that 80% of organizational data is redundant, obsolete or trivial is that it's not high enough. I've had companies come to me and say they think 95% of their data is rot. But I can assure you is that it's not an easy problem to go out and figure out which data to eliminate, but that most data in the enterprise is never analyzed at all. So, let's look at this in the context of data strategy and data governance. Again, from a governance perspective, it may be a box over here on a chart and the data strategies here so then the question becomes what is the relationship? Data strategy specifies what the data assets do to support the organizational strategy. Data governance is about better doing that. So, it's the what and the how if you want to think of it that way. The feedback on that should be how's it going? Because that is kind of an important aspect. And again, I've said it's only supporting the organizational strategy that a data strategy has rationale and motivation around these things. In this world, I'm able to specify a little bit to the extent of IT projects and things like that. We'll throw in a couple of feedback loops and make for a fairly complex chart, but not really helpful. Here's the chart I would show most people. It's just sort of this one and I've had one other piece to it here. And that is that the thing that the data strategy should do to support the organizational strategy should be expressed in specific tangible business goals and the feedback should be in metadata. If you're not speaking the language of metadata, you are risking miscommunication within your organizational effort. So, when we talk about the motivations around data strategy, there's a couple of aspects that we need to look at. Look at it as sort of a three component process as you probably aren't surprised. The first one is that you're improving your organization's data. That's a good place. Everybody can buy into that. And you do that because data points to where the valuable things are. Data has intrinsic value in and of itself and it has inherent combinatorial value when combined with other assets that you can control or obtain. However, if we don't improve the way our people use data, because of course you use data to measure, to manage, and to motivate change all the way around, you have a block in your process of getting data to support organizational strategy. Because only when you have both your improved data and the way in which your people use its data has also improved. Then and only then are you going to get to the place where you need to be to actually use the way people can practice becoming data strategy and helping the organization to create a competitive advantage with data. Let me give you a very brief but direct and very illustrative story around this. Obviously, you can see it talks about the company Rolls Royce, which is a really phenomenal company that makes phenomenally good products that we generally do not worry about. There has been exactly one failure of these engine parts. This was by, I don't believe even a Rolls Royce engine, but jet engines in general are extraordinarily safe pieces of machinery. Rolls Royce was a product company. They sold things to people. The people they sold them to were the people who ran the airlines. The people who ran the airlines were very happy to purchase Rolls Royce products because Rolls Royce makes an excellent product. As do most of the other jet engine manufacturers. They all compete in a terrific industry and it's very, very vibrant and lucrative around that. But Rolls Royce was observing that they were unable to have conversations with their partners, strategic conversations with their partners. Consequently, what happened was they literally changed the entire business model of this aspect of Rolls Royce. They went from a product company to a services company. And there is nothing that is more difficult for a company to do than change from a product to services or a service to a product in real time on this. But they were careful about it. And again, their new way of describing this was that they were no longer selling jet engines. They were now selling hours of tower thrust. They had a great catchy name, power by the hour. And one of the things that you might observe in a situation like this was that nobody gets paid under this model for downtime. And if there's no payment from downtime, this is the conversation, one of the conversations that Rolls Royce wanted to have with its people, the customers that they had that they were having trouble having this conversation. They said, look, we can learn from other industries and do things that might be very illustrative here. And finally, when they're both on the same side of the table because Rolls Royce doesn't get paid if the airlines don't get paid and the airlines don't get paid if Rolls Royce doesn't get paid, that's the definition of this new cooperative model on this. They said, okay, now let's have that conversation. Watch what happens in terms of improving the way in which we change tires during a race. This is the Indianapolis 500 in the year 1950. There were restrictions. Time to refuel and change tires. Newmore himself changes the tires. Only four crew members, including the driver, are allowed to work on the car. It's the tenth time. Holland stays in his seat, anxious to get away. Let's watch. The tires are changed at last. A crewman polishes the windshield as Holland moves away just 67 seconds after he stops. There's a great measurement. Two tires, 67 seconds. If you blink, you might have missed it. That was going from two tires in 67 seconds to four tires in four seconds. Now, why is this relevant? And this is, of course, why the people who were selling the product, the beautiful jet engine that ran fantastically, couldn't get into these process-oriented conversations with their customers because their customers were confused about this. So they developed, cooperatively, a new process called wing-to-wing that has already been placed into effect. And they're now able to look out even further. So, yes, the airlines are very interested in applying those types of techniques to the process of changing an engine when you're playing lands at Ohio and you all have connections to Ohio, didn't I? Oh, here. And you all have connections to get to the next place and not much time or your plane is late. Again, faster. This is the way they want to go. Now, the next question that I would ask you all to consider is just what year do you imagine this new model was invented? And the answer is 1962. So there's tremendous opportunities that are out there. They are non-trivial to go after, but you better believe data was an important, important aspect of this strategic move by Rolls-Royce to create value on this. And they are still innovating, of course, today around all of this. So, hopefully, you see the strategy is necessary for governance around this. Now, let's talk about there are some blockages and things we need to clear, first of all. Data strategy moving and, again, even the work, using data strategically is the way I like to say it, is implemented in two specific phases. First of all, the first one is to get rid of the prerequisites to make it easy so that people can do what we want them to do. And, again, the second part is the lather, rinse, and repeat cycle that I spoke to you of earlier. The first piece of this prerequisite is that this is a dramatic change. There are things that need to change in this organization. My next book that I'm working on as we speak and almost ready to go is on data literacy. And the more I've researched this, the more I've found that this is an untapped productivity aid for us, and it will help us in terms of data as well. We need to completely put a new layer of education in for our knowledge workers. And if we can't get that education to them, then our organizations will be providing that education to the knowledge workers on here. Data literacy is the most requested training form for this year at this point. So there will be lots and lots of offerings, lots of people to look around and do it. And this is just starting with the dramatic change in how to use it. The second part is to look specifically at how our recruiting practices are sort of problematic in ways we can look at to evade them. The third one is the Seven Deadly Data Sins, which was the subject of the last webinar of last year. So we sort of put them across the holidays like this. Let's dive a little further into this process of preparing for dramatic change and determining how to do the work. And I have to be, I have to own it. I'm the one that wanted to write the book that says CIOs aren't. And the book ended up being a sort of a rationale for why you need to bring on a Chief Data Officer for your organization. It's not really very nice to say CIOs aren't, but in truth, it is the case that data is one thing that CIOs have not been able to do a lot about or do a lot well. One in 10 CIOs is a very savvy CIO. The other nine 10 are very, very good people at what they do, but it is challenging to ask them to do more with data, particularly the way data volumes are increasing at this point. Interestingly, when I had this book translated into Chinese, the Chinese translation of the title came back, Chief Data Officer Combat. And I thought that was kind of interesting, but it is very much of a tension here in many organizations. When you introduce the CIO and the CEO, remember the Chief Information Officer is just exactly that. And what else would I be? And now you've got somebody that you're bringing in that you're calling the Chief Data Officer. Now I would also say that's the reaction from about half of the CIOs. The other half of the CIOs are going, yep, I never have had a chance to get to that. And I'm not going to tell you the resources. I am so glad somebody else's problem. Here you go. Give me a call if I could be of assistance. Right? So it's an interesting set of times that we're going through and we will see some things happening around this. The most interesting one I think is with respect to the reporting structure of the Chief Data Officer. Now I'm not really... I don't demand that they be called Chief Data Officers. I've also heard of them called Enterprise Data Execs. I've heard of them called Top Data Jobs. I think as long as somebody's got the idea that there's one person, one set of accountabilities, one stroke to choke, if you will, to take care of these parts, that's really the direction that we need to work towards on this. Mario Farah, who's a Gardner Art Analyst says, yes, you've introduced confusion, uncertainty, doubt, resistance, but we're getting better at it. And one of the ways we can continue to improve our approaches is by taking advantage of a group of professionals that are already available to us. Change management leadership professionals can provide ways and help us to do things like diagnose organizational readiness. Again, there's been some simple formulas that have been out there for years and years and years. This is one that says, if I see vision and skills and incentive and an action plan, but I also witness frustration, I know that they are missing the resources. And if I see vision, incentive, resources, and an action plan, I know they're missing anxiety. Again, you can fill in the blanks on these, but the bottom line, of course, is that you don't get any change unless you have all five of these variables in place. And that is part of the process of doing this because culture is the biggest impediment to shifting our organizational thinking about data. It is a big, big challenge. I don't have a webinar on that one, but I did write a case study on it. It doesn't even require you to register. You just navigate over to that link and download it. And I feel fairly successful with it because I've had 11 companies come up to me and say, hey, you really captured our experience in that article. How did you get so close to us? And of course, the answer is I didn't. And there's lots and lots of examples for us to observe around about this. And if it's general enough, it seems to be a problem that's out there. So move on to the next phase here then again. If you can get them prepared for dramatic change, how do we still go about recruiting the knowledgeable enterprise data executives? The people that are going to interview are challenging. I mean, think about it for just a minute here. Let's take a step back and look at our general framework on the approach to strategy. If we're looking at business needs, which is a good place to start, and simply saying the business needs then move us directly into the solution, we're leaving out a very important variable, that variable. So I consider that to be also wrong. That variable is the current state of the organization. So as they look at their existing capabilities and map together, only when I find a match between a business need and an existing capability should I propose a strategic data imperative in order to go through. And execution should start only at that point. Again, a necessary sequencing activity to do this. Because simply put, organizations have little idea what data they have. They don't know where it is and they don't know what their knowledge workers are doing with it. And we're still, the definition of a knowledge worker is somebody who works with data, right? And we teach them nothing about data, but they all use it all of the time. And it's even worse on IT. We take our wonderful IT professionals who are going through computer science and information research, information systems programs, which is what I teach in, and they get one course, how to build a new database, which means professionals who we work with have observed these curriculum and say, data is only one of 10 courses in the curriculum. Therefore data is only one-tenth of the things that you should do. And by the way, what you should learn how to do is build a new database because that's an easy thing relatively to teach. What they also do is they draw a conclusion that says data is a technical skill that is needed when I develop new databases. So if I'm creating a brand new ERP, I don't need data people because it's not creating a new database. And if I'm going through and merging two existing databases, I still don't need data people because I'm merging two database. I'm not building a new database, right? And finally, again, data people, what if I'm going about and implementing a new CRM? I don't need data people because that's not implementing a new database, right? Again, when you teach people the answer to all their questions is a new database, why should we surprise that we have so much siloed data out there? Again, I also had this perfectly with the nail on the head, if you will. Again, it's probably not a flash to most of you that large numbers of companies report making inaccurate decisions based on bad or outdated data. If you're business decision makers and you're technical decision makers are not knowledgeable about data, they will make bad decisions and that will result in poor treatment of organizational data assets as well as poor quality of data and that will lead to poor organizational outcomes, lather, rinse and repeat. That is, of course, not the direction that we want to go. Yes, thank you, Morgan Freeman. Once again, this is wrong, all right? So now we go to our hiring panel and our hiring panel says, great. I listened to you. You heard Peter Peter said you need the data leader at some sort. So let's interview people. Are you a data leader? Yes, you say you are good. How do they communicate? There's really very little, I mean, yes, you can have an outside expert to sit in on the panel, but most of these are about C levels and they're executive recruiting firms. And by the way, they have recruiting firms that are specializing in this area, which is really wonderful to see around this. It is a non-trivial problem and in some of the governmental situations, we have better success because the data people across the organization, since they're not in a competitive situation, are sitting in on each other's data panels, interview panels, so that they can help people to understand what type of qualities are there that we need to put in place in order to get these. Because we need somebody at the top to provide leadership. Again, I like to call it the top data job. There's the enterprise data executive or the chief data officer. Either way, we need some form of leadership to liaise with the top IT job through a data governance organization and focus on data asset leveraging. Focus on not being constrained by an IT mindset and focus on reporting to the business. I'm going to spend a minute on each of those because it is critical to get what we're talking about on that. The key is that if you have your mind divided to something else, we just know that all of the research shows that multitasking is possible to do but it isn't good to do. So focus on a single focus. Just the same way your CFO is focused on the fiscal assets if your chief risk officer was focused on doing a payroll, you'd be asking questions. You've got to be unconstrained by an IT project mindset. IT mindset tells the majority that you're going to get something correct. The project mindset is one that says these things have a beginning and an end and somewhere in that we're going to put data into it but actually it's the other way around. Data is always there. It persists and the IT project will come and go and visit it and report it and store it and perhaps transform it on that. And finally to avoid that IT mindset in particular, let's report to the business for the next couple of years on this to see how that works out. I think we'll find it's actually quite useful because we're seeing another interesting dichotomy here and that is that there's sort of two roles that we're asking this one individual to do. The first one is to come in and make this massive change as I've described it to you. Already we've decided it's not particularly an easy task to do and probably doesn't occupy the same skill set as somebody who wants to come in and actually use the data but we've got to shake things up before we get there. So there's probably sort of a transition to a video role that can be out there. Maybe it's rentable. I don't know. I haven't explored that possibility but it's something that we might entice to look into as well. So again, we're now at the seven deadly sins and I'm just simply going to outline them very, very briefly. Again, there's an entire webinar that we did on them just last month but it is kind of a fun topic to talk about. These are really prerequisites that are common across organizations. The first one you probably can already guess here is failing to address the cultural to change management aspects of the things that we need to do in order to do this. In addition to that, number six then is you have certain sequences that must be observed in implementation of data strategically and if you get them wrong, it can be very consequential around that. It's absolutely critical to manage expectations and my favorite way of doing that is to imagine that you're running a data group that has five people including yourself and that you're all getting paid $100,000 a year. How quickly and how long and how much of your annual budget would it take you to produce a good business case for why you saved the company more than it cost them the last year to do this. I had some companies that said, oh, we've got a five-year window on this, right? Well, there's two problems with the five-year window on expectations. One, the average CIO is still only two to four years. So the idea that you might have a deal there could go away very quickly when the new manager comes along to do this. But similarly also, now you've got a $2.5 million net that you've got to cover in order to do that as well. The fourth deadly data sin is that the data program is what you align IT projects to and that because it doesn't exist at a formal level in this organization is a difficult, difficult task. You have to implement a robust programmatic means of developing shared data. You will not develop a good set of enterprise-wide data project by project. The implementation of a robust sharing means of data can be done by a project by project, but the project by project is useless if you do not have the programmatic aspects of it. Finding that qualified data leadership that you're looking for, is it grown from inside? Is it somebody that you go get from the outside? Is it talent that we can do? Can we develop a certificate around that to at least some folks who feel that the promising avenue of exploration on this? And finally, we're going to spend a little bit of time on not understanding data-centric thinking. Now, data-centric thinking is something that everybody wants to do. When you look around, this is the most popular thing, data-centric thinking. This is what everybody wants to do. What is it? So, Todd Harbour and I in our book on data strategy tried to codify it specifically and the idea is we posted this at a website. There's a conversation that we'll start to have around this. We'll probably incorporate this in with DAMA International as well going forward on this. But let me just take you through these four pieces up here. And if this looks familiar, it absolutely should. I ripped this stuff shamelessly off from the Agile Manifesto here. But what the Agile Manifesto ends up saying is that while there's value in the things on the right here, we value things on the left more than we value things on the right. And that's literally the word for word what they said. I just put in four different things here. Todd and I argued about these for quite a while. So, again, just sort of walk through them here. Spend a minute on each. Data programs must proceed software projects. If we do not, then we have always the software project is then satisfying what data should go inside it. If organizations would look at their software purchases, their software rentals, the things they're buying, whatever it happens to be that they're doing, in the light of their existing data models, they would be much more successful. It is now considered to be best practice to request anybody that you're buying some services or software from to provide you with a copy of the data model of that software before, so it can be evaluated before purchase in this case. Because discovering it don't fit afterwards is not a very good way to do it. If you have people writing code and then you stabilize data structures, you're unlikely to not have to write code. You're more than likely going to have to go back and rewrite code. So don't do it that way. Stabilize your data structures before you stabilize your code base. Data sharing has to complete, proceed complete software. If it does not, then you do software and you have the same problem with the stable data structures preceding stable code. Nobody is going to develop shared data out of altruism. You have to incentivize them to do this. And finally, reusable data must proceed reusable code. We've done studies in the academic world on why people don't reuse their code and the answer is because it's hard. Outside of the open source software environment and technology, which is a lot of really good stuff that works really well, right? If you are a programmer, you're expected to have your own site on GitHub by the time you graduate high school at this point. Well, we've got to put those same kinds of activities around reusable data. If we do not, we will end up in the same place as everybody else. So this is our data doctrine and in the new data literacy book, we're going to have a revised version of this, but Todd and I haven't finished doing the arm wrestling on it yet. So I'll reveal that to you in an upcoming webinar. We're now at the last part of this, which is really where we get to the strategy part. And people say, oh my goodness, how can you wait so long? Well, it's important to get the prerequisites correct. If we don't get them right, none of the rest of this will make any difference. Let's talk about the way this works about. So you've eliminated the prerequisites in phase one by preparing for a dramatic change and employing professionals who can help you change the organization in tangible, meaningful ways. You have found some way of recruiting typical talent or that is appropriate, excuse me, for your organization where it's at. In other words, if you need a changed CDO, don't recruit yourself a data scientist that's an introvert. It won't work. On the other hand, if you're ready to go dive into the next coronavirus vaccine that doesn't need to be refrigerated at 86 degrees below zero, by all means give us the introvert. And finally, you've eliminated seven deadly data sins. So again, as I said, the key for phase two is first of all, the cycle is identify the primary constraint that is keeping data from fully supporting your strategy. Exploit that constraint to remove it. Subordinate everything else if that first step doesn't work, elevate that constraint to a higher level and repeat until it is complete. Some of you may remember a book that somebody told you to read at some point in your life called The Goal. I'm very familiar with it because my spouse said to me, if we're going to talk about business, you must first read this book. And I kind of went, huh? And she said, just set up and read it. Being the correct person, I set up and read it. And now make, of course, all my students read it as well. And absolutely everybody is enthralled. If you haven't read this book, it is a masterful approach to explaining the theory of constraints. It's a novel. It has characters. Alex Rogan, I believe is the rogoc, is the hero of the story. But let's just talk about the theory of constraints. It's a management view that says that any system is able to be improved by removing small constraints or a small number of constraints. A few things are blocking you in a major way. But if you try to do all of them at once, you will not be as successful as if you focus on one, eliminate it and then go back and do it again. So the idea is that a chain is no stronger than its weakest link. And that our various organizational processes are vulnerable because these weakling components, the data in this case, can damage or break them. But these are not recognized as data problems because they manifest themselves as an IT problem or as a process problem. Again, imagine you've installed Salesforce. Kind of a wonderful job, terrific new product. Everybody's excited. And you forget to do your little data quality exercise around that. Well, that's a problem. And you know what everybody's going to say? They're not going to say that data in Salesforce is wrong. They're going to say Salesforce sucks, which is so unfair to poor Salesforce. But I've seen it happen, unfortunately, way too many times. So again, let's look at this cycle. Identify the constraint. What is it that is blocking our goal realization? And that implies we have to have goals. We need to figure out what goals do we need to have in order to achieve organizational strategy. We then, of course, try to exploit that constraint simply by trying to do it quickly and easily. If we can do it without making a major deal out of it, let's do it. But many times we can't. So we now need to review all other activity in relation to this one to make sure that this is, in fact, the subject of our focus, or, more importantly, the pattern in a stream of events is to, for now, fix this particular problem. Alleviate that particular constraint if we can do to eliminate it. If that doesn't work, we need to keep at it until we eliminate that particular process. This has been extraordinarily successful. And when you apply it to improving your data, what you're saying is what in our organization is blocking us most from being more helpful at supporting the organizational strategy. That's our data strategy. Then let's fix it. Correct it operationally. If we can't correct it operationally, then we're going to be able to go in and do a sense of re-engineering activity and restructuring type of an activity. And again, repeat until either the constraint goes away or not. Hopefully that you see now what I was talking about a few minutes ago in terms of, first of all, for instance, repeating, because this is the process that we need to get good at. Because this organization will be much more resilient than will the organization that has a 100-page data strategy guiding it. Again, I said this earlier. I'm going to repeat it here. Doing this in a cyclic fashion increases capacity and improves our capabilities. And it changes our focus from evolving, in this case, to proactive. We can be much more on top of the various situations. So I'm going to return to our data strategy framework. This is part two of the same piece, because there's another aspect of this that we need to finally put a cherry on the top of the whole thing. So again, remember our business needs, and most people try to go directly to a solution. That's wrong. So again, we're going to bring them in on this side here and say, like, only when you have a match between your capabilities and your business needs should you go forward. Here's where it gets interesting. Our roadmap, however, still needs to also be balanced. And the important thing is if we maintain that all we're doing is creating business value and that we're not working on creating capabilities. This typically occurs using consultants to an extent that's perhaps unhealthy in some organizations. They will think that this is great, but we will not have any muscle memory. Our organization will not gain the value that I've already described or being resilient in this. You need also to provide new capabilities. But if you err too much and provide too many new capabilities and not enough business value, management will get the idea that what you're doing is a, in this case, science experiment, and they will be unhappy with you. They will be impatient. So only when you have a good balance of business needs and existing capabilities, as well as business value and new capabilities, should you look to implement your data strategy framework in this case. So we've spent most of the last hour talking about this. I hope this makes more sense now when I talk about strategy being an inherently repetitive process that should be easily improveable on our organizations. It is absolutely critical to make sure that that takes happen. Otherwise, you'll end up with a 100-page strategy and how well is that strategy going to work when we're also, all of a sudden, working out of our homes, can't get on airplanes, et cetera, et cetera, et cetera. Hopefully, you now also understand the dependencies that we're talking about as well, our data strategy is only good in supporting the organizational strategy, but the nice part about it is, if they tell you this is important and you show them how you've helped them get it, you probably are going to gain a seat at the table. They're going to come back to you and say, look, I invested $100 in this individual last year and they did great results for me. Anybody want to double down and go for $200 this year? Yes, it is happening where I'm seeing it. The evolutionary process, early on, you're not going to be very good. You're not going to have the right team players. Your first data strategy may be an absolute failure. It's okay. That's why you moved to version two. By the way, that makes it really easy from a change management, from a configuration management perspective. We're not doing data strategy anymore, number one. We didn't work. We're going to go to number two. Hopefully, you don't have too many of those, but it does happen. Again, the output, there should be the ability of the organization to develop increased data competencies. Increase data literacy around all of our knowledge workers in here as a different topic, but we'll get into that as well. People on process challenges are largely the problem. Yes, I know everybody thinks we've solved it when we buy something very, very nice, like an ERP-like thing to manage our data governance efforts. It's perfectly good. It makes sense. But again, it's not the main problem. We're not addressing the people in process problem. The more the software can help us to address those people in process problem, the more you should be investigating that particular software. So again, how do I get to Carnegie Hall? Practice, practice, practice. So we spent, again, most of the last hour describing how a data strategy should specify specifically and detailed how data assets are to be used to support the organizational strategy. You now understand that while there are a bunch of different strategy definitions, which makes sense to use one that is in widespread use a pattern in a stream of decisions. And the data strategy then is to support that pattern and to apply that same model to fixing our data. So when we make decisions about data, which one will help us achieve our strategic objective more quickly? And let's do those things first. And again, working together, the best of all worlds, when you have to report annually and you're able to say, you asked us to increase sales when we use data and the sales department said there are better data. We're able to give them increased sales and they lad at the, yeah, that's exactly what you want in terms of nirvana. The data strategy then is necessary for effective data governance around that. It could be the main missing ingredient from your data governance organization. This three-step process that the organization should be focused on is improving your organization's data and improving the way people use their data because only when you have better data and better people's skills can you use it to support organizational strategy. I understand that there are a couple of prerequisites. As we look at this, it's just generally a lack of organizational readiness to change, failure to compensate for lack of data competencies and eliminating the seven deadly data sins. And then our data strategy should be an iterative process. Lather, rinse, and repeat makes a lot of sense to people. Most of us do it daily. And so this balance is absolutely going to be required around this and it is now 259 in 22 seconds. Tony, back to your user. Thanks, Peter. And thanks, as always, for doing a great job on this topic. I do hope I've been online all this time. Let's see if I can find questions. So the nature of the questions that are coming in so far, and let me just mention to folks if you have a question about Peter's presentation or data strategy, use the Q&A section in the bottom right section of your WebEx screen, please. Peter, I'm going to start the conversation with kind of an adaptation of the questions here because there's some folks in the chat in particular who have situations or related questions that aren't necessarily specifically about the strategy, but they are byproducts of if you like. One question here from Shikha, for example, is we have a joint data and analytics strategy, which is very technology heavy in the strategy document. And the question is, should we be focusing more on business needs and capabilities in that document? Absolutely. Technology? Yeah, so the real thing that we've seen in this space, and again, Tony, you and I have, as you said, named each other forever, and we've watched things immensely change over the years. And goodness, one thing we know about technology is that sometimes soon there's going to be another person there, so there's nothing wrong with saying our organization is a Microsoft shopper, a Java shopper, an R shopper. Again, these are perfectly fine, and it makes sense to acquire people who have these types of skills and abilities, but the technology by itself does not solve your problem. If it did, the vendors would pay for results, just as in this case, Rolls Royce absolutely doesn't get paid if they're playing, doesn't get paid. Think of it as a three-legged stool, and I didn't say that in the webinar, but people, process, and technology, you've got to have three elements to make it strong, to give it structural integrity, and too much of a technology focus is not good. Another thing to do, just to look at the balances and things, look at ITEL and COVID and their data sections and see how little that they have and of course, in our current curriculum on data in most university curriculum use days, that is inadequate. Thank you for the question. That's a great one. I'd like to get up on my high horse and rave about that one, as you can tell, Tony. So let me, before we move on to the next question, just to answer a couple of things that come up all the time. Will we be getting a copy of the presentation and recording? Yes. Within two business days, the university will send an email out, which will contain links to recording and to the slide deck, so everybody will get a copy of that. All right. Okay. So I want to go back to a question that John asked early in the presentation. He was asking about whether you'd be presenting the types of deliverables that support a data strategy. And I didn't see a specific reference to deliverables during the presentation. If I missed it, I apologize. But what sort of deliverables do you see as part of delivering a data strategy? So thank you for the question, John. That's a very good one. Let me start off by saying that I did not include a table of contents for the data strategy. In fact, hopefully the document itself is shortish in there. You see, again, yes, what your data strategy should encompass by the book is all of these pieces, whatever you have going in your organization, whatever parts of those that you have, absolutely important to do, but very difficult to do from an ongoing basis. It comes down to spending much more on overhead than not. So again, the goal here is to say, look, don't measure your data strategy and try to make it anything other than I'm going to make this better. And the reason I'm making this better is because it's going to help this specific organizational strategic objective. There's no better way to keep yourself in a job situation than to say I'm the one that helps us achieve those objectives. That's a very simple message. And then we'll go back to the elevator story that I was saying before. Again, if I sit on there and say, okay, data governance is a blah, blah, blah, it doesn't help them. But if I say managing data with guidance, they'll immediately get two things. Somebody's managing data, that's good. And maybe it wasn't managed with guidance before? That could be a problem there. John, did I answer your question? I hope so. Thank you. Okay. I'm sort of a related pop. Do you want to ask if there's any templates that you're aware of to use when writing a data strategy? If you Google data strategy on the Internet, you will see lots of examples. Just add the caveat. But again, I was going to head to another slide on this one. Since people do seem interested in it, maybe that'll, I may have gone through that material too quickly. So, yeah, there we go. So, again, the elements of the data strategy. Remember, think about what Walmart's data strategy, Walmart's business strategy is every day at a low price. I'm not saying you're going to come up with a wonderful four letter strategy of how to use your data, but it should be simple enough that everybody in your group will be able to get behind it. And think about the discussions that occur among data people, right? So, we have very good discussions. One of the wonderful things about the diversity community is if you guys push back and give us wonderful ideas. But in order for a strategy to be effective, we're going to have to do something and get somewhere. So, if I'm crossing a bridge, I'm achieving some sort of a goal, it doesn't need volume. And again, it should be shorter in general than whatever the organizational strategies are just slightly longer than that. And again, that there should be versions on this. So, to ask what parts should have in it, well, it depends on what you're trying to do. I would have something that says, you know, our data situation is X, maybe a paragraph to describe that. And the way we can most improve is by doing Y. And the reason we're picked Y is because Y will help us gain the most leverage to support the organizational objectives. Everything else is sure, it's going to be helpful that the person that said earlier they had a lot of technology in their strategy. Great, that's usually hard work and be very thankful that you've got that in a nice written form. But let's go back and make sure we observe those other people and process dimensions as well. Yeah, if you've ever done anything with organizational communication, it is a very difficult subject. To get non-data people to pay attention to any aspect of your data strategy, the simpler, the more direct, the easier it is to understand the better able they will be able to implement this. Because after all, the strategy is that roadmap. It's where are we going and how are we going to get there? Again, thank you for asking the question. Very good one. So if the strategy is the roadmap and how are we going to get there, what is data architecture? How do you distinguish those two things? Data architecture is the idea that you're understanding the structures of the data. I just happen to have this slide up at the moment. If you look in the right-hand corner of there, you'll see that sort of greenish diagram, not the arrow, but the one with all the little arrows pointing to it. That's just a, it would take, you know, a minute or so to look at this and figure out what is the question. In fact, it's small, doesn't help either. So when we look at how organizations treat these various processes, they do not understand. It turns into blah, blah, blah, very, very quickly. And so, messaging is very important. I find that companies in Europe have understood the importance of a communications function within the organization. And I was just on a conversation with a group of Finns this morning, and when they talk about a comm kit, they understand this. It's not an American concept, although it perhaps should be an area we could certainly learn a bunch from. Anyway, did I get to the question, Tony, or did I wander too far? We can take that one up again another time. I've been in numerous conference sessions where that question has come up. And, you know, I think part of the issue is just everybody has their own definition as you started out your presentation. You know, everybody has a different definition of what strategy is or data governance. So I don't want to get, I don't want to take the conversation into too much of a semantic debate. There's quite a few questions about where does such-and-such fit into data strategy? Like, where does data privacy fit in? Where does data quality fit in? Is there a broad answer to this question that's sort of equally applicable to all of these individual components? Maybe to answer the question about, you know, where does data privacy fit into a data strategy? And let's see if we can extrapolate from that. So that's a very good question. And in fact, it's something that Denmark needs a revision in so that we can incorporate some of these aspects in to do this. So when you think about privacy, first of all, the word has to go with security as well. And so consequently when people try to graft privacy or security onto an already existing product after its, you know, minimum viable shape has already solidified, it's a very difficult piece. So privacy has to be architected in. And I'll tie it back to your previous question there, Tony, as well. This is another role that architecture can play. People may say, well, what do you mean by architecting privacy? And we'll say, well, maybe one of the goals of the organization is to minimize the exposure of private data so that we're only going to keep it on, for example, certain types of equipment or certain types of technologies we may prohibit from mobile technologies. Again, not that there's good ways of doing this or better ways of doing this, but if we architect this in at the beginning, we'll be able to do it. If we try to get to the end and then go, oh gosh, how do we make Facebook so that perspective privacy? That's not going to happen. That's one of the problems that they have. Their whole technology base originally was something crazy. What was it? It was PHP, I think, that they used in the SQL server. It sounds wonderful, but when you really need to scale and look at what they're doing, they had to invent technology to make that operation work. So getting back to it, when you look at something like privacy, it's not even represented here, but the question is if somebody said, okay, here's your data group. Now, get good at this stuff. From a strategic perspective, that's really not useful. First of all, again, I'll critique the DIMBAC wheel and maybe challenge our loyal audience here to help us improve this. There's two things that this wheel does not show us. It doesn't show us optionality. As in maybe you might need to do document and content management. Maybe you don't. Again, it's going to depend as Tony said earlier in this. So maybe showing on this somewhat way we could have said some things are mandatory and some things are optional. That might be an improvement to this. Maybe another perspective also might be that we look at it and say some things are dependent on other things. For example, I get a lot of people say we should come first to the data warehouse or the metadata management. Ideally, we'd like them we'd love to have the metadata management on their first. But what goes to the question then, well, it's a three-legged stool. So trying to do any one of these is probably not as good as trying to put three of them together in some combination. And I think that's what you have to look at. So that combination there may be very different from another combination. And maybe your combination, you know, right up front that privacy needs to be one of those pieces. Well, by all means, write to us at DAMA so we can make sure that working group incorporates that into the next version of the DIN box. In fact, if you scream loud enough, we'll probably assign you a chapter or two to do the work around that. So maybe Tony is getting a little bit more towards privacy architecting. Again, it's got to be done from the beginning because putting it in afterwards just doesn't provide good results. Yeah, interesting using the privacy example triggered quite a few comments in chat and additional questions. Clearly. Think about it. We don't teach ethics to most students that are going through these computer programs. So there's another component that we've got to get to as well. Yeah. Okay. I'm going to go back to something that somebody asked earlier in the presentation and really it was a question to the rest of the audience I think that I'm going to put it to you Peter, which is there's a lot of chat around managing a data team or data department and just how many people are involved in that, what their roles are and how they can contribute to the strategy. I wonder your experience given that you've seen a lot of different organizations you know, if somebody looking to develop a data strategy, what sort of people need to be involved in that process? Really key to have business people involved in that aspect because while we're really good at celebrating data successes we need to get better at celebrating data successes that lead to business successes. Again, I'll give you particularly in the computer science area where we have rewarded innovation and it's a good thing to reward innovation, but I'm going to suggest that it may be more important to reward a combination of innovation and utility because that would actually drive things more in a direction that would be useful for us. Without a data program in place, organizations don't have the ability to provide the concentration. So one of the things I like to do is to go to them and say, okay, if you're asking a question about size but just a question that comes up early, how big should the department be? Well, first of all, let's look at it as the type of department it should be. Nobody in your organization, and I don't care who you work for, nobody in your organization is saying, well, you know what, I think we've done enough HR. You know, I think everybody's going to behave themselves. We're never going to hire another person as long as we have this organization here and it's just going to be, you know, it'll be fine from this point on out. So thank you, HR people. We don't need you anymore, right? Your data department is going to be as necessary as your HR department. So what's the department size? Well, a way to do some sort of sizing on it is to look to your networking and your security groups. Somewhere in your computer networking, your IT shop, there's a group of people who know where every wire in your building, every airdrop and there's lists of authorized users and systems and services that they're available to access. In a 30-person IT group, I generally will find 30 people involved in that. There's wide variance that can occur, so there's no good measures that allow us to predict, but at least can say, with a 30-person IT group, three of them spend time keeping track of who is allowed access and what services they're allowed access to. That's a good analogy for it because they do data management by themselves. Another way to engage the maturity of an organization's practices is to see how many how many personnel job categories are in data and this is a problem that takes us back to the federal government. DAMA is involved in lots of things and we have been very responsive when the Bureau of Labor Statistics reaches out to us and says we want to do a survey of the data profession, but the only two data profession categories that they will recognize are data-based administrators and data architects and so they have us count the number of them which obviously misses entire classes of people. Tony, I don't know if you remember, but one conference we had, we counted more than 300 different titles that we had of the 1,000 participants, 1,000 delegates that we had in the audience that year. It was amazing. Well, and it's only increasing too. I mean the whole realm of new analytics of data science roles is expanding very quickly. Peter, you said something earlier in your presentation that you and Todd were arm wrestling about and I was curious what that was. You said that you were still arm wrestling about something and that you would share the outcome with us. What's the topic that you're having trouble agreeing on? So the real challenge, Tony, and you've seen this as well, is that organizations all want to be data-centric, data-first, data-centered, data-data-data-data, but there's no objective definitions around that. So while it's wonderful as an aspiration, we need to have some very specific behaviors that we can prescribe and use as a test to see whether somebody is in fact data-centric or data-first or whatever it is that they're trying to do. So this is a conversation and I know that you've hosted several of these types of events with people like Dave McComb, who is also very interested in this subject, as is John Ladley and Tom Redmond. So there's a great group of minds that are trying to think on this. We just haven't come up with the answer just yet. But the second version of this, so this is version one and version two, hopefully, will be at one time this spring that's perhaps a little bit less focused on IT and a little bit more focused on usage of an application of, if that makes sense. Sure, sure. Okay. Let me take a look at the last couple of questions that have come in. Funny comments, right? Yeah. You mentioned that data literacy is an essential part of a data-driven culture. How does one develop data literacy in their own direction? There's a good effort that was done by a combination of Accenture and Click. It's called the DataLizuracyProject.org and they did a very good first job. As I mentioned at the top, the next book that's coming out will be focused on data literacy because I see it as a kind of imperative for our country. If we don't and I don't mean that for the world population. The more citizens are literate, the better off everybody will be. So I'm proposing in the book a set of 30 citizen data literacy needs. You can tell I'm not a marketing person, Tony, because it does not roll off anybody's tongue. But those objective needs should be met before somebody becomes the various levels that are there. So there's not one objective data literacy, but there's a range of data literacies that we need to look at from a societal perspective. Don't get me started on that. I'll go down to that rabbit hole, but perhaps we'll be able to bring it out as a course offering this from with you guys. Okay. So we have about nine or ten minutes left just in case anybody is wondering what our timeframe is. Robin from the IRS has asked the question related to the federal data services. The FDS has 40 practices to focus on and we've selected eight within her agency to focus on. She's supporting a call for action that can be proposed and accomplished in one to one and a half years. What do you think is critical for them to try to accomplish in order to do that? Well, sort of stretch for the focus. We do real well communicating ourselves as a data community. Resources like diversity provides wonderful places for people to come and go and share. It's the first place I go when I look up a new topic that pops out. But outside of the data community there's very little knowledge or awareness of any of these even conversations much less the topic. People want to know why their battery goes down. If you start telling them the data all over the place they'll start paying attention on this. So Robin's question and Robin and I have known each other probably about as long as you and I have Tony so she's been a good friend for many years. The question is when you have 40 that you can choose from and you decide to choose eight see even of those which would be good things that would make a difference. So again it goes back to the only purpose data that's for is to help achieve the organizational strategy. And so the more you can tie what you do data things happen here to and therefore these business things happen the more successful that you will be because it's going to take decades to educate society as they're going to get smarter about this. Imagine kids these days are less literate than I was and I was pretty stupid when I hit high school. It's just an unimaginable threat in my mind that we're facing in order to do this. So thank you Robin. Great question. Okay, so we have a CDO question here from Dean about what approaches tool methods would you suggest to the C level in order to get buy in on getting a CDO onto the team. So I guess the business case for hiring a CDO. So it turns out that data problems in your organization manifest in a number of different ways. I already described one of them using poor sales force as a representation. If you go and buy a nice new copy of sales force and you're really excited about it and you fill it up with rubbish data people aren't going to say your data in sales force is bad. They're going to say sales force is bad and in order for us to get these messages home it's just critical that we focus in and make what we're doing important and accessible to everybody else. So I do not expect people to understand or memorize my 30 citizen data literacy needs but I absolutely hope people start to recognize wait a minute you just told that company that they could go into your address book and take your address book and share it with who knows whom. Didn't you experience a problem a couple of weeks ago when your address book got into some Lithuanian bank account and all of a sudden all of your friends got a bunch of spam emails and everybody was really mad and they knew it came from you because it was obvious that's only going to happen a couple of times in society before people start taking you out of their books and ghosting you virtually or otherwise. Again there's just a lot of aspects of this that we really haven't quite figured out and we've got to do more work on it but very little really focused work is happening in these areas. So again we've got to be even when I go into companies and they say to me alright well we really want to start a data stewards council because that's different from our data quality group which is different from our I said whoa wait a minute nobody's going to hear a word you say let's just call it the data group because that's all anybody else on the outside is going to recognize inside it yes we could specialize we will understand this but let's not try and make everybody else learn that aspect of it if we can get them to come think data is a valuable commodity wonderful we have made a very very significant progress on that. Okay there's some questions that I are a little bit too specific or granular for today's conversations so forgive me I'm not going to pose those ones but a couple that a lot of people would be interested in you talked about the importance of change management do you have any particular book that you recommend about change management? Second there's one on the slides which is Mary Lipman's work where she came up with that original framework is a wonderful framework on that and I'm just going to reach over back whoops too fast there we go there's the reference managing complex change okay it's not quite loading yet I'm not going to put it up for that piece in the corner oh I'm sorry okay yeah it's just it's just the superscript at the top there adapted from a book managing complex change by Dr. Mary Lipit all the way back to 1987 have things not changed in the past 30 years unfortunately people are still people so no actually that's very steady I was looking for this if I can find it I'll put it on afterwards but yeah that's important organizations are appreciating more and more the value of at least having these types of skills in their organization available to them all right Mike McMorrow hi Mike he asked a question here and I can't do an Irish accent Mike or I do it justice but so I'll ask it in a semi Australian one well organizations are very different regulations are very standard I do see data strategies I mean governance initiatives currently dominated by regulatory shapes for example the ECB IRB regulations forgive me I'm not quite sure what that acronym stands for it sounds like European maybe but anyway do you see these initiatives currently dominated by regulatory shapes such as the ECB effectively mandate data quality frame work based on data dimension I really botched that question Mike I'm sorry but Peter it's in the Q&A section at the bottom there of course I can't get to while I'm presenting so Mike you're right there are again this is probably another flavor of strategy as well if the goal of your organization is to make sure that you are within strategic compliance of whatever set of regulations that you're trying to apply and I just had to move the DAMA international website from one place to another and it was a challenge finding a company that said no we know how to thread the needle through all the various privacy aspects that occur in the organization so there are a lot of groups that take both their governance and their strategy and focus it on regulation and one of the questions I asked them is do you think regulation is going to increase or decrease in your area if it's going to increase and don't treat it as a one-off project but go ahead and get good at becoming compliant it's not a bad practice generally there's a good rationale for putting these things in place in the first place but that said if you're not in an industry that suffers lots and lots of regulation in that context then maybe that's not the flavor to go off and do and again look at your organization strategic objectives if the strategic objectives are not focused right we'll all be out of a job sooner than later in that case so the best we can do is to help support those objectives along with everybody else's efforts. Alright well folks thank you very much we are at our time thank you Peter for another great presentation and your Antispect Q&A just to remind everybody we'll be posting a recorded webinar and slides within two business days and you'll receive a follow-up email to let you know when those links are available thank you again for attending today's webinar hope you all have a great day and we look forward to seeing you next month with Peter again thanks bye bye. Thank you so much bye everybody