Page 17 -

xvi Preface

This book is for those who need to “do data governance.” It is not for IT, it is not for business. It is
for anyone who has to make sure information management is happening. To be clear, this is a “how to”
book. I tried very hard to eliminate the bromides you can easily hear from a tool vendor or big-name
consultant. If you are reading this book, you have heard the platitudes, embraced them, and now want
to do something about it instead of talking.
Pundits of all types will talk about the twenty-first century being the era of information and the use
of data, and cite its huge dependence on analytics. However, if we continue to treat data as the ugly
lubricant of departmental business processes instead of the precious asset it is, we will come nowhere
near to fulfilling these forecasts. None of it is possible without this significant change in mindset where
day-to-day habits in the treatment of data and information change. Here are some real scenarios you
should consider:
Ô
• Running a business on 40,000 Access databases and consolidated statements from spreadsheets is
not considered acceptable by Wall Street. (This is true. A leading financial services company had us
do an assessment and we stopped counting at 40,000 Access databases.)
• Expediting a business process or completing a departmental project is no longer measured by
completion time or cycle time. They are also measured by data quality metrics and adherence to
asset management policy.
• Rather than throw up your hands and start building departmental databases in Access or Excel
due to perceived delays, business leaders work with IT and information managers to get the data
right. In other words, take the time to be right the first time versus doing it overdagain and
again and again.
• Application developers are no longer rewarded for the on-time completion of projects if they do not
meet data control and quality standards at the same time.
• Business users are flat out not allowed to produce a report that leaves the enterprise unless it has
gone through an approved process for creation and verification.

The term maturity is often tossed about in the context of managing information. This book was
written with that in mind, but also with another scaledthat of learning maturity. My weekend hobby is
aviation. I also teach other people how to fly, and I learned a great definition for learning when I
became a flight instructor:
Learning occurs when you see a change in behavior as a result of experience.
In other words, just hearing about something is not going to create learning. You need to do it,
develop experience, and then look and measure for the change. Frankly, most companies I deal with
want a two-week assessment, a four-week road map, and then they somehow think these artifacts and
a few hearty commands from management will work miracles. Data governance will require some
work and some significant behavior changes. So this book is written with an eye toward changing
behavior, and assimilating and managing the work to be done.
The following pages present the steps, artifacts, techniques, and insights developed by my
companies over the past 20 years or so. Some of this material can be incredibly dry, so if I sprinkle in
a story or amusing metaphor, it is not because I am overly glib. It is because I really want you to pay
attention. This stuff really matters. Your organization is going to live or die based on how it deals with
data. You can do ERP, buy business intelligence tools, or attempt sophisticated analytics. But unless
you manage what is going into the infrastructure and control what comes out, you will never be sure
you are doing anything correctly.