My colleague Max Gano, a data strategist, did advanced studies in Political Economies for Information Technology. No wonder, then, that he brings an interesting perspective to discussions about defining politically informed data strategies, data governance models, and data management plans. According to Gano, political economics can be considered a system of decision making about how to allocate scarce resources.
When I first heard this perspective, I had trouble meshing it with my view of politics associated with our national and state governments. I was focusing on politicians, power, deal-making, rhetoric, and career advancements. But then it clicked: these were manifestations of the overall system of decision making. And yes, decisions are constantly being made about scarce resources: where to spend money, where to send troops, how to allocate resources for social programs, where to focus the attention of our best and brightest minds, how to win the minds and votes of constituents. Yes, I concluded, when it comes to nations and states, politics is certainly concerned with decision making around scarce resources.
But what about politics regarding organizations and their information? Of course, we’re all aware of corporate politics. Some of us embrace the game; some of us try to avoid it. The question, I realized, is whether it is important to pay attention to politics if we’re working with strategies, governance, or information management. If so, what factors do we need to pay attention to? And is it possible to be politically savvy without getting caught up in unwanted games or struggles?
The answer to all these questions is “Yes!” Your ability to deliver an actionable strategy or plan will be influenced by politics, whether you want it to be or not. And so, you ought to understand that influence. And yes, there is a very simple tool you can employ to bring clarity to the situation in a way that is objective, agenda-agnostic, and appropriate to the work of managing an organization’s information assets.
This simple tool is a Decision Rights Matrix. We’ll look at an example, but first let’s look at how, where, and why to apply them. As an initial example, let’s consider a data governance program.
At its essence, every form of governance is concerned with making rules; implementing controls to enforce the rules, detect and deal with non-compliance, and resolve issues; and setting accountabilities for this work while providing appropriate support and protection to constituents.
With data governance, these rules take many forms: policies, standards, guidelines, canonical data definitions. approved calculations, source-of-truth designations, classification schemas, change control, valid-value sets, and rules about data access, usage, privacy, quality, integrity, and other criteria. Data-related controls can be preventative, detective, or corrective. They can be manual, automated, or a hybrid. They can be invoked as needed or embedded in systems or workflows. They can exist anywhere in a technology stack or a data environment. They can accomplish their control objectives without any assistance from other controls, or they can exist as part of an inter-related set of checks and balances.
Good governance involves appropriate pairing of rules and controls. Rules should inform controls, and controls should be designed to enforce rules.
Neither rules nor controls invent themselves. A series of decisions must be made about them. Some decisions address intent and the mechanics of the situation:
- What will they focus on?
- What are their objectives?
- What data stakeholders’ needs should be considered?
- How will success be measured?
- What constitutes “good enough” and what is optimal?
- How will conflicts be recognized and dealt with?
- How will we understand the impact of a change in rules or controls to an information/data ecosystem?
Likewise, decisions must be made about accountabilities for working with rules and controls over their life cycles. Which groups will:
- Propose them?
- Design them?
- Build them?
- Test them?
- Implement them?
- Monitor them?
- Support them?
In looking at decisions about accountabilities, economic implications become clear. What resources (funding, staff, leaders’ attention) are needed for these activities? Are these resources scarce?
For many non-routine data-related accountabilities, these resource are very scarce indeed. For instance, the more complicated our technical and data environments, the more likely that our best and brightest minds will be needed to help us understand impacts and implications. And the more siloed our business functions, the more likely that there will be disputes over who should pay for work, contribute resources, make changes to systems, be responsible for maintenance of controls, and be accountable for the quality of data.
This situation, by the way, is not limited to data governance decisions and accountabilities. It holds true for nearly any data-related set of accountabilities. For example, consider the following universally difficult decisions.
- Who should pay for data clean-up as part of a data migration?
- Who should pay for the cost of adding functionality to an operational system when it is not needed by operations but is needed for analytics?
- How do we balance the need to protect sensitive information with the benefits of information sharing?
- Who should be responsible for compliance controls embedded in function-spanning processes?
- How do we enforce data quality controls that have a negative impact on call center operations and metrics?
When faced with tough decisions that have significant impact on budgets, timelines, capabilities, and compliance, the next question assumes huge significance. “Who gets to decide HOW to decide?” Or, in the language of governance, what decision rights model will be applied to any given decision?
Now we are clearly in the arena of politics. Who gets to make a decision that involves scarce resources and will impact many stakeholders?
Some organizations spell out information-related decision rights quite explicitly as a matter of common practice. Others deal with most such decisions in an ad hoc fashion. In these latter cultures, only sometimes is it clear when a vote is needed versus a management decision. Only sometimes is thorough attention paid to identifying all impacted data stakeholders and giving them an appropriate voice in the decision. Only sometimes is consensus built around what constitutes a quorum, a valid vote, a decision that would survive a challenge.
If you are responsible for a data-related activity, function, department, or program, you probably have the power to introduce more formality to decision rights and decision making. Consider this approach:
- Develop a list of types of decisions that will have to be made.
- Enter related decisions as rows in a matrix.
- Add stakeholder names or roles as column heads.
- Populate the cells of the matrix with words or codes to designate decision rights.
D = decides.
C = consulted before a decision is finalized.
I = definitely informed of the decision, but possibly after a decision has been made. - Ask data stakeholders to review the matrix and provide input.
Following is an example of a Decision Rights Matrix I used in a class. Purposefully incomplete and controversial, it generated a lot of debate that turned into useful discussion.
The debate began around when a legal department should provide disclaimers for a report. It rapidly moved to whether an analyst or the business person requesting the report should be allowed to decide the formulas for calculations and the source of data when that data exists in multiple database tables. Half of the room insisted that the analyst should make this decision. The other half insisted that the report should meet the needs of its owner or requestor. The debate became heated.
Eventually, it became clear that those championing the analyst were assuming the report contained financial or compliance information that needed to roll up consistently into an enterprise view, and that the analyst understood those requirements and was prepared to meet them. The other group was assuming this was an ad hoc report containing operational data and metrics specific to the requestor’s domain. In an “aha!” moment, the class concluded that completely different decision rights models should inform these two categories of reports. Accepting that these models might vary from organization to organization, they suggested the following as starting points.
Some of the people in this class lead programs and departments; they expressed excitement that such a simple tool could help convert politically charged situations into black-and-white written agreements. As one said, “I’m going to put these in place before I need them. That way, I think I can help my staff avoid getting pulled into politics.”
But my favorite comment came in the hallway during a break. A woman whispered to me that she had been caught in the middle of a dispute that involved several people in the class. Evidently, one person (a project sponsor who represented Finance) had been advocating an architectural choice that would speed and simplify their own project. Another had been pointing out that this choice would negatively impact other groups’ ability to use data they needed.
The woman looked around, then quietly opened her notebook. “I’m considering showing the sponsor this sketch,” she said. “I thought I’d say that maybe I misunderstood their intent – surely they weren’t suggesting Option 1 or Option 2, were they?”
“What do you think?” she asked me. “Do you think this might change the conversation?”
I had to agree that it would, especially if her architecture group was subject to a policy that they HAD to notify stakeholders of architectural choices that would impact them. If this were the case, it would be clear that the project sponsor could either proactively involve stakeholders or have to react to them if they heard about these plans from someone else.
Of course, I did not counsel the class attendee to take this course of action. Instead, I reminded her that she knew better than I did about the politics of her organization and the wisdom of taking such a action, and that my counsel was to consider carefully the ramifications of her next move.
“Mmm… you’re right,” she said. “I should talk to my boss. But at least now I have a clear picture of the situation to share with her. Then she can deal with the politics, and tell me how to move forward.”
That single conversation demonstrated to me the power of using Decision Rights Matrices. After a week of heated discussions, discord and concern, this architect had a tool to capture options in a clear, unambiguous, auditable, and actionable format. This low-key person, who did not want to be embroiled in politics, could now easily escalate an issue (who can establish the decision rights model that would be used for establishing decision rights for an important data decision). She could let others work the politics of the situation, and she could ask that the results be captured in a Decision Rights Matrix that she could include in her project materials.
“Finally,” she said, “I might get some peace over this.” And that – I think – was a scarce resource for her.
Gwen Thomas is president of the Data Governance Institute and publisher of their website at www.datagovernance.com.