May 19

May 19 How Much "Data Program Governance" Do You Really Need?

Dennis D. McDonald

Data Governance, Project Management, Program Management, Metadata, Data, BDPM, Strategy, Standards, Big Data

By Dennis D. McDonald

Definition of terms

Let’s first define some terms. In Thinking About Data Program Governance I suggested the following:

Data includes any kind of data such as numeric, financial, textual, image, or meta.
Program means an organized set of activities designed to accomplish a defined set of objectives.
Governance means the program is planned and managed in an organized and sustainable way.

Note the terms "program" and "governance" are used together. This implies an ongoing effort, not just a one shot deal. 

Where to start

If you are thinking about improving how your organization governs data, you need to consider why you want to do so. Your immediate interest for improved data governance might be the result of some very tactical situations, e.g.,

Management has heard about what some competitors are doing to analyze their own data. You realize you need a more consistent way to approach data sets that are currently managed independently.
A staff member saw a data visualization demo at a conference. She wants to know what it would take to do something similar with a growing collection of transactional data you control. 
The last time you pulled together data from your organization's different divisions you spent all your time manually dealing with fundamental differences in what Manufacturing and Marketing were supplying about the same product line.
Management wants both your internal reporting and external web pages to standardize on terminology required by government regulations.
Management wants you to begin analyzing and reporting chat session text from your customer support operation in parallel with demographic data you already have in your customer file.
You've just discovered that the data conversion shop you hired to key data from handwritten forms has been following inconsistent coding rules that has led to an increasing number of rejected records -- which is causing you to underestimate your outgoing bills.

These are just a few examples. Each potentially has both short and long term implications. Sometimes there is a "quick fix." But in many cases you realize that something more permanent and potentially more consistent and wide ranging needs to be done.

Where do you start? How can you ensure that what you do is not only effective but applicable to other problem areas as well?

A balancing act

In Improving Data Program Management: Where to Start? I suggested that deciding where to start a data governance program may require a "balancing act" between doing something quickly and addressing the problem more strategically:

Despite the importance of strategy, you also need to start somewhere and deliver benefits to the project sponsor as soon as possible in order to gain support for the work. It's important to balance the desire to comprehensively realign how data are governed -- which can take a long time -- with convincing and useful solutions to specific and important analytical or data management problems. 

One approach is to focus on a well-defined or important business problem – or “pain point” -- where a solution will have a measurable benefit in terms of one or more of the following types of metrics:

Cost or time savings
An increase in an important metric such as satisfaction or sales
A reduction in errors or returns

Fundamental: a language based approach

The approach we recommend, even with a "small" or well defined problem area, is to start with a focus on the language and terminology used by people and systems, beginning with an inventory of all the data you have that's relevant to the problem.

Focusing your efforts only on formal database contents, data dictionaries, and existing technical standards, while useful, will not be sufficient if you really want to get at the core issues associated with data governance and the problem you're attacking. You also need to understand the variations in terms used in relation to this problem, who "owns" or manages the systems and processes this problem touches, and the media (including emails, documents, forms, presentations, regulations, rules, and reports) that relate to this problem. To tie all this together you also need:

A process for identifying and documenting (and potentially modeling) the core concepts and terms used to address the problem.
A way to document the connections or traceability among your goals and objectives and the systems, processes, data, and relevant business concepts.
A governance process to resolve differences, inconsistencies, and definitions in those areas where undesirable variation exists.

Conclusion

How language and terminology are used across your organization, systems, and processes are critical, hence our suggestion that you focus on a definable project or problem in order to control project scope and the variety in the language used. Once you do that, you will be well positioned to (a) prioritize which data needs to be "governed" and, (b) adapt these systems and procedures to other areas of the enterprise where data governance challenges exist.