OCDQ Blog

I grew up and lived most of my life in the suburbs of Boston, Massachusetts.  But just prior to relocating to the Midwest for work seven years ago, I lived in Derry, New Hampshire, just down the road from the historic landmark where Robert Frost, the famous American poet who was also a four-time recipient of the Pulitzer Prize for Poetry, wrote many of his best poems, including the one shown to the left, The Road Not Taken, which has always remained one of my favorite poems—and also provides the inspiration for this blog post.

Historically, there have been only two “roads” diverged in the corporate world, two well-traveled ways: The Road of Business and The Road of Technology.

Although these two roads have a common starting point near the center of an organization, they will almost always extend away from each other, and in completely opposite directions, leaving most employees to choose which road they wish to travel—often without being sorry that they could not travel both.

I don’t believe that I am taking too much of a poetic license in describing this common calamity as how an organization is “a house divided against itself,” which to paraphrase Abraham Lincoln, cannot succeed.  I believe that no organization can succeed as half business and half technical.  But I also do not believe that any organization must become either all business or all technical.

There is a third option—there is a third road diverged in the corporate world.

Organizations struggle with the business/technical divided house because they believe the corporate world is comprised of technical workers delivering and maintaining the things that enable business workers to do their things.

And of course, there can be an almost Lincoln–Douglas debate about what exactly each of those things are because, in part, it is commonly perceived that they operate independently of one another—whereas the truth is that they are highly interdependent.

However, it’s no debate that organizations suffer from this perception of a deep divide separating the business side of the house, who usually own its data and understand its use in making critical daily business decisions, from the technical side of the house, who usually own and maintain its hardware and software infrastructure, which comprise its enterprise data architecture.

The success of all enterprise information initiatives is highly dependent upon enterprise-wide interdependence—aka collaboration.

Therefore, in order for success to be possible with data quality, data integration, master data management, data warehousing, business intelligence, data governance, etc., your organization needs to travel the third road diverged in the corporate world.

The Road of Collaboration is long and winding, a seemingly strange and unfamiliar road, quite distinct from the well-traveled, long, but straight and narrow, and somewhat easily foreseeable paths of The Road of Business and The Road of Technology.

Your organization must abandon the comforts of the familiar roads and embrace the discomfort of the unfamiliar road, the road that although less traveled by, definitely makes all the difference between whether your entire house will succeed or fail.

But if The Road of Collaboration does not yet exist within your organization, then you can not afford to settle for continuing to travel down whatever path you currently follow.  Instead, you must follow the trailblazing advice of Ralph Waldo Emerson:

“Do not go where the path may lead; go instead where there is no path and leave a trail.”

Neither trailblazing, nor taking the road less traveled by, will be an easy journey.  And there is no escaping the harsh reality that The Road of Collaboration will always be the path of the greatest resistance.

But which story do you want to be telling—and without a sigh—somewhere ages and ages hence?

Do you want to tell the story about how your organization continued to walk away from each other by traveling separately down The Road of Business and The Road of Technology—leaving The Road of Collaboration as The Road Not Taken?

Or do you want to tell the story about how your organization chose to walk together by traveling The Road of Collaboration?

Three roads diverged in the corporate world, and our organization—
Our organization took the one less traveled by,
And that has made all the difference.

Related Posts

Scrum Screwed Up

The Idea of Order in Data

Finding Data Quality

Data Transcendentalism

Declaration of Data Governance

The Prince of Data Governance

Jack Bauer and Enforcing Data Governance Policies

Podcast: Business Technology and Human-Speak

The Dumb and Dumber Guide to Data Quality

Not So Strange Case of Dr. Technology and Mr. Business

Have you ever experienced that sinking feeling, where you sense if you don’t find data quality, then data quality will find you?

In the spring of 2003, Pixar Animation Studios produced one of my all-time favorite Walt Disney Pictures—Finding Nemo. 

This blog post is an hommage to not only the film, but also to the critically important role into which data quality is cast within all of your enterprise information initiatives, including business intelligence, master data management, and data governance. 

I hope that you enjoy reading this blog post, but most important, I hope you always remember: “Data are friends, not food.”

 

Data Silos

“Mine!  Mine!  Mine!  Mine!  Mine!”

That’s the Data Silo Mantra—and it is also the bane of successful enterprise information management.  Many organizations persist on their reliance on vertical data silos, where each and every business unit acts as the custodian of their own private data—thereby maintaining their own version of the truth.

Impressive business growth can cause an organization to become a victim of its own success.  Significant collateral damage can be caused by this success, and most notably to the organization’s burgeoning information architecture.

Earlier in an organization’s history, it usually has fewer systems and easily manageable volumes of data, thereby making managing data quality and effectively delivering the critical information required to make informed business decisions everyday, a relatively easy task where technology can serve business needs well—especially when the business and its needs are small.

However, as the organization grows, it trades effectiveness for efficiency, prioritizing short-term tactics over long-term strategy, and by seeing power in the hoarding of data, not in the sharing of information, the organization chooses business unit autonomy over enterprise-wide collaboration—and without this collaboration, successful enterprise information management is impossible.

A data silo often merely represents a microcosm of an enterprise-wide problem—and this truth is neither convenient nor kind.

 

Data Profiling

“I see a light—I’m feeling good about my data . . . Good feeling’s gone—AHH!”

Although it’s not exactly a riddle wrapped in a mystery inside an enigma,  understanding your data is essential to using it effectively and improving its quality—to achieve these goals, there is simply no substitute for data analysis.

Data profiling can provide a reality check for the perceptions and assumptions you may have about the quality of your data.  A data profiling tool can help you by automating some of the grunt work needed to begin your analysis.

However, it is important to remember that the analysis itself can not be automated—you need to translate your analysis into the meaningful reports and questions that will facilitate more effective communication and help establish tangible business context.

Ultimately, I believe the goal of data profiling is not to find answers, but instead, to discover the right questions. 

Discovering the right questions requires talking with data’s best friends—its stewards, analysts, and subject matter experts.  These discussions are a critical prerequisite for determining data usage, standards, and the business relevant metrics for measuring and improving data quality.  Always remember that well performed data profiling is highly interactive and a very iterative process.

 

Defect Prevention

“You, Data-Dude, takin’ on the defects.
You’ve got serious data quality issues, dude.
Awesome.”

Even though it is impossible to truly prevent every problem before it happens, proactive defect prevention is a highly recommended data quality best practice because the more control enforced where data originates, the better the overall quality will be for enterprise information.

Although defect prevention is most commonly associated with business and technical process improvements, after identifying the burning root cause of your data defects, you may predictably need to apply some of the principles of behavioral data quality.

In other words, understanding the complex human dynamics often underlying data defects is necessary for developing far more effective tactics and strategies for implementing successful and sustainable data quality improvements.

 

Data Cleansing

“Just keep cleansing.  Just keep cleansing.
Just keep cleansing, cleansing, cleansing.
What do we do?  We cleanse, cleanse.”

That’s not the Data Cleansing Theme Song—but it can sometimes feel like it.  Especially whenever poor data quality negatively impacts decision-critical information, the organization may legitimately prioritize a reactive short-term response, where the only remediation will be fixing the immediate problems.

Balancing the demands of this data triage mentality with the best practice of implementing defect prevention wherever possible, will often create a very challenging situation for you to contend with on an almost daily basis.

Therefore, although comprehensive data remediation will require combining reactive and proactive approaches to data quality, you need to be willing and able to put data cleansing tools to good use whenever necessary.

 

Communication

“It’s like he’s trying to speak to me, I know it.
Look, you’re really cute, but I can’t understand what you’re saying.
Say that data quality thing again.”

I hear this kind of thing all the time (well, not the “you’re really cute” part).

Effective communication improves everyone’s understanding of data quality, establishes a tangible business context, and helps prioritize critical data issues. 

Keep in mind that communication is mostly about listening.  Also, be prepared to face “data denial” when data quality problems are discussed.  Most often, this is a natural self-defense mechanism for the people responsible for business processes, technology, and data—and because of the simple fact that nobody likes to feel blamed for causing or failing to fix the data quality problems.

The key to effective communication is clarity.  You should always make sure that all data quality concepts are clearly defined and in a language that everyone can understand.  I am not just talking about translating the techno-mumbojumbo, because even business-speak can sound more like business-babbling—and not just to the technical folks.

Additionally, don’t be afraid to ask questions or admit when you don’t know the answers.  Many costly mistakes can be made when people assume that others know (or pretend to know themselves) what key concepts and other terminology actually mean.

Never underestimate the potential negative impacts that the point of view paradox can have on communication.  For example, the perspectives of the business and technical stakeholders can often appear to be diametrically opposed.

Practicing effective communication requires shutting our mouth, opening our ears, and empathically listening to each other, instead of continuing to practice ineffective communication, where we merely take turns throwing word-darts at each other.

 

Collaboration

“Oh and one more thing:
When facing the daunting challenge of collaboration,
Work through it together, don't avoid it.
Come on, trust each other on this one.
Yes—trust—it’s what successful teams do.”

Most organizations suffer from a lack of collaboration, and as noted earlier, without true enterprise-wide collaboration, true success is impossible.

Beyond the data silo problem, the most common challenge for collaboration is the divide perceived to exist between the Business and IT, where the Business usually owns the data and understands its meaning and use in the day-to-day operation of the enterprise, and IT usually owns the hardware and software infrastructure of the enterprise’s technical architecture.

However, neither the Business nor IT alone has all of the necessary knowledge and resources required to truly be successful.  Data quality requires that the Business and IT forge an ongoing and iterative collaboration.

You must rally the team that will work together to improve the quality of your data.  A cross-disciplinary team will truly be necessary because data quality is neither a business issue nor a technical issue—it is both, truly making it an enterprise issue.

Executive sponsors, business and technical stakeholders, business analysts, data stewards, technology experts, and yes, even consultants and contractors—only when all of you are truly working together as a collaborative team, can the enterprise truly achieve great things, both tactically and strategically.

Successful enterprise information management is spelled E—A—C.

Of course, that stands for Enterprises—Always—Collaborate.  The EAC can be one seriously challenging place, dude.

You don’t know if you know what they know, or if they know what you know, but when you know, then they know, you know?

It’s like first you are all like “Whoa!” and they are all like “Whoaaa!” then you are like “Sweet!” and then they are like “Totally!”

This critical need for collaboration might seem rather obvious.  However, as all of the great philosophers have taught us, sometimes the hardest thing to learn is the least complicated.

Okay.  Squirt will now give you a rundown of the proper collaboration technique:

“Good afternoon. We’re gonna have a great collaboration today.
Okay, first crank a hard cutback as you hit the wall.
There’s a screaming bottom curve, so watch out.
Remember: rip it, roll it, and punch it.”

 

Finding Data Quality

As more and more organizations realize the critical importance of viewing data as a strategic corporate asset, data quality is becoming an increasingly prevalent topic of discussion.

However, and somewhat understandably, data quality is sometimes viewed as a small fish—albeit with a “lucky fin”—in a much larger pond.

In other words, data quality is often discussed only in its relation to enterprise information initiatives such as data integration, master data management, data warehousing, business intelligence, and data governance.

There is nothing wrong with this perspective, and as a data quality expert, I admit to my general tendency to see data quality in everything.  However, regardless of the perspective from which you begin your journey, I believe that eventually you will be Finding Data Quality wherever you look as well.

 

Follow OCDQ

If you enjoyed this blog post, then please subscribe to OCDQ via my RSS feed, my E-mail updates, or Google Reader.

You can also follow OCDQ on Twitter, fan the Facebook page for OCDQ, and connect with me on LinkedIn.

This Sunday is February 14—Valentine's Day—the annual celebration of enduring romance, where true love is publicly judged according to your willingness to purchase chocolate, roses, and extremely expensive jewelry, and privately judged in ways that nobody (and please, trust me when I say nobody) wants to see you post on Twitter, Facebook, Flickr, YouTube, or your blog.

Valentine's Day is for people in love to celebrate their love privately in whatever way works best for them.

Valentine's Day is not for data. 

However, when was the last time you showed your data how much you care?

Data needs love too.

 

Tainted Data

Sometimes, I am sure that you feel you've got to run away, you've got to get away from the pain that poor data quality has driven into the heart of your organization.

The data you share throughout the enterprise seems to have lost its light, for you toss and turn, you can't sleep at night.

Once you ran to data—you ran—now you run from data—this tainted data you've been given.

You feel you've given data all a person could give.  It's taken your tears and that's not nearly all.

Oh, tainted data—tainted data.

You really want IT (if you're with the Business) or the Business (if you're with IT) to make things right.

And you think data quality just needs a one-time cleansing project for someone else to play.

But I'm sorry, data quality doesn't play that way.

Don't ignore data, please. It cannot stand the way you tease.  Data loves you though you hurt it so.

Data doesn't want to pack its things and go.

 

It's not your data, it's you

The majority of data quality initiatives are reactive projects launched in the aftermath of an event when poor data quality negatively impacted decision-critical information.

Many of these projects end in failure.  Some fail because of lofty expectations or unmanaged scope creep.  Most fail because they are based on the flawed perspective that data quality problems can be permanently “fixed” by a one-time project as opposed to needing a sustained program.

Tactical initiatives will often have a necessarily narrow focus.  Reactive data quality projects are sometimes driven by a business triage for the most critical data problems requiring near-term prioritization that simply can't wait for the effects that would be caused by implementing a proactive strategic initiative (i.e., one that may have prevented the problems from happening).

Even when a reactive data quality project is successful, it's success will only be short-lived. 

Another project will be necessary when the organization is forced into triage once again during the next inevitable crisis where poor data quality negatively impacts decision-critical information.

One reactive project at a time will never do data quality right—because one is the loneliness number that you'll ever do.

 

Maybe you're just not that into your data?

Across the vast digital landscape of the Internet, I see you rolling your eyes because you know what's coming next—the talk.

That's right—it's time to talk about your relationship with data, about your need to take responsibility for data quality.

I see you hesitate.  After all, nobody has a data governance ring on their finger, do they?

Data governance establishes policies and procedures to align people throughout the organization.  Successful data quality initiatives require the Business and IT to forge an ongoing and iterative collaboration. 

Neither the Business nor IT alone has all of the necessary knowledge and resources required to achieve data quality success. 

The Business usually owns the data and understands its meaning and use in the day-to-day operation of the enterprise and IT usually owns the hardware and software infrastructure of the enterprise's technical architecture. 

The Business and IT must partner together to define the necessary data quality standards and processes.

But maybe you previously attempted a data governance program or other initiative requiring Business-IT collaboration.

Perhaps harsh words were spoken, promises were broken, old wounds were opened, and collaboration walked out that door. 

Are you too proud to make up?  Are you ready to break up?

Or maybe you're just not that into your data?

 

I don't know much

Look at your data, I know its poor quality is showing.  Look at your organization, you don't know where it's going. 

So many questions still left unanswered, so much that's never broken through. 

But the Business and IT were made for each other.  Just like Data Governance and Data Quality were made for each other.

Just like you and your data were made for each other.

I don't know much, but I know data needs love too.  And that may be all I need to know.

 

I had to say I Love Data Quality in a Blog Post

Well, I know it was kind of strange.  I hope it made some sense to you.  But what I had to say couldn't wait. 

I know you will understand.  Every time I tried to tell you, the words just came out wrong. 

So, I had to say I love data quality in a blog post.

Maybe every time the time was right for you to start your data governance program, all your words just came out wrong. 

Maybe you'll have to say you love data quality and you need a data governance program using this blog post?

Happy Valentine's Day to you and yours. 

Happy Data Governance and Data Quality to you and your data.

Related Posts

Data Quality is Sexy

In the past, I have explained various aspects of data quality using blog posts inspired by two primary sources of wisdom:

1. Literature

• Charles Dickens – A Tale of Two Q’s
• William Shakespeare – My Own Private Data, To Parse or Not To Parse, and Data Quality Whitepapers are Worthless
• T. H. White – The Once and Future Data Quality Expert
• Edgar Allan Poe – The Tell-Tale Data
• Robert Louis Stevenson – Not So Strange Case of Dr. Technology and Mr. Business
• Alexandre Dumas – The Three Musketeers of Data Quality
• Dante Alighieri – The Nine Circles of Data Quality Hell

2. Science (including Science Fiction)

• Isaac Newton (and Star Trek) – The Second Law of Data Quality
• Star Trek – Resistance is NOT Futile and Hailing Frequencies Open
• Albert Einstein (and Star Wars) – The General Theory of Data Quality and Beyond a “Single Version of the Truth”
• Erwin Schrödinger – Schrödinger's Data Quality  

 

However, in this blog post I want to channel the seldom tapped wisdom of Lloyd Christmas and Harry Dunne, from the Academy Award Eligible and American Cinema Classic – Dumb and Dumber.

 

The Dumb and Dumber Guide to Data Quality

“What the one doesn't have, the other is missing.”

Data and Quality—do they really need each other? 

The Business and IT—do they really need to work together?

Isn't data quality an IT issue?  After all, the data is stored in databases and applications that they manage.  Therefore, if there are problems with the data, then IT is responsible for cleaning up their own mess.  Aren't they?

Isn't data quality a Business issue?  After all, the data is created by business processes and users that they manage.  Therefore, if there are problems with the data, then the Business is responsible for cleaning up their own mess.  Aren't they?

Listening to the Business and IT argue like this reminds me of Lloyd and Harry playing the game of Tag:

Lloyd:  “You're it.”

Harry:  “You're it.”

Lloyd:  “You're it, quitsies!”

Harry:  “Anti-quitsies, you're it, quitsies, no anti-quitsies, no startsies!”

Lloyd:  “You can't do that!”

Harry:  “Can too!”

Lloyd:  “Cannot, stamp it!”

Harry:  “Can too, double stamp it, no erasies!”

Lloyd:  “Cannot, triple stamp, no erasies, touch blue make it true.”

Harry:  “No, you can't do that . . . You can't triple stamp a double stamp!  Lloyd!”

Lloyd [with hands over his ears]: “LA-LA LA-LA LA-LA!”

Harry:  “LLOYD! LLOYD! LLOYD!”  

Yes, the Business usually owns the data and understands its meaning and use in the day-to-day operation of the enterprise.  And yes, IT usually owns the hardware and software infrastructure of the enterprise's technical architecture.

However, neither the Business nor IT alone has all of the necessary knowledge and resources required to truly be successful.  Data quality requires that the Business and IT forge an ongoing and iterative collaboration.

Tag—you're both it!  And executive management says: No quitsies!

 

Not every theory looks good in a tuxedo

“Hey, look, The Monkees. They were a huge influence on The Beatles.” 

Without question, there are many theories available about how to properly execute a data quality initiative. 

You read about them in critically acclaimed books.  You hear about them in expert presentations at major industry conferences.  You even sometimes see them published in blog posts underneath pictures of two weird looking dudes wearing wacky tuxedos.

Most theories include models describing an organization's evolution through a series of stages intended to measure its capability and maturity, tendency toward being reactive or proactive, and inclination to be project-oriented or program-oriented. 

I am certainly an advocate of searching for sound theory and working with proven methodology. 

But the harsh reality is there is no “one theory to rule them all” or one-size-fits-all methodology—and anyone who tells you otherwise should be treated with the same disdain as those who truly believe The Monkees were a huge influence on The Beatles.

You need to find something that will adapt to your organization's unique culture.  Most important, you need to find something that will meet your organization wherever it happens to currently be within the capability and maturity model.

Just because some expert says you should be wearing a black Armani tuxedo with a crimson cummerbund and monogrammed cufflinks, doesn't mean you should.  Maybe the bright orange or powder blue tuxedo with the frilly shirt, top hat, and cane is more your style.  Or maybe it is the only thing currently in your size—or the only thing you can currently afford. 

Rock whatever tuxedo (theory) fits you best today.  Just remember—it's a rental.  As your organization and the individual change agents leading the way mature and evolve, your wardrobe (culture) will become ready to evolve right along with it.

Only you can decide what theory works best for your organization—as well as when you're ready to take it to the next level.

 

Not every practice can be considered best

“Well, it's not gonna do us any good sitting here whining about it. We're in a hole. We're just going to have to dig ourselves out.”

So you have selected a theory and now you're ready to get to work.  Every theory includes some recommended best practices.

However, if you are looking to follow a step-by-step, paint-by-numbers, only color inside the lines, fool-proof plan, then you are going to fail before you even begin.

Best practices simply provide a reference of recommended options of what proved successful for other data quality initiatives.

Best practices should be reviewed in order to determine what can be learned from them, as well as to select what you think will work in your environment and what simply won't.  However, it often won't be easy to tell the difference.

The key word in “best practice” is practice—and not best, as in the perfectly stupid phrase: “practice makes perfect.”

Real practice doesn't make perfect.  Real practice is messy.  Real practice colors with the red crayon much more often than with the green crayon.  Real practice doesn't color inside the lines—it draws on the walls.

In other words, you're going to make mistakes—lots and lots and lots—of mistakes.

And not because you are dumb—or dumber than others who successfully followed the same recommendations.

Not even best practices make perfect because nobody works at a company called Perfect, Incorporated.  Through trial and error you will figure out what works best for you and your organization, and those practices will become your best practices.

 

Couldn't we get by just fine without data quality?

“So you're telling me there's a chance...”

You may be thinking that a data quality initiative sounds like a lot of work.  You may be wondering if it is really worth the investment of all that time, effort, and money.  You may be asking if you really need a data quality initiative. 

Couldn't we get by just fine without data quality?

The following dialogue between Lloyd and Mary Swanson provides a better answer than anything else I can imagine:

Lloyd:  “What do you think the chances are of us getting by just fine without data quality?”

Mary:  “Well, Lloyd, that's difficult to say.  I mean, we don't really...”

Lloyd:  “Hit me with it!  Just give it to me straight!  What are the chances?”

Mary:  “Not good.”

Lloyd:  “You mean not good like one out of a hundred?”

Mary:  “I'd say more like one out of a million.”

Lloyd:  “So you're telling me there's a chance...”

Strange Case of Dr Jekyll and Mr Hyde was Robert Louis Stevenson's classic novella about the duality of human nature and the inner conflict of our personal sense of good and evil that can undermine our noblest intentions.  The novella exemplified this inner conflict using the self-destructive split-personality of Henry Jekyll and Edward Hyde.

The duality of data quality's nature can sometimes cause an organizational conflict between the Business and IT.  The complexity of a data quality project can sometimes work against your best intentions.  Knowledge about data, business processes and supporting technology are spread throughout the organization. 

Neither the Business nor IT alone has all of the necessary information required to achieve data quality success. 

As a data quality consultant, I am often asked to wear many hats – and not just because my balding head is distractingly shiny. 

I often play a hybrid role that helps facilitate the business and technical collaboration of the project team.

I refer to this hybrid role as using the split-personality of Dr. Technology and Mr. Business.

 

Dr. Technology

With relatively few exceptions, IT is usually the first group that I meet with when I begin an engagement with a new client.  However, this doesn't mean that IT is more important than the Business.  Consultants are commonly brought on board after the initial business requirements have been drafted and the data quality tool has been selected.  Meeting with IT first is especially common if one of my tasks is to help install and configure the data quality tool.

When I meet with IT, I use my Dr. Technology personality.  IT needs to know that I am there to share my extensive experience and best practices from successful data quality projects to help them implement a well architected technical solution.  I ask about data quality solutions that have been attempted previously, how well they were received by the Business, and if they are still in use.  I ask if IT has any issues with or concerns about the data quality tool that was selected.

I review the initial business requirements with IT to make sure I understand any specific technical challenges such as data access, server capacity, security protocols, scheduled maintenance and after-hours support.  I freely “geek out” in techno-babble.  I debate whether Farscape or Battlestar Galactica was the best science fiction series in television history.  I verify the favorite snack foods of the data architects, DBAs, and server administrators since whenever I need a relational database table created or more temporary disk space allocated, I know the required currency will often be Mountain Dew and Doritos.

 

Mr. Business

When I meet with the Business for the first time, I do so without my IT entourage and I use my Mr. Business personality.  The Business needs to know that I am there to help customize a technical solution to their specific business needs.  I ask them to share their knowledge in their natural language using business terminology.  Regardless of my experience with other companies in their industry, every organization and their data is unique.  No assumptions should be made by any of us.

I review the initial requirements with the Business to make sure I understand who owns the data and how it is used to support the day-to-day operation of each business unit and initiative.  I ask if the requirements were defined before or after the selection of the data quality tool.  Knowing how the data quality tool works can sometimes cause a “framing effect” where requirements are defined in terms of tool functionality, framing them as a technical problem instead of a business problem.  All data quality tools provide viable solutions driven by impressive technology.  Therefore, the focus should always be on stating the problem and solution criteria in business terms.

 

Dr. Technology and Mr. Business Must Work Together

As the cross-functional project team starts working together, my Dr. Technology and Mr. Business personalities converge to help clarify communication by providing bi-directional translation, mentoring, documentation, training and knowledge transfer.  I can help interpret business requirements and functional specifications, help explain business and technical challenges, and help maintain an ongoing dialogue between the Business and IT. 

I can also help each group save face by playing the important role of Designated Asker of Stupid Questions – one of those intangible skills you can't find anywhere on my resume.

As the project progresses, the communication and teamwork between the Business and IT will become more and more natural and I will become less and less necessary – one of my most important success criteria.

 

Success is Not So Strange

When the Business and IT forges an ongoing collaborative partnership throughout the entire project, success is not so strange.

In fact, your data quality project can be the beginning of a beautiful friendship between the Business and IT. 

Everyone on the project team can develop a healthy split-personality. 

IT can use their Mr. Business (or Ms. Business) personality to help them understand the intricacies of business processes. 

The Business can use their Dr. Technology personality to help them “get their geek on.”

 

Data quality success is all about shiny happy people holding hands – and what's so strange about that?

 

Related Posts

The Three Musketeers of Data Quality

Data Quality is People!

You're So Vain, You Probably Think Data Quality Is About You

 

Additional Resources

From the Data Quality Pro forum, read the discussion: Data Quality is not an IT issue

From the blog Inside the Biz with Jill Dyché, read her posts:

• Dear IT: A Letter from Your Business Users
• A Letter to Our Users, From Your BI Team

From Paul Erb's blog Comedy of the Commons, read his post: I Don't Know Much About Data, but I Know What I Like

People, process and technology.  All three are necessary for success on your data quality project.  By far, the most important of the three is people.  However, who exactly are some of the most important people on your data quality project? 

Or to phrase the question in a much more entertaining way...

 

Who are The Three Musketeers of Data Quality?

1. Athos, the Executive Sponsor - Provides the mandate for the Business and IT to forge an ongoing and iterative collaboration throughout the entire project.  You might not see him roaming the halls or sitting in on most of the meetings.  However, Athos provides oversight and arbitrates any issues of organization politics.  Without an executive sponsor, a data quality project can not get very far and can easily lose momentum or focus.  Perhaps most importantly, Athos is also usually the source of the project's funding.

 

2. Porthos, the Project Manager - Facilitates the strategic and tactical collaboration of the project team.  Knowledge about data, business processes and supporting technology are spread throughout your organization.  Neither the Business nor IT alone has all of the necessary information required to achieve data quality success.  Porthos coordinates discussions with all of the stakeholders.  Business users are able to share their knowledge in their natural language and IT users are able to “geek out” in techno-babble.  Porthos clarifies communication by providing bi-directional translation.  He interprets end user business requirements, explains technical challenges and maintains an ongoing dialogue between the Business and IT.  Yes, Porthos is also responsible for the project plan.  But he realizes that project management is more about providing leadership. 

 

3. Aramis, the Subject Matter Expert - Provides detailed knowledge about specific data subject areas and business processes.  Aramis reviews the reports from the data quality assessments and provides feedback based on his understanding of how the data is actually being used.  He helps identify the data most valuable to the business.  Aramis will often be an excellent source for undocumented business rules and can quickly clarify seemingly complex issues based on his data-centric point of view.

 

Alexandre Dumas fans will recall the novel's plucky primary protagonist was an outsider who became the Fourth Musketeer and yes, data quality has one too:

 

4. D'Artagnan, the Data Quality Consultant - Provides extensive experience and best practices from successful data quality implementations.  Most commonly, d'Artagnan is a certified expert with the data quality tool you have selected.  D'Artagnan's goal is to help you customize a technical solution to your specific business needs.  Unlike the Dumas character, your d'Artagnan usually doesn't accept the Musketeer commission at the end of the project.  Therefore, his primary responsibility is to make himself obsolete as quickly as possible by providing mentoring, documentation, training and knowledge transfer. 

 

Your data quality project will typically have more than one person (and obviously not just men) playing each of these classic roles although you may use different job titles.  Additionally, there will be many other important people on your project playing many other key roles, such as data architect, business analyst, application developer and system tester - to name just a few. 

Data quality truly takes a team effort.  Remember that you are all in this together.

So if anyone asks you who is the most important person on your project, then just respond with the Musketeer Motto:

"All for Data Quality, Data Quality for All"

“Abandon all hope, ye who enter here.” 

In Dante’s Inferno, these words are inscribed above the entrance into hell.  The Roman poet Virgil was Dante’s guide through its nine circles, each an allegory for unrepentant sins beyond forgiveness.

The Very Model of a Modern DQ General will be your guide on this journey through nine of the most common mistakes that can doom your data quality project:

 

1. Thinking data quality is an IT issue (or a business issue) - Data quality is not an IT issue.  Data quality is also not a business issue.  Data quality is everyone's issue.  Successful data quality projects are driven by an executive management mandate for the business and IT to forge an ongoing and iterative collaboration throughout the entire project.  The business usually owns the data and understands its meaning and use in the day to day operation of the enterprise and must partner with IT in defining the necessary data quality standards and processes.

• This common mistake was the theme of my post: You're So Vain, You Probably Think Data Quality Is About You.

 

2. Waiting for poor data quality to affect you - Data quality projects are often launched in the aftermath of an event when poor data quality negatively impacted decision-critical enterprise information.  Some examples include a customer service nightmare, a regulatory compliance failure or a financial reporting scandal.  Whatever the triggering event, a common response is data quality suddenly becomes prioritized as a critical issue.

• This common mistake was the theme of my post: Hyperactive Data Quality.

 

3. Believing technology alone is the solution - Although incredible advancements continue, technology alone cannot provide the solution.  Data quality requires a holistic approach involving people, process and technology.  Your project can only be successful when people take on the challenge united by collaboration, guided by an effective methodology, and of course, implemented with amazing technology.

• This common mistake was the theme of my post: There are no Magic Beans for Data Quality.

 

4. Listening only to the expert - An expert can be an invaluable member of the data quality project team.  However, sometimes an expert can dominate the decision making process.  The expert's perspective needs to be combined with the diversity of the entire project team in order for success to be possible.

• This common mistake was the theme of my post: A Portrait of the Data Quality Expert as a Young Idiot.

 

5. Losing focus on the data - The complexity of your data quality project can sometimes work against your best intentions.  It is easy to get pulled into the mechanics of documenting the business requirements and functional specifications and then charging ahead with application development.  Once the project achieves some momentum, it can take on a life of its own and the focus becomes more and more about making progress against the tasks in the project plan, and less and less on the project's actual goal, which is to improve the quality of your data.

• This common mistake was the theme of my post: Data Gazers.

 

6. Chasing perfection - An obsessive-compulsive quest to find and fix every data quality problem is a laudable pursuit but ultimately a self-defeating cause.  Data quality problems can be very insidious and even the best data quality process will still produce exceptions.  Although this is easy to accept in theory, it is notoriously difficult to accept in practice.  Do not let the pursuit of perfection undermine your data quality project.

• This common mistake was the theme of my post: The Data Quality Goldilocks Zone.

 

7. Viewing your data quality assessment as a one-time event - Your data quality project should begin with a data quality assessment to assist with aligning perception with reality and to get the project off to a good start by providing a clear direction and a working definition of success.  However, the data quality assessment is not a one-time event that ends when development begins.  You should perform iterative data quality assessments throughout the entire development lifecycle.

• This common mistake was the theme of my post: Schrödinger's Data Quality.

 

8. Forgetting about the people - People, process and technology.  All three are necessary for success on your data quality project.  However, I have found that the easiest one to forget about (and by far the most important of the three) is people.

• This common mistake was the theme of my post: Data Quality is People!

 

9. Assuming if you build it, data quality will come - There are many important considerations when planning a data quality project.  One of the most important is to realize that data quality problems cannot be permanently “fixed" by implementing a one-time "solution" that doesn't require ongoing improvements.

• This common mistake was the theme of my post: Are You Afraid Of Your Data Quality Solution?

 

Knowing these common mistakes is no guarantee that your data quality project couldn't still find itself lost in a dark wood.

However, knowledge could help you realize when you have strayed from the right road and light a path to find your way back.

 

New York City, 2022 - Technical Architect Robert Thorn and Business Analyst Sol Roth have been called in by Business Director Harry Harrison and IT Director Tab Fielding to investigate an unsolved series of anomalies that have been plaguing the company's Dystopian Automated Transactional Analysis (DATA) system.

 

Harry Harrison (Business Director):

“Thank you for coming on such short notice.  We hope that you will be able to help us with our DATA problems.”

Robert Thorn (Technical Architect): 

“You're welcome.”

Sol Roth (Business Analyst): 

“I am sure that we can help.  Can you provide us with an overview of the situation?”

Harry Harrison (Business Director): 

“We hired quality expert William Simonson from Soylent Consulting to fix our DATA problems.”

Robert Thorn (Technical Architect): 

“Soylent Consulting?  Never heard of them.”

Sol Roth (Business Analyst): 

“They are the professional services division of Green, Incorporated.”

Harry Harrison (Business Director): 

“Yes, that's right - the High-Energy, Environmentally-Minded Corporation”

Tab Fielding (IT Director): 

“More like the High-Rate, Weak-Minded Corporation, if you ask me.”

Harry Harrison (Business Director): 

“Well anyway, Mr. Simonson first met with me to receive the business requirements.”

Sol Roth (Business Analyst): 

“Receive?  You mean he was handed the completed business requirements document?”

Harry Harrison (Business Director): 

“Yes, of course.”

Sol Roth (Business Analyst): 

“So...he didn't meet directly with anyone on the business team?”

Harry Harrison (Business Director): 

“No, I write the business requirements document so that meeting with the business team is unnecessary.”

Sol Roth (Business Analyst): 

“O...K...then what happened?”

Tab Fielding (IT Director): 

“Mr. Simonson met with me to receive the functional specifications.”

Robert Thorn (Technical Architect): 

“Receive?  So...did you write the functional specifications?”

Tab Fielding (IT Director): 

“Yes, I write the functional specifications after reading Mr. Harrison's business requirements document.”

Robert Thorn (Technical Architect): 

“Reading?  So...you didn't even meet directly with Mr. Harrison?”

Tab Fielding (IT Director): 

“No, before today's meeting, I haven't even seen him or anyone from the business team in months.”

Robert Thorn (Technical Architect): 

“O...K...then what happened?”

Tab Fielding (IT Director): 

“Mr. Simonson spent a few months coding, implemented our solution, then told us he was ‘going home.’”

Harry Harrison (Business Director): 

“And now our DATA is worse than ever!”

Sol Roth (Business Analyst): 

“And both of you are wondering how it came to this?”

Harry Harrison (Business Director) and Tab Fielding (IT Director): 

“Yes!”

Robert Thorn (Technical Architect): 

“I'll tell you how.  Because you both forgot the most important aspect of DATA.”

Tab Fielding (IT Director): 

“What are you talking about?”

Robert Thorn (Technical Architect): 

“It's people.  Data's Quality is made by People.  You've gotta tell them.  You've gotta tell them!”

Harry Harrison (Business Director): 

“I promise, Thorn.  I promise.  We will tell executive management.”

Robert Thorn (Technical Architect): 

“You tell everybody.  Listen to me, both of you!  You've gotta tell everybody that Data Quality is People!”