Jim Harris

My name is Jim Harris, I am the Blogger-in-Chief of OCDQ Blog, and an independent consultant, speaker, and freelance writer for hire.

My Services Contact Me
Search OCDQ Blog
Recent Comments
« The Data Encryption Keeper | Main | The Cloud Security Paradox »
Thursday
Oct202011

Data Governance and the Adjacent Possible

I am reading the book Where Good Ideas Come From by Steven Johnson, which examines recurring patterns in the history of innovation.  The first pattern Johnson writes about is called the Adjacent Possible, which is a term coined by Stuart Kauffman, and is described as “a kind of shadow future, hovering on the edges of the present state of things, a map of all the ways in which the present can reinvent itself.  Yet it is not an infinite space, or a totally open playing field.  The strange and beautiful truth about the adjacent possible is that its boundaries grow as you explore those boundaries.”

Exploring the adjacent possible is like exploring “a house that magically expands with each door you open.  You begin in a room with four doors, each leading to a new room that you haven’t visited yet.  Those four rooms are the adjacent possible.  But once you open any one of those doors and stroll into that room, three new doors appear, each leading to a brand-new room that you couldn’t have reached from your original starting point.  Keep opening new doors and eventually you’ll have built a palace.”

 

If it ain’t broke, bricolage it

“If it ain’t broke, don’t fix it” is a common defense of the status quo, which often encourages an environment that stifles innovation and the acceptance of new ideas.  The status quo is like staying in the same familiar and comfortable room and choosing to keep all four of its doors closed.

The change management efforts of data governance often don’t talk about opening one of those existing doors.  Instead they often broadcast the counter-productive message that “everything is so broken, we can’t fix it.”  We need to destroy our existing house and rebuild it from scratch with brand new rooms — and probably with one of those open floor plans without any doors.

Should it really be surprising when this approach to change management is so strongly resisted?

The term bricolage can be defined as making creative and resourceful use of whatever materials are at hand regardless of their original purpose, stringing old parts together to form something radically new, transforming the present into the near future.

“Good ideas are not conjured out of thin air,” explains Johnson, “they are built out of a collection of existing parts.”

The primary reason that the change management efforts of data governance are resisted is because they rely almost exclusively on negative methods—they emphasize broken business and technical processes, as well as bad data-related employee behaviors.

Although these problems exist and are the root cause of some of the organization’s failures, there are also unheralded processes and employees that prevented other problems from happening, which are the root cause of some of the organization’s successes.

It’s important to demonstrate that some data governance policies reflect existing best practices, which helps reduce resistance to change, and so a far more productive change management mantra for data governance is: “If it ain’t broke, bricolage it.”

 

Data Governance and the Adjacent Possible

As Johnson explains, “in our work lives, in our creative pursuits, in the organizations that employ us, in the communities we inhabit—in all these different environments, we are surrounded by potential new ways of breaking out of our standard routines.”

“The trick is to figure out ways to explore the edges of possibility that surround you.”

Most data governance maturity models describe 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.

Johnson suggests that “one way to think about the path of evolution is as a continual exploration of the adjacent possible.”

Perhaps we need to think about the path of data governance evolution as a continual exploration of the adjacent possible, as a never-ending journey which begins by opening that first door, building a palatial data governance program one room at a time.

 

Related Posts

“What is is the was of what shall be”

Datenvergnügen

Don’t Do Less Bad; Do Better Good

Delivering Data Happiness

Why isn’t our data quality worse?

Data Governance and the Buttered Cat Paradox

Beware the Data Governance Ides of March

Aristotle, Data Governance, and Lead Rulers

Data Governance Star Wars: Balancing Bureaucracy And Agility

OCDQ Radio - Data Governance Star Wars

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (2)

From the LinkedIn Group for the IAIDQ Information/Data Quality Professional Open Community, Paul Erb commented:

“I see it this way, too, Jim. Reading the thread on data migration, we can see that there's a trench between those who think adjacent means out of scope and those who think it means opportunity.”

And Wouter van Aerle commented:

“Excellent post, Jim. As you concluded in the final paragraph, data governance is much more of a continuous journey where the destination keeps changing, rather than a single effort like a project with a fixed goal. It takes leadership for an organization to recognize this.

Furthermore, what I read in your post as well, is that there's hardly ever a greenfield situation. Exceptions excluded, data governance initiatives (or any initiative / project / program for that matter) nearly always need to start from a current state and gradually improve from there. In my opinion, this is often underestimated in designing a data governance approach.”

And Paul Erb responded:

“Great leaders know that good stories make for better governance for an organization that needs to adapt and evolve, but stay true to its mission. Built from, but not about, real facts, good fictions are broadly true without being specifically true, and therefore they carry well to adjacent business processes where their truths can be applied to making improvements.

On the other hand, if it weren't for nonfiction--accounts of real markets and processes--there would be nothing for the "possible" to be adjacent TO.

Managers often have trouble with this because they feel called to manage the facts, and call anything else an airy-fairy waste of time. (See this short blog post on the matter: The difference between management and leadership).

So a data governance program needs to assert whether its purpose is to fix the status quo only, or to fix the status quo in order to create agility to move into new areas when needed. Each of these should have its own business case and related budgets and thresholds (tolerances) in the project plan.

And it needs to choose its sponsorship and data quality players accordingly.”

October 23, 2011 | Registered CommenterJim Harris

I like this thinking. Setting up formal data governance structures seems to consume an awful lot of effort and I think that for many organisations it is simply to big a leap from their current state.

For me it is about an evolutionary approach; eliminating bad practices whilst introducing better practices. By taking smaller steps it allows everyone involved to visualise the change, understand it, and accept it more easily.

Every step takes you in the right direction, in time it should be possible to build enough momentum to create a large scale movement for change. I think the problem that needs to be overcome with this approach is gaining acceptance and getting into people's priorities in the short term, because visibility within the organisation is going to be limited.

October 24, 2011 | Unregistered CommenterRoss Gourlay

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>