Although data governance is relatively new, it is quickly maturing. Part of this process involves a shift from data governance seeking to influence the rest of the enterprise, to the enterprise demanding services from data governance. For instance, a few years ago it was common to find a data governance council made up of an assortment of individuals from various parts of the enterprise who did little more than meet once a month and make pronouncements about data management, with little effort to communicate them effectively and little idea of how they might be operationalized. Today, data governance units are staffed with dedicated professionals who work in a range of specialized activities. With such dedicated personnel, the rest of the enterprise recognizes it has a resource to help it with its data-related needs and has begun to request services from data governance.

These service requests can cover a wide spectrum of needs. Some examples are: requests for information about data; questions about the legal appropriateness of processing data in a certain way; whether certain data elements can be released to customers; requests for a policy or rule in a particular area; and mediating a dispute about data between two organizational units. Many more examples could be added, and as data becomes ever more central to business models, the diversity of service requests can be expected to grow.

What is Casework, and What is it Not?

If data governance simply reacts in an ad hoc manner to the services requested of it, then it is likely to be limited in its effect and will have difficulty demonstrating how it is making a positive difference. However, if data governance can manage its service requests via a casework approach then it can be much more successful. Casework involves using a standard process to record, assign, prioritize, manage, report on and close out service requests. We often think of casework as something that the police, or social workers, doctors or elected representatives do, but it is quite feasible - and actually quite necessary - for successful data governance units to adopt casework principles and apply them to their everyday activities.

Some might argue that casework is nothing more than issue management, but I disagree. Issue management certainly has some aspects that are found in casework, such as prioritization or triage. However, it has a number of very specific aspects that are not found in all cases, such as prevention of further loss, and correction of a root cause. Also, there are many other kinds of service requests besides issues, such as requests for information or requests for adjudication of a decision, which are very dissimilar to issues. It is true that some kinds of issues - typically nonstandard ones - should be included in data governance casework. However, other kinds, such as dealing with data quality exceptions, should not be included. These kinds of issues, where there are many instances of the same overall type of issue, should be dealt with via their own dedicated, specific processes.

Principles of Casework

When a data governance unit decides to formally adopt casework as a way of working, there are a number of principles that should be followed:

1. Record every case in a standard way. Every case should be given a number and title. The name of the requester and the date of the request should be captured along with additional metadata items. However, caution should be exercised in getting too carried away in terms of numbers of metadata items; only those that will be used - rather than something that "maybe we can use" - should be captured.

2. Assign every case to a data governance staff member. Each case must be given to someone who works for the data governance unit and who will be accountable for the case from beginning to end.

3. Immediately triage every case to determine if it is truly a data governance case. Unfortunately, many individuals or groups that cannot get work done by those truly accountable for it may try to give this work to data governance. Triage is a process that divides things into three classes. In the case of immediate triage, cases are divided into those that are certainly something data governance must address, those that are certainly not something data governance must address, and those which it is unclear that data governance must address or not. For this triage to be effective, data governance must have a very clear idea of what its purview is. How data governance arrives at this understanding is beyond the scope of this article. For the class of cases for which it is unclear that data governance must address them, analysis should be carried out.

4. Prioritize cases. The data governance unit must as a whole decide the order in which cases should be worked. At a minimum, this is another instance of triage where cases are classified into high priority, low priority, and those of uncertain priority.

5. Determine case scope early on and stick to it. There is always a danger of scope creep in cases. For instance, I was recently asked to author a policy, and when that was complete I was asked to author a FAQ for the policy. I treated the FAQ as a new case, not part of the original service request, as it was not even discussed until after the policy had been written.

6. Do not do work on cases where data governance should only coordinate. This is another danger. Many cases involve data governance coordinating among business units that are responsible for the work to be done in the case. The danger is that data governance staff may be tempted to do the actual work just to close out the case, especially if there is pressure to complete the case. If data governance staff actually try to do the work, they may not be qualified to do it well and will likely not have enough time to do it well.

7. Always close out cases. Administrative work after the substantive work of a case has been done is often unpalatable. However, formally closing out cases ensures that all stakeholders are aware the case is closed, that all documentation is filed appropriately, and provides an accurate reporting status. It is quite possible to have "cold case files" that are dormant. This is legitimate, and no case should be closed merely because it has reached a certain age.

8. Report case statistics. The formal management of cases permits data governance to report in detail on this important area of its work. The senior management funding data governance often has little idea of what data governance is doing. Statistics on new cases per month, number of cases closed per month and so on provide the quantitative statistics that senior management need.


Setting up formal processes for data governance to do casework has many advantages. It undoubtedly has some administrative overhead, but this is dwarfed in comparison to the benefits. All modern data governance units should seriously consider adopting casework practices.