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
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:
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
