Tag Archives: data quality

Data Quality – The Inadvertent Oxymoron

 

It boggles my mind.

How can a unit/team/group have processes that either flat-out cause data quality problems or enable them by turning a blind eye, yet have budget and resources assigned to fixing up the mess after the fact? How can a phenomenon such as this occur? Is it because the organization is new at Data Quality and their idea of resolving it is to apply re-active fixes because they don’t know any better? I DON’T THINK SO!

I think they know better. I think they know better but they also know that resolving it will require Data Governance which means organizational change. Big Change. And discomfort. Big discomfort.

So here is my question then. How can our leaders, strategists, financial analysts and auditors present their budget figures for the year and get approval for this inadvertent Oxymoron of processes?

Just sayin…

Informal Data Governance?

Can data governance be informal? Is there such a thing? Doesn’t formalization make up a key (and critical) component of Governance? As in; formal roles and responsibilities, formal processes including escalation, formal decision bodies, formal communications, templates, etc etc..
 
Isn’t informal data governance not data governance at all, but a hugely expensive and time-consuming (and mind-numbing…don’t forget to add mind-numbing…) approach to getting people to buy in?
 
Just sayin….
 
What do you think?

The Data Governance Journey – Part 1- Getting Started

Our organization is finally (YAY!!) embarking on a Data Governance program and I’d like to share the saga journey with you. If you are unfamiliar with my story here are the basics:

  • Due to a CRM initiative there was an agreed upon corporate need for Data Quality
  • I was asked to lead the development of the program and establish the team
  • The business functional areas agreed that data quality was needed but were not in a position to sponsor or champion the initiative
  • The program and team had executive IT sponsorship
  • In 4 years the team established a solid program and raised considerable awareness, but due to lack of business sponsorship or a champion much of the work was re-active.

Now, due to a major data related initiative, the corporation has once again agreed that data quality is an issue that needs to be resolved in order for the initiative to be successful. But what’s different this time is that the agreement was formalized.

How we achieved this

A series of workshops were established where those who had agreed that data quality was a critical success factor for the corporate initiative were asked to attend. The workshops were a series of facilitated meetings where different stakeholders were asked to identify goals and objectives, roadblocks and risks and what are the things they felt would enable them to achieve their objectives. The outcomes that resulted were varied but what was obvious were the common themes around their data;  ‘accountability’, ‘establishment of formal policies and compliance processes’, ‘a senior cross functional decision body’, and ‘Training and Communication’, all components of a Data Governance Program. Success measures were also a part of the workshop and agreement was reached on those as well. The final workshop was used to confirm what was agreed upon, what the success measures were and recommended next steps.

Key Strategies

  • Use cross functional workshops to formalize the common themes stakeholders have already informally agreed upon.
  • External consultants help facilitate the process by using subject matter expertise to guide the alignment between business and IT.
  • Always be sure to identify agreed upon success measures.
  • Once agreement is achieved confirm, confirm, confirm the outcomes and next steps.
  • Document the outcomes, agreements, next steps and communicate to the organization.
  • Be sure to include the process to establish funding as a next step.

The Challenges

Most of the stakeholders that were needed to participate are mostly at the senior level and so their availability was a challenge.

What we did

  • Reinforcement of the verbal stakeholder agreements, the corporation’s business objectives and how quality data will help achieve those objectives really helped. Once the first workshop took place everyone was keen to continue and so it got easier to obtain their participation in later sessions.

That’s it so far….I imagine things may get a little more interesting as we get into the development of the program. 

Be sure and tune in for the next episode: Part 2 – Overcoming (the first set of) obstacles.

The role of a Business Analyst in the Management of Information

A new article showed up the other day on our organization’s internal wiki. The topic was ‘The Role of a Business Analyst (BA) in an Agile project’. The content of the article is just starting to be developed, so I took it as an opportunity to add a comment in the form of a question on “the role of a BA in the management of our information as an asset”. My goal was to generate some discussion around this idea, to see what others in the organization are doing/thinking, and to start the process to perhaps develop some formalized responsibilities in this area.

No sooner had I hit the save button when BAM, there was a response that showed interest in the topic and asked me to elaborate! Exactly the response I was hoping for! Muwah ha ha! You probably should know that the person who responded is a very good friend of mine who is quite comfortable with social collaboration and if it wasn’t for her I probably would be having a discussion with myself…ok it’s not really that bad but why is it that some colleagues have no problem updating their facebook status daily but when it comes to collaborating in a wiki they are running for the hills??  Sigh…subject for another day…

So what is the role of a BA in the management of our information as an asset? A  lot may depend on how your organization is organized, what the culture is, what types of resources you have ( maybe you have BA’s solely responsible for information management) and how mature your IM (information management) practices are. But let’s say for the sake of this opinion that you have a somewhat immature organization from an IM perspective, and you are just starting to organize Data Governance and MDM initiatives. This could mean that you are just starting to develop governing principles and operating policies around IM, and you may not yet have them ‘baked in’ to how you manage and deploy projects. Since some resources within an organization may not be familiar with some of the concepts, my approach will be to describe some of the key outcomes that result from not-so-good information management practices, and how a BA might help to resolve them, or ensure they don’t happen to begin with.

Multiple sources, conflicting rules and differing business uses of information

In order to resolve these types of issues you need to link the data to business objectives. This is standard stuff that I don’t often see. I’m not talking “here’s the data I need for this report”. That is not a business objective. The objective should describe the business decisions or triggers or changes that are the intended result.  e.g. This piece of information is used to determine what type of industry our customer is in so that we may ensure that the best person is assigned to them to help them with their needs. When the business objective is clearly linked to the data, it helps IT resources determine how to best architect the data, and business leaders with the information that they really need. It also helps in the resolution of conflicting rules. E.g. while one unit may use the information to identify the appropriate account manager, another business unit may use the information to identify the total amount of risk they have in that industry so that they can ensure they follow regulatory rules. You cannot resolve conflicting rules without having a good understanding of what the information is used for.

Lack of common understanding of what the data means

Ensuring the data has a clear and easy to understand definition and communicating it broadly reduces errors when data is created, transformed and reported on. Eg.  ‘Address’: describes the street location where the company physically resides. Although it looks somewhat self-explanatory, unless it’s clear and understood, what usually happens is you get all kinds of addresses: the mailing address, an email address [I kid you not], a city, etc..  You cannot assume that everyone has the same understanding of what a piece of data means.

There is a problem with the data but no-one seems to care

Identifying who will be responsible for business decisions on the data (and describing what that responsibility is) will ensure you don’t waste time when something needs to be resolved. This need not be a steward of the data as the organization may not be set up that way, but it could be a person or a role, and it should be written into the requirements that there is someone somewhere responsible for making business decision. E.g. The person (or role) responsible for making decisions regarding this data is XXXX. You may find that you are having difficulties getting someone to actually agree to having their name or role written down and being responsible. If this happens, don’t give them the data. Simple as that. No name, no game!

The data is in a mess (still….) and needs to be cleaned up!

Cleaned up to what? Including quality attributes as part of business requirements ensures that everyone understands how good the data needs to be and allows you to better manage  keeping it that way. E.g. The address information must be updated at least one per year to ensure freshness. It cannot contain phrases such as ‘unknown’ and special characters are not allowed. Using the quality requirements allow you to either perform an analysis of the data to understand how bad (or good) it is, and you can also provide the business with a weekly, monthly or yearly report on the quality, so that they can determine if it still meets their needs.

Here’s the summary of my opinion on how a BA can help in the management of our information as an asset

  • Link the data to business objectives
  • Ensure the data has a clear and easy to understand definition
  • Identify who (or what role) is responsible for business decisions regarding the data
  • Identify quality requirements for the data

This is by no means a comprehensive list, but it does go a long way to helping manage information as an asset. And it’s easy peasy stuff! The hard part…ahhh…the hard part.  Try telling someone a report is not really a goal and see what happens. Not really a good approach. The best way to go about it? Keep your rule/definition/goals antenna on at all times. Although it may seem hard to extract this information in a formal setting, most business stakeholders talk about this stuff all the time. In fact, that’s all they talk about! We just need to be really good at hearing it!

The role of a Business Analyst in an Agile Project while taking Information Management best practices into consideration (whew!)? That is a story that I hope we are beginning to work on!