TRILLIUM SOFTWARE INSIGHTS

Changing Wrong to Right – Making the Case for Data Governance

By Nigel Turner, Vice President, Information Management Strategy, Harte-Hanks Trillium Software

In my last blog, our data quality (DQ) protégés of LA’s most famous fictional detective Philip Marlowe had been investigating a number of key suspects which they believed had been hurting the business. They had pounded the mean streets, interrogating witnesses to the crime. Evidence had been gathered. It was now time to act. The next step was to make the case to the Business to prosecute the data and try to right the wrongs that had been perpetrated.  

No data quality improvement project should ever be started without a business case.   DQ improvement is never an end in itself. Before deciding to invest in DQ, it’s vital to demonstrate to the business that the problem to be addressed is worth tackling, and if successful, will deliver real benefits to the organisation. 

From my time in British Telecom, where many cases were assembled and presented for business endorsement, a number of general lessons emerged.

First, before preparing a case based on the analysis and evidence gathered earlier, ensure that the case has a business sponsor. This is a clear sign that someone in the business cares about it and feels it worthwhile to pursue. The sponsor should have sufficient influence and authority to champion the case, gather support and break down inevitable barriers that others will put up. 

It also needs, at least, the initial support of key stakeholders who will be affected by the proposed improvements, and / or who might be needed to make the changes required, especially if those changes demand alterations to business processes, people’s objectives and so on.

Second, always try to present more than one option for action. For example, your investigations might have uncovered inconsistencies between billing and sales data which had been causing loss of revenue. You might lay out two improvement strategies. One might be a relatively inexpensive option with tentative or reduced risk and benefit, such as introducing an additional manual check of data before transferring data from Sales to Billing. 

The second option might be a full blown automated DQ tool-based validation and remediation solution, which would initially be more costly but which would deliver more enduring longer term benefits. Make sure you include a recommended option, but give the business some leeway. In any and all cases always include a ‘Do Nothing’ option. Here doing nothing might mean that billing and sales sources become increasingly out of step, with potential revenue losses increasing gradually over time. It also shows that doing nothing is not a viable choice, now or into the future. 

Third, whatever the core rationale of the business case (whether it’s enhancing business performance, customer perceptions, conformance to regulation etc.) always try to include quantitative financial benefits. DQ improvement almost always requires material investment and costs, so your case will be more compelling if you can show it will positively impact the bottom line. Even regulatory drivers usually have some underpinning or tangential financial benefits, e.g. avoiding the risks of hefty fines from a regulator if you get it wrong. 

Fourth, remember that each business case is unique. Every DQ problem I have come across is caused by a unique combination of people, process and technology shortcomings. The benefits of improving it, and the costs involved in doing so, are therefore always specific to that case. If you can, enlist the help of a finance expert who has worked on business cases before to help you assemble the case and to validate any financial benefits. He or she will know what works and what doesn’t work in your organisation. 

Once you’ve gone through these steps you are ready to present the case to the business and IT people who you need to make it become a reality. In the next blog, I’ll highlight some techniques for winning support within your stakeholder community.  Putting a strong case together is a necessary but not sufficient step. You now need strong advocacy to convince the judge and jury.

Philip Marlowe has done his job and is working on his next investigation. It’s now time to call in Perry Mason.

 

Illuminating the Mean Streets - Investigating & Quantifying Data Quality Problems

By Nigel Turner, Vice President, Information Management Strategy, Harte-Hanks Trillium Software

In my previous series of blogs I focused on how one large global organisation, British Telecommunications (BT), recognised the need to take action to address data quality (DQ) barriers to the development of its business, and started to identify candidate cross-organisational DQ problems that could be addressed within the broader context of an enterprise-wide data improvement initiative. 

Now, I plan to highlight how this long list of potential problems was narrowed down to a specific list of initial improvement projects, how business cases for action were made, and how these cases won the backing of BT’s senior executives. This particular blog focuses on how the list of DQ suspects was further narrowed down. Key to this was a detailed investigation of the problems.

It was the time to use forensic techniques. It was time to call in the detectives. 

One famous fictional investigator, Raymond Chandler’s Philip Marlowe, would have recognised the challenge. As he walked alone through the mean streets of LA, Marlowe would learn that dirty data quality deeds had been done, that unspeakable crimes involving data had been perpetrated. His job was to establish the facts, and put things right. As one of Chandler’s most famous Marlowe novels, the ‘Big Sleep,’ memorably stated, “The streets were dark with something more than night,” so investigation was needed to throw light on the data quality problems, and to point the way to a brighter future.

Like all good detectives our DQ investigators started with what they knew. This was the list of 50+ candidate data quality themes and problems uncovered by earlier analysis. It was now time to identify the prime suspects. But the investigators could not do this alone. Expert help was needed. 

So they called in a group that understood the damage these suspects had caused.  This group was known as “The Business.”  A workshop with these business stakeholders was set up. Many of the business people invited had been identified in the first phase of investigations; others were suggested by them.

The investigators provided the list of suspects and let The Business decide on their fate. They used a combination of established techniques – Force Field Analysis, Benefits Management, and the Boston Grid – to help the Business decide which cases to focus on first. There was much wailing and gnashing of teeth but eventually a shortlist was drawn up. The Business also agreed to meet again when the detailed analysis was complete. 

The investigators did what they were told and conducted a detailed examination of the prime suspects. They used two primary tools. First, they interviewed key people impacted at all levels in the organisation, recorded process and people problems caused by the data, and did a first cut assessment of the financial and other impacts (e.g. regulatory compliance) of these problems. In parallel with this, they put their magnifying glasses on the data itself, first identifying the key sources where the delinquent data was held.

Using data profiling tools they then assessed the scale and scope of the data problems in these key sources. They also put together an initial improvement proposal, embracing people, process, technology and the data itself. 

Some general rules emerged from this process. First try to express the impact of DQ problems on the business by their financial impact. This is best done by estimating the costs of poor quality data. What processes fail when data is incorrect or missing?  How much does each failure cost?  How often do these failures happen? What are the estimated costs of failure in six months, one year’s time?  

Second, what other damage is done? How do these failures damage the company’s image and brand? How do they jeopardise the organisation’s ability to meet its legal and / or regulatory obligations?  How are customer perceptions affected?  How is the morale of the organisation’s people impacted?

The end result of these investigations was a detailed analysis of a small number (3-5) of key DQ related problems. The prime suspects had been rounded up and interrogated. The next step was now to decide what their fate would be.  It was time to call in the Business again. See my next blog for what happened next…

What Works When Planning to “Operationalize” Data Governance

By Michael Stiffler, Strategic Consultant, Data Governance, Harte-HanksTrillium Software

In case you missed it, we presented our thoughts around “operationalizing” data governance in a recent Trillium Software-sponsored webinar. I wanted to stress a couple of key takeaways:

1. Data governance is an iterative program.  You need to set the expectation that the program will evolve, especially as the company's business requirements evolve. For instance, you may have to adjust your framework to include other areas that are now important to the business. Or perhaps you understand the corporate culture a little better now and need to adjust your approach to increase your chances of being successful.

2. Don't do data governance just for the sake of doing data governance. You need to understand the key business drivers, and tie data governance to activities that will actually increase business value. What business pains can be mitigated through data governance? How should they be prioritized? These are questions you'll need to answer.

3. Are you able to measure success? How does the business define success? Dashboards and scorecards are one way of measuring and showing improvements to your data (which is one definition of success). This may also resonate better with the business folks, especially if you have gotten their input in defining "success."

4. Make no mistake, you will experience roadblocks or setbacks.  How you respond and recover is what makes the difference between success and failure.  Don't be afraid to admit your mistakes and learn from them.  Use these lessons learned to help improve implementations into other data domains.

5. Communicate your successes. Set up a forum to share best practices across the team of data stewards, data owners, and other stakeholders involved in your data governance program (e.g., center of excellence). Additionally, the dashboard mentioned above will help communicate your successes.

I outline these takeaways because they have been critical components of the real, live data governance engagements I’ve seen and managed. They were presented with the hopes of helping you plan better in advance, and reach success faster. I hope these are helpful considerations for you as you move forward with your own data governance efforts.  Good luck!

 

Don’t Be Afraid to Talk about Your Data Quality Issues

By Michael Stiffler, Strategic Consultant, Data Governance, Harte-HanksTrillium Software

One of the best pieces of advice I give to my clients is to talk about your data quality issues to people in management and IT.  Don’t be afraid!  This seems like a very obvious activity, but it’s often overlooked, or avoided like the plague in case it could reflect on you or your team. But, talking it out is a great way to gain support in the business, and then partner with IT when necessary, to solve those business issues on a wider scale across the enterprise.

The “data quality” conversation opens up a forum in which the different organizations within the enterprise can collaborate to solve a problem instead of pointing fingers to assign blame. Often anecdotally, the business will claim there is a data quality issue and maybe even propose a solution without even talking to IT. In reality, it may not be a technical issue at all. It could be a business process issue.

If your Data Governance program already has the business processes documented, the root cause analysis will be executed much faster. If not, then get the process in writing quick.  Do it now.

Once you have identified the cause of the issue, you can work on the solution. If the cause is indeed a technical issue, you work closely with IT to resolve it. If it’s a business process issue, you may want to work with both the business and IT to resolve it.  In fact, I recommend that to cover all the bases and ensure everyone is on the same page. 

For instance, the original business requirements may not have included capturing a piece of critical data up front that is causing an issue downstream. Now the business folks can work with IT to revise the rules to capture that data in the application and store it in the database. Or, depending on the case, IT can enrich back-end process using a data quality solution to append the piece of data - zip+4, gender, etc.

Once the business recognizes that data quality issues aren’t always IT problems, it will be easier to have future conversations with them, and most importantly, business managers and analysts will start owning some of the issues.

And, that will certainly alleviate many of your data fears so you won’t be afraid to talk about what you may not know.  Remember, when it comes to data, what you don’t know may hurt you…or your business.

 

ID Specific Data Quality Problems - Talking Happy Talk

By Nigel Turner, Information Management Consultant, NHT Data Consultancy Ltd.

In my last blog, I highlighted how a major global telco, British Telecommunications, recognised that endemic data quality problems were hurting its business.  Reaching this stage of awareness is an important first step, but before things can improve, it’s vital to hone in on specific data issues that can be tackled via an improvement programme.

Any data quality initiative needs to start with the business and its needs.  So the first thing we did was to ensure we understood the strategic objectives of BT as an organisation.  You cannot secure the business support you’ll need to succeed unless you can demonstrate how your data quality initiative will help to improve the business. 

In BT’s case, its main aspirations were to deepen the loyalty of its existing customer base, build new propositions and generate new customers, create a world-class network, and build long term partnerships with customers.  It was evident that data was at the heart of all of these strategic aspirations. 

For example world class network capabilities depend on accurate recording of the components that make up that network – switches, routers, cables, customer devices and so on – and so accurate inventory was key for network planning, operations and support.  Our initial focus was how data was being used to support these key objectives, and to critically obtain an initial view of how fit the data was for this purpose.  

How did we set about doing this?  Well, one of my favourite musicals is ‘South Pacific’.  I’ve always found this movie has an enduring ability to raise the spirits.  The most exuberant scene is when the larger than life character Bloody Mary sings ‘Happy Talk’, a song which praises the value of talking with others.  ‘Happy talk’ became a mantra for what we did next.

We quickly learned there is no better way of gathering evidence on specific data quality problems than to talk to the people who create data and use it as part of their daily jobs.  So we built an initial list of the people who we surmised made a core contribution to delivering BT’s strategic goals.  These included senior executives, marketers, salespeople, IT specialists, finance managers, HR specialists, engineers, account managers and so on.  

It’s important to talk to people at all levels in the organisation.  A day spent sitting alongside a BT call centre operative generated a long list of problems with customer and product data; a day out with a BT engineer whose job was to install new equipment at customers’ premises highlighted inventory data shortcomings.   A session with a senior finance manager exposed billing and accounting shortcomings.

Gradually a picture of some of the main data domain problems began to emerge.  Talking to people also generated many other insights.  People who work with the data understand its context – how it is used, why, and what the impact of inaccurate or missing data is.  They can also point you to others who have a detailed knowledge of the data problems, so you can evolve your stakeholder list.  Many of the data experts we came across became key stakeholders, supporters and subject matter experts for the data quality improvement programme.

It’s also essential to prepare carefully for each interview or session.  Ensure you have a generic list of questions (e.g. What key data do you use in your role?  What are the main problems with the data?), supplementing these with specific questions relevant to the person you are seeing or shadowing.

When each data problem emerges it is vital to record it in a systematic way.  This means a simple business description of the problem, ideally related to the strategic business objectives referred to above, a rough scope and scale assessment (e.g. how often is this data inaccurate or missing?), what is the business impact of the failing, ideally expressed in financial terms, the primary business process(es) impacted, and the main stakeholders affected.

Also capture initial ideas of how the problem might be improved in terms of potential people, process and technology changes.  At this point don’t aim for a comprehensive analysis of the problem and potential improvements but for an initial understanding.  Building a detailed case for action comes later.  

This approach enables you to build a dynamic prospect bank of data quality problems.  Collecting them in this way also allows you to start to look for key data issues which impact several areas of your organisation, for example poor capture of customer addresses impact marketing, sales, invoicing, operations and so on.  This helps build a data centric view which transcends organisational boundaries, processes and systems. 

In my next blog I’ll cover how this prospect bank can be further investigated, evaluated and prioritised and so help to ensure a focus in on the problems that really matter to your business.

Embed Data Governance into your Enterprise Processes Early

By Michael Stiffler, Strategic Consultant, Data Governance, Harte-HanksTrillium Software

One activity that may help create a credible and successful Data Governance program – and achieve early executive buy-in – is embedding Data Governance policies and processes into your corporate infrastructure. This allows for seamless integration of Data Governance into existing processes your company is already relying on.

An example of where you can do this is in your software/system development life cycle (SDLC). Now, of course, if you don’t take this approach, violations of these data governance policies will be seen downstream after the project's completion (ideally earlier if you have robust test and development cycles). But to keep rework to a minimum, be proactive about Data Governance and embed your DG processes into the development lifecycle in the planning stages and through the formal project management organization.
 
Gathering business metadata, documentation, approvals, accountable parties, and data owners is usually much easier when you incorporate these elements up front, than after the completion of the project.  That makes sense, right?

And creating new processes for data quality mitigation or establishing escalation processes is less  efficient when it needs to done as a fire drill on the back end.

Additionally, Data Governance will be a part of the project timeline and you won't have to reset expectations or risk losing resources (e.g., subject matter experts) that are not already allocated and approved for the Data Governance effort.

Among other things, Data Governance should help bridge the gap between IT and the business.  As part of this partnership, these two organizations would have already agreed to follow a standard process for application/system/database development (from collecting requirements to production release), so Data Governance policies will fit right in.

Piggy-backing off existing lifecycle project agreements and embedding Data Governance processes into your SDLC is a logical extension and should make enforcement of Data Governance policies a little easier.

Have you done this before?  How did it work out for you?

It’s not about seeing the solution, It’s seeing the problem.

By Nigel Turner, Information Management Consultant, NHT Data Consultancy Ltd.

In this second blog I’ll talk about why BT decided to embark on an enterprise wide programme of activities to address data quality issues, an initiative that ultimately delivered more than $1 billion of benefits to the company.  I’ll do this by focusing on two main questions.  How did BT know it needed to act?  How did it get started?

The first step in addressing a problem is always to recognise it.  Initially we found ourselves in a position where, as the English writer GK Chesterton once wrote, “It isn't that they can't see the solution. It's that they can't see the problem.” 

At the outset we didn’t know we had a problem with data quality.  We knew we had business and IT issues around marketing & sales, operational efficiency, product launches, etc.  But we had not made the connection that these disciplines had a common thread – data. This wasn’t because we were sleepwalking, but in those very early days in the late 1990s, few people anywhere had viewed data quality as a focus in its own right. 

But gradually the mist started to clear, mainly by chance and not commission.

Despite massive investment in new IT, business managers complained that they still couldn’t do many of the things they hoped new IT projects would deliver.  These included getting a single customer view, faster and less manually-intensive processes, quicker launching of new products, cheaper IT support costs and so on.  At the time, one cynical senior executive was cited as saying, “All I’ve got from this new IT is the same wrong information but twice as fast as before.”  A less than ringing endorsement.  The CIO knew she needed to act fast.

So she ordered an investigation of the problems. Some of the conclusions were predictable, for instance closer collaboration between the business and IT was needed, particularly more disciplined requirements management.   But to many people’s surprise, a common theme kept emerging – data quality.  A common gripe was that the “T” in IT was working OK; it was the “I” that was the primary bugbear. 

Because of known and suspected shortcomings in data, processes kept falling over, and achieving a consolidated data view of customers and products was a major challenge as data was duplicated (but almost never exactly) across many of BT’s hundreds of core IT systems.  Moreover no-one in the company had any specific responsibility to manage data end-to-end. It soon became obvious that a specific focus on data quality was needed.

So data quality was tackled as a problem across the company for the first time. The CIO put together a small cross-functional team, containing people from both corporate business and IT.  Their brief was to do something to investigate and alleviate the problems.  BT’s journey had started.

So what’s the point of this story for others embarking on an enterprise data quality and data governance journey?  First, in an organisation which is just understanding the importance of data quality and its management, a key role of data quality and data governance specialists is to redefine the problems in data centric terms and to explain these to others in the organisation.  They need to inculcate a new way of thinking.  Data professionals therefore need to be effective agents of change.

Second, IT usually gets the blame for the problems, so it is critical to build business awareness of their responsibilities and commitment right from the outset.  BT’s CIO made it clear to her Board colleagues from day one that she could not address the problems alone but we required a concerted business and IT partnership.

Finally, prepare for a long haul.  In large organisations the scope, scale and complexity of problems caused by failings in data and its management take many years to develop.  They can therefore take years to resolve and can’t be fixed overnight.  Manage expectations carefully.   To paraphrase a much wiser man than I, the Dalai Lama, do not let expectations hinder your path.   

In my next blog in the series, I’ll relate how the small team established in BT started to tackle these challenges.

 

The Data Governance Journey – V is for Vandalism or Veronica?

By Nigel Turner, Information Management Consultant, NHT Data Consultancy Ltd.

The Roman philosopher and statesman Seneca once observed “Every new beginning comes from some other beginning's end.”    Writing this as a guest blogger for Harte Hanks Trillium Software marks a beginning for me, but also marks the end of another beginning.   

For most of the last 30 years, I worked in various IT, data management and CRM roles in a major global telecommunications company, British Telecommunications.  BT is an organisation with a $30 billion (£20 billion) turnover, 100,000 employees in over 150 countries, and more data than it’s possible for most of us to envisage. 

A former colleague once worked out that if all the data held by BT was printed on A4 sheets, and these were laid end-to-end, they would stretch from the Earth to Saturn and back, a distance of over 1.6 billion miles across the cold, dark void of our solar system. For the less cosmologically conscious amongst us, this is a very long way indeed. 

In this context, where the company was storing vast quantities of data and it was growing exponentially year-on-year, the challenge of data governance was never going to be easy. And it wasn’t.  Here’s an example of how things could and did go wrong with data when BT started its data improvement & governance journey back in the mid-1990s. 

It centred on one particular town, Wolverhampton in England.  Business reporting applications had identified a trend which suggested many customer faults had arisen as a result of vandalism of BT network equipment.  So BT launched into action, quickly authorising a business case to better secure and protect its equipment in the hope this would discourage further attacks.  But one sceptic decided to relook at the data before committing the expenditure. 

He discovered that all fault data in Wolverhampton at that time was inputted by a lady named Veronica.  So he thought it worthwhile to talk to her. When he did so he had a surprise.  She told him that when she entered details of a fault onto the main reporting system, she used a one digit field to enter her initial (V) to show she had input the record.  Unfortunately the field in question was intended to capture cause of fault, and, you’ve guessed it, V was the input code for Vandalism. 

The business case was rapidly and quietly filed away under ‘close shaves’, Veronica was put right and the problem rapidly disappeared. 

This taught me a few home truths about data quality and data governance.  First, problems arise for all sorts of reasons, usually a combination of people, business process and IT issues conspiring together to make things go wrong.  This case also showed that data governance is not about better IT alone but better business practice; in this case IT was not a major cause of the problem.  

This was one of many data quality issues that surfaced at that time. So BT decided to act.  My role was to coordinate a programme of activities to start to address the problems.  Ultimately this programme, which evolved to embrace the whole enterprise, lasted for close to ten years, proving data governance is not a short term fix but a long term commitment to continuous improvement.  

By the end of the programme, BT saved hundreds of millions of dollars as a result of better data governance and improved data quality. Near the culmination of this journey, industry analyst firm Gartner commented that ‘BT is one of the few companies that is actually meeting the challenge of managing data quality effectively.”

Over the next few months my future blogs will outline our data governance journey.  I’ll relate how we took our initial steps, secured business and IT support along the way, got going with improvement projects, and what we found when we reached our destination.  I’ll also touch on the times when we got lost and had to find the right road again.   It was a long haul but well worth the trip in the end.

The Four Pillars of Data Governance Scope Planning

 By Jim Orr, Director, Enterprise Data Strategy, Harte-Hanks Trillium Software

As companies continue to figure out data governance and attempt to understand how it will impact and add value to their business, I’m finding there really is no single magic formula for data governance.  It’s not like a single implementation suits all.  Everyone has their own, different slant on what data governance is and what is should be.

As you can imagine these definitions vary across organizations, and even between businesses within the same industry. Because of this phenomenon, the actual scope of each data governance initiative is trending toward touching a wide range of applications, functions, or responsibilities.  Companies are trying to cover all their bases (using a baseball term as spring is finally almost here).

For some organizations it’s all about stewardship, for others it may be data quality, yet others it is data modeling or metadata management. In some cases, it covers a cross section of these activities and each with a different depth and breath of involvement.  My, how confusing!

Furthermore, scope can vary based on project and data types. For example, many data governance programs are launched in conjunction with CRM, MDM, BI, or DW and can focus entirely on B2C, B2B, consumer, product, or content data. Collectively these disparities are a common point of confusion for organizations looking to draw parameters around their data governance program.

One way to scope a data governance program at a high level is to define four specific areas of focus for both the short and long term:

1) Projects – Identify the project that the initiative will begin with as well as possible subsequent projects,

2) Data – Identify the data and the data sources that will be involved (consumer, products, content, etc.)

3) Data Management Function – Identify each data management function that will be a part of the program both initially and over time. (data quality, metadata management, data modeling, stewardship, lineage, security, etc.)

4) Business function – Identify the business functions that will be addressed (marketing, sales, customer service, risk & compliance, mail & transport, order to cash, etc.)

Drawing much more manageable parameters around these aspects of data governance can be a useful, high-level exercise, especially if it reflects both initial implementation and ongoing growth. It will also help you explain the short and long term direction of the program to executives, business leaders, and associates. 

And, even more important, by splitting the initiative into smaller bite-sized chunks, it will be perceived as easier to implement, will offer better results quicker, and will help you obtain buy in from key executives earlier in the process.  And with buy-in comes funding and resource allocation, which is the eventual key to getting what you want to happen….happen. 

Which of these four scope pillars have you thought about recently?  Let me know.  Have a great day.

 

Enterprise-wide Data Governance: Walk the Walk

 By Jim Orr, Director, Enterprise Data Strategy, Harte-Hanks Trillium Software

One of the biggest obstacles I see with information quality is that all too often it is confined to a single project. While more and more organizations are beginning to go enterprise-wide with their quality initiatives, too few are actually doing it.  They’re talking the talk, but not walking the walk.

At the same time, companies realize they must branch out across the organization if they are to resolve upstream data issues as well as identify and address other opportunities and risk associated with their data.

We could point to a number of contributing factors why businesses remain stranded at the project layer but the primary one points to the absence of data governance.

Going upstream to mediate data quality issues requires us to work “outside the box” and that means coordinating cross-functional people, processes, technologies, lines of business, and budgets. The only way to accomplish this is on the back of a formal data governance program.

Data governance enables full life cycle and enterprise information quality which in turn optimizes data and business results.

How many of you are embarking on a formal data governance program?  OK, how many even know where to start?  Let me know.