As your stewardship effort matures over time, there are certain common problems you’ll need to learn to deal with. These issues must be handled in order to keep stewardship on track and successful. So here’s my “top ten” list of these important items.
Finding a new steward
Stewards are key business people who know and use the data, and whose peers turn to them for advice on what things mean, where to find them, and what the data quality issues are. But stewards are also employees, and thus their assignments can change, or they might even leave the company. When that happens, you’re going to need to find a replacement steward. Technically, of course, just because a steward transfers to another department or begins performing a different function, it doesn’t mean they can’t continue as the steward for the previous business function. But in reality, they are likely to no longer be “in the loop” for changes and new developments for their old business function, and that means they will be less effective as a steward.
To obtain a new steward, you’ll need to ask that business function’s representative on the Data Governance Council (or whatever you called it) to assign someone. This is actually one of the key responsibilities of that governing body, and hopefully you wrote that into its charter. But since this is a responsibility that hopefully doesn’t have to dealt with too often, the request should be accompanied by a short meeting (a half-hour should do it) that reminds the data governance council member what the steward’s responsibilities are and what sort of person you need. It should also remind him or her what the consequences of NOT assigning a replacement will be. I built a short “tutorial” in PowerPoint that I keep handy to present whenever I need a new steward to be assigned.
Getting Stewards to Participate
Stewards are busy people, yet you’ll need regular input from them, and they must take part on a regular basis in making key decisions – like determining the owner of newly exposed data elements. Of key importance is having the stewards understand not only the importance of the work they are doing (part of the orientation presentation and regular refreshers) but having them understand that if they do their job well, they will actually save time, as the repetitive questions they deal with every day can be answered by the phrase “look it up in the repository”.
Nevertheless, there may be a few stewards who simply don’t show up. The long-term solution is to have a discussion with the data governance council member who assigned them. But in the short term, it may actually be ok for some stewards to be M.I.A. The bottom line is that there are a huge number of data elements that need to be dealt with, especially in the early stages, and if a steward doesn’t participate, simply focus on the data elements belonging to those who DO. However, as you put out your regular status reports and communications on progress (and metrics for participation), highlight and display the stewards who are participating and the number of owned and approved data elements by business function (and thus by steward), as in the chart shown below. This makes it very obvious who is getting the benefit and who is not. Further, if it becomes necessary to tell someone that you don’t have an answer on what something means or how it is used; make sure to copy the errant steward on the communication.
Getting funding and support for tools
There is only so far you can go without tools. You can achieve a fair amount using freely available (at least in most enterprises) tools such as SharePoint, but at some point you are going to need some commercial software to get to the next step. As most everyone knows, the key to getting a toolset is to make management aware of what MORE you can accomplish with commercial tools, and what you CANNOT accomplish without them. The tipping point seems to be the need to connect your business data elements (and their definitions, derivations, data quality rules, stewarding business function, etc.) to the physical data elements which implement those business concepts in your systems. To do that, you need the ability to scan the physical metadata (e.g., the database physical structures; BI and CRM environments, and so on). Ideally, you’d like to be able to examine the Extract, Transform, and Load (ETL) jobs that move the data, thus providing lineage. Not only is lineage critically important to meeting certain regulatory requirements (especially in banking and financial services), but it enables you to identify just a single physical data element mapping to a business data element, then lineage find the rest of them. Having watched a large company attempt lineage manually, I’m here to tell you that it is resource intensive, error-prone, and is out of date before it’s done.
If you’re already thinking “Metadata Repository”, we are on the same wavelength. But that must include a “business glossary” component so that you can record the metadata around business data elements and stewardship. This might look something like this:
This metamodel includes the concept of “project data stewards”, which we will discuss shortly.
Applying stewardship to Projects
There are many (well, three) ways to expose new data elements that need governance and stewardship attention. By far the largest and most telling are data elements that will be used as part of a project. Not only does a project usually impact a significant number of data elements, but a project is the perfect time to expend some effort understanding what the data means and how you define “good” data quality. Get it wrong (or don’t do it all) and the project is likely to be late, over-budget, and perhaps not work at all. But projects seem to have endless meetings and deal with far more than just the data. So it is impractical to have your data stewards sit in on project meetings to “listen in” for trouble areas related to data. Nor is it practical for them to read all the various project documents.
A more reasonable answer is to use what I call “project data stewards” (PDS). These are individuals who have a general background in data management and who can participate on several small projects or a fewer number of large ones. Their main job is to represent the needs of data stewardship. They can be assigned “take aways” to get answers from the data stewards, feed the data elements into the ownership process, and provide answers back to the project team. This is a far more efficient use of the data steward’s time, and after a while, the project data stewards themselves become quite expert at their jobs.
The downside is that project data stewards have to be funded. This isn’t too big a problem on large projects with big budgets as long as you make sure the project team understands the need to fund this individual. But smaller projects often don’t have the extra budget, which is why I like to use contractors for the larger, funded, projects, and one of my staff as the PDS for the smaller projects. Of course that means that the Data Governance organization has to have this headcount available, and that, too, can be a battle. Hey, I didn’t say it was going to be easy.
Determining Ownership of Data Elements
One of the most important things that the data stewards – and the Data Stewardship Committee – are responsible for is determining ownership of data elements that have been exposed as needing definitions, derivation rules, data quality rules, and other types of metadata clarification. This is because, in the final analysis, data stewardship is about ownership, and someone must be responsible and accountable for making decisions about the data.
To go about determining ownership, use the following steps:
- First, gather as much information as possible about the data element in question, usually from subject matter experts or project personnel who are concerned about the data element.
- Next, this information must be communicated to the stewards through whatever collaboration mechanism (email, SharePoint list, Wiki, etc.) you are using.
- Invite the stewards to a meeting in which any steward interested in being the potential owner attends. This means that, for example, the HR data steward doesn’t need to show up for a meeting to discuss Insurance data elements.
- Discuss the data element, its meaning, and usage with the interested data stewards. Ask questions like the following:
- Whose business would be severely impacted if the data element did not exist or suddenly had its meaning and usage changed?
- Whose business processes would fail to work if the data element was “hijacked” for another purpose?
Here is a diagram that illustrates what the ownership/definition process might look like:
These are just the first five of the common Data Stewardship common issues. Continue to Part 2…
[...] the first installment of Data Stewardship Common Issues, we covered five items that can be difficult to deal with. In [...]
Hi, Neat post. There’s an issue along with your site in internet explorer, may test this? IE nonetheless is the marketplace leader and a big section of other folks will omit your magnificent writing due to this problem.