A New Approach to Steering Strategic Enterprise Data Initiatives – Part 3 of 8

In Part 2 of this series, I outlined the initial questions that senior management should ask to start to get a sense of the scope and scale of the work, so that they can start playing an effective steering role.  In Part 3, I’ll explain a bit more about how the answers to these high level questions need to be compiled, to enable even more insightful steering of the work.  I’m deliberately keeping this to data, systems and issues at this stage: more on how this approach can be used more widely in future posts.  This is where the “list-based” approach starts…

Please read my Disclaimer by clicking here.

Answering the executive questions: the list-based approach

So, the executive-level questions have been asked.  How do you go about compiling the answers?

In simple terms, by creating a set of lists, with clear status, priority and ownership against each item in the lists.

This bit requires someone with a bit of data management knowledge to lead, if you want it to be done quickly and to get it as right as possible first time.  However, the principles are very simple to follow.

What data is in scope and how much of it is “OK”?

Let’s start with the list of data.

I’d suggest starting with a simple table (yes, capturing this in a spreadsheet is fine for now: you can move to a whizzy metadata tool later), which captures the following:

• Data item name
• Description
• Data item type (data entity, data set, data element)
• Parent data item / link to data entity (if applicable)
• Status (proposed, under review, approved)
• Owner (name of specific person)
• OK-ness (OK, not OK)
• Priority (01 – High, 02 – Medium, 03 – Low)
• In scope? (yes, no)
• Comments (including notes on rationale for priority, for not being in scope, for OK-ness etc as appropriate)

…and that’s it, for now.  The titles that you use can be adjusted, the options you choose can be changed to meet your needs and so on – but these are the basic things you need to capture.

I’m not going to go into too much detail about what these mean – that’s what you need a data expert for (for example, why do you need data item type?  Trust me, you do – but you don’t need to worry about this at an executive steering level, in most cases).

A couple of things to note:

1. The “OK-ness” (or “Compliance” or “Fitness” or whatever) – is a simple yes or no, to enable a simple rolled- up view.  I would advocate keeping this as simple and binary as possible, to avoid a lack of clarity.  However, it should be made up of a set of criteria, which are agreed by senior management.  For example, data might be OK if:

• It’s got an owner
• It’s got an agreed definition
• It’s got a set of signed off data quality and data usage rules
• It’s got a clearly identified and agreed authoritative data source
• It’s got some data quality metrics that are being reported regularly
• It’s got a list of known issues that are being tracked

NOTE: you’ll notice that the OK-ness here is not about its data quality, it’s about where it’s being properly managed and governed.  Data Quality reporting and management is important and related to this, but should be handled separately, with dedicated focus and appropriate methods and approaches – which could well form the basis of another set of posts in the future!

2. Its priority should be simple as well, but needs to be setup in such a way that you don’t have everything grouped up at the top of the priority list, so that you can put the list in some kind of actual order.  Sometimes it’s useful to have a “priority order number” column, where you literally assign a number from 1 to N, with a rationale column to explain why.  The criteria for assigning priority also needs to be based on a set of more granular criteria, which are also agreed by senior management.

For example:

• Is the data critical for a mandatory legal or regulatory purpose, such as financial crime purposes (sanctions screening or anti-money laundering)?
• Does not having the data well managed prevent the business from performing a critical process that negatively impacts customers in some way?
• Do problems with the data drive significant costs?
• Is the data needed to support anything that is critical to enable the organisation’s strategic objectives?

To help further with this, it’s probably worth mentioning that in my experience, there are a set of data entities, data elements and datasets that almost always appear near the top of any priority list.

They are:

• “Master” data such as the following (the data entities, their data elements and “master” datasets):
• Customer data (and any other related Parties)
• Employee data (including applicant data)
• Supplier data
• Product data
• “Reference” data such as:
• Unique identifiers and lookup codes
• Location (country, region, town, building, etc…)
• Classification and categorisations (customer segments, demographics categories, ranges etc…)
• Organisation or company structures (legal entities, management structures, cost centres and accounts, etc…)

The above is not an exhaustive list, but whatever data you are processing, I can almost guarantee that you’ll need to get a handle on master and reference data, such as the above, to enable any of the things you want to do – both operationally and analytically.

OK, so you’ve got your list of data, which enables you to answer the basic questions about what data you have and how OK it is.  Now onto your systems…

Coming up in Part 4…

In part 4, I’ll go into how to create your list of systems and their “OK-ness”.  This sets us up for the following post on issues, from where we can then expand this list-based approach to other types of lists…