Page 71 -

50 CHAPTER 5 Process overview for deploying data governance

Considerations

You are building a program that requires a framework for operation. That means some basic blocking
and tackling in terms of Management 101. However, since many DG teams come from technology
areas, there is often a major slowdown in the DG effort as people who have never done organization
design start to do it. This is not an exercise in scraping together a few organization charts.
Another common mistake is to fail to keep the design of information management processes
separate from data governance processes. This is usually because the initial staffing of DG is drawn
from information areas. Often the initial DG staff are told to “fit it in” to their current roles and
5
responsibilities. It is challenging for these individuals to maintain the separation of duties mandated
by the V while creating embedded organizational processes, new roles, and a sustainable program.

Activities

1. Determine core information principlesdThis activity is arguably the most important in the
development and deployment of DG. A significant part of Chapter 10 is devoted to these tasks.
Simply put, the DG team identifies, documents, and vets the core organization principles that
will be adopted to manage information as an asset. Without these, the DG effort is crippled.
2. Determine baseline DG processes to support businessdAll organizations do “stuff.” This is where
(usually using a list of generic processes) the DG deployment team determines the core list of what
DG will be accomplishing. In essence, you add the details to evolve the Vdoften by developing
process models (think flow chart, swim lane presentations, etc.). The team also points out where
current business processes are changed. For example, we have often found that a detailed
presentation of the DG issue-resolution process is required (i.e., how an issue is identified,
recorded, promoted, and resolveddonce we even designed a “911” process for emergency
attention to data policy transgressions). Lastly, do not fail to consider the IT areas in addition to
changes in business-user activity. Processes and methods for developing and managing
computer applications will also change.
3. Identify/refine IM functions and processesdIn a similar fashion, the DG team gathers (or helps in
defining) the more IM functions. Remember not to blend the two areas; it will result in confusion
and a loss of effectiveness of both areas.
4. Identify preliminary accountability and ownership modeldThe essential lists of DG and IM
processes are not at all useful until the DG team identifies who does what, and what the various
levels of responsibility are. In this step, the team examines the functions to identify where
responsibility and accountability might need to exist to ensure sustainability of DG. This is not
the final pass in terms of the new DG “organization”dthat happens in the next activity. This is
more of a first pass so management can understand the change potential and be able to consider
the new DG processes and framework in context and in an intelligent manner.

5
Kudos to those IM staff we have worked with over the years, who, to a person, have all had to do double duty. There are
many hard-working people in information management, and we have never seen a management team allow the designated
DG deployment team to offload their current duties. Of course, it drags things out, but they hang in there. As for the
management who demands the double duty (and does not offer additional incentive) while at the same time saying how
important DG is, well, we will refrain from comment.