Page 65 -

44 CHAPTER 5 Process overview for deploying data governance

Defining exactly “what” is governed is also of key importance. For example, are any business areas
exempt due to regulatory reasons? Is there a division that, due to its business model, DG would not be
helpful? (This happened in our practice. The client had a line of business that dealt entirely in research,
so experimental data and research papers were the core information assets. Those folks already took
very good care of their data!)
Besides scope restrictions, you may need to consider factors that require a larger scope than
initially considered. What about business market factors? A data governance effort attached to
a master data project may need to consider a greater scope if a company’s market share is suffering and
poor-quality data is a contributor. If your company has recently completed or is in the middle of
implementing an enterprise-level application project, such as SAP or Oracle ERP, then your data
governance effort will need to cozy up to those programs.
The intensity of DG is part of the scope decision. Are the information principles that will arise from
the DG effort required to have the weight to cover an entire organization? The same decision goes for
policies. Your DG program will create new policies and you need to decide to what levels of the
organization you will extend those policies. If appointing individuals with new roles of accountability,
or decision rights that are new to your organization will be an issue, then your human resource area
needs to be considered as part of the project scope.
It is not a trivial matter that the scope of DG is set by the nature of an organization (i.e., the methods
used to set and enforce policy and rules, how decisions are made, and who makes them). If an
organization has a culture of accountability, then the scope of DG can be broadly stated. If the
organization has operated without blatant accountability for information technology and data assets,
then DG scope must be stated very specifically, and mention that accountability will be entering the
organization’s lexicon.
Lastly, remember the “E” in EIM stands for enterprise. You are defining DG for an enterprise. That
means, start with the whole thing, and only reduce scope for specific reasons. There is no such thing as
3
departmental governance. It is a contradiction in terms.

ASSESS

Once scope is understooddand approveddthen the DG team can move on to the required assess-
ments. Unlike assessments done for data quality or enterprise architecture, the DG assessments are
focused on the ability of the organization to govern and to be governed. We use the alliterative phrase
“capacity, culture, collaborate.” That is extremely important to determine the current state of the
mechanisms and processes an organization will be changing as data governance rolls out.
“Capacity” refers to the capacity to change. Desire to change should never be confused with the
capacity to change. For example, the IT organization at a past client of ours knew that data quality was
the number one obstacle to developing a customer master data management (CMDM) architecture.
Business users across the board openly acknowledged that customer data was, overall, pretty awful.
When we came upon the scene, the project was stalled. All of the data problems were known. Many of
the processes to correct the problems were designed, but nothing was happening. There were countless

3
Perhaps “departmental governance” will enter the “oxymoron hall of fame” along with military intelligence, jumbo
shrimp, and political ethics. Then again, maybe not.