December 03, 2024

00:10:28

Details Are Important In Information Governance - E96

Details Are Important In Information Governance - E96
What Counts?
Details Are Important In Information Governance - E96

Dec 03 2024 | 00:10:28

/

Show Notes

2024 Episode 96 - Details are important in information governance planning and implementation. The devils are in the details when it comes to trying to get information governance activities moving forward in your organization. Join Information Governance Consultants, Maura Dunn and Lee Karas, as they use the TrailBlazer Framework to help explain where the devils in the details can hide. Each episode contains important information gained through our experience working with companies across various industries and we talk about how you can apply this experience to your company.
View Full Transcript

Episode Transcript

[00:00:01] Speaker A: Hello, thank you for joining us. This is what Counts, a podcast created by Trailblazer Consulting. Here we highlight proven solutions developed through our experience working with companies across various industries, and we talk about how you can apply these solutions to your company. We share our experience solving information management challenges like creating and implementing your records retention schedule, creating an asset data hierarchy, or helping with email management. This is Lee, and in this episode, Moore and I will use Trailblazer's framework to point out where the devil and the details will lurk. Maura, this is another ominous type of subject matter introducing this episode. Where are we going with this one? [00:00:48] Speaker B: So we've been talking about information governance and different pieces of information governance for many episodes now, dozens of episodes, I've forgotten how many, but the. I have to tell the audience that you're making faces at me to explain why I just burst out laughing. So anyway, we've been talking about information governance and the principles involved in information governance. The, the approaches to how to, how to use these principles to manage business, to manage your business, to manage your records, to manage your data. And it occurred to me that, well, it occurred to me many, many times, but it hit me strongly about two weeks ago that we haven't really said one of the sort of lessons learned along the way. And it's one of these. It's a frustrating thing for me because the principles are clear and people, when they finally understand the principles, then their first reaction is almost always, oh, that's easy. Yeah, we should do that. But the problem is it's not easy. It's not easy to carry out the principles in your business, in your information, in your records. And one of the critical reasons that it's not easy is because the volume of information grows so much more quickly than you can stop and look at every single thing and apply, apply a rule. So a lesson, the lesson learned. The sort of watch word that I have for myself is the devil's in the details. And that covers a host of things. It's kind of like that yada, yada, yada phrase, if you've got, there's a lot built in there. So starting with our framework. It's comprehensive. We worked a long time on the framework and just to refresh everybody's memories, there are six elements to it and we usually draw them like a house or something, where the bottom row of it is the infrastructure and that's where you base all of your information management activities. Information governance activities could be an on site platform, it could be a cloud platform, it could be multiple platforms. That work together. If it's multiple platforms that don't work together, then that sets the stage for some of your later decisions. It also can be paper storage if you're still in a paper based world. So the, that's the. Where we start is that foundation then jumping to the roof. We have governance and governance is where we put a lot of things about people, about communication, training, decision making. And this is where, this is one of the places, this is the main place where principles get defined and we start to think about how are they going to be carried out. And then in the middle we have the four pillars. Policy, process, data and content and applications. And I remember when we decided to go with data and content, data with a vertical bar, just dividing it from the word content, that was a pretty big discussion in our team about, well, it's all the same thing. And even having data and content and applications being separate again, a lot of people were thinking and we had lively discussions in our team over the need to draw these things out separately. And this is one of the first places where the devil's in the details because you think about a system as being everything together, but in fact the data is not the, is not equivalent to the system that the data sits in. And you find that out quickly as soon as it's time to upgrade or move to a different system. And how do you get the data out of your old system and into your new system? So separating out data from applications made sense. The reason we decided to go, and I think it was you, Lee, who made the argument around data vertical bar content. Do you remember? [00:05:20] Speaker A: I do remember, but the reason is because of the difference. But the vertical bar was very significant of something and I don't remember that. [00:05:29] Speaker B: I think the significance of that was they are equal, but they are not the same. And it was about allowing for the practical differences between data being structured pieces of information in a record in a row where you could pinpoint something versus content, typically being an object like a file, a document, a picture and, and needing to address that differently. And again, that's a key place where those details are coming into play. So I jumped over policy and process to get to the, to the reasons for this seeming anomaly of splitting out data, content and applications. But policy and process are critically important. You have the policies set the, what you want to do. What does your, what does your organization want to do with its information? You might have a policy that says retain the information needed to operate safely. You might have a policy that says retain the information. That's Required by law or something like that. Policies are usually pithy like that. Then you get to process, which is what happens to the data and what happens to your information as you go through your business. Does it. How does it flow from one end of the organization to another? How do people access it? How do, how do you have the. How do you know the versioning and the name changing and how are you going to find it later and all of those things. So we have those six pillars, and when we talk to a company, we talk about the need to address all of them. It's not enough to find a technology solution. And I know we've had other episodes where we've mentioned that a technology solution on its own is only going to address applications, maybe infrastructure a little bit, maybe data or content, probably not both. It's not gonna. Not gonna help you define policy or process. It might help you support those things, it might help you enforce them. But if you haven't thought about it already, the system by itself can't do that for you. [00:07:51] Speaker A: Okay, yes, I'm nodding my head saying absolutely. Don't think that software is going to solve all your policy process problems. [00:07:59] Speaker B: Absolutely. But the converse is true as well. Just writing a policy and saying follow the rule doesn't give your team, your business, your employees any hope of being able to do that. And it certainly doesn't give you as an organization, any confidence that everybody's going to pick the same way to follow the rule. So if you have a retention schedule that says keep these records for the life of the equipment, or keep records and keep drafts that are important. When we were working for the government, there was a whole thing around rulemaking and which drafts had to be kept and which comments had to be kept. And it was to document the whole regulatory process, the rulemaking process. Well, letting people decide that on their own which one is an important draft versus which one is a throwaway draft, that leads to a lot of confusion and inconsistency. And it's very hard to defend any decisions that you make as a company if you've got examples throughout your company where people picked their own rules, made their own. Made their own interpretations of your rules. So policy on its own doesn't do it either. So what I'm proposing in our next couple of episodes is that we talk through what are these details to think about in each one of the pillars, and then how do we bring that together in different projects to bring them all to bear? Okay, that's my introduction for today. [00:09:41] Speaker A: That sounds good. That sounds like each one of those could have a significant amount of devils and details. [00:09:50] Speaker B: Absolutely. And we've seen a lot over the years. So stay tuned for our next episode where we are going to talk about the devil in the details of governance. [00:10:02] Speaker A: If you have any questions, please send us an email at [email protected] or look us up on the web at www.trailblazer us.com. Thank you for listening and please tune into our next episode. Also, if you like this episode, please be a champion and share it with people in your social media network. As always, we appreciate you the listeners. Special thanks goes to Jason Blake, who created our music.

Other Episodes