The Body Has a Heart and Soul:
Roles and Responsibilities of the Chief Data Officer
January 2007: Originally published in IDQ Newsletter Vol 3 Issue 1
By
Thomas C. Redman, Ph.D.
Introduction
I closed my July 2006 column with the assertion that, “in time, organizations will recognize data as assets on par with other assets such as people and money. And Chief Data Officers (CDOs) will be named.”
I promised to discuss the roles and responsibilities of the CDO in the next column, but as I labored away, I realized that the most important job of the CDO was serving as Secretary to the Data Council. Since not all readers may know what a Data Council is, who sits on it, what they do, and why they are so important, I devoted my October 2006 column to that topic.
Now, I finally have an opportunity to deliver on my earlier promise — to discuss the roles and responsibilities of the CDO.
But First, an Important Note
I use the term “Chief Data Officer” loosely to refer to anyone leading a Data Program, whether they are true C-band officers, middle managers anointed with the task of getting a Data Program started, or junior technicians just trying to get started in their work groups.
The CDO as Secretary to the Data Council
In last quarter's article, I proposed four specific roles for the Data Council:
- Provide Visible Leadership (including strategy and business purpose);
- Establish Process and Supplier Management Teams;
- Define and Document the Organization's Data Policy; and
- Advance a Data Culture.
Perhaps the CDO's most important job is to serve as Secretary to this Council. I use the term “Secretary” here not as “an executive's secretary” but as “Secretary of State.”
A Secretary of State has many and varied roles: from proposing strategy, to recommending and implementing policy, to leading the State Department. Similarly, the Chief Data Officer, as Secretary of the Data Council, has many and varied roles.
The CDO grapples with policy and implementation challenges
Thus, while the Data Council “owns” the data strategy, the data policies, and the associated business cases, the CDO actually does most of the work. This responsibility is not as straightforward as it sounds, given that data strategies and policies are difficult to define and even more difficult to implement.
To illustrate, consider these three possible statements in a data policy:
“Don't pass bad data onto the next person. And don't accept bad data from the previous person.” [1]
“Don't take unencrypted data about our customers, suppliers, or employees from the building.”
“Business Unit and Division Heads must report on their progress on the data strategy at the end of each fiscal year.”
Each of these statements has merit. But implementing and supporting them is another matter. Convincing people that policy is even needed, advising them of their responsibilities, working out the practical details, and handling violations are all problematic. Should a junior analyst, citing the first policy, refuse to complete a report because the figures provided by Finance don't seem right? Or should a salesperson, citing the second, not sign up a new customer when the encryption software on the company-issued handheld device doesn't work? The list of issues can go on and on.
So the CDO must balance the potential utility of a policy statement against the difficulties of supporting it. There is no point defining a policy or a strategy that cannot be supported. Similarly, good data strategies must not only advance the organization's business objectives; they must be within the organization's ability to execute.
The job of selling and implementing policy and strategy falls to the CDO. The CDO is the day-in, day-out face of the Data Program, working with the organization's various departments and process owners to help them understand their roles and obligations, integrate data into their plans, and create “urgency” so the data program is given its due. [2] The CDO helps translate strategy and policy into shorter-term plans and more objective measures of success, and enlists people to join cross-departmental efforts. Finally the CDO tracks progress by defining and assembling the Data Quality Dashboard and helping the Data Council understand the results and their implications.
It bears repeating that the Chief Data Officer is a tireless salesperson, a teacher, and a skilled politician. Most people agree that “data are important,” but they already have too much to do. Convincing an organization to do more is no small task, especially if it entails clarifying their requirements, defining objective measurements, or completing an improvement project!
Which comes first: The Council or the CDO? Organizations may well decide to name a Chief Data Officer before they have a Data Council in place.
In such cases, the CDO may have to start working without the benefit of the Data Council's support. Since much of the CDO's mandate to work across departments comes from the Council, the job is much more difficult without senior level support. The best approach may be to demonstrate success on relatively small projects and use them to justify the formation of a Council before tackling larger projects.
The CDO Leads the Data Quality Program
The CDO is the day-in and day-out leader of the data quality program. This individual crafts the data quality program and communicates it throughout the organization.
The CDO must explain both the philosophy and the methods for managing processes and suppliers, measuring quality levels, conducting improvement activities, and so on. In this regard, one important role of the CDO is to import the techniques of data quality management and make these techniques as easy to use as possible.
For example, the seemingly simple task of renaming the six-sigma DMAIC technique as “Our Bank's Quality Improvement Cycle” is not a straightforward exercise. The task involves selecting techniques to best suit the organization, translating them into the organization's language, and using the organization's case studies to illustrate their usage and effectiveness.
Finally, as a leader of the Data Quality Program, the CDO either provides or arranges training and education on topics relevant to the data program, and builds deep expertise in all aspects of data and quality management so that these skills can be brought to bear on especially challenging or important issues.
The CDO leads the Data Supplier Management Program Office [3]
The CDO also plays an important operational role by leading the Data Supplier Management Program Office, with the following responsibilities:
- Translating the overall Data Policy into policy relevant to data suppliers;
- Ensuring that a department is assigned to manage the most important data suppliers;
- Resolving issues that arise when two or more departments compete for the attention of a single supplier;
- Setting organization-wide goals for data supplier management, and tracking progress against them;
- Assembling the overall Supplier Scorecard; and
- Conducting the Supplier Certification Program.
The Office of the CDO as the Home of Metadata Process Owners
Over the last several years, I have come to believe that too many organizations suffer from the lack of good metadata:” [4] Consequently:
- Critical data elements are poorly-defined;
- Business rules are lacking, and too many of the rules are ignored;
- Data standards are poorly defined or poorly implemented; and
- Critical data are difficult to find and even more difficult to protect.
To make matters worse, organizations that do have some form of metadata do not always manage metadata as an enterprise resource. Far too many things fall through the cracks when the work of creating, maintaining, and using metadata is not managed as an end-to-end process. To quality practitioners this is, of course, a cardinal sin. Organizations simply must manage their metadata processes end-to-end, and the owners of these processes need a home. I believe the Chief Data Office is an excellent choice.
Final Remarks
I liken the Chief Data Officer's job to “herding cats.” The successful performance of this role is complicated by: (a) the fact that virtually everyone “touches” data in some way; (b) the presence of organizational silos; and (c) the lingering feeling that “data is the province of IT.”
The first generation of CDOs will doubtless be overworked and underappreciated. And as organizations and people better understand the importance of data, the job will no doubt become even more political. Yet CDOs may well be the heart and soul of their organization's data programs.
Your thoughts and comments are welcome. Please send feedback to tomredman [AT] dataqualitysolutions [dot] com
1 This statement is a re-wording of my favorite quality policy of all time. I used it last time and it is so good I repeat it here.
2 A somewhat more cynical view of this work is that many people resist new thinking, tools, and techniques. One frequent comment is “This doesn't apply to us because…” So the work of the CDO aims to mitigate excuses.
3 I have not made up my mind whether a separate “Process Program Office” is needed. I suspect that some organizations will benefit from one.
4 I know a lot of others believe as I do. But I do not know of any survey that supports or contradicts my belief, further illustrates the key issues, or calls out successful approaches.
© 2006 Navesink Consulting Group, LLC
About the Author
Thomas C. Redman, “the Data Doc” is president of Navesink Consulting Group in Rumson, New Jersey.
Dr. Redman was the first to extend quality principles to data and information. He has helped hundreds of organizations understand the importance of data, start their data programs, make order-of-magnitude improvements to data quality and, by doing so, lower costs, increase revenues, improve customer satisfaction, and more make more confident planning decisions.
His fourth book, Data Driven: Profiting from Your Most Important Business Asset (Harvard Business Press) is a Library Journal Best Business Book of 2008.
Tom is an internationally known lecturer and the author of dozens of papers. He holds two patents and is an IAIDQ co-founder, and is the recipient of the IAIDQ’s 2011 Distinguished Member Award.
He can be reached at tomredman [AT] dataqualitysolutions [dot] com