 Hello and welcome. My name is Shannon Kemp and I'm the Executive Editor for Data Diversity. I'd like to thank you for joining today's Data Diversity webinar, Implementing Successful Data Strategies, Developing Organizational Readiness and Framework. The latest installment in the monthly series called Data Ed Online with Dr. Peter Akin brought to you in partnership with Data Blueprint. 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. If you'd like to chat with us or with each other, we certainly encourage you to do so. You can just click the chat icon in the upper right corner for that feature. For questions, we'll be collecting them by the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag dataed. To answer the most commonly asked questions, as always, we will send a follow-up email to all registrants within two business days, containing links to the slides. And yes, we are recording and will likewise send a link to the recording of this session as well as any additional information requested throughout the webinar. Now let me introduce to you our speaker for today. Peter Akin is an internationally recognized data management thought leader. Many of you already know him or have seen him at conferences worldwide. He has more than 30 years of experience and has received many awards for his outstanding contributions to the profession. Peter is also the founding director of Data Blueprint. He has written dozens of articles and eight books. The most recent is Monetizing Data Management. We're going to have to update that here shortly, Peter. He has experienced with more than 500 data management practices in 20 countries and constantly named the top data management expert. Some of the most important and largest organizations in the world have sought out his data blueprints expertise. Peter has spent multi-year immersions with groups as diverse as U.S. Department of Defense, Deutsche Bank, Nokia, Wells Fargo, the Commonwealth of Virginia, and Walmart. He often appears at conferences, especially data diversity conferences, and is constantly traveling. Joining Peter this month is special guest Michelin Casey. So let me turn the floor over to Peter to get us started and to introduce today's guest speaker. Peter, hello. Thank you, Shannon. Absolutely. It's a pleasure to be back with everybody and to talk with everybody, and I'm actually kind of landed for a change. So I'm just coming off of literally 25,000 miles of travel. So get a week at home today. I'll be very, very, very restful. Anyway, we're very pleased today to have Michelin Casey with us today. And we have an interesting bit. This is sort of a preview of a book that Michelin and I have been working on for about the past six months on the subject, obviously, of data strategy. Those of you that have not had a chance to peruse her biography, she's been in this business for a long time. We met, first of all, when she was the Chief Data Officer for the State of Colorado and was the first state government Chief Data Officer out there. She's had lots and lots of other experiences since then and has worked a lot of that experience into her contributions for the book. Most recently, she was the first Chief Data Officer for the Board of Governors at the Federal Reserve System and is now doing some entrepreneurial work out in Silicon Valley. Michelin, we're so pleased to have you here to join us today. Thank you, Peter, and hi from the West Coast. And they did not have a hurricane, so we've been talking weather and all sorts of other things. We're going to try to cover three aspects of the new book. And as I mentioned before, Michelin is writing the forward and the last chapter. And we were joking just before we got started, but I actually believe this very strongly. You know how when you pick up a book, you sort of try to figure out whether to read it or not. What do you read? Do you read the first part and the last part? Well, those are the two parts Michelin is writing. The first part and the last part. So in that sense, you don't have to read anything in between, but we'll try to give you a little bit of an idea of what we're headed for on this. So we're going to just do this in three parts today. Part one is what is a data strategy? Part two, what does it mean to implement a data strategy? And part three is about how to get rid of all those pesky little things that life throws up in your way as you're trying to do first two pieces on this as well. So again, Michelin, thanks for joining us. We're looking forward to the Q&A at the end of the hour here so that we can dive in and see what sort of questions folks have, because that will actually help us formulate some of the content of the book as we finish it up. So let me just give a starch on this and say that sort of it's a lifelong passion of mine to try and get people to perceive data differently. Most people when they think of data sort of say, yeah, there's this IT in the business and they've got to work well together and data kind of sits in the middle. I had somebody tell me once that that little green spot in the middle there looks like sort of a bat or something like that. Okay, but it's really not the way we'd like to think of it as. And the reason for that is particularly important. IT is largely a project-based discipline whereas business is much more a program-based discipline. And so those two things. We do IT projects to help keep our business programs running. And the challenge that we've had an awful lot has been that people have tried to slot data projects in in order to make them work. So I'm hitting the change button on the slide right now and give you the desired state. This is how we'd like you to think of data instead as this absolutely integral part of keeping IT and business running but being really much larger than most people understand and in addition to that extending our concept of program discipline in here in order to really encompass the data world, data cannot be implemented as a project because if you think about it a project has a start and an end and data of course persists. If you want data to persist across IT projects you can't expect to implement it correctly as a number of projects. Michelin, I'll just pause and see if you want to add anything to that before I dive into the data strategy framework. Yeah, thanks Peter. I think that's a really good emphasis on the importance of looking at data whether you're talking about foundational capabilities, your data governance program, data quality programs or master data programs. These are long-term ongoing activities that support not only the current needs of the business but the emerging needs of the business and needs to be really thought about in a very holistic way and not just the start and end date perspective. So totally on board with that, thanks. And you use the word program on each one of those as well and people really do have to understand the distinction between the two of those. So thanks, that's super. So let's talk about the framework that we're using then given this context. Everybody understands that you should start out with the business needs. Now when I say business needs, if you're in a nonprofit organization or an NGO or any of the other different organizations that we've worked with over the types of years, it still is some sort of what is the organization about. So if you don't have a strategy, it's a mission, but it still is the place that you start out with. And then logically when most organizations do this, they move what seems naturally then to say, well, given those business needs, what data needs should we do? And the challenge with that is that it's just absolutely wrong. The idea that you can go straight from where most businesses are, which is running pretty well to programmatic aspects of data, is not where most organizations do. They have very big challenges in order to get there. And it's really important to understand what the current state, the current appetite, the current maturity level of the organization is. And to incorporate that as well, my analogy here is very simple. Those of you that have had the pleasure of driving a Tesla, which is a wonderful piece of engineering, probably understand very well when I say it's not the car that you want to hand to a 16-year-old that has not had much driving experience. Having a great car and an inexperienced driver tends not to produce a really good outcome. And so, consequently, if you don't take into consideration the business needs and the existing current capabilities of the organization, it's very unlikely that you will be successful with your data strategy. One of the things that both Michelin and I have seen over the years is that organizations will come in and say, oh, well, we want a 360-degree view of the customer, which is a very reasonable objective from a business perspective. But the organization's ability to get what that means, to take the average of 17 different databases where their customer information is stored and have that integratable in some reasonable time fashion is absolutely not in the capabilities of most organizations. Once we have that ability for the first step, the first baby step off into data strategy land, then you develop execution and roadmap capabilities. And the key there is also to understand that that requires a balance between business value and new capabilities as well. It's good to deliver some business value, but if you deliver business value only, you're probably hitting low-hanging fruit and not really attacking the capabilities that need to be built up in your organization. Similarly, if you focus in on new capabilities, and I actually worked for a CIO one time that said, that's okay, our CEO says we've got five years to deliver on this, so we don't have to deliver anything at all for five years. And I just looked and said, how often do you think things stay the same in the business world for five years? And, of course, they didn't within two years. We had a new CEO who said five years. Don't think that's going to happen again. The key is to balance that business value with these new capabilities in the way to do that. Again, Michelle, I'll pause to see if you want to say anything on that particular slide there. Yeah, so thanks, Peter. I love this slide, by the way, and I've spoken about that a few different times, but I think this slide does a few different things that I haven't seen on some other frameworks. So, first, let's talk about business needs. And when we say business here, I don't know the mix of private and public sector folks on the phone and nothing to tend to get, but when we talk about business needs, even if you're in the public sector, your organization has specific mission needs and objectives that it is trying to achieve. It has specific strategies and objectives, and it certainly has a lot of emerging trends and emerging needs that it must keep up with. You know, if you think about the Department of Transportation and what's going on with autonomous vehicles right now, what an enormous amount of change that the Department of Transportation needs to think about and be prepared for as autonomous vehicles come into our future over the next decade or so, or the U.S. Department of Energy and renewable resources coming online that are putting a lot of pressure on traditional sorts of energy and the power grid across the U.S. So, again, my point is that this language here around business needs isn't just tailored toward private sector organizations, it's banned into the public sector, NGO and nonprofit world to really take that to heart for those of you in those worlds right now listening to us. And the other piece I think is really important is that current state box. I've seen time and time again in my consulting that a lot of times companies want to run before they can walk and crawl, and if you don't have some foundation, good strong foundational capabilities built up and good data management skills and knowledge, not just in your data stewards and data managers, but across your workforce, it's really hard to achieve that level of organizational maturity that you'd really like to get to. And so as we get into building the section that we're going to talk about in a minute here on building the data strategy, we're going to talk about looking at that organizational readiness piece and building in the capability model throughout that roadmap so you can not only hit the business value targets that you want, but you're also improving the organizational maturity and the data capabilities across the organization. Thanks, Beasley. And the next piece that we want to talk briefly about is what do we mean by a strategy? And most people are not aware of the definition that we use, which is that strategy is a pattern in a stream of decisions. So many people don't really understand it, but we like this definition because this definition talks to behaviors and how we want people to think. And the easiest way to conceptualize this is my favorite example of an organizational data strategy that was in existence a while back. Walmart used to use the strategy every day low price as a strategy, which meant that whether you were an associate working at the cash register or somebody working in the stock room or somebody who was working on IT or somebody who was out negotiating contracts with vendors, when you had a decision to make, this strategy governed that decision making process and said how can I deliver better value for Walmart's customers? It is pervasive throughout the culture of the organization and it is a great example of how organizations use data strategy and strategy in general to try and focus things on. So you can imagine from there, a data strategy at Walmart is going to be very similarly easy to use because the key is that the strategy must be the business and the business must be the strategy. initially, I think you had an example here that you wanted to impart if I recall correctly. Well, I'm forward looking into our next couple of slides, but yeah, I don't think I have anything for that one, Peter. I'm sorry about that. All right, let's move on then. So another piece that we want to draw your attention to just as background, we won't play this for you right now, but Simon Sannick has a wonderful TED talk. We've got a reference tier on the slide for you to do. And the essence of his talk is that organizations are pretty good and people are very good at describing what they do. But once it gets to how they do it, they're less good and when they talk about why, they really haven't been very good at all. And yet when you listen to Simon's talk here, and it's about an 18-minute TED talk to go all the way through, he gets to the point where he says it's not what you do, it's why you do it. People don't buy what you do, they buy why you do it. And one of the best examples that he has in his talk there is that he says, imagine if Martin Luther King's speech had been, I have a plan. It's not. That's not what Martin Luther King said. You have a dream. And that's really the difference between the two of those perspectives that are on there. So strategy is all about why. And why is important because you've probably heard the phrase life is what happens while you're making plans. Or Mike Tyson's famous quote, everybody has a plan until they get punched in the face. In organizations, we've got to realize that data is an asset and that there are all kinds of things that we include in our asset management capabilities of organizations, but data is not typically included in there. And the reason is because IT has had a different focus for many years, and the business thought IT was taking care of it, but we also want, in this case, to have everybody understanding that the business really should be the owners of data assets in the organization. So we have a little credo that we sort of say, we believe that data is the most powerful, underutilized, and poorly managed organizational asset. It's the only asset that we have that can't be depleted, that does not degrade, that is durable in nature, and therefore it is strategic in nature. When we look at what's actually happening out there in the world, data, we see this over and over again, data is the new oil. Well, the problem with thinking about data as the new oil is that that really thinks to a production function, and what we'd really prefer people to think of is that data is instead of the new oil, the new soil, plant something in it and something will grow. If we need to call up the new bacon, that's okay. We'll be glad to do that. Whatever we can do to get people to pay more attention to the data portion of all this. So collectively your data strategy should be about strengthening your existing data management capabilities, finding solutions that will work at the organization's ability to incorporate those solutions into the partnership that you have, and finally building a partnership so that the next iteration of the strategy, because of course you're never going to make one data strategy, you're going to make your first version of a data strategy. And then you're going to move to your second, third, fourth, hopefully fixing all of these things as we go. So we're about a third of the way through here. Let's move into this next category here. Micheline, I'll toss it over to you. We're on the slide that says why is a data strategy and why have one. Thanks, Peter. So let me just start with a story. I think the story is just super powerful. So I recently did some consulting for a financial services company, and I was one in a string of, I don't know, less than a dozen, somewhere between seven and a dozen data type of consultants that this organization has had in over the course of the last five to ten years or so. And I did my assessment, had my recommendations, got in front of the executive team, and went through my presentation, and lots of good questions, super engaged group, and then we got to the end. And the CEO asked me a question, and he said, you know, I've had people like you come in and tell us that we need to do a better job of managing our data. And so we implemented an enterprise data warehouse, and we're still having the same problems, and I don't understand why. And I think that story is really telling, because while they had implemented the data warehouse, and it started to build an analytical team, they didn't have any data governance across the organization, and so while some people pulled their analytics from the enterprise data warehouse, others pulled from source systems, and they could never figure out why they were getting collisions with the number of, or the differences in the answers that they were getting when they would pose a question, whether it's the number of customers they have, the number of revenue, or however they wanted to slice and dice it. And really at the end of the day, just implementing a piece of technology isn't going to solve a particular problem. You really need to have a holistic view. You need to have a strategy about what you're doing, why you want to do it, and go beyond just the technology and get into the people process and culture aspects, and we're going to talk about that with regards to the data strategy. So Peter did a great job of kind of walking everyone through what a data strategy is. What I'd like to say about it is just really, the strategy is about how you're going to do things with your data that's going to make your business more competitive, make your business more successful, allow you to grow, gain that competitive advantage, in whatever way that is. And again, even for those of you in the public sector, you're trying to improve operational efficiencies. You're trying to do more with less money. You're trying to serve citizens and businesses more efficiently. All of these things that I'm saying apply to you as well. At the end of the day, this is about creating value for your business. Next slide, please. So some of you may have seen some statistics. I'm not going to dwell too much on this, but a decade into what I would call the data revolution is where we're having some hard and fast numbers about how being data-driven can really help a company and an organization perform better. And quite frankly, if you're not data-driven, by this point you're falling behind. Next slide, please. So what are some good characteristics of a data strategy? If you were to build a data strategy, and some of you may already have data strategies, how do you know if it's a good one? We've got some things here, lining with business goals, actionable, measurable, relevant, et cetera. These things are particularly important. And what I will say, what I want to highlight is it's living. This isn't a once-and-done thing. We're not developing shelfware here. We're not developing a five-year plan. You're developing a 12-month to 24-month roadmap that you go back and review on a regular and consistent basis because your business and organizational needs are changing. Your ecosystem needs are changing. And so it does need to be a living document because that's the only way it actually adds value to the organization. Next slide, please. Now we're going to kind of get into the need of actually developing a data strategy. And again, hopefully many of you on the call already have data strategies. Some of you may have data strategies that hopefully this shows a little bit of light. I'm always interested in how companies have developed their data strategies. So if you have some good things you want to share later, I would also love to hear some of your use cases and processes as well. So we talked a little bit earlier about data being a program. And it is, but what I would say about developing a data strategy is to run it like a project. It does actually have a start and an end date. You do have to deliver something to your stakeholders in some period of time. And you're going to go through a normal set of project planning activities. You set out your list of activities, have milestones, and a set of deliverables. So someone needs to own the data strategy process. If your organization has a chief data officer, that person is an obvious executive to own the development of a data strategy. If you don't have a chief data officer, there should be someone identified on the business side of the house who should be able to take this on and really lead the charge and the effort. So over the course of the next few slides, I'm going to get into each one of these bullets in a lot more detail. Next slide, Peter. Thank you. And Peter, if you want to jump in on any of this, you know, please feel free. You got it. I can't turn anything back over to you. You're driving. Okay. So the free planning process. This is an activity I would hope you would all do for any sort of a project. Really understand who needs to be involved, how things are going to work, what the timelines and deliverables are going to be. Again, those who, what, where, when, why, how, questions. You need to identify the stakeholders and participants, whether on your team or stakeholders across your organization or even outside of your organization, depending on the type of work that your business is in, the industry your business is in, some of your external stakeholders might be very valuable in the process. And make sure that you've got them lined up to help with this. How will the process actually happen? How is it going to be gated? Certainly you need a communications plan. I can't emphasize the communications plan enough. You should be communicating in advance across your organization to the stakeholders about what you're going to be doing, how they're going to be involved, how you're going to be able to answer their questions and get back in touch with them, and then run it like a marketing campaign. Keep people up to date. Keep people interested and engaged, because at the end of this process you actually have to sell this. And what I mean by selling it is you need to get it funded. And the more that you can communicate what's going on and why you're doing these, the things that you're doing as part of the process, the more awareness there is and the easier it'll be when it comes to that end step of actually getting funded for this. So certainly you need to have a project manager. You need to make some determinations about if you're going to use contract resources or do all of this in-house, just a mix. What the gating process looks like, how iteratively you're able to work the process and we're going to talk about the iterative agile method in a little bit. Certainly you need to do some good thinking about who needs to be involved for both strategic and tactical buy-in and support, both across the business and from the IT side of the house. And think about how you're going to use them. You know, for your senior executives, you're not likely to sit them down in a focus group type of environment and try to solicit input from them, but you may go one-on-one and just drop in for 15 minutes or so and ask them a few pointed questions. So that engagement model of how you're going to involve folks at what point, what you're going to ask them about and how you're going to leverage them is something really to consider. The other important thing to talk about is having some sense of when you've gotten it enough done that you feel it's both good enough but you haven't wasted so much time on trying to make it as perfect as it could possibly be. I think lots of us who take a lot of pride in our work tend to want to make things extremely perfect and oftentimes perfection is the enemy of the good. I'm sure that you've heard people say that. So at some point you have to make a determination that you've covered enough territory, you've talked to enough people, you've gotten enough input. There's a level at which talking to additional people probably isn't going to give you much more insight than you had previously. So what is good enough and what does that actually look like and mean to your organization? We actually can measure that by diminishing returns. That's when we're getting less out of it than we're putting into it. Two more key points on this slide that you emphasize and I want to just make sure everybody gets very, very strongly. First of all, the communication plan. You are being defensive here because if you are not actively talking about what's happening in your data strategy plan, you can be absolutely sure that other people in the organization are making up stuff about what you're doing. In other words, absence of any good information from you. Somebody else will stick some really bad information in. I can't tell you how many different times we've both been in organizations and we'll hear this rumor about the data strategy and we'll kind of look at each other and go, where did that come from? And that's our signal that we clearly aren't communicating enough. It's very, very difficult to over-communicate about a data strategy around this because it is new, it is unfamiliar. And again, if you don't actively push stuff out there, people will make stuff up about it. The other piece that Michelin talked about here too is that it's very important to label this as version one. That lets people know that there will be a version two coming out when we've accomplished the goals. And this is what Michelin was talking about earlier. It's a program implemented as a project. Great point, Peter. Thank you. Okay. So one of the first things that you should be thinking about as you're thinking about the process itself is understanding how your organization does or potentially doesn't do strategic planning. And I'll talk about a few points. Most companies, every company at least has a budget cycle. Most organizations have a strategic planning cycle. And that could be a three-year strategic planning cycle with yearly updates. That could be two years of planning. It could be a five-year planning cycle, whatever it is. But most organizations have some sort of formal planning cycle. What's important to understand is when does that start and stop? When does funding decisions actually get made? How far in advance do you need to have your document done and out in front of stakeholders for socialization so that when it comes time to make the funding decisions? At least some of the programs and projects and initiatives that you've got in your roadmap are actually funded. Those are all really strategic decisions and things that you need to understand in advance because if you miss a planning cycle, then you've got another year or so to wait until the things that you put in your roadmap are up for consideration. And typically it's been my experience and I'm sure there's some exceptions to this rule. Typically what gets funded is what actually gets worked on, right? Because they end up in people's performance plans and there's rewards and incentives about all of those things and people tend not to work on projects that certainly they're not intended to work on or haven't been funded by an organization. Again, there are exceptions to that and I recognize that, but really understanding your organization's planning cycle is a really important part of it and try to get out ahead of that to the extent that you're able. Anything else to add there, Peter? No, again, your keyword there is leverage, right? Don't go in and ask for something that's off-cycle. It's just not going to work. Absolutely. All right. So the development process. And after we talk about the development process and cycle we're going to talk about what should actually be in a data strategy. What are those key components? But the cycle itself, right, from start to finish, on Peter's slide he talks about the business side and understanding sort of what's going on with the organization and strategic objectives and that sort of thing, that nice data strategy framework that we talked about previously, the box on the left. And then we've got the box on the right, which is current state analysis. So those are two of the major inputs that go into this first step, which is gathering inputs and artifacts. Certainly, there's a lot of things across your organization that already exists. They could be former strategic plans. They could be projects and program plans. There could be exercises going on across your organization and your current planning cycle. Certainly, there's a lot of material from a SWAT perspective, our strengths, weaknesses, opportunities, and threats that you can probably get your hands on. So first step is to just look around and see what you've already got. And if you already have an existing data strategy, awesome. That's a great something off point that certainly it's most likely to need to be updated. You also want to then conduct some interviews and assessments across the organization. Go out and talk to people. What's really going on? What are the high priorities and needs of the various divisions or business units within your organization? How do those tie into the overall strategic needs of the organization? Typically, what you'd see from a strategic planning process is a set of enterprise strategic goals and objectives that then trickle down into business unit or divisional goals and objectives and then down to the programmatic level, et cetera, et cetera. So hopefully some things like that exist. But it's really good to go out and talk to people and get a sense for where things are at, what's going on. Look for the blind spots that you may not be aware of. Certainly, I think there's always things that we don't know what we don't know until we actually go out and talk to people. And so that's the key thing you're trying of this next step of conducting interviews and assessments. You may even want to have some focus groups. And certainly, as the strategic plan gets developed, you should definitely hold some focus groups across the organization. The next step is to actually develop a strategy and iterate on it. And what I mean by iterate on it is I like to run my data strategy project in what I would loosely call an agile method. Probably this isn't quite that quick, but a very iterative approach. I found what's worked most effectively is to get buy-in and agreement on the large, the enterprise goals and objectives that you want to achieve and just start there before you actually start building anything else into the strategic plan. Because if there's not agreement at the highest levels around what goals and objectives you're trying to achieve for this planning cycle, and again that could be one year, three years, five years, whatever your planning cycle is that you're developing this data strategy for, everything's going to stop dead in the water until you go back and get agreement on what those goals, those highest level goals and objectives should be. After you've got agreement on the highest level goals and objectives, then you can dive deeper into each one of those areas and begin to flush out some of the details. But you can do that pretty iteratively and think about getting your stakeholder group, whatever that looks like. That could be your data governance council. That could be your data boards. I'm sure lots of you have those sort of committee structures already existing within your organization that are very cross-functional, multi-disciplinary in nature and are representative of, if not all, most of the parts and pieces of your organization. Get those folks together. Get them to come together and help you think through what the goals and objectives should be and then what each of the particular projects should be within those goals and objectives. And certainly you can do that in a very iterative sort of way. Those stakeholder reviews are going to be critically important, again, for buying and support. If you've got, again, a data governance council, an advisory board sort of thing, leverage them, get their input and buy-in. And in particular, if they're tied into their strategic and senior leadership, you want them to be advocates for what's going on. And so the more that they can be involved, the more that they know, you should also be able to have them go back up the food chain and say, this is what's going on. This is how we're prioritizing things. This is what was included. And this is why I believe this is the right thing to do. So you've got that, you've got those stakeholders advocating early for what it is you're trying to do. Once you've got a fully developed plan, and so I fully developed, I mean, a full version draft one, begin to socialize that final plan across the organization. And again, you want to go to your key stakeholders, particularly those that will be involved in funding decisions and key division or business unit leads across the organization, but also really think about who could say no and who could totally toss water onto the fire and put that out and go talk to them and get their insight and make sure that they're on board to the extent that you're able to. And then finally, once you've got all that input in, you're going to finalize that strategy and start to put budget numbers against that. And those budget numbers would be people numbers, that would be project numbers, that would be technology numbers, all of that wide variety of things that goes into a budget. One of the things I will talk about later is leveraging storytelling. And so what I found over the course of the last decade that's worked really well is actually develop your data strategy as a slide deck presentation, not a 100-page Word document that's going to end up on the shelf. You've got key executives who are very time crunched and as much as I'm sure they would love to read 100 pages of how you're going to make the world better with all their data, they just don't have that much time. So you need to engage them really quickly. Tell the story about why this is valuable to the organization, how the vision is, how it's going to be accomplished in a fairly short form process. One of the things I had my team at the Fed do was when we started out, I think they ended up, the first draft was like 140 slides. And I said, okay, great, your challenge over the next month is to cut it in half and then cut it in half again. If you can get your final strategy down to 25 to, I don't know, 30 slides, that's great, less is more. We ended up at about, I don't know, 38 slides is what I think we ended up with. But really think about how you tell the story about why this is important and how it adds value. Peter, anything else to add there? Just that you have really hit on the key pieces here, which is that when your group finishes doing its data strategy, you're going to be expert at this. And the rest of the organization is typically at zero. So they've gotten really great and they want to get out and talk about it with everybody else. Your emphasis here on socializing the plan, making sure that you have stakeholder buy-in in that process, each of those people in turn then becomes a person who can advocate for the data strategy going on upwards. We just can't under-emphasize the, sorry, over-emphasize the importance of that multiplication effect in there. Great, thank you. So I see you've already moved on to the next slide with those components. So what should actually be in your data strategy? You know, first I would caveat it as a good consultant to say it sort of depends on what works strategically for your organization, what sort of things are normally involved in a strategic plan. But generally what you should expect to see and what you should expect your data strategy to contain are the things that are listed here, right? So background, just provide some context and alignment, whether that's around your existing strategic planning and budgeting or could be some vision or art of the possible end-user stories, purpose and scope, like what's in and what's out of your data strategy. You know, what is it you're actually going to try to do as part of this data strategy so you're just not going to even touch? Having those lines of demarcation are really helpful for the end-user readers because while you've been in it and writing this thing for, I don't know, two months, six months, whatever that timeframe is, nobody else has. And so while you know what's in your mind and what's been written down, the end-users are going to still have lots of questions. So one thing I think is really interesting to consider is what in the actual process are called ethics or end-user stories. And this is about when we talk about vision and business case and benefits, this is really getting into the heart of what's the art of the possible? What is the why we're doing this? Going back to the Simon Sinek, TEDx story, or TED Talk. And again, if you haven't seen that, I highly, highly encourage you to go watch that. It's a great timeless TEDx talk. But really thinking about painting that picture of what the future could look like. And all of you across your organizations actually have those stories in your mind. If you've paid attention at all to what people are saying in your organization, you know, oh, my gosh, wouldn't it be great if, oh, if only we had this data, we could do this. Oh, if only we had X, we could do this. Those stories already exist. They may just not be written down to the extent that they're actually fleshed out as an epic story. One of the things we did at the Fed was actually build four end-user stories that were in our data strategy right up front. And we titled it like, What might the future look like once the goals and objectives have been realized? And we created a story for several types of roles within the organization and several types of use cases within the organization. And we went out and actually interviewed people across the organization. We wrote our stories. We went back out and validated with those same end-users, you know, that we heard them correctly. And we built these stories that once folks across the organization could read them, people's heads nodded, like, oh, yeah, that's what we've been missing. That's what we need. And while those are the stories that people understand, having a 360-degree view of the customer, that thing gets translated into specific objectives and initiatives within your data strategy that is more what I call the technical data management, data capabilities language. Most of your end-users across the organization aren't going to understand and nor likely care about that technical language. They're buying into what the vision is that makes their life easier. And those are some things that really should be communicated as part of this strategic plan. So the other things, goals, objectives, strategies, and initiatives, you know, what is it you're actually going to do? What's that roadmap look like? How are you going to prioritize the work? What are your risks? What are the organizational risks and success enablers? What are your budget estimates? And then what are your KPIs and metrics? At the end of the day, how are you going to know that you've been successful? And certainly most of you probably have heard lots of things about, you know, you measure what's important and there's lots of, you know, Peter Drucker and other sort of things around measurements, but you should have some sense, even if it's not super granular, about how you know you've achieved what needs to be achieved as part of this data strategy. Next slide. So I wanted to spend a little bit of time talking about prioritizing initiatives because this is actually not easy. There's probably a million things that across your organization you could think of doing as part of your data strategy roadmap. And part of it also depends, part of it depends on what your business needs are and what the priorities are on the strategic side, but it also depends on what you're capable of, how mature is your organization, are there foundational gaps in your data management capabilities that actually need to be built up and how can that be timed in to support the priorities. So all of those things need to be taken into consideration when you look at your priorities. Next slide, please. There you go. So in thinking about how to prioritize your initiatives, right, and certainly I've got a graphic there on the right, you're going to have some sort of a timeframe for how things, you know, get implemented over the course of, you know, your time horizon. But thinking about the value as to the organization based on your business goals and objectives, what capabilities you either have in place or need to be added. Look at existing projects that you might be able to leverage or can create multiplier effects. I think some cautionary tales is you don't want to, if you're new to building data strategies, certainly you don't want to have too many strategies and initiatives. You need to be really realistic about what you're able to achieve organizationally and how mature your organization is. So if you have a roadmap with, I don't know, 50 to 70 initiatives, that's realistically probably too much for your organization and you probably want to keep things a lot tighter than that. Having three to five key goals over a three-year time horizon is about where you want to be, potentially less depending on the maturity level of your organization. In terms of where and how to focus time and activities, you know, look for those strong use cases that you've got across the organization. You could focus on things that are happening within specific business units. You could look at things around specific data domains. You know, certainly having a 360 view of the customer is important and that customer master data domain is something that should be high on the list of things to work on. You could look at functional cross-disciplinary focused example, right? So if your organization has five different definitions of the term client, that makes it really hard for your executives to answer questions consistently. And so maybe you need to pull together a cross-disciplinary group of people to start working on that as an example. So with this, there's lots of different ways to slice insights of the work. Do what makes sense for your organization. Be realistic about what your organization can actually achieve, the maturity level, the number of people that you're able to have involved, and move slowly, if it's your first effort. Next slide. So I have just a couple more slides left in this section. I know we're getting close on time. I talked a little bit earlier about telling the story and using the storytelling format, and I can't emphasize this enough. The Simons and X, Y, TEDx, you know, it's really about inspiring action in people because at the end of the day, this data strategy is going to require people, most likely, to do things very differently in many ways than they had previously with data. It's going to require changes from people, from processes, new technologies potentially, and changes hard for people. And so, again, you want to get them bought into the vision and the why you're doing this that makes it really important for the organization. I've got some basic talking points there. We talked about the ethics and the user stories. And, again, really here, you're just trying to create the art of the possible for people. Next slide, and then I'll turn it over to Peter to wrap up. And at the end of it, really, go back and look at lessons learned, particularly if this is only your organization's first or second time creating a data strategy. It's going to be a challenge. It's going to be a challenge for your team if they've never built one. It's going to be a challenge for your stakeholders if they don't know how they're supposed to be involved and engaged in what you need. And it's really important to actually, probably within a couple weeks of finishing the data strategy, to sit everybody down, both your internal team and the stakeholders who are involved, and talk about it. Talk about what worked, what didn't. Look for areas for improvement. Write all of this down so that you've got it written down while expressing your mind for next time because there will be lessons learned. Even if your organization has had a decade worth of data strategy experience, you still have new people coming in and out of that organization and new business pressures or new organization that might require a different approach. So really take this to heart. Most organizations don't actually think about or talk about lessons learned after doing work. And I think this is a really important end step in the process, but a really good input into the next plan cycle. So with that, Peter, I'm going to turn it back over to you. There's a wonderful little bit that you can add on to the end of this, which is that every bit of the discussion that you have here in your postmortem is actually metadata and goes into your metadata repository in the sense that it is information about the process you're using to try and help your organization manage its data better. And so it's a wonderful way. Again, the emphasis that you have in here on storytelling is so critical, and I just want to make sure everybody takes that part away. Now, Michelin said several times that this is hard, and one of the things that we talk about in the book is the seven deadly data sins. These have to be overcome as part of your data strategy. And Michelin's already said, don't overreach your first time. If you present 50 accomplishments that your data strategy will achieve in three years, there's not an executive that's going to give you five minutes on their calendar to go through all 50 of these. So present three. If you deliver 50, phenomenal. By the way, if you do, tell us about it because we'd love to highlight your stories as part of this process in this series that we use here. This is all about sharing. So the seven deadly data sins here are that most organizations don't understand that doing a better job with their data will actually result in lower IT costs. That's only the first-level impact in the organization, but it is so important. 20 to 40 percent of IT costs are consumed because people don't understand that doing data well helps out IT as well as the business. The second sin in that context then is not having good data leadership, and it's very, very difficult to find people who understand how to do this. Michelin and I probably in the last three or four years have done about 50 CDO events, and I would say that between the two of us, we agree that there's only about half the people who actually have the title CDO know what they're doing. The rest of them are what we call posiers. They're want-to-bees. They're people who want to do it. I don't mean any disrespect to them, but they are people who are really just looking for the next executive-level position, and they really don't understand what's going on in the data world. The idea that we highlighted earlier on, if you're doing project work and all your data work is occurring in projects, there is no way that you can develop a robust means of sharing data. Data sharing has to be done at the program level, not at the project level. And the real interesting part of that is to say, well, somebody pays for a project, but who pays for a program? And if nobody's willing to pay for a program, then you can only achieve data sharing by hook and crook by not actually doing this. This is the key to align the data program with the IT projects. The IT projects are ways of implementing your data program, and they should be part of it, but that the program has to be there, and this is really the concept that data strategy will help organizations to understand is going through that. And Michelin did this very, very well. Again, expectations. Okay, so my day is going to be fixed in a year, or as she started out with her very first story, that I'm sure all of you will remember now. Buying a data warehouse does not mean your data is going to be able to improve. So again, not just the technology, but looking at it within the context. We also have to understand that data strategy needs to be sequenced. And our favorite approach to this is to say, let's use data strategy to drive out some savings, because after all, if you invest $100 in something, and you get $100 in some value back, let's say you get $200 back out of it. That's a terrific piece. I'd like to give you cash if you can do that, by the way. The organizations likely say, you know, we gave you $100 last year, and you showed us that you saved us $200. So we'll give you another $100, or maybe we'll up it and give you $300 this year, and you can save us $500. But those savings have to come first before we go out and try and be really innovative. It's a very, very different process. And finally, there are cultural issues that we are going to have to overcome as part of this data strategy process. We are talking about a new way of thinking, a new way of doing things. And this is absolutely critical to make sure of this. So there are good ways of addressing cultural and change management issues within your organization. Leverage them. There's nothing new that needs to be invented here. We can hire specialists if you don't have them in your existing firm in order to come in and help you with this. But failure to pay attention to those cultural issues is going to be a problem. I'll have more to say on that slide after the next one on this, but this is really pretty critical. First of all, there are no unicorns. It's just very, very difficult to find individuals like Michelin that have the knowledge skills and abilities to help out in this. Perhaps Michelin, that's why you've helped so many companies out because there's so much demand for the kinds of services that you have out there. But there are very few unicorns. And it's even more problematic because most hiring panels don't know what they're asking. Again, I think I made the statement. I don't know if I've ever heard you make it, Michelin. I've never been interviewed by a competent hiring panel. And I don't mean that badly. They're good people. They're really focused on trying to do the right things. But when I go in to do consulting work, they don't know what questions to ask me to see if I know if I'm competent to do the work. And that's a problem. It's going to take some time before we can actually set that up. Change just for organizations is difficult anyway. And there's going to be a competency gap in your organization that even if you get hired to do the work, one of the things that you've mentioned in your story about the FAD Michelin is training your team and making sure that the team was able to come up to speed and get where they really needed to be on all of this. So we use this diagram, Mary Lippert developed this, 20 years ago, but it still applies very, very well today. When we see things on the right-hand side and those yellow boxes, for example, if I see anxiety in an organization, usually there's a vision, there's incentive, there's resources, and there's an action plan, but the skills are missing. And if I see that there's frustration, I see vision, skills, incentive, an action plan, but not usually the resources that are there. So a very good way of sort of diagnosing all of these things, but it just reinforces the point that we both said culture is the biggest impediment to thinking about organizational strategy because most people haven't been taught that they should have a strategy to manage their data. And yet, of course, it is your sole non-depletable, non-degrading, durable, strategic asset. So why wouldn't you have a plan in order to do this? We're originally going to call this slide. The sacrificial lamb takes a bullet for the team. That's a pretty awful metaphor. This is not much better. But the real key is that the first person to take on this role of data strategist for the organization is likely to get beat up. And, of course, you know what happens next on this. It's WWW, so they won't actually step on each other in order to do this. But it is tough because it does require sort of a two-part process. First one is eliminating those seven deadly sins, and you can't do them all at once. You're going to do them little by little, chipping away at the stone. And secondly, then you can go into a lather rinse repeat field, which is what is the thing I can do with the resources that I'm given in this budget cycle to address the biggest problems that the organization has and then deliver some results on it so that they give you funding for the next cycle. And that's really how we do this. Phase one, eliminate the data sins. Phase two, lather, rinse, and repeat around that. Now, just to finish out at the top of the hour here, I always like to sort of finish off with talk about my barn. The bank that I borrowed the money to borrow, to build the barn from was smart and said, we'll give you enough money to build the foundation. And then you will come and bring our inspector in and prove to us that your foundation is sufficient to actually support the rest of the barn. Imagine if I built the barn on top of a poor foundation. Well, the horses, what I put in the barn, would not be happy and I would spend money on vet bills and that money would not go back to the bank in order to pay off what we've spent on that. So the bank says, you know, show us that you've done the foundation. We'll give you enough money to build the foundation. And then only then when you prove to us that you have a sufficient foundation for this barn, can you build the rest of it. Unfortunately, there is no IT equivalent in most organizations because most organizations do not understand that while there's fun stuff up here from a technological perspective, and we'll go back to Michelin's story at the beginning about the data warehouse, that really is just the tip of the iceberg in there, that we've really got to have the foundational practices that she and I have both alluded to in this presentation that build organizational capabilities so that you can accomplish the things on the top without doing the things on the bottom, but it will take you longer, it will cost you more, it will deliver less, and it will present greater risk to the organization. That's instead you learn to crawl, walk, and then run your way to the very top. Speaking of the top, we're at the top of the hour and it's now time to turn it back over to Shannon and see if you guys have some questions for us about data strategies. Thank you, Peter, and thank you, Michelin. Great presentation. And of course, we have a ton of questions coming in already and just a reminder, I will be sending a follow-up email by end of Thursday with links to the slides, links to the recording, and anything else requested throughout. So just starting up at the top, this question came in really early and I think you covered it quite a bit, but maybe if you can reemphasize, how does data governance fit in with data strategy? You want to take it, Michelin? Sure. We love the question. Yeah, so I guess in a nutshell what I was saying is certainly data governance is one of your core foundational data management capabilities that should be part of your data strategy. A strategic plan is a very holistic view of what's needed across the organization and certainly a data strategy has multiple components. It could include what you're going to be doing, additional things to focus on in terms of data governance or data quality or master data or metadata. So data governance could be a component that's important in your data strategy and certainly no matter what you're trying to tackle, your data strategy, there's bound to be some level of governance that fits into that, whether it's improving your master data and the policies and processes you need to have in place for governance perspective to support that or if one of your goals is to improve enterprise access to data across the organization. That's a great noble goal, but that also means that you've got to have some governance around who can actually see data and do what with the data because most organizations have some sort of regulatory and compliance roles that they're working with, whether it's PII, HCI, HIPAA, FERPA, you know, throughout the law, there's a lot of them. And so each one of these things, each one of your goals and objectives and initiatives probably has some element of governance that's wrapped around it. One of the things that's also important is to think about the maturity level of your organization vis-a-vis data governance and where you might need improvements in that and build out teams or build out processes to support the items that are contained in your roadmap. So I have to tell you guys something. Poor Shannon has probably done what Shannon, maybe a hundred or so data governance webinars and on over the past couple of years and done this. I know she's heard these things before, but I know that's why she set that up as the first question because she knows it leads into some bigger and better issues. Let's add on to what Micheline said there and try to abstract it to the simplest message that we can. Data governance, by definition, means managing data with guidance. If you're not managing data with guidance, you're taking the organization's valuable resources and managing them any way anybody feels like doing it. That clearly shouldn't be the case. So managing data with guidance is what data governance is. The data strategy says what guidance are we going to give them? Again, go back to Walmart. Every day low price was one of their old business strategies, and that business strategy is very simple, understandable, and obviously played a role in their data strategy at some point as well. Great question. Thanks, Shannon, for setting this up so good. Well, the attendees kind of make it easy, so really nothing to do with me. But leading right into that, though, the next questions come in, and again, you covered a lot of this later in the presentation after this came in, but if you can just highlight again, examples of a data strategy and the difference between a strategy and a plan. Peter, do you want to start? Sure. So I think what we'd do there is draw the distinction between a program and a project. I don't actually have my program and project slide in this particular deck, but many probably have seen it before. The data strategy at the programmatic level is really saying, you know, across projects we're going to be implementing these types of things. The plan, then, I would equivocate roughly to the roadmap of an iteration of a version of the strategy. So the strategy might be getting to know our customers better and there may be three steps involved in getting to know our customers better. The first year we're going to consolidate, by the way, I used the number 17 before. I don't know how many of you picked up on that, but that is the average number of databases that customer information is stored in across organizations. So if your organization stores its customer data in fewer than 17, you are above average. Now plan versus a program, right, or plan versus a strategy. A plan is going to be an instance of that, but your strategy is the thing that's going to guide all the thinking. Remember, our definition of strategy here is a pattern in a stream of decisions. A plan is a particular instance of that strategy that's going to occur. Michelin, anything to add to that? Yeah, I guess maybe this is an easy way to think about it, or at least this is how my mind works, is the strategy is the why and the what, and the plan is the how. Ooh, love it. Love it. So let's go back to Simon, right? Yep. The why and the what, okay? And this plan is going to be the how. Yep, I like that a lot. So getting more specific, are there any case histories of implementing all this good stuff in the mineral processing and heavy chemicals industry? Any dollars for your life? Sorry. I know. That's a great question. Let's see. Do we have any instances? We've got a case study in the chemical industry. I don't know about mineral. Michelin, you're Colorado. Maybe any experience from those days? Well, I don't have any particular experience. I have experience in the energy sector, but not sort of in that subcategory. So probably the answer is I'm sure they're out there somewhere, but we don't have them. So good question. But I would also say like we've given some really general guidelines that would be applicable across all industries, right? I guess that every industry has its own intricacies and specialties and set of rules and regs that these can comply with. But at the end of the day, most strategic plans have pretty similar components across the industry. So what we've outlined here is quite adaptable no matter what industry you're actually in. Sure. And the question goes into a question. Certainly, Peter, we've done a whole webinar on just what's the dollar realized by investing in big data man hours? What's the ROI on the data? And that's an interesting piece of your strategy. So Michelin was talking about the stories that need to occur around this. One of the stories that we've used over and over again on purpose was a focus on how well the military had actually done data strategies in a specific area. And that's in the monetizing book. But the purpose of that story was done not so much to help the individual project, but because the individual who had the story occur, who caused the story to occur, was a very highly ranking official. And that official knew that that story would be repeated over and over and over throughout the Department of Defense. And so consequently, it's that ability to affect multiple things with a very small lever. But leaders really are very good at doing that. So we're moving a little bit away from the questions of specific strategies in the industry sector and how to monetize these things. But it is absolutely possible to do this. And again, I'll just put in the plug for the monetizing book down there that there are 17 cases in there on how to do exactly that particular process. Peter, can I just add something to that? So I get the enamorment with big data and predictive analytics and all of those things. But again, to share a story, so I recently did a consulting project with a healthcare company, cloud-based from the get-go. So really, you know, forward-looking emerging tech company has been around for about 15 years. And I had a friend who was hired a couple years ago to be their VP of analytics. And she was brought in to help them monetize their data and to start doing more predictive analytics with management, patient populations, and really be able to leverage that data in new and interesting ways. In the two years that she's been there, she hasn't even been able to get the IT team to build a data warehouse. To A, get this monthly baseline metrics out of, let alone, and get the sort of NoSQL Hadoop cluster created where she could actually start to do predictive analytics. The lack of data architecture and data governance has made it nearly impossible for her to actually do her job. And so when you look at some of these ROI cases, you know, you might want to do big data and predictive analytics, but if you don't even have, you can't even get access to your customer data or you don't have your high-quality, high-degree of quality and confidence in your customer data, for example, running predictive analytics on bad data is not actually going to help your organization. So from a strategic perspective, it's really important to have strong use cases around big data on what you're trying to do and then take a look at what exists across your foundation and what improvements actually need to be made in order for the big data use cases to actually happen, which is a really nice example of sort of crawl, walk, run. You know, you can't do predictive analytics on your customers if you have customer data sitting in 17 databases and it hasn't been normalized. You can't at least do really, really good predictive analytics on it. So again, do emphasize Michelin's point, changing is hard. It's just going to be a difficult piece and this would be an example of sin number six, not sequencing the data strategy implementation correctly. Again, trying to run before you can walk, just not a really good idea. Great question. Going back in the conversation a bit, if there isn't any existing data governance groups currently within a company, which group would you try and use instead? So no data governance at all, huh? Well, no data governance group. So I would go to the business. Michelin, I think you've had some success in that area as well, which is that that's really where the impact of this has felt. It's been very, very interesting for us to observe, but in the long run when IT doesn't go well, IT doesn't get penalized or hurt, but the business does and that's really where the stories, the leveraging, the sources of expertise that already exist within your organization are really important in there. Yeah, so if there's not an existing data governance group and certainly what you'd want to look for is a strong cross-functional team that can be pulled together from the various business units or divisions or however your organization is structured, certainly you'd want to include, you know, some representatives from the IT department, your legal department, your cyber security team, but really the business rules, the business requirements, the business needs around the data are business-driven and so you want that group really supported to enlarge them by the business side and then have some of your more technical folks there as needed. What I like to do is to draw an analogy between that and the way your fiscal assets are governed or your HR assets are governed. For example, a company that has lots and lots of HR resources, again, let's think of thousands and thousands of employees, is going to have some HR people to make sure that the HR assets are appropriately utilized in the organization. So we use that to say, why wouldn't you have similar governance over top of the same thing and to help them make the case for that, whether it comes from IT or not, or whether you call it data governance or not, we simply want to say we wouldn't want to let anybody in the organization ready to check for any amount of money at any point in time that would not be recognized as good governance. All righty. Well, data strategy can often impact every level of the organization who deal with data. What is the best practices advice if there's a strong culture that resists the new data strategy as put forth by senior management? So I'll say you haven't been listening to Micheline then in that case because remember what her cycle here is. If you go put out a data strategy without conducting the requisite stakeholder interviews and socializing the plan and I'm just picking two things off of her chart here that has lots more into it, you know, you have made an error in that process. Agree, Micheline? Yeah, absolutely. By the time you've developed the data strategy, there actually should not be a surprise to anyone. There should be no surprises to anybody. At the senior leadership level or down several levels, you want to involve your senior leaders and your stakeholders from the very beginning. Again, we talked about a communication plan as well and being in communication with them regularly include them as needed for input, for feedback, for socialization. All of those things should be going on from the very beginning and it should be thought about in advance, right? We talked about pre-planning and thinking about how and when to engage your stakeholders at what level, what time, right? So if you're talking about building the goals and objectives for your data strategy, you want the executives totally bought into that, but as you're looking at specific initiatives to achieve those goals and objectives, you probably don't necessarily need to have your senior leadership team actually sitting down with you thinking about the specific initiatives. You might want to have some program managers across the organization, some IT people, et cetera. So really thinking about and targeting who you're going to engage with and leverage those stakeholders is really important and at the end of the day, they should be advocating in support of your data strategy because they've been involved all along. They're giving you feedback. They should have some level of buy-in into this and communicating it back up throughout their organization, whether it's up the food chain or to their peers. Think about how you can... One of the things that we did as the Fed was after each one of our meetings with our stakeholders is we sent them talking points and said, okay, like, here's what we talked about. Here's what we agreed to. Here are the things that we'd love for you to communicate back across your organization at your next all-hands meeting or next senior leadership team meetings. And really think about how you can make it easy for them to communicate back throughout their parts of the organization so that you've got buy-in before you actually go try to get budget money for this. Again, providing talking points in particular is good because while they'll come up with a long story, if you can distill it down to something that is really quite meaningful to the business and repeatable, you will find people repeating it. Yeah, it's interesting here. We have a few more questions specific to industries. I'm not going to bring them up again. I mean, I know you guys look covering basically the generics of what crosses all industries, but it's interesting. Maybe there's something we can do in the future to be industry-specific on this particular topic because I haven't seen quite that many industry-specific questions before. But so let me think about that to those of you asking those questions and see what we can get out to you. But keeping to the generic, can we say strategy equals vision plus mission? We're both pondering that clearly. Yeah, but it's not enough. So we've got vision, we've got mission in there, but notice there's a lot of other things that we've got as well. And again, it goes back into the piece I've said that's missing from the mission vision piece right away is that current state. And again, the reason Michelin and I emphasize that so much is because we've done this for a number of different organizations of different sizes and shapes and characteristics, and each one of them is different. Each one of them is a different place along the journey, and each one of them needs a different aspect of the strategy to be emphasized, particularly as they're getting started. You know, they say a journey of 1,000 miles begins with a single step, but which step you take can be really, really important. Again, I'll go back to the point Michelin was talking about with a big data perspective. I had a colleague of mine who came and announced that he'd gotten appointed as CDO as a big organization. I said, oh, okay, good. What are you going to do? And he said, oh, I'm going to go replace all their legacy systems with Hadoop. And I said, oh, why do you think that's important? He said, well, I just, I really believe in big data. And you know, Michelin and I both believe in big data too, but it's much more that big data, and this is true of IT in general, nothing ever completely replaces the old systems. We have mainframes. We have client server. We have web. Everything gets layered into the new environment in there. So it's a matter of seeing how you can complement your existing stuff rather than replacing all of your existing stuff with something new. I mean, it would be like us going out and trying to replace the entire infrastructure of the United States with all the gasoline cars that we have with electric cars. It just can't happen overnight, and it's probably a really bad idea to do that as well. Michelin, anything you want to add? I don't think I have anything that's different from how Peter just summarized it, so I'm good. All right, so moving on to the next question then. How do you convince the CIO that data governance should be driven by the business and not IT? So we've both had different experiences with this. I'll talk from my perspective. Half of the CIOs that I talked to say, you know, if you want to do the data thing, I haven't been able to do that much with it, so go ahead, have a crack at it, and take it off my plate, and now when it goes wrong I get to blame somebody else. The other half of them get quite insulted and say, wait a minute, my title is Chief Information Officer. Are you telling me that I'm not doing my job? And it's a tough conversation each way. The real question is, as a CIO, have you been given the resources and the authority and positioned well enough in the organization to be able to do this? And it really goes back to perception. You know, most CIOs have a lot on their plates, and they do a fantastic job with what they have on their plate, but this is their perception of data here, and they really think that data can be handled by projects. Hopefully one of the things you all are taking away from this is that the data strategy is the thing that will help you elevate your data up to a programmatic level and to realize that data is much bigger and that CIOs do a great job of IT, but really within the average organization, and I've got lots of empirical, boring data, if you want to read the academic papers out there, just send me a note and we'll be glad to send you the academic papers because they are not...in fact, let me put a link up here for you guys to take a look at that because I did have that revolving a little bit earlier. This stuff is absolutely not easy to do. And here's a great case study that's out there. You can just go to this link and download this case study to read a little bit more about how difficult, in fact, it actually is to do all of these things. Michelin, what's your thoughts on that? Yeah, so it's a good question. I guess if your first thought was to the CIO to talk about data governance, I guess I would suggest the conversation should probably happen with the CEO or Chief Operating Officer or... The board of directors should go to say yes. But, you know, I am a strong believer of two things. First of all, that the business should own data governance and second of all, IT should really be a strong partner in that process. You know, lots of data governance activities, lots of data management capabilities require some level of IT support to implement and to carry out. But the business really owns the business rules, the business requirements, the business needs. Oftentimes, IT does a great job of pulling out all of those business requirements as they do projects. But typically, project teams are siloed and aren't thinking strategically and holistically across the variety of projects. If you've got a committed data governance council or a group of people on the business side that can sort of be overseen and understanding the interconnectedness of all those projects into the bigger picture and advocating for the data from a business perspective, that's where you really get banged for the buck. Oftentimes, the IT side, when they own data governance, tends to be far too tactical. And people oftentimes lose interest and then it's just not done very well or at all. All right, so next question coming in. How do you drive data strategy from a lower management position? So the other, so from the bottom up instead of top down, whenever management is not data-focused? So one of the reasons I don't particularly like the title Chief Data Officer is that it implies that it has to exist at a certain place in the organization. And I believe it should exist where the title says it should be, but that also does leave exactly that question unanswered. So my preferred title is Enterprise Data Executive. And I would urge any of you that are listening out there on this call to feel like they are in charge of data for the organization to write themselves up a little title and put it up on their death cubicle wall, whatever it is they need to do to say, I'm in charge of all this organization's data. And the reason I say that is because it can happen from the bottom up. It's not as easy. It's always easier to have executive leadership. But data is being done generally very well and most organizations at the work group level. And what we're trying to do is go across work groups. And so even if you're not at the top, even if you don't have the CEO's ear or the CIO is not an advocate of this type of thinking that we're describing here, you can still make something happen by identifying the business needs by looking at the current state of your organization and saying things like, hey, you know, 17 places probably causes some inefficiencies in our organizations. And we would benefit from consolidating that. And here's how I think that benefit could occur in there. It's not as easy, but we have both of us seeing lots of organizations work their way up there. And eventually somebody says, you know, the work that you're doing is great. By the way, some people will come along and say, who told you you could be the enterprise data executive? And of course the answer to that is, oh, if not me, then whom? And then here's your sign. So most of you don't remember the old joke about that, but it's definitely real. All righty. And that is, we've gone through all of the questions. Again, just a reminder, again, and if you have an industry-specific question, let me think about that and we'll see what we can get out there for you. And people are looking for the book link, so I will certainly get that out in the follow-up email that will go out by end of day Thursday with links to the slides and links to the recording of the presentation. Peter and Micheline, thank you again so much for this great presentation. And Q&A really appreciate it. And thanks to all of our attendees for being so engaged in everything that we do. We just love all the great questions that have come in for today. And next month, we will... What are we talking about next month, Peter? I think we've got some... I think we're diving into some big data topics next month. So some of the questions were perhaps prescient or else they've been reading the website. Who knows? That'll be on November. We'll talk about some best practices. So anyway, I hope everyone can join us then and I hope everyone has a great day. Thanks, Shannon. Thanks again, Shannon. It's always a pleasure to work with you. Bye, Micheline. Bye. Bye.