THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

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

1. 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.
2. Practical Data Stewardship Structures, The Data Administration Newsletter, Issue 35, Q1 2006. Online: http://www.tdan.com/view-articles/5044
3. TDWI Data Quality Survey, The Data Warehousing Institute, March 2006.
4. The Value of Data Quality, 2005. Online: http://www.businessobjects.ch/download/events/archive/2006fr/WalterWijn_EIM_FR.pdf.