by Charles Roe
This is Part 2 of the article “Governing with Real Power: Developing Win-Win Relationships in Data Governance.” The article is a report on Len Silverston’s Enterprise Data World 2011 Conference presentation of the same name. The first part of this report began with an introduction that discussed a primary issue that often immobilizes the success of many Data Governance projects: human dynamics. According to Mr. Silverston, there are six inevitable scenarios that can, and often will, occur during a given project. The ability for the primary stakeholders involved to stop those scenarios from happening, or fix them if they already have happened is a key to the success of the project.
In Part 1, the first three scenarios were discussed, along with the first three principles that can be employed as solutions for fixing them:
1. Scenario 1: Data “Mine”ing.
A. Principle 1: Don’t React – Observe
2. Scenario 2: I am Right!
B. Principle 2: Disarm – Step to the Other Side
3. Scenario 3: Enterprise versus Project
C. Principle 3: Make it Easy to Say Yes – Build a Golden Bridge
Each of the scenarios and principles were discussed in terms of a specific example, or multiple examples and some tools were provided on how the issues can be overcome. Part 2 of this report will cover the next three scenarios and principles, then conclude with some final thoughts to help data governance professionals move forward with their projects to successful ends.
4. Scenario 4: Trouble Getting Buy-in
Anyone who ever tries to get an enterprise-wide project going eventually hears “yea, yea, another enterprise-wide effort, good luck with that” from some top level executive that has to sign off on it. Getting buy-in is no easy task and it requires a skill that is not usually added to the job descriptions of Data Governance positions: sales associate. Data Governance, at least for those who have to get the buy in, is a sales job. Any good sales person knows that the bottom line of selling something is to understand the motivations of the buyer – whether they are the CEO or Eskimos buying refrigerators. In the Zachmann Framework of Enterprise Architecture there are six columns and six rows; the columns are: Data (what), Function (how), Network (where), People (who), Time (when), Motivation (why). But, time and again the final column is the least understood and not modeled. There are models for everything else, but in most organization how often are the motivations modeled? Not very much and yet they are so important; they are the human dynamic of the entire equation.
D. Principle 4: Understand Motivations
The most important motivation to understand is our own. It is not possible to understand someone else’s motivation, to have true clarity in a situation if we don’t know what we want and why we want it first. Were an organization to model Zachmann’s sixth column in a Motivation Model then certain questions would be central: Who is this person? What is their role in the organization or project? What does this person want? How will this (your) project help them? How is this project/program an obstacle to them?
Use those questions to create a model of each stakeholder, tie them together and a much broader understanding of the entire motivational map of the project’s human dynamic will be gained. Such clarity will allow for a real understanding of each person’s motivations regarding the project and how best to move forward. All people are motivated by something, whether it is control, security, differentiation or approval. There is a key driver to what pushes them and understanding that driver or drivers will aid in understanding how to work with them and achieve collaboration. In the end, the primary driver for most people is service, or a desire to be useful in the workplace. Thus, the salesman with the contact list wants to feel like he has control of his data, wants to know his data is secure, wants people to know why his data is so good, wants to be commended for such data and in the end wants to be known for helping the enterprise because of his many years of hard work collecting that data. Know this and he will buy in to the entire process, as will anyone else.
5. Scenario 5: What’s the Value?
Why does the enterprise care about this project? The project’s team has built many lovely, color-coded models, data governance diagrams, organizational charts, policies and procedures with lots of technical terminology, but what is the value to the enterprise? It does not do any good if the genius of the vision cannot be explained in ways that everyone will understand. Data Governance is the management of data as a corporate asset – those six words are perhaps the most important a Data Governance project team can ever have. But, what does that mean? And how is that concept going to affect the bottom line? The business side of the equation must know and it takes vision to show them.
E. Principle 5: Have a Clear, Compelling, Common Vision
These three Cs are of crucial importance. The vision must be clear so that everyone understands why it is important. During presentations to the business side remove the technical terminology to stop confusion. What exactly is the particular Data Governance project going to do for the enterprise? Make the answer compelling: “Data Governance provides rock solid information that the enterprise can count on.” Or in other words, “this project will give the organization data that will not get us in legal trouble, will provide solid reporting metrics and in the end not hurt our bottom line – it is the right data, at the right time to help with the right decisions.” Show why it’s clear and compelling, and then bring it all together into a common vision. The Data Governance project is part of the enterprise’s movement into the future, not the other way around – their missions are the same. Sell the value and the project will move forward successfully.
6. Scenario 6: Politics!
Graphic Six demonstrates the principle problem of Scenario 6 – the issue of cordial hypocrisy versus honest assessment. It will not help anyone if a top level executive or their people are saying they support the Data Governance project, when in fact they have their fingers crossed behind their back; that is cordial hypocrisy. Trust is necessary from all sides, but if there is a lack of trust coming from the top down, then it must be built from the bottom up.
F. Principle 6: Integration Requires Trust (IRT)
Data management people love acronyms and this one is important: IRT. In situations where there is a lack of communication and lack of trust, there are usually four possible ways to deal with the situation:
- Blame somebody else
- Fix the issue then communicate about it
- Communicate about the issue then fix it
The first two will certainly not help build trust. The third is often employed, but in the end can cause people to wonder why they weren’t informed about the issue at the beginning. The best way to build trust and start to get through the political quagmire is to use open communication and honest assessment of a situation. Get everyone on the same page and then work on fixing it. For example, if all the shipping operations go down in a company at the same time, what happens? First, people start losing control since they cannot do their jobs, emails go out and data governance eventually gets involved since it is their databases that seem to have stopped. Eventually, in a perfect world, one employee stands up and says, “I’m sorry, I thought I was working on the development database.” The entire shipping database was taken down because of a mistake. Instead of his resigning, or being blamed after-the-fact, the best possible conclusion to stop politics from derailing everything, is for that database engineer to send out apologies to everyone, then fix the issue; problem solved.
The keys to trust are earning it, caring about others and vulnerability or openness. A situation like that outlined above is only one possible instance in the entire universe of politics for a project. But, in that situation the correct way forward was to accept responsibility, communicate the problem properly and resolve the issue. The employee in question acted properly and earned the trust of those around him. The project could move forward, data governance did not become a scapegoat for whispers around the coffee machine and trust was built from the bottom up.
Conclusion – You Can’t Fix Everything at Once
Applying these techniques to any project is important, but difficult (if not impossible) to apply all of them at the same time. These inevitable scenarios are not going to happen during every project, but knowledge of them and preparation for their possibility is a first step in understanding how to stop them before they happen or relieve them if they do or already have happened. Clear communication that is built upon trust, respect and openness is a crucial aspect of all of these elements; create that within an enterprise and a given project, and the rest of the pieces will fall in place much easier. If a program is beset with more than one of these scenarios, do not try to fix them all at once, that will only cause more disruption and in the end nothing will be corrected. Assess what is the most important problem to work on, resolve that and move forward with the rest of them.
For more information on this topic, there are some free articles from Len Silverston on the subject at his website http://www.universaldatamodels.com.
“Data Integration Requires Trust” http://www.univdata.com/Publications/Articles/DataIntegrationRequiresTrust/tabid/264/Default.aspx
Data “Mining” Versus Data “Ours”ing