Page 108 -

Overview 87

reduce the cost, or improve the value of investments in information architecture, and ensure data
accuracy, quality, and consistency.
(We did not recommend the insurance example, as it was in existence when we got there. It is
a little too focused on information technology, but it set a baseline for measuring and achieving the
mission, so it sufficed.)
Tips for Success

This activity is, fortunately, one where it is effective to gather many examples from elsewhere. Be
certain that the definition contains elements that are meaningful to your organization. If discipline will
be a challenge, mention it. If authority is important to success, mention it.
Ideally, your MDM project or EIM area will have mission and vision statements that can be
leveraged. If not, you will need to assist in these efforts by creating them. Remember the fundamentals
of mission and vision statements.
•A vision statement should provide a picture of where an organization would like to be at a certain
point in time in the future. As such, it must clearly state what is to be accomplished, therefore
supplying a foundation for measurement by framing the goals and objectives. For example,
a vision of “we are going to be the best” is not very clear.
•A mission statement is a carefully worded statement of what an organization does in support of its
vision, goals, and objectives. Each word of the mission statement is chosen for a specific reason.
The elevator speech needs to be positioned similarly. You also should fold in what DG will do for the
company, using terms such as “ensure value, increase revenue,” etc.
Whatever you do, never use words such as “better data,” “improved decisions,” or similar terms.
They are vague and irrelevant to most executives.

Activity: Draft Preliminary DG Requirements

This activity goes hand in hand with definition, metrics, and elevator speech. The definition and
considerations will allow you to organize a first cut at what is going to be governed. This activity starts
with business needs. In addition, known issues, requests, and works in process are factored in to create
a view of what is going to be governed. The team will need to consider specific business events,
application maintenance requests, and regulatory or compliance obligations.
If MDM, BI, or data quality efforts are driving the rollout of DG, it is likely that much of this
information will be available. Remember, DG is a program to ensure that BI, MDM, DQ, etc., all
“stick.” The drivers for these are also drivers for DG. Interestingly, it is not until we assist clients in
getting the DG effort going alongside the other efforts (MDM, DQ, etc.) that they actually catalog and
examine the business drivers of MDM. They are aware of the drivers in an anecdotal sense, but they do
not sit and catalog and consider them. You might be able to sneak MDM in without a lot of consid-
eration of business drivers (as long as you have a good sponsor and are solving a business problem).
However, DG requires consideration of the business drivers and documentation of the following:
• How lack of DG-induced discipline could affect project sustainability.
• How lack of DG-induced discipline could increase risk by affecting the ability to comply with
regulation, loss of market share, or potential lawsuits.