Data Governance takes a long time, and particularly in the early phases, it takes quite a lot of effort. Therefore, it is understandable that people look for ways to speed this process up. One of the ways I am often asked if this can be done is by fast-tracking the creation of items in a data glossary by using standard definitions.
However, it’s not a part of the process that can be skipped or glossed over, so to speak. Part of the reason for this is that organisations, even those within the same industry, very rarely use the same terminologies in exactly the same way. This means there is no bank of standard definitions to pick and choose from; what works for one client, will very rarely work for the next. Only by creating your own data glossary can you be sure that you have the correct definitions within it.
The best way to explain why is to give you a real-life example of a conversation I had with a client a few years ago.
This particular client had been making slow but steady progress with their Data Governance initiative and they had decided to bring forward some target dates for the completion of certain tasks, and to help with this they appointed a project manager.
This had happened in between my visits and so when I next visited, I had a conversation with the new project manager, and it went a bit like this:
He said: ‘We’ve got to get the data glossary built sooner and therefore we’ve got to find a better way of completing the data glossary than getting the data stewards to draft it and the data owners to approve the definitions.’
And naturally, I said: ‘Well, I can’t think of a way that would be successful that I’ve seen to date.’
He replied: ‘We’ve got a really good idea. There’s a chap that’s joined that department over there. He has just come from another company in the same industry. He’s got some time spare, and we’ve given him the fields that we need to be defined.’
I replied: ‘But he doesn’t know what this organisation means by those terms.’
And the project manager said: ‘But they are standard terms used in the industry.’
Unfortunately, as I predicted, it was not fine.
This team member spent quite a lot of time filling in these definitions but when we shared those with the data owners and the data stewards there was a lot of confusion and back-and-forth about various terms and what they mean in different contexts.
This will almost always be the case within organisations. In my experience, where I have worked with multiple clients in the same industry, it is very rare for people to use the same jargon in exactly the same way.
Many organisations think they use terminology in the same way, but when they start comparing – particularly when people move between companies like in our example – there are always subtleties and sometimes it is even more than a subtle difference.
I would love to say that this would be a great way to fast-track the creation of a data glossary and that a bank of standard definitions is the answer to all your prayers, but I’m afraid it’s probably more likely to result in confusion.
In the example above, it also doubled the workload and prolonged the creation of the data glossary. It also risks disengaging your data owners and data stewards; therefore, I would advise avoiding that approach if you can. Sometimes it is better to take the long road for a better outcome.
Don’t forget if you have any questions you’d like covered in future videos or blogs please email me – firstname.lastname@example.org.
Click here to read more LTL blogs about data
Click here to find out more about Nicola