In one of my previous articles – Chief Data Steward or Chief Data Officer: Another C-Level Acronym?, published in Q1
’07, I talked about the emerging role of the Chief Data Steward or the Chief Data Officer (also described as CIQO – Chief Information Quality Officer by Larry English). One of the foremost
challenges facing the CDO or the CIQO is the need to establish a business case or ROI (return on investment) for DQ management or data governance initiatives. This article attempts to outline 15
principles of ROI development for data quality (DQ) projects that can be leveraged across any industry.
Does ROI Matter?
The cost of poor data could be attributed to be anywhere from 10-25% of the total revenues of any organization. The topmost technology reason for customer relationship management (CRM) projects to
fail or miss expectations is poor DQ. The Data Warehousing Institute estimates that data quality problems cost U.S. businesses more than $600 billion a year. Over the past few years, my observation
has been that it is NOT the lack of awareness of the value of high quality information, but rather how critical it is to the business and how bad data really affects the business. Like any other
project, data quality and data governance initiatives require funding to proceed. Management will not sign off on any anything unless the value of investment can be quantified. No action happens
until they know what they are going to get.
ROI – An Art or a Science?
ROI is an accounting formula that is used to obtain an actual or perceived future value of an expense or investment. ROI
measures how effectively a business uses its capital to generate profit (see Figure 1). It is a return ratio that compares the net benefits of a project versus its total costs. The higher the ROI,
the better it is for the organization. It has been my personal belief that securing funding for DQ projects is more of an art than a true science – it includes a combination of soft skills,
business acumen, and application of scientific principles in a unique way to achieve maximum advantage. This article elaborates on some basic principles that can be followed to achieve greater
success.
Figure 1: ROI Explained – Benefits versus Costs
Principle 1 – Know Where the Money Is
This involves identifying the costs and opportunities that are associated with processes that depend on data. It also involves finding out as to who the stakeholders are in terms of who would pay
the costs and who needs to understand the costs. Leaders of functional areas where the pain is most felt would be the best stakeholders. It is also important to evaluate how these costs or
revenues can be potentially measured and tracked.
Principle 2 – Know Your Data
One of the most important requirements while making a business case to ask for more money is to understand the data flow within the organization. The presenter immediately loses credibility if he
or she does not understand the usage and purpose of data within the various applications in the organization. It is imperative that they understand the structure, meaning and quality of data at
least at a high level; but, most importantly, they should be able to eloquently explain how bad data affects the business and the day-to-day operations in respective functional areas within the
organization.
Principle 3 – Keep the Model Simple
It is sometimes very tempting (and I will admit that I fall prey to this one once in a while too) to fill up the model with too many numbers or valuations. The principle to remember here is to
keep the model simple and include 1 or 2 numbers that really matter – one shouldn’t need to be a financial wizard to understand the numbers. Most managers are functional experts and
do not have the financial expertise to understand the results of complex financial analysis. The reality with upper management in most organizations is that they are generally moving from meeting
to meeting and have a very short attention span. So it is very important for the key stakeholders to clearly understand the funding that’s needs needed to proceed and what the return on
investment or payback would be from the program.
Principle 4 – Study Your Stakeholders
This principle cannot be stressed enough. It is very essential to identify the stakeholder with budget and resource responsibilities. One needs to identify what things are important to them, and
also to understand what model they like while approving projects. Some managers may like more detail while others might like less detail and things to be explained in a few slides. I have also
found it that it was wiser and more prudent to identify the key stakeholder and tailor the presentation to his or her needs. In such a meeting, it is almost suicidal to attempt to please all
styles.
Principle 5 – Ensure Investment in all 3 Areas: Time, Funding and Resource
When you read this principle for the first time, it would seem that they are all one and the same. But that is far from true. Management should be aware of the percentage of “time”
commitments from key individuals that would need to be involved with the project. It is easy to identify the “resources” – whether they are virtual or full-time – but
without the percentage of time commitment from the relevant managers, it does not mean much. Almost all DQ projects will require “funding” of some sort – whether it be new
headcount or capital budget to be spent on software or hardware. It is essential that funding be called out in explicit terms along with resource names and their time commitments. It is highly
recommended that the initial program start with off with a virtual team if a full-time team cannot be funded at that time. Practical experience seems to suggest that the virtual team approach is
much more prudent and pragmatic than asking for funding an entire team along with additional dollars toward a capital budget.
Principle 6 – Pick a Data Problem Where the Problem is Apparent
It is very easy to quantify the impact of bad data when its impact can be somehow tied in to the organization’s goals. When the managers see that their day-to-day operations and hence their
ability to meet the organization or department goals is affected by bad data, they feel more aligned to it as they feel the pain directly and understand that their success in the organization is
dependent on good data.
Principle 7 – Establish Organization and Structure
The business case carries a lot more weight when a high-level data governance structure with roles and responsibilities is laid out. If possible, it is also a good idea to include suggestions
regarding who should play the respective roles; but if this proves to be too sensitive due to political issues, then it can be deferred to a later occasion. It is very helpful if there is a
natural leader that emerges for the CDO (Chief Data Officer) or CIQO (Chief Information Quality Officer) role. The high-level modus-operandi for the data governance team should be defined in the
context of this role and the roles that will interplay with it. While formulating high-level organization structures, an important aspect that needs to be kept in mind is the need to understand
the downstream impact to teams. If the teams feel threatened due to loss of control, they will be much more rebellious and non-cooperating toward the new initiative. A high-level overview of how
the CDO’s organization could be laid out has been outlined in the TDAN article published in Q1 ’06 – Practical Data Stewardship Structures. The roles mentioned in the article could be combined and played by the same person in a scenario
where the team is starting off in a small way. The place where the CDO falls in the corporate organization structure is also explained in the TDAN article published in Q1’07 –
Chief Data Steward or Chief Data Officer: Another C-Level Acronym. It is difficult to imagine the CDO
to be successful if they do not have C-level backing from the rest of the organization.
Principle 8 – Build Momentum Around the State of DQ
It is also very essential to build a sense of momentum around the problem and current state of DQ. What this means is ensuring that the company is not in denial around the DQ problem as it is a
very well-known fact that getting money for an unrecognized problem is difficult at best. One important technique that effective project managers have used over the years is to have one-on-one
meetings to communicate the key messages prior to the actual ROI meeting. If you sync up with the lowest level managers whose operations are impacted in advance of the meeting, there is a better
chance of them supporting the initiative in the long run. This is where the soft skills of the CDO (namely, diplomacy, tact and perseverance) come into the fore.
Principle 9 – Gather Statistics from External Sources Around DQ Benefits
This principle focuses on the act of gathering statistics around DQ benefits from external sources like the TDWI Data Quality Survey (see Figure 2 below). It serves the purpose of eliminating
ambiguity as to why DQ is being given so much importance and helps raise awareness around DQ. This eliminates any controversy around situations where the audience feels that the presenter is
trying to accomplish some ulterior career-promoting objectives by introducing some new buzzwords into the ears of management and making the problem bigger than it should be or just inflating the
numbers related to benefits. The potential data governance and DQ program benefits are very different for respective organizations, but having some industry numbers around benefits realized by
other organizations definitely does add more credibility to the overall business case.
Figure 2: TDWI DQ Survey – 2006
Principle 10 – ROI Model Development is an Ongoing Effort
One important principle that often gets forgotten is that ROI calculations and the ROI model itself need to be adjusted and refined at every toll gate or phase of the data governance program.
Financial analysis should be made a living and changing part of the program. Assumptions developed around the ROI model could very well get invalidated as you complete the first phase of the
initiative. The ROI model for establishing a DQ initiative for the first time could be different from one where the first project has been successful and now greater funding is needed to fuel the
initiative in an enterprise way. Achieving buy off on the business case and ROI for the DQ or data governance initiative is probably the most important task of the CDO or CIQO.
Principle 11 – DQ Initiatives Should Almost Always Be Tied to Compliance
The Sarbanes-Oxley Act of 2002 also known as SOX or Sarbox has established new or enhanced standards for all U.S. public company boards, management, and public accounting firms. Any project that
gets linked or tied up with SOX compliance will get all the attention else it is almost invisible (see Figure 3 where it talks about the same concept although in a jocular vein). As compliance is
mandatory, there is always a higher willingness to pay for it. Although the tie-up with compliance produces enough political mileage, overdoing it also could prove to be detrimental and
counterproductive as the data governance initiative needs to be couched and positioned as an opportunity for improving the business instead of another “have to do” project.
Figure 3: SOX Compliance and Visibility
Principle 12 – Pick a Pilot Project Where Results Can Be Demonstrated Quickly
It has been my personal experience that the first project that’s selected for the DQ program is probably the most important one as it sets the mood for success or failure of future
projects. If the project is not successful, it is quite possible that the entire program might get scrapped due to poor execution or the lack of measurable progress. Management is impatient to
see measurable results, and this is possible only when both the scope and duration of the project can be managed effectively. It is found that it is most effective when the duration of the
project can be limited to a maximum of 2 months. The DQ strategy needs to scale up slowly as the scope increases to cover other areas in subsequent phases of the program. The first project should
be simple with clear, measurable, and non-ambiguous goals with demonstrable results.
Principle 13 – Establish How You Would Measure Progress Using Simple Metrics to Establish and Sustain Quality SLA
This involves measuring the success and progress of the initiative using concepts like EIQ. EIQ (Enterprise Information Quality Quotient) is a single-valued enterprise level metric to measure
state of DQ and IM (Information Maturity Level). The usage of “EIQ Trending” graphs that graphically depict progress before and after the initiative are very helpful. Management likes
numbers and nothing is easier to comprehend than the sight of error percentages going down and the level of DQ going up. EIQ progression can be used as a succinct measure by the CDO to
communicate the state of quality to senior management and provide comparative assessments over time. “One size fits all” set of metrics is never a good solution, so it is always
prudent to customize. But it is also important to not let the team get too stuck on semantics. Pick the top 5 quality metrics that are most relevant and generally agreed upon within the
organization.
Principle 14 – DQ Management Components Should Include Reactive and Proactive Components
Many times the organization is already aware that DQ is in a bad state. In this scenario, they wish to see the mind-set that the program will “react” to problems that already exist in
the short-term and also establish a DQ program framework that will diminish the potential for new problems to arise over a period of time. Both mind-sets are needed as a purist approach of just
being “preventive” sounds good in theory but is very difficult for management – both upper-level and mid-level managers – to accept in reality.
Principle 15 – Provide a High-Level Overview of DQ Methodology to be Followed
This principle of ROI development emphasizes the need for a DQ methodology that is being is proposed or recommended for the DQ initiative. It has been my personal observation that any methodology
that is chosen for the exercise cannot be implemented verbatim and needs to be adapted to meet the needs of the organization. But choosing one or at least having a strong opinion about one is
important to establish a strong business case. The DQ methodology could be one provided by the vendors (for example Business Objects’ DQ Methodology – see Figure 4 below) or by
industry experts such as Larry English (see Figure 5 for an overview of the TIQM Methodology).
Figure 4: Business Objects’ DQ Methodology
Figure 5: TIQM Methodology (Courtesy of Larry English)
Conclusion
The principles outlined in this article have been conceptualized based on real-life experiences of what has worked and what has not worked. It is quite possible that all of the principles
elucidated may not be applicable in every situation – some might be more applicable toward a new initiative while some might be more effective in securing funding for subsequent phases of an
existing data governance initiative. Also some principles might be more applicable for the first business case session while others might be more appropriate for subsequent sessions – whether
they be for new or existing initiatives. Thus, ROI and business case development definitely include elements of art, but it is also clear that some common business principles based on scientific
and quantitative analysis can be used to achieve greater success in this endeavor.
References
- Chief Data Steward or Chief Data Officer: Another C-Level Acronym, The Data Administration Newsletter, Issue 39, Q1 2007. Online: http://www.tdan.com/view-articles/4581.
- Practical Data Stewardship Structures, The Data Administration Newsletter, Issue 35, Q1 2006. Online: http://www.tdan.com/view-articles/5044
- TDWI Data Quality Survey, The Data Warehousing Institute, March 2006.
- The Value of Data Quality, 2005. Online: http://www.businessobjects.ch/download/events/archive/2006fr/WalterWijn_EIM_FR.pdf.
