Data Quality - Running in the Badlands

I like to run a little. Actually, I like to run a lot. Back in the days when my work had me travelling most weeks one of the upsides was the opportunity to regularly find new running routes in new cities. Most times this resulted in an enjoyable run and the chance for a bit of sightseeing. However on occasions things didn't go quite so well. Several times I've felt very uncomfortable and one on occasion I had genuine fears for my safety.

Three such times stand out for their similarities although they occurred in different cities around the world - Las Vegas, Milan and Philadelphia. On each occasion I was speaking at a conference and so had a little time to kill, but not enough time so that I could run too far from my hotel. All of these cities promote themselves as either tourist or conference destinations and to the casual observer seem to fit this brief well - safe, busy, functional and (in two of the three cases) prosperous. At first glance it would seem that nothing is amiss and that the "service" they offer is well provided; they are "fit for purpose", if you like. However in each city less than six blocks from my hotel I found myself running through either seriously rundown areas, areas with (in one case) chain mesh fences and burning cars or areas where I was harassed and threatened.

Now, I admit that probably 99% or more of tourists or other visitors to these cities will probably never see the areas I did nor find themselves in a threatening situation. It strikes me that there are parallels with data quality in many business systems: the places where everyone goes, those areas that support the most common transactions and queries have had most obvious data quality issues sorted out. In most cases the people using these systems largely have no problems which stem from data quality issues so over time the perception develops that data quality is not an issue. Even when the odd data quality problem does crop up often its dismissed as an outlier or the pain of it forgotten before it can be used as a driver for a data quality improvement initiative. Much like the cities I visited all seems to be working smoothly as it should.

However on my problem runs I definitely didn't get the result I was after - I didn't enjoy sightseeing and the training effect I had planned for didn't eventuate as I either had to cut my run short or ran (away) at a faster pace than I had planned. Without doubt there was at least a loss of effectiveness and probably a failure to get to the desired outcome. The same occurs in our systems when data quality issues lurk just out of plain sight. When users venture into those areas, be it with ad-hoc requests or with infrequently run analytics, the outcome they seek may well either be missed entirely or hampered by inefficiencies. These issues have knock on effects too - perhaps someone reading this blog won't run next time they attend a conference in one of those cities or may even choose another conference entirely, in much the same way users may choose not to again wade through an analytic process in a certain area of data, preferring instead to rely on gut feel or their own sets of numbers from desktop spreadsheets.

So should we as data quality or data governance practitioners act to rectify these less mainstream data quality issues. The answer is probably "it depends". For me, it's a cost benefit question, if the impact of the problem is bigger than the cost to fix it then there could be a strong business case to be built for a fix. The bigger issue though is not knowing that the problems exist in the first case, so perhaps it is beholden on us to attempt to understand where these problems lie so we, and our stakeholders, can best choose where to focus data quality improvement efforts. Interestingly this very style effort actually is in play at the hotel I stayed at in Philadelphia. Seeing me walk back into the lobby in my running gear the hotel concierge asked how my run was and then offered me a pre-prepared map showing run routes and a very clearly marked border indicating the outer limits of where it was safe to run. I only wish they had advertised the existence of this data steward before I'd gone out running!

Data Ownership and Data Responsibility Should Go Hand in Hand

Chances are that all of us who have tried to advance a Data Governance initiative will have had the data ownership discussion and socialized the idea that IT shouldn't own the data. In the earlier years of my data governance efforts getting acceptance of this concept was most often the first stumbling block. Common remarks from both the business and IT fronts reflected long established culture and practices in which data was seen as an IT focus - they managed it, wrangled it, invested and got to the root cause of data problems, and they held the responsibility of fixing data problems. This resistance, although frustrating, at least had a common theme which allowed me (and I suspect others like me) to build up a toolkit of arguments, presentations, stories and case studies to help move stakeholders toward an understanding that data is best owned by the business and not the IT function.

I've written about the need to keep working away toward implementing data governance before in my post on Thinking Like a Vogon. Having a bag of tricks built up and finessed over time is, in my opinion, key to successfully importing data governance at an organization. It allows those of us charged with championing data governance to keep working toward advancing stakeholder understanding and buy-in over weeks, months and years. Recently I've noticed a trend which has the potential to poke a hole in this bag of tricks, reducing its effectiveness and necessitating a rethink of how I engage with stakeholders. These days I encounter less push back when I propose the idea that IT doesn't own the data. The concept that the business owns the data now often seems to be easily accepted, with some business users going as far as saying "of course we own the data!"

Acceptance! It's all easy from here, right? Maybe not. While there seems to be a lot more widespread agreement that business users own the data this doesn't always translate into the best outcomes for data governance and improved data quality. Statements from stakeholders along the lines of "we own the data, but IT let us down because they can't get the data quality right and they don't understand our data" ring alarm bells for me. That one step forward may just have been followed by two quick steps back. What's missing here is responsibility. Ownership without responsibility is hollow and reflects an understanding which still has quite some way to go to reach maturity. I liken this sort of statement to a father boasting about the achievements of his children before reaching for the phone to arrange a nanny to look after them whilst they are home from boarding school. Just like we can't expect school teachers and others to take sole responsibility for shaping our childrens' lives and helping them through their problem times, business users can not claim to be data owners and then take a passive role only getting involved in data issues long enough to point the finger of blame at IT.

So how can we this new phenomenon be dealt with? Sure, a part of what needs to be done is updating the message and tailoring the tools and communication methods we use to address this new position. But, it's more than that, as data governance professionals we need to look for ways of showing those in the business with this view "what's in it for them". We should look to find success stories - show where there was demonstrable benefit gained when another business user started to take an active interest in the health and well being of their data. Even better, we should spend time with those business users who have already embraced not just data ownership but data responsibility as well, helping to make them into champions for the cause and assisting them to sell the benefits to their colleagues. The broader IT function also has a role to play here. We need to ensure that IT doesn't reinforce the existing culture, and as such there needs to be a little gentle push back when the business shows signs of pushing all data responsibility to IT. This need not mean a flat out "no", nor an abdication of any and all responsibility, but rather taking these opportunities to engage with business users, working with them as enablers rather just than in isolation as technical troubleshooters blindly trying to solve problems often without enough context or knowledge. By working together - making changes on both sides - IT will boost data context familiarity and those on the business side will get involved more often and earlier. From a management perspective, look to change IT policies if they talk about IT owning and managing the data, and think about establishing data reference groups.

No matter what approaches we take, there is one very important thing that can not be forgotten. We must help business people in their new roles as data stewards. We can not leave them to feel their way along. Build documentation and tools to help and guide them, recognise new responsibilities by modifying Position Descriptions and the way these people are measured and rewarded for performance. Not only will this signal that the organisation is serious about data governance and data quality, but it will also guide and encourage the stewards to perform better.

Pragmatic Data Governance - It's a Matter of Trust.

This post had its genesis in a comment I wrote in response to a great piece about data governance written by Jim Harris (Twitter: @ocdqblog) over at Obsessive Compulsive Data Quality (http://www.ocdqblog.com/home/aristotle-data-governance-and-lead-rulers.html). I hope Jim won’t mind if I expand on those comments here. This post has grown organically and I'm not totally sure it captures all of the key issues bouncing around in my head, but getting it our there might help my thoughts develop and gel. So look out for a follow up post in the not too distant future.

Among other things Jim talks about the need for data governance to be applied with a degree of flexibility rather than following a set of rigid rules. This is a great perspective which exposes one of the key reasons why data governance initiatives often fail. In my opinion too often it seems that those involved (or those sponsoring) expect that hard and fast rules are what's needed.

I wonder how much of this stems from organisational cultures where staff time is closely budgeted and monitored. A common pushback I've struck in the past is managers of potential data stewards (almost) insisting on an exact breakdown of what data governance activities their people will be working on and how long each activity will take. Add to that the desire to help out new data stewards by providing them with tools to use as they learn what their new role involves and a situation where the rules and their strict application come to the fore can quickly emerge! The problem is compounded if the stewards feel that they may be blamed in some way if others are not happy with their choices or the downstream effects of them.

In my opinion, when setting up data governance programs we need to make sure that data stewards have top coverage – that is senior management endorsement and support when it matters- to give them time to act and the freedom to make considered and pragmatic choices that might involve bending or extending data governance “rules”. We must trust and allow the stewards to interpret rules according to the circumstances at hand whilst still being mindful of past precedent and any negative impacts their choices might have.

Without this support I’d question the value that a data governance program is going to deliver. Sure, maybe some cosmetic short-term data quality wins might occur, but chances are they’re the low hanging fruit and would probably have happened eventually anyway.  In the longer term all that is likely to happen is that the data stewards will come to be seen as blockers to progress - the holders and enforcers of a set of petty rules, putting up hoops for others to jump through. The hard issues (the ones likely to be standing in the way of unlocking real value) may never get tackled, the program will slowly wither and die as complaints mount against it and future data governance efforts will have a much harder time gaining any traction.

When a steward feels the need to build in a degree of butt covering into what he or she does there is a problem. If he or she can claim to have exactly followed the rules as a means of avoiding any blame storming about a bad situation that may have manifested from a data governance decision chances are the best outcome for the business isn’t going to manifest. We need to give data stewards the room to think, reason, weigh up the contributing points of view and then make the appropriate choice in the circumstances. A little trust in human nature and faith that people will want to do the right thing is required. If the organizational culture doesn’t support this then a successful data governance initiative might be possible, but it may mean that the data stewards need to sit higher in the food chain. But, ideally you can seek out and find stewards who already have the trust and respect of senior management and then will have the flexibility to act pragmatically when needed.