The Rise of the Chief AI Officer: A Strategic Imperative for Data-Driven Leadership

 

As we stand on the precipice of a new digital dawn, the role of the Chief AI Officer (CAIO) emerges as a beacon of innovation. This role is not just another title in the executive suite; it is a clarion call for a transformative approach to leadership in the age of artificial intelligence. The CAIO is envisioned not as an isolated figure but as a unifying force, seamlessly integrating into the very core of an organisation’s strategy.

 

Hold on there! I didn’t write that, AI did. Sounds compelling though, doesn’t it? Either that or it sounds like the first paragraph of a novel in which our hero, CAIO, saves the day.

Image generated with AI, August 25 2024 at 6.19pm

I came across this article (The Changing C-Suite: Chief AI Officer In, Chief Diversity Officer Out (itprotoday.com)) which put forward different points of view about the potential for the emergence of a Chief AI Officer and where the role might fit within the broader C-Suite. It got me thinking and I dropped a few quick thoughts on LinkedIn.  Now that I’ve mulled some more and my friendly Co-Pilot has grabbed your attention with his (its?) prose, here’s a little more reflection…. (This bit actually written by a human!)

 

The corporate world is abuzz right now with the potential of artificial intelligence and the lure of its promise to redefine the boundaries of innovation and efficiency. But the success of AI, to my way of thinking at least, in many cases can’t be separated from the quality of the data that fuels it. Well-managed, accurate, trusted and understood data is the cornerstone upon which AI systems should be built. Without this critical foundation, AI projects are at risk of underperforming, leaving a chasm between the expected value and what’s actually delivered.

 

Beyond the Silo: The Collaborative Paradigm for Sustainable AI Integration

I’d suggest that if Chief AI Officers do appear as a mainstream role, the successful amongst them will be those who embraced (and were allowed to embrace) the multifaceted nature of the role. A leader who is solely focused on AI and what it can do for the organisation isn’t setup for success. He or she is potentially isolated from key enablers. At best, isolated in their own process, they lack the influence to attract the necessary consideration and support from others. At worst, they’re blind to the things that could erode the value AI brings or cause serious organisational harm springing from an unseen implication or missed consideration.  Without an holistic view of the organisation’s data and all its nuances, they may well find themselves at a disadvantage. This narrow focus can lead to a short-sighted approach chasing quick perceived value, but potentially overlooking the broader implications on risk and governance.

A siloed Chief AI Officer may find themselves navigating a labyrinthine path, fraught with challenges, short-lived victories, not to mention their own short tenure!

The sustainable integration of AI into business practices needs a leader who is not only doggedly chasing the value from AI but also has a deep understanding of the business landscape. The Chief AI Officer must not just be a collaborative master personally, but also build a culture of collaboration, working hand-in-hand with both line of business leaders and data leaders.  Anything else may well fail to ensure that AI initiatives are more than a momentary shining star.

 

Chief Data Officer: Sidekick or hero in this story?

The Chief Data Officer, already attuned to the intricacies of managing both defensive and offensive with regard to data assets, provides a complementary perspective to the Chief AI Officer. By joining forces, either as a single role or a collaborative partnership, the CAIO and CDO can create a synergistic relationship that uses AI for its transformative power and new ways to deliver value while also building upon and strengthening pre-existing data imperatives.

My view is that early integration is a good thing. Sure, find the box canyons and the gotchas the hard way. Innovate and potentially fail before trying again. But, wouldn’t things be easier with an ally to help point out the pitfalls ahead of time?

Balancing offensive gains with a defensive awareness and building from a solid base, gives our hero half a chance to move from just starring in a quickly forgotten short story to become the feature act across a box set of novels.

---

 

A Christmas Rant - Who Needs Data Quality in Marketing?

A few days before Christmas my family received a Christmas card in the mail from the real estate agent who handled the sale of the house we bought about 18 months ago. It read:

"Dear Scott, Louise and family, hope you are enjoying the big house. Thanks again and warm regards...."

No doubt it was part of a campaign to have us keep the agent top of mind next time we choose to sell a house, but a nice touch nonetheless. Or at least it would have been had my wife's name been Louise!

What's more the "big house" reference was odd as we had down-sized when we bought this house in order to get a property closer to the city. Something the agent should have known only too well as it had come up in conversation on a number of occasions.

Whilst I found the use of the wrong name a little amusing and the reference to the size of the house didn't bother me, my wife was less than happy. It's a safe bet that when we do choose to sell this house this agent will indeed be top of mind - as someone we will definitely not be using.

For less emotive reasons, I'd actually arrived at the same conclusion as my wife. When I sell a house I want the agent acting for me to employ numerous tools to ensure the fastest sale for the best possible price. One of the tools I expect him to use is a database of potential purchasers which he or she has compiled and curated over time. Now, if the agent in question is unable to get basic details right (such as the name of a purchaser and the size of houses they have lived in) then what faith can I have that any of the other details he has will be accurate. Chances are that all he has is a list of names and a collections of facts which may or may not be right. the marketing campaign he'll conduct on my property may well be targeted incorrectly, either missing an obvious potential buyer or having me waste funds marketing to those who have no interest in my property.

So, he's lost a potential future client. So what? Does that really matter, he hasn't really lost any money, has he? Well, I think he has. If you consider the standard fee for an agent (where I live at least) is 4.25% of the sale price and my house might sell for around half a million dollars then he'll actually miss out on the chance of around $21,000. What's more, if my wife tells 10 of her friends that number balloons out to close to a quarter of a million dollars. Sure, not all of those would have been in the market to sell, nor might he have been one of their considerations for a listing agent, but the point is that there is indeed a cost to what at first glance seems like an almost irrelevant data quality issue.

You don't need to work in real estate to be subject to cost stemming from data quality problems. I'm sure that something of the same ilk could happen in many industries. So next time you're faced with what seems like a data quality issue too trivial to worry about just remember John* and his lost income.

* Name changed to protect the not so innocent.

Data Migration: Low Hanging Fruit Can Be Bad For Your Health!

 If you’ve been through a few data migration exercises then you’ll probably recognise the scene.  You’re in the midst of a busy data migration, the pressure is on, there’s too much to do and too little time to do it in. You’ve been back and forward with the business users trying to resolve data quality issues that are preventing data from successfully loading in the new system. One, two, three, or more trial data loads have come and gone and still there are pieces of data which stubbornly refuse to play ball and load in to the new system.

With deadlines looming you start looking for ways to solve the problem, to migrate the data, to just get it in there. Or perhaps, even worse, those above you begin to apply the pressure for you to do the same. The questions / demands start to come. “Look for the low hanging fruit, what can you do to just make it work? Just get the data loaded!”

One common idea is that a whole parcel of load errors associated with free text fields can be easily and quickly solved by simply truncating the data to match the maximum allowable length of the fields in the target system.  Load the data in; produce an exception report for the text fields that were too long and were truncated and, hey presto, problem solved! You’ve got a bundle of errors out of the way and proved that the data can load. There’s now confidence that, come the next cutover trial or the real cutover and go live, that the migration in this area will be fine. Now it’s been done successfully once it can be repeated successfully and can only get better. After all the business users will get your exception report and immediately and diligently get to work on cleansing those fields which needed attention.

They will, won’t they? It’s not like they got anything else competing for their time. Their line manager doesn’t need them to do anything else. They’re ready and waiting to cleanse data for you as their top priority.

OK, wake up and head back over to the real world! Once (or if) they finish doing the day to day tasks of their own job, not to mention the tasks of those of their colleagues who have been seconded to that big project that is underway they may have time to add the data cleansing tasks to their to do lists, but I bet those tasks don’t get added to the top of the list.  If that data is going to get cleansed then you need to present a reason to prioritise its cleansing.  A hard failure is that reason, and a much more compelling and immediate reason than an exception report for data which (after all) has already loaded.  If the data doesn’t load then it needs to be cleansed if it is to be available I the new system.

Give the business all the help you can. Point out exactly and ambiguously what the problem is, show them exactly which field(s) in which record(s) need to be cleansed and what good looks like (i.e. what rules and conditions must be met before the data can migrate) and use data profiling tools to give them some indications ahead of the next trial load that the cleansing they are doing is effective and having the desired effect. But, don’t own their problem nor try to solve it for them in isolation. Most times, the business folds will know the data much better than the data migration folks. As soon as the data folks start making assumptions about what is safe to do with the data in the name of getting it to load, be it truncating text fields or some other technique, then the organisation takes on a long tail risk and liability in that the meaning of the data may have been lost or changed which may manifest in negative impacts to process or operations at some point post go-live. Bad for the organisation and bad for you as often times it is the data migration folks that will be perceived as having been the cause of the problem.

But, in the end, pragmatism must rule the day. Your data migration must run. There will be those (hopefully few) areas where you’ll just have to make some calls for the sake of allowing the data to get into the system at final cutover. If you don’t you’ll find your name quickly in the same sentence as the words “…we didn’t go live because of…” So go ahead, pick that low hanging fruit, but wait until you absolutely must, it still may be poisonous, but less immediately deadly than the alternative! 

Data as an Asset – Walk the Talk

Establishing data governance programs, data quality initiatives or other projects aimed at looking after or enhancing the well being of a company’s data can be difficult to get underway and sometimes even more challenging to keep alive.  Such initiatives (especially if your company’s funding approach forces you to tackle them as a series of individual projects) cannot always deliver the concrete and tangible “things” that you might get from a more traditional IT project. More often than not there is no new asset created, no new system to implement and enable across a go-live weekend, nor are benefits always obtained and measurable in the short term. Unless your business is facing real pain (and honestly attributes that pain to not just problems with the data itself, but also with how the data came to be in the state it is) then you may well struggle building support for, and keeping data initiatives running.

Often this seems surprising to data folks. It seems that this isn’t logical. The business says all of the right things about valuing data quality, about wanting a single source of truth from which to make better, faster and more cost effective decisions and maybe someone has even sprouted the “data as an asset” phrase, but this hasn’t resulted in them beating down the door with bags of money to fund data improvement initiatives. At first glance it seems key business stakeholders are showing moral support for the concepts but no commitment to the actions required to really solve the problems in the longer term.  They are the chicken to the data team’s pig.

But perhaps it’s not all that surprising. Are you, as a data leader, walking the walk or simply talking the talk? Do you treat your company’s data as an asset yourself? And does your data strategy reflect that? Do you even have a data strategy or are you one of the many, described by Joyce Norris-Montanari in her recent blog post  (http://www.dataroundtable.com/?p=12661), who fall into the group lacking a vision for their data and a strategy to help them get there?

If you’re not walking the talk then chances are that you’ll need some work up front to sell a congruent picture to the business, and particularly to those stakeholders holding the purse strings.   Make sure that you can show the basics around the company’s data that you would have around any other asset.

• Knowing what you have – an inventory of your data;
• Knowing where this data is – which systems house which data and (ideally) how it moves around between them;

• Knowing which stakeholders care about which data (you don’t need to get to business data ownership just yet, but at least you should know which data helps achieve, or threaten, which stakeholder’s bonus package);
• Knowing what preventive maintenance is required to keep your assets running at the required level and optimize the investment in them- some idea (and documentation) of where the problem areas lie. The big data quality issues (and importantly their real impact on the business);
• An understanding of how you can protect your asset – which may include classifications for data along with associated handling rules and other security aspects; and
• A vision for continuous improvement and a better future state of asset management – thought out and documented ideas for better use of your asset (which might include identifying and reducing redundancy, identifying inventory gaps or working better at the extreme ends of the asset life cycle).

With enough of the above in place you have your house in order and can say that you are indeed making efforts to treat data as you would any other asset. Now that you have a congruous story to present to the business you may find your next funding request is met more favourably. Even better, chances are you may well have identified a number of projects to deliver some concrete shorter-term benefits along the way as well.   

Dead Men Pay No Bills

There should be more data quality horror stories out there. No, really there should. When we data quality practitioners struggle to get stakeholder buy-in for our initiatives it's good to have a few in the kit bag to pull and illustrate the problems poor quality data can have. So, to that end, let me share a recent experience.

Mid-afternoon late last week my phone buzzed with the arrival of a new text message. It came from a number I didn't recognise: "Steven, we refer to our demand for payment of last week sent to your address in Midway Point. If this amount is not paid by Wednesday at 5PM legal action will be started. Please contact us on xxxxxxxx and quote reference number xxxxxxxx to arrange payment." My first thought was wrong number or phishing attempt. Either way I wasn't going to action the request. Odd though - my Father is Steven and he had a Midway Point address. Odder still in that he died almost 5 years ago.

Curiosity got the better of me. A phone call to the provided number revealed that it was in fact a debt supposedly owed by my Father to a local electricity retailer. That bill had been dealt with years before when the lawyers were wrapping up Dad's affairs, why was a debt collection service chasing payment now and why / how on earth were they chasing me?

This is squarely in brand damage territory. Not the stuff of front page headlines, but certainly fodder for those trashy tabloid "current affairs" TV shows, and certainly capable of causing some degree of negative sentiment, brand avoidance and customer churn. Putting the commercial implications aside, it also has potential for emotional distress. Five years since Dad's passing gave me the space need to see the absurdity of the situation, but I suspect a more recent death would cause unnecessary upset for the person receiving the payment demand.

Looking from the outside in I can only make educated guesses at what is likely to have happened to get to this point. Here goes:

1. I know the company replaced their customer care and billing system between Dad's death and the payment demand. I assume there was a data migration exercise at the same time. Could it be that some part of the data associated with Dad's account wasn't migrated successfully, or even attempted to be migrated at all? Perhaps only the structured transactional data was migrated and the non-structured data attached to the account, such as notes advising of his death, wasn't migrated, or lost its association during migration.

2. There has been a concerted push from the major shareholder of the utility to recover debts recently. What if some form of data matching had been applied in order to find my mobile phone number (previously not associated with Dad's account) and use it as another communications channel to attempt to recover the debt. Dad and I share the same first initial and last name, we have at various times in the last forty odd years shared the same address and we were born in the same month of the year. Did we somehow become fuzzily matched as the same person? I'm all for finding ways to get value from your data in new ways, but it's got to be based on solid foundations - if the data quality is not understood, acknowledged and good enough then the insights gained may well be flawed.

Who knows what really happened - I'm guessing as to the chain of events that transpired. But I am sure of one thing - this is one bill that won't be paid.

Why Data Quality is Like Shaving

Maintaining data quality is like shaving. That thought hit me early yesterday morning whilst I was doing it - shaving, that is, not maintaining data quality! Here's why.

A few things that most of us know about shaving and probably also know about data quality:

1. It's not much use if you just do it once. You've got to keep at it every day.
2. If you don't do it for a while you can still get back to a good state, it just might take a bit longer and be a bit uncomfortable for a while.
3. Sometimes there's blood!
4. Convincing someone who's never thought of data quality as important that they should do something about it is as hard as convincing someone who has had a beard for 20 years that they should shave it off.

And here are a few things that might not be quite so obvious about shaving (and about data quality undertakings):

1. If you don't do it most people won't notice nor care. But a few people who are really important to you might treat you differently and not give you what you want. Just ask my wife!
2. A little is good. Do a bit more and many people around you might look at you strangely but chances are the extra you did will pay you back many times over one day when you least expect it. Just ask a cyclist who has had to apply sticky bandages to his legs after a fall if it's easier with or without hair on his legs!
3. Doing it everywhere you possibly can is probably a wasted effort (and just a little bit creepy!) And if you must do it everywhere, then some areas will definitely need more caution during the exercise (refer to item 3 in the first list!)
4. The longer you've been around the more places you'll have to pay attention to. At 25 we all laughed at people with ear and nose hair, but it comes to us all in time. That data you've got hanging around from the time it was "faster" to work in spreadsheets will start showing eventually!
5. Shaving gives you the chance to take a good look at yourself in the mirror everyday, often without any of your imperfections covered up. Maintaining data quality calls for the same regular scrutiny and openness.

And here's the biggest thing most people will immediately accept about shaving and should accept about data quality too:

Chances are you're not going to ask someone from your internal hairdressing department to keep you clean-shaven. It will work far better if you take care of that yourself. Data quality's no different. It's your beard and it's your data!

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 Governance and the Self Licking Ice Cream

A friend and colleague regularly uses the self licking ice cream phrase to illustrate to the project management team he mentors that projects need to provide value to the enterprise and not just operate in a vacuum. No matter how well those in the project build a system, or how well that project is managed, it's unlikely to be perceived as a useful and successful exercise unless the various stakeholder groups agree that the work was needed and worthwhile. From their point of view all that the project will have achieved is keeping those on the project busy and employed for its duration.

But that can't be said for data governance, can it? Every organization has at least some data quality problems, conflicts around data ownership, data silos preventing leveraging the data asset across the business, so therefore every organization could benefit from a data governance program.

That may be true, but I'd still like to bet that many, if not most, data governance programs are seen by many in the organization as self licking ice creams. Ask an exec or senior manager from one of those firms and chances are they'll not see the value of the data governance initiative. If you're heading a data governance program and your execs don't recognise the need for it then, even if you think what you're doing is worthwhile, I've got bad news for you - to others you're licking your own ice cream! It won't matter if you've been making great advances in improving data quality, finally getting the data stewards to work together to understand master data issues, or building understanding across your data landscape and producing mountains of documentation along the way. From the outside you'll just be seen as doing little more than using scarce funds and making a call on their peoples' time for no other reason than to keep yourself in a job.

Of course securing an executive sponsor for the program and working to win wider executive awareness and buy-in will help avoid this scenario. However, this will be difficult to achieve and retain unless you continue to find ways to make your data governance work relevant and demonstrate value that can be seen by key stakeholders in the organization. For me, to do this it's critical to have demand placed on a data governance program. If people in the enterprise don't recognise they have data problems and aren't coming to you to help solve them, then you need to find something tangible for your program to tackle. If you're lucky enough to be facing upcoming system changes with associated data migration then that may be a great driver. If not, then try and find the areas where non trivial amounts of money can be saved due to data problems or look for the issues that keep your execs awake at night because they lack confidence in the data. If you believe that those situations can be helped through data governance then start to work on them, if not keep looking - trying to force them to be data governance issues won't do you much good.

If there's nothing in your organization that you can apply data governance to (and be seen to create value) right now then don't be afraid to let things lie for a while. Pushing ahead on things others don't perceive as valuable may actually torpedo the longer term success of a data governance program. Better to lie low and bide your time rather than have others shut the program (and perhaps your career prospects) down. But, keep your ear to the ground because there will come a time when there will be a big problem facing the organization which data governance could help solve. Be ready to seize the opportunity. If you don't and one of your execs later reads about data governance then being a self licking ice cream will be the least of your worries - you may fall victim to airline magazine syndrome!

Your Data Migration Project is Not a Data Quality Exercise

If I look back across all of the data migration exercises I’ve been involved with one aspect has come up during every single one of them – at some point someone involved with the project will try and seize the opportunity to use the migration as the means by which all past data quality sins will be dealt with and solved.  There was a time when I’d have embraced this idea and tried to incorporate it in to the project plan, on more than one occasion I may have even been the person advancing the idea.

But not any more. That was then, this is now. Looking back over some of the projects which struck problems, one recurring theme seems to have been a push for wide ranging data quality improvements as one of the key deliverables, either as a mid stream addition to, or change of, focus or a key aim from day one.  I’ve reached a conclusion – looking at it now it seems stupidly obvious, self evident if you like, but I suspect it may seen a tad controversial to more than a few people out there:

Data migration exercises are about migrating data. This should be the first and only aim. If you don’t get your data from the old to the new system then you have failed – it’s a simple as that. All of those forecast business benefits that rely upon having data migrated will be reduced, deferred or missed entirely. Don’t even think about using the migration to do anything else, data migration is hard enough without making a conscious choice to try and increase the complexity, cost, timeframe and risk. Don’t do it to yourself!!

I’d suggest only entertaining the concept of improving data quality when it can be shown that the new system can’t and won’t operate successfully with the level of quality of data currently available in the incumbent system. Then, and only then, look to incorporate data quality improvements, but keep them as light as possible. Only improve the data as much as is required to allow the new system to operate. This may seem counterintuitive, even perhaps bordering on delinquency of our duty as data professionals, but step back and look at the bigger picture, the interconnectivity of the data in (and across) systems. The changes you may make to improve a particular aspect of the data in one area may have unforeseen and impacts elsewhere. Sure, data profiling can go some way to help understand the impacts here, but do you really want to be following convoluted lineage trails just to be sure that no nasty surprise side effects crop up? Worse still, much improved data quality in one area of the system will soon be forgotten if whole other areas can’t even get the base data they need to operate due to migration woes.

Now, before all of you data quality folks delete my blog address from your favourites folder, let me reassure you that I’m not saying that we shouldn’t improve data quality. In fact I think that the arrival of a new system and the data migration project that comes with it is a great opportunity to push for funding to improve data quality. We just need to play the long game and look a little further ahead - designing projects to make specific data quality improvements before the data migration even begins. Start selling the benefits of improved data quality well ahead of the migration (months, if not a year or more) and angle the pitch in such a way as to show how these projects will reduce the risk of your company becoming the next data migration horror story headline with huge cost overruns, customer churn and brand damage.

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.