Search This Blog

Sunday, June 20, 2010

Principle Before Practice

Before I begin, a caution. Do NOT think that I am taking a negative position re: data governance. On the contrary, I firmly believe that the concept is essential. But what is the concept?

As I watch data governance related position descriptions parade by on DICE.com, MONSTER.com, etc., I am struck by the focus on the practice of data governance. They are all about tools and skills and methods and all either assume that everyone knows what the goals are or (worse yet) that goals for this company are the same as those for every other company.

I have learned at least one thing in my 27 year adventure in all things data-related and that is that doing something, no matter how efficiently or effectively, is very often a wasted effort without some forethought about the principles that we are attempting to implement.

Principles provide the glue that links all of our efforts together and the medium that allows us to be productive even when our last effort was a failure.

As with so many initiatives around data, this wave (governance) has crested and achieved the status of "best practice" without ever achieving measurable ROI. We have seen smaller-scale successes--enough to keep hopes high--but not, to date, the enterprise wide success that was used to sell the initiative in the first place.

But maybe I'm getting ahead of myself. What is the principle that data governance represents? Some candidates are:

  • Make life easier for DBA's by reducing the rate of database schema changes
  • Make life easier for developers (programmers) by making requirements less ambiguous
  • Reduce cost due to rework by making the rules for data quality and completeness more accessible at the point of capture
  • Make the data warehouse more useful by applying the same rules to data everywhere it is captured.
  • Reduce the number of sales lost because we can't keep track of our customers
  • Establish process consistency so that we can begin improvement efforts
  • Stop those sobs from delivering junk and expecting me to fix it
  • Define and establish (standard) processes to reduce variability in output quality
  • your favorite here

Which one(s) do you like? I believe the answer is all of the above and then some. What is the principle that unifies all of these goals? I discussed this in a broader context in a prior post. My point though is that if we don't have a firm and commonly held idea of the principle(s) we are attempting to implement, then no matter what we do, which tools we use, or how skilled the workers are, we aren't going to accomplish anything meaningful. To put it another way, "If you don't know where you're going, any route will do."

Wednesday, May 26, 2010

What Do You Do When Things Aren't Working The Way You'd Hoped?

Let's pick a context first because a) this problem is pervasive in the world I live in (how about you?) and b) the context will determine our course of action. I'll use my own life as an example.

I have spent my life seeking to understand my environment so that I could have a chance of staying out of hot water by being able to predict outcomes. I actually got pretty good at the predicting part but was never able to translate that into the staying out of hot water part. It turns out that when you see a result coming that is unwelcome to everyone, hot water is the least of your worries.

Of course I could have kept quiet and just let things happen but the problem with that is that almost invariably a minor course change would have prevented the outcome. It always seemed reasonable to attempt that minor change. Just as invariably there were political implications involved in any changes to the published plan. Bottom line: my career is littered with "you were right's" that came three years after I moved on.

So. if you would learn anything from my example, maybe it would be that "being right" carries no value. Maybe it's that you should just keep your head down and wait for the seniority promotion of for retirement. Maybe the lesson is that you do what you can and the rest belongs to someone else.

I will say that over time I have achieved objectives that others considered "impossible" because I was willing to take risks. The problem there of course if that if the objective was considered unachievable then no one is prepared when the find themselves standing inside the walls.

I think that this is also the story of data management (to include what has come to be known as data governance). Organizations have been talking about data management for nearly thirty years now and there are hundreds if not thousand of experts who will tell you exactly what you should to enjoy the benefits of good data management practice. What none of them will tell you because a) you don't want to hear it and b) you wouldn't hire them is that there is no proven methodology--no set of practices and tools, skills and technology--that will guarantee results.

Why should this be? You would think that in 30 years someone would have stumbled across something that will deliver predictable results. The answer lies in the subject matter. "Data" is a concept understood by everyone. Everyone in the boardroom has their favorite data. The issue at the root of all problems is that "everyone" is seeing data "as through a glass, darkly."

The inability to communicate about data and reach a consensus is what is keeping us from our objective. To this add the cult of personality that defines the management--let's call it governance--of the corporation. The decision makers understand nothing of the underwater portion of the data iceberg, seeing only the table, graph or dashboard that's in front of them. What must be managed is the abstraction that is data and not the values that are only the visible portion. When we try to do anything with the abstract, we find that there are side effects on the visible portion that cause VIP personalities to convulsively respond in exactly the least useful way.

You can get useful results if your objective is modest. For example, it is possible to get two business functions who are exchanging data or three or more that have a symbiotic relationship based on data to take consensus action to stop what is often a great deal of daily pain. The intractability is encountered when we attempt to broaden the scope to cross departmental or divisional boundaries. The goals and methods of data management are counterintuitive to those raised in the power politics of corporate "success."

We usually find ourselves managing data as a commodity, "how much", "how many", "what is the cost", "who produces", "who consumes", "spoilage rate", "how fast"... While these all have an attraction in that the answers can be easily captured in one of those tables, graphs, dashboards, none deal with the underlying problem of managing the abstraction. Data is the most complex thing that a corporation attempts to manage. It is more complext even than money.

The pity is that we treat data as if putting it into a "piggy bank" solves all our problems. You heard it here first:
  • Technology is no answer--technology can help us sort different kinds of values into different piggy banks, no more.
  • Technical skills (modeling, DBA, quality...) are no answer. The cashier makes use of such skills to keep his/her drawer in order and reconciled.
  • People skills by themselves can't achieve any result except perhaps building meaningless consensus.

This is enough clues. If you call, don't bother to tell me what DBMS or CRP system or BI tools you're using. None of those things are of interest until the final stages of a solution. I don't expect any calls because too much credibility is wrapped up in the current initiative--whatever it is. When it fails to produce results, a new personality will step in and you'll start the cycle anew. Someone, someday may actually be willing to take a risk to stop the pain. I'll be retired or deceased by that time but maybe you'll have learned from this what you should be searching for.

Thursday, April 29, 2010

Data Quality: Getting Started

If you happen to be a "mover and shaker" or if you aspire to that role, then you'll be looking for access to one or more key decision makers of influencers closest to the top of your organization. You'll be determined to convince those people that
  1. investing in data quality is a sound business decision
  2. you are the right person to produce the ROI that they'll be looking for

If, however, you simply want to make things better as soon as possible and create new friends and allies while doing so, then you may want to take a different approach.

My recommendation is to use the tactics of the Special Forces. The "Green Berets" were formed into small teams comprising skills critical to the people they were trying to help. They then went out to those people and lived with them. Doing this allowed them to gain credibility and to learn what kinds of changes might (or might not) be acceptable.

The Green Berets helped the people with their work and, while doing so, offered improvements--small changes that produced higher productivity or more consistent results. The goal was to create allies.

"Data Quality" represents exactly the same kind of productivity and/or consistency improvement for our "indigenous" people in whatever part of the company they may serve. A DQ Team may be as small as one member and can produce results that are shocking in their scope and value as well as in their lack of cost. It isn't necessary to spend long periods of time "living" with the people. In fact, one lunch or a couple of coffee breaks will do IF you

  1. ask the right questions
  2. listen carefully to the responses
  3. offer support
  4. follow through

You'll ask about what happens when they get incomplete or incorrect forms (data is usually thought of collectively as a form) from their internal "customer". You'll ask about the extra work they have to do in such situations. Be prepared for an emotional response, this is what causes them to miss deadlines, work overtime, add staff... Also be prepared to hear that they simply pass the problems on because they aren't staffed to deal with them and don't feel accountable for fixing problems they didn't create.

Listening will uncover the sources of the most frequent or egregious DQ errors. Now you can mention that you are about to begin a project with those dirty so-and-so's, that it's likely they don't even know the hardships they're creating, and that you'll be happy to mediate a discussion amongst the parties to try to find a resolution. You may already have some ideas.

Create the meeting, making sure that ALL parties are represented (you were listening carefully, right?) and facillitate the discussion, if necessary gently guiding the discussion but never offering solutions. When the solution is "discovered", the people will own it and will implement it with minimal assistance from you. If your assistance is required, make certain that you deliver and do not hold them up.

Follow up by monitoring, coaching, facillitating and then ask if they'd like some help in publicizing their success. Because you know important people, they'll almostly certainly jump at this opportunity. You give them all the credit and they'll make sure to let everyone know that your help was both timely and critical.

This approach works and can even result in regular meetings to follow the improvement and to look for new opprtunities.

Two approaches--you choose which one has the highest probability of success for the greatest number of people in the shortest time at the lowest cost.

Monday, March 29, 2010

The Theory of Everything

The US economy, so far as the majority of citizens is concerned, is in the toilet and swirling rapidly in a clockwise direction. Health Care, long in its own toilet, has at least stopped swirling momentarily. All of us have a stake in what happens in those toilets.

I have a stake in another toilet as well. The portion of the economy devoted to technology has been caught in a vortex since the dot com implosion 15 years ago. I realize it will do no good to link all of these since linkage simply makes the resulting mess seem even more impervious to any corrective action.

However, (deep breath) if we don't consider the nature of the connection between them, we have very little chance of making sustainable progress in any of them. So, as my contribution to posterity, I nominate the accension of appearance to the pinnacle of importance in decision making as the criterion most likely to be acknowledged as the root cause of all three problems.

Since 1950 the rate at which appeareances have displaced substance as the motivation for decisions in the US has increased at a dizzying rate. In the past two years I have seen the nations physicians, as represented by a blue ribbon panel from the Mayo Clinic, state that the answer to the nation's health care woes is better access to insurance. The calling that was Medicine has emerged as a new entitlement program for the elite.

In the economy, fiduciary responsibility has been replaced by revenue numbers as the force that justifies all decisions.

In the Technology world, the means have come to justify the ends. Any decision can be justified if it allows me to position myself as a front-runner, new, hip, cool. "There's an app for that" allows us to spend unjustifiable amounts of money just to have that app in our pocket. Similary, corporations spend unconscionable sums on technology projects for which the need is poorly understood. Because the "solution" has to be new to give the proper appearance of tech supremacy, the outcome is always in doubt. Risk isn't so much managed as PR-ed. Spin control is the name of the game.

In almost 30 years of working with technology I have learned one lesson that transcends all others:
Either control your technology or it will control you.
In assessing the meaning of this for your own situation it is well to remember that
  • Technology demands consistency
  • Humans and human organizations are incapable of consistency

Just a few recommendations

  • Be clear about WHY you want to do something
  • Insist that others are clear about WHY they want to do something
  • Choose a path that is known to produce the desired result--or at least choose next steps that are known to produce appropriate results.
  • If you are unable or unwilling to do the above, choose another line of work if possible and stop complaining if not.

We are all either a part of the solution or a part of the problem. In either event, complaining about what someone else is doing or not doing will produce absolutely no change.

If you can't tell the difference between substantive value and the appearance of value you should avoid positions in which you will be called upon to make decisions. If you can tell the difference, then for all our sakes, make the decision and don't give it to someone else.

Tuesday, December 15, 2009

Christmas Wish List

The 13+ years I have spent in Healthcare have sensitized me to some things. I might have preferred to remain ignorant of many of them. In the spirit of Christmas, which is handy at this time of year, I'd like to nominate a list of gifts that would bless all residents and citizens of the U.S.A., regardless of theology or philosophy. Each item in the list relates to health care.
  1. I wish that the role of technology could be clearly understood. There are a vast number of well-funded voices who want us to think that technology is health care or that health care is technology. In reality, technology is best thought of as a tool--an inert and often expensive piece of equipment, which, in the right hands, can produce wonderful results.
  2. "The Patient" or "our patients" is not the same as "my patient" or "Josie Jones, patient". It may not be possible to apply technology designed for delivering care to a generic patient to Ms Jones. That doesn't mean that the technology is bad. It only means that the technology must allow for deviation in procedure. I wish that the role of abstraction is system design could be clearly understood.
  3. I wish that all of the factions in the healthcare struggles were clear about their goals--with themselves and with each other. Only by being self-aware, open and open-minded can the parties negotiate a solution advantageous to all. Doctors, nurses, administrators, vendors, government and patients are currently at odds. The friction is not only between factions but within factions. Who will speak for physicians? The A.M.A.? Mayo Clinic? Who? Who speaks for government, for vendors, for patients, for nurses, for administrators? Each of these groups functions like a mob--surging to and fro as a strong voice emerges and then is drowned out. Each group must organize itself before "healthcare" can be organized.
  4. Though I recognize that individuals and groups may be driven by ego to appear more knowledgeable than the next, I most devoutly wish that each of us might recognize that the person across the table might actually have some knowledge that we don't. I wish that we would listen first and assert only when necessary. I wish that we could see ourselves as occupying the same driverless bus.

There are many more things I might wish for this year but I don't want to seem greedy. May you each be showered with blessing upon blessing as one of God's beloved and may we fully appreciate each blessing as it comes.

Tuesday, December 8, 2009

Principles of Data Governance

Malcolm Chisolm, in a recent column in Information Management (A Principles-Based Approach to Data Governance) raises an excellent point. In 2006, when I attended my first Data Governance Conference, there was much discussion around a definition of DG. Implicit in this discussion was the need for something that was concise, yet comprehensive, and on top of that, engaging. The idea was that this definition could be used:

  • As part of a sales pitch (like a slogan)
  • To create synergy within the emerging discipline
  • To provide focus for any ongoing methodology efforts

Some present may have had additional motivations, but I think these were the ones on most people’s minds.

The definition that emerged was acknowledged to be a work in progress. By the 2008 Conference, one of the tutorials quoted three definitions:

  1. Data Governance refers to the organizational bodies, rules, decision rights and accountabilities of people and information systems as they perform information-related processes.

  2. Data Governance is the practice of organizing and implementing policies, procedures and standards for the effective use of an organization’s structured/unstructured information assets.

  3. Data Governance: The execution and enforcement of authority over the management of data assets and the performance of data functions.

These were troublesome to me then, probably for the very reason that Malcolm mentions. All seem to acknowledge a context based on an organization’s information assets, but their focus seems to be quite different. The feeling I have is that they are advocating a judicial, legislative and executive approach to governance.

In the U.S., a Constitution lays out these three perspectives and establishes the mechanics (framework, architecture) within which governance will be administered. Within the Constitution and before any of the mechanical parts are discussed, in fact, within the preamble, first principles are asserted. The writers tell us that what follows will be a system of governance for the purpose of

  • Forming a more perfect union

  • Establishing justice

  • Insuring domestic tranquility

  • Providing for the common defense

  • Promoting the general welfare

  • Securing the blessings of liberty to ourselves and our posterity

While this model would probably work on its own in establishing [data] governance, there are just a couple of nuances that will have to be accommodated because our system will not be working in a representative democracy but in a corporation.

Within the context of our system, leaders are appointed and serve at the pleasure of stockholders rather than the public. The principle of one-man-one-vote does not apply. One person may control sufficient votes to dictate to the Board of Directors. Within the day to day operations, the ability to dictate policy, direct activities and appoint deputies is granted at multiple levels, though always subject to the pleasure of the higher levels.

Having now established a context, it’s time to agree on some first principles for data governance. The candidates are:

  • The entire corporation must agree to be subject to the system.
    While those placed higher may still, at their pleasure, appoint and dismiss deputies, they must agree that [data] governance operations will be a factor in those actions.

  • It must be understood that within the corporation, domestic tranquility, the common defense and the general welfare are all dependent upon the information assets owned and managed by the corporation.
    When the system is followed, all processes will flow smoothly, problems are addressed at the process level, personal antipathies are secondary to process execution and process anomalies such as unplanned rework and delays are greatly reduced in number or even eliminated completely.

  • Consistency is everyone’s goal.
    In a work context, surprises are almost always seen as negatives. Our goal must be to improve the consistency of our processes and their outputs such that surprises become exceedingly rare (six sigma has been suggested as a goal) and predictability becomes commonplace.

These principles should be the touchstone(s) of our efforts. Everything we do should be evaluated on the degree to which these principles are addressed.

I will suggest that these may also be the principles of the corporate Quality Assurance effort and remind everyone that they are also the basis of Deming’s 14 points as well as other quality improvement methods. No improvement is possible without first establishing a stable (consistent) process.

I leave you with one final principle: Data governance will not be implemented as a stand-alone initiative. If we cannot see data governance as part of a larger, comprehensive system of governance, we will not be able to address any of the three principles suggested above.

Friday, December 4, 2009

Survival, Error & Technology

I'm going to pass on some wisdom here. It's not very often that we encounter wisdom today, especially where technology is concerned, and it's often the case that we don't recognize or acknowledge wisdom until we're looking back over the wreckage and trying to figure out what we should have done. I'm probably also setting myself up by labeling this as wisdom but I am so weary of seeing the same ads with different acronyms and talking to the same people with different names.

You will never find your way out of the current mess you're in or about to be in by searching for and hiring someone with recent experience on a specific product. To put it another way, a specific product, no matter how much buzz it enjoys, is never the answer.

I will be among the first to acknowledge that the use of absolute language (never, always...) and even the use of unqualified superlatives (best, worst, fastest...) is a habit to be avoided, nevertheless, decades of experience have proven that the absolute statements in the preceding paragraph represent wisdom and that failure to heed this wisdom will produce cost overruns, timeline disasters, confusion, stress, employee turnover and a host of other undesirable outcomes.

In large part, the success of the human race has been due to our ability to recognize exceptions without necessarily understanding the rule. My own take on this is that, with today's reliance on technology, we may have reached the point where the process of natural selection that has honed this skill over countless generations has now produced a liability. "Something's different," is enough to put us on guard and may be enough to launch a complex defensive reaction to preserve the safety of the individual or group.

First of all, while it is still good to recognize exceptions, it is now absolutely essential (that's an absolute absolute) that we develop the ability to recognize the underlying rule. A study of human error (Human Error, Set Phasers on Stun...) shows that leaping to conclusions about the rule is what produces the error condition. In fact, if we can't describe the rule in terms of the logic of the computer (if... then... else...), we can't rely on technology at all.

You might ask, as I did, how we might acquire this ability. The time tested way is known as [survivable] experience. There are a host of cause-and-effect analysis tools and techniques that have the appearance of rigor and reliability and are an improvement over experience, especially when combined with exhaustive testing, but you will find that even these are more productive when used by people with experience in the world being analyzed.

Tools are great and another critical human enabler, but--and this can't be over-emphasized--no tool is so advanced that it runs itself. Every tool, no matter how advanced the technology requires human hands and a human mind to guide it. If you were to be presented with the greatest woodworking tool in the world or the most advanced sewing machine or fishing gear or computer, would you immediately become a master cabinetmaker or designer or fisherman or software developer? You might note that the only immediate change is one of expectation.

An experienced person with rudimentary tools is more likely to produce a quality result than the inexperienced person using the "best" tools. The fact that I used a tool just yesterday says nothing whatsoever about the level of my experience in producing the required outcome. I have made the mistake of looking for help and focusing too narrowly on what amounts to recent experience with the tools in my shop. I have learned (through experience) that I will enjoy better results if I'm learning while interviewing my prospective employee. If I'm talking with someone whose knowledge stops at the tool's user interface, then I had better be prepared to devote myself to directing the employee's work. If I have a staff composed of such employees, then I need to possess all of the requisite experience myself or else be prepared to conduct a project whose principle product is more experienced workers.

The challenge is to find the right mix of experienced people in supervisory or team lead roles and people who possess dexterity but are in need of experience. If I'm in a director or management role, I have to have experience producing a product with that scope. A technology "system" has a complexity that is beyond human comprehension. The only way to design and build it is through a process of identifying smaller and simpler pieces, building those and then assembling them into the final product. You need to look for people who have an appreciation for the amount of effort this takes and the discipline--both personal and organizational--that it takes.

Stop looking for Oracle or CRM or Rational or even "use case" or "data model" experience except as clues about the approach that the candidate might be expected to take. I understand that these things are ideal as targets for a logic rule processor, but the rule ("find resumes that include these terms") is so simple-minded as to be useless. If your only goal is to turn 1000 resumes into 100, then proceed, but if your goal is to find someone who can get you out of the predicament you're in, then you should spend more time on your rules so that the exceptions are more productive.