Search This Blog

Friday, March 27, 2009

The Beginning (5)

In order to get where we want to be (business intelligence) and have the characteristics we are looking for, we will have to make an alliance with our systems vendors.

Our vendors are grown accustomed to thinking of themselves as "partners" and now it's time to call their bluff. We have learned that the long term success of our business depends on the quality of the information that it possesses. Without reliable information, the most efficient and productive process will fall immediately into non-productive and costly tachycardia. Tachycardia is the disorder in which the heart's productive rhythm is disrupted and it's consistent, productive beat turns into an erratic, non-productive, and potentially life-threatening arrhythmia.

How can our partners help us deal with this? They must be responsive to questions about data models, semantics and relationships. They must show evidence that their internal consistency is at least as good as ours. You may want to audit their process consistency. Companies that have achieved the Malcolm Baldridge Quality Award have suppliers who allowed themselves to become this kind of partner.

You will have a robust Quality Assurance capability and you will want them to be linked with a similar capability in the suppliers' organizations. Quality Assurance has been alluded to in previous posts and the QA involvement is data quality should not be minimized.
Quality Processes Produce Quality Data
Processes that are uncontrolled or out of control are incapable of producing reliable data--whether they are in your organization or in a supplier's organization.

Next time we'll address Management specifically.

Wednesday, March 25, 2009

The Beginning (4)

In my experience, those who can do the least about data quality feel most responsible, while those who have quality literally at their fingertips feel no responsibility whatsoever. This creates many difficulties for one who wants business intelligence.

I'm going to collect receptionists, customer support, sales, anybody who enters data into any of your computer information systems under the heading of "the business." We could also include those who collect or transcribe data to/from paper if it eventually winds up in a computer-accessible data file.

Maybe we have done too good a job in convincing the people seated at computer keyboards that they have nothing to fear. In any event, many simply do not pay adequate attention to what they are doing. There are many reasons for this including:
  • heavy work volumes causing a pace that is too fast for error recognition or for going back to correct errors
  • inadequate training
  • inadequate guidance built into the user interface
  • inattention/distraction

On the other hand, I have encountered way too many instances in which people were actually aware that they were producing garbage but didn't care enough to do anything about it. Sometimes it's sabotaging the people in the next department. Sometimes it's a statement to the supervisor and sometimes it's "so what."

It is true that some data can be repaired after the fact, but the sad fact is that "cleansing" can never be 100% effective and in some applications cleansing isn't even possible--if it isn't captured correctly the first time, there's no going back. Repairing bad data is very expensive for your business. Experts estimate that, for anyone who receives data as part of their work process, from 30-60% of their work day is spent in rechecking or validating or repairing the data so that they can do their job.

The data architect will have worked with the folks to understand their data needs so if we can prove that they have participated in that process and that the architects and developers have complied with their defined processes, then what we are left with is attitude or training as problem sources. These are issues for management to resolve.

One final area for the business to think about: there is a need to include problem recognition in training and provide safe reporting paths for those who do take note and take action. Those at the front line typically have little awareness of the business that they front-end for. They don't know that someone cares or that someone can actually do something to fix a problem that they struggle with on a daily basis.

You will want to include a module on the data resource in the New Employee Orientation. You'll want to take remediation to department meetings to catch all who missed the new employee offering. It must be simple to report a problem and there can be no "grilling" of callers by the support line triage staff. Take the call and send someone to see the problem in person while the reporting employee works. Use a remote desktop capability to watch the problem happen. There are many options, but if the caller is made somehow to feel guilty or foolish or ignorant, they will never call again.

Next time we'll take on the vendors.

Tuesday, March 24, 2009

The Beginning (3)

Before we explore the data architect role in terms of our overall goal, I should say that I do not intend to go into depth for any of the roles. I mentioned the need for standard processes but didn't specify any of the necessary processes. For one thing, that level of detail is well beyond the scope of this (or any) blog. For another, the processes and standards must be compatible with the organizational culture. I wouldn't go so far as to say that any path will do, but I will say that, if you live in Minneapolis, there is more than one way to get to Miami. The thing to remember is that there are more constraints as you depart and again as you arrive. We ask, "What's the best way out of town if I'm headed south?" And then we ask, "What's the best route to city hall if I'm coming from the north?" But in between we can take the scenic route, the shortest route, the fastest route, the Civil War route or any other route that seems good at the time as long as we keep our eventual goal in mind.

From the standpoint of business intelligence and our four characteristics, we would want to pay special attention to what the programmers are doing or not doing with respect to definitions (semantics). The data architect will have spent considerable effort in researching and compiling information about the data. They will have learned about how various kinds of data relate to each other for different business functions and users and they will have defined quality rules for each kind of data.

The process standards, to be monitored by Quality Assurance and warrantied by Quality Control, will ensure that the programmers have those definitions and rules in a format that they can use and that they do, in fact, use them.

If your programmers work for someone else, the processes and standards will be about acquisition. They will ensure that the data definitions and relationship rules embodied in the application or system are compatible with those of your business. You are going to have to lean hard on your vendors and they will squirm and plead "proprietary." The best advice that I can offer is to walk away from this vendor. Another vendor will be happy you asked because it will allow them to really get close to you and they will be proud of their quality processes. The ones who drag their feet do so because they aren't able to produce the assurance you need. Proprietary is a euphemism for we don't know.

Become interested in these things. Ask questions. Expect answers that you can understand. Don't accept arm-waving and diversionary tactics. You will be well on the way to business intelligence from a high quality, reliable data resource.

Next time: the "business" role

Monday, March 23, 2009

The Beginning (2)

Because we want our intelligence at our fingertips, easily accessible, we collect and store data in computer-based filing systems. In return for the convenience of this and not having to store mountains of virtually useless paper (the bigger the pile, the less useful), we have taken on the responsibility of hiring and working with various kinds of technology-savvy people.

At the foundation is the programmer, also called a developer or a software engineer. These are the people who actually create the scripts for the computer to execute. 20 years ago, programmers were visible to the rest of the organization. Today they are typically segregated and largely invisible except to the CIO.

These are the people who create the screen forms and buttons and functionality that your front line employees actually use to capture and look up information. In larger organizations today, the programmers do not create the filing system for data. Instead, that is designed and built by someone else (the data architect) and the programmer merely connects to it. The power that the programmer holds in terms of our four characteristics of good BI is the power to knowingly or unknowingly subvert the quality of our data.

This is a good time to introduce the concept of the data resource. It is essential that today's business view the data that is captured, modified, stored, retrieved and archived as a resource in the same way that capital is a resource or buildings and property is a resource or employees are a resource. The business must devote the same kind of attention to the data resource as it does to the financial resource of the company. Neglect or failure to do so will render the data resource valueless at best and a liability at worst. In between those two extremes, the business will experience increased costs as your workers struggle to get the quality they need from the data that feeds the processes they work within.

So the programmers who build screens and functionality that allow corruption into the data resource are slowly destroying the business just like termites in the framing of your house. It is vital, in order to end up with the BI we need, that programmers employ processes that are controlled for quality purposes. Employing process standards for programming will not guarantee that our four characteristics will be delivered, but NOT doing so will guarantee that we will never be able to produce the BI that we need.

Before we wrap up this installment, it's good to recognize that there are two kinds of programmers; those who work for you and those who work for someone else from whom you purchase or license the programs (or software or applications or systems or...). No business today is unaffected by programming.

When you are getting control of your processes and instituting quality assurance, you will want to ask the same questions of your software or application vendors. Today, they are often unwilling to talk about this and will use deflectors like "proprietary" to avoid the questions. You need to ask yourself whether you can bet your data resource on "proprietary."

We'll get into this a little deeper next time when we discuss the role of the data architect.

Sunday, March 22, 2009

Begin at the Beginning (but with the end in mind)

Business intelligence, data warehouses, data stores, stewardship, governance... Where do we begin?

Let's begin by assuming that we want to have something we can recognize as "business intelligence" when we're done. The most important characteristics of business intelligence will be.
  • meaning (semantic) understood
  • applicability (use/utility) understood
  • currency (timeliness) understood
  • source/lineage/pedigree understood

There may be other characteristics that are of specific interest to a business customer, but these will put us squarely in the middle of the ballpark.

Before we go any farther, this is going to take more than one post so let's think in terms of a series of posts addressed to specific roles that, together, create the governance road map.

If business intelligence is the goal, then we must begin with the business and we'll start right at the top with the CEO. Of all those involved in the business, the CEO has the greatest power to influence, for better or for worse, the attitudes and motivations that will eventually produce business intelligence. Others in leadership roles will have similar effects to lesser degrees.

Mr., Mrs. or Ms CEO, begin by absorbing the four characteristics above. Ask yourself what it would take for you to feel good about the intelligence presented to you. Once you feel comfortable about your ownership interest, you will need to become single-minded in your pursuit of these characteristics.

Practice asking for proof, for information about the intelligence (which will be known as meta data by some of your staff) and insisting on answers that give you comfort. You may view this as self protection, which is a very good viewpoint to have. In fact, if you are consistent in this, you will find that Sarbanes-Oxley is a piece of cake for your business.

This is where it will start. The next post will address sources of the information that will eventually emerge as business intelligence.

Thursday, March 19, 2009

Fear, Accountability and Approval

Fear is an interesting thing. Fear is an emotion that is at the root of many other emotions. If negative emotions comprise a spectrum, then fear is like the sunlight, which, passing through our situational prism, produces the stress, anxiety, mistrust that we actually feel. It takes a lot of self-examination and hard work to be able to let the lesser emotions go and find the fear and its source.

Of all the ways that fear manifests, perhaps the most destructive for a business is that of controlling behavior. The need for control is based on feelings of inadequacy. Many people feel inadequate and still manage to function well in a cooperative environment. Sometimes, though, a person finds himself in a position that he never dreamed of being in and inadequacy, fueled by the fear of losing it all (by proving that he really is inadequate) creates a desperate need for control.

This person will find a way to insert himself into as many important committees as possible and will create new committees if there seems to be a gap in the information flow. This person can't tolerate subordinates who are successful because they become a threat. They have a dislike for group contexts and prefer to use one-on-one meetings to better control the message.

The single worst thing effect of controlling behavior is that the controller manipulates everything so that he has the key decision. This produces several negative impacts including
  • an entire organization is slowed to the pace of one individual
  • decisions are arrived at through discussion with peers rather than with knowledgeable subordinates
  • information needed by subordinates may be concealed in order to preserve the decision authority
  • frantic scrambles to meet deadlines arrived at without benefit of process
  • no closure on "projects" because of information hiding and diminished credibility
  • frustration among subordinates--although a really talented controller will be able to keep this frustration focused among and between subordinates
  • after-meeting meetings among subordinates for the purpose of validating perceptions
  • much talk about accountability without any accountability
  • lack of standards because control diminishes in an objective environment

Do you have someone like this in your organization? How do you deal with it?

One approach might be to create standards around process and measure compliance. With good, useful and actively used standards accountability can be made real. Without them, the best we can do is approval. Accountability is objective. Approval is subjective. Accountability creates no fear. Approval is all about fear.

Your best people have a set of internal standards to which they hold themselves accountable and they won't stay long in an approval environment once it becomes clear that they will have to compromise their standards. The ones who do stay...

Wednesday, March 18, 2009

A Hammer in Search of a Nail

Are we all familiar with this metaphor? Abraham Maslow ("Hierarchy of Human Needs") is said to have originated this, but it hardly matters. The concept rings so true that it has probably been known since the first tool.

I have lately participated in some discussions on LinkedIn with the result that I now believe that the vast majority of workers in information technology are in possession of a tool that they are seeking to apply to every problem that they encounter. The really dangerous ones are creating problems to use their tool on. Oh, wait, there's a name for that--it's called marketing.

Notice, too that I said "in possession of" a tool. It is apparently no longer necessary (if it ever was necessary) to actually be skilled in the application of your favorite tool.

I once worked with a guy--a programmer in this case, but I'm not looking to single out programmers--who said something rather like, "We don't support the business. We are the business." The business was rail transportation and it is true that if all of the applications used by this particular company were to suddenly disappear, those "left behind" would no doubt have had to cease operations until they could be reorganized.

That's not the bad part though. the bad part is that this is a really good example of just how far the notion of "where's the next nail?" can take us. When I believe that the world as I know it is held together by this tool that I hold in my hand, I am in the midst of a dissociative process. I don't go home and act this out. When I'm not at work for example, I'm just the guy next door. When I do get to work, though, I'm still the guy next door--it's just a different door. We--most, if not all--live in two separate realities. About the only thing that keeps us from being diagnosed with a dissociative identity disorder (DID) is that we (usually) remember what happened in the other world.

I could go on at length but the bottom line is that, not only is our work life a separate reality from our real life, but there is a completely different reality in the executive suite than there is on the floor, and (for me) most importantly, a separate one for I.T. Leave aside for a moment, the variety of realities we might encounter as we go from networks to servers to DBA, to data architecture, to development to QA--it is absolutely amazing that we get anything at all accomplished.

The poor data architect finds himself stepping into and out of a dozen distinct realities every day. It is certainly a defense mechanism to take refuge in a favorite tool--the "data model." This is the talisman used to shield against the swarm of alternative realities. Unfortunately, the tool was designed for a different purpose, to capture and integrate all the different realities. Nails come in many forms, too.

Tuesday, March 17, 2009

Relationships

Check out this SlideShare Presentation:

Assistance vs Solution

How can we believe that someone can give us a "solution" when we haven't even been able to frame the question? Are we that simple minded? Have we been brought to this--that we are puppets, manipulated by marketeers?

We all have need of assistance at one time or another. This is a good thing to recognize. I've run into something I don't understand. I'd better find someone who does understand so that I can move on.

If we feel ill, we might look for some relief from the cold remedies or pain relief aisle at the grocery store. We might even go to a drug store and ask for help from the pharmacist on duty. We may do some research on line or at the library in search of relief. Do we expect to be cured like this? Most would probably admit that they aren't seeking a solution--just some relief from a particularly unpleasant symptom while they wait for "natural" healing to happen.

Some, on the other hand, will look for a "solution" by visiting a medical doctor (or maybe a chiropractor). They will get relief from the most unpleasant symptoms with the advice to "do this for a week." The result is the same except for the cost. Of course there are times when consulting an expert is indicated without question. When I have severe, unexplained pain or profuse bleeding or when a bone suddenly develops a new joint, then it is time to involve outside expertise.

When we ask for assistance and then insist on telling the expert what to do, we can sometimes get what we want (say antibiotics), but doing so will not provide a solution and will, in fact, be detrimental to ourselves and to others.

How does this relate to the business world? Pretty directly as it turns out. When we experience symptoms, we could look for the source and begin lifestyle changes that will render the source harmless in the future. We can even apply topical analgesics in the form of temporary hires, a revenue bond issue or something of that nature to relieve the symptoms while we wait for the cure to develop. Or we can buy some technological antibiotic at considerable expense and increase the general frustration/pain level as we try to graft the "solution" into our corporate body.

When dealing with issues of personal health, does it make sense to ask the pharmaceutical rep what to do? He or she will undoubtedly have the "solution" in their inventory (or pocket). No matter how you ask the question, they will have a product that will provide relief. This is exactly the approach we take when it comes to technology.

What we should do, as a business or an individual, is engage a personal trainer to show us the lifestyle changes and the personal discipline that will be needed to break out of the cycle of pain. The trainer will even recommend some aids when appropriate.

Please, please stop going to technology vendors asking for solutions. Please, please stop and think when "your account manager" calls to tell you about the newest solution available through him.

No two people and no two businesses are the same. A real solution must fit the individual physiology and lifestyle. It must come from within with the aid of expert assistance.

Monday, March 16, 2009

Practical, Pragmatic, Productive

We kind of like to think of these three as synonymous. Don't they all require a frame of reference, a context, a perspective? Certainly they do if we want to think of them as synonyms. Further, in order to be synonyms, wouldn't they all need the same frame of reference, context, perspective?

I've noticed that people have a hard time with those (like me) who split semantic hairs. And yet, the long-term success of anything relating to data depends on grasping the nuances of differing frames of reference, context and perspective and integrating them into something that will be useful to all.

Beware the architect who listens to your 30 second description of what the strategic information system must do, then asks "when do you need it?" and disappears.

My son at 6 years asked me for help in building a submarine. I asked him a few questions and learned that he intended to actually travel under water--not just a play submarine. He had corresponded with his teacher's son who was an officer aboard an actual nuclear submarine. He had diagrams and photos. I asked him what he proposed to build it out of. He took me to the garage and showed me some 2x2 and 2x4 lumber and some chicken wire left over from building a rabbit cage. I asked how he proposed to keep the water out and learned that this was to be my contribution.

In my career, I have seen the equivalent of this scenario reenacted many times. It's absolutely amazing how much effort is expended on these projects. Yes, it is hard to tell your 6 year old son (or your boss) that the project can't be done and it is possible that your credibility will be diminished. I wonder whether the cost of information technology couldn't be cut by 90% if we simply learned some better ways of saying "no."

Oh, and, by the way, was it practical, pragmatic, and productive to gather diagrams, photos and written material, identify materials and find an "expert" to assist with the hard parts? Was I practical, pragmatic and productive in my approach? What was the result?

Sometimes the impossible must be done but far more often it's better to simply move on to something more in line with our actual capabilities. And, in the cases where we do have do accomplish something "impossible" the very first thing we have to do is discard practical, pragmatic and even productive because those are what brought us to impossible in the first place.

Saturday, March 14, 2009

Guerrillas and Governance

Back to the American colonies in 1775.

Over the course of nearly 200 years, the colonies had grown from the equivalent of a handful of lemonade stands into a dozen or so franchises with new locations opening up in the undeveloped markets to the west. Since the appointed governors liked comfort and their delegates had few qualifications beyond their socio-economic status or their relationship to someone important, and since communication was so poor (or slow, which amounts to the same thing), governance was like the light of a lantern.

Close to the governor things looked good but you didn't have to get very far away before the light began to fade and things became less and less distinct. By the time a traveler left the last organized settlement, he had to be prepared to take care of himself.

The problem for the governors--and the leader back at empire headquarters--was that those people out there got to be pretty good at taking care of themselves and actually began to enjoy being out of sight and out of mind. When the leader needed to have better productivity from the empire, there was some push back.

The governors were under pressure to produce more and the workers out there on the boundaries were pretty satisfied with things the way they were. The governors asked the leader for more resources to improve their ability to govern. The leader sent in mercenaries to quiet things down and implement better governance, by which was meant to suppress dissent and put everyone back to work for the king.

Of course, the outsiders didn't know anything about the locally designed governance and stepped all over it because they only had one tool, force.

Enter the guerrilla. There are leaders everywhere and sometimes they have a vision for governance and the future. When the locals see a better life with the guerrilla governance than they do with their formally appointed governance, the guerrillas will eventually have their way.

There are many points to be made from this story but I leave them up to you. This is history, but it's also today.

The one point I do want to make is that governance has to work for the governed as well as for the empire and that replacing something that is poorly understood but seems to be working may, if it is not handled well, produce more harm than good.

As always, your comments are welcomed and appreciated.

Friday, March 13, 2009

Pragmatism and Sacred Cows

Something happened to me today that has happened before. I thought I had filed the barb off the hook and that I wouldn't be snagged by this any more, but I was wrong.

I made the statement that my work would be done when people no longer talked about data governance having realized that all varieties of governance are "governance." The response was to remark that statements like that are blue sky and that people will turn me off and look for someone more pragmatic.

Knowing, as I do, that the statement represents the ultimate in pragmatism--the application of what is known to make sense of what is unknown--I proceed (very quickly) through several emotions. I guess I have blunted the hook to the extent that I recognize the emotions as they appear--which is good. Where I wound up, after passing through the "I don't need this" phase, was appreciating Galileo, Darwin and Einstein.

I'm not comparing my contribution to theirs. I am comparing my emotions to what they almost certainly experienced as they struggled to break through the thickest of all possible walls--common knowledge.

Sometimes we have other names for common knowledge. We say "everyone knows that..." or "best practice states..." or any of a host of other codewords for what amounts to a sacred cow.

I have learned that the words "practical" or "pragmatic" or even "heresy" are silver bullets most often applied to protect the sacred cows from attacks by, well, me. I just want you to know that if you want practical solutions, you should get as far from best practice proponents as possible. You might even want to venture out to the boundaries of your organization to see what pragmatic really looks like.

Thursday, March 12, 2009

Measuring Governance

I apologize. I said I would address this yesterday. We do have to get back to the guerrilla movement on the frontiers of the empire, but let's take a little time to look at measurement of governance.

First, let's agree that data governance is like any other governance except that it focuses on data. A governance program directed at process or at competency or whatever, would have the same characteristics? OK, I'll attempt a justification for that statement.

What do we ask of a data governance process? What are the objectives? By the way, I use the term process here in the sense of a set of activities that are ongoing and have a consistent purpose. The purpose of the data governance process is to:

Optimize the value of the data resource by insuring that the capture, storage, retrieval, destruction and use of the resource is done in accordance with established policy, procedure and standards.

Do you buy it? If not, I'd be pleased to discuss alternative purposes, but the remainder of this discussion is based on this purpose.

Based on the purpose of data governance then, several perspectives on measurement suggest themselves. The most obvious one is the QA (quality assurance) perspective. How are we doing at following established standards? It is tempting to count the number of standards, policies and procedures because counting is easy to do and there is a tendency among the governors to equate many laws with good government. Strangely enough, among the governed the emphasis is on the quality of the laws rather than their quantity. A small number of effective and easily understood standards may deliver more benefit than a larger number of over-specialized or esoteric ones.

The most effective measurement will be part of the standard or process itself, but some organizations may find it useful in getting governance going, to do retrospective analysis to see how well/consistently processes are being applied. Health care makes extensive use of the "chart review" to gather this kind of data retrospectively. Measurement intrinsic to the process or standard has the potential to be much more nuanced and useful than that done retrospectively simply because all of the context is available.

Clearly, though, the nature of the metric(s) is very much determined by the process or standard itself. For this reason, it makes no sense to discuss metrics or KPIs (key process indicators), a special kind of metric, without first establishing the process context.

Other perspectives might differntiate among standard, process, and policy or might measure in conjunction with the data life cycle, specific subject areas or specific usages.

One last point, should you be tempted to think in terms of measuring accountability.

Accountability in the absence of a standard is really approval.

No governance mechanism can exist for long based on approval. Each change in "leadership" will create massive turmoil as everyone seeks to reorient to a new approval model.

Wednesday, March 11, 2009

Oxymorons in Abundance (part 3)

Yesterday I stated that governance already exists and we ignore it to the detriment of all. A bit more discussion on this will be helpful.

Back to the frontier first. A settler had the problem of governing the household. There isn't much that need be said about that since we still deal with that issue today and probably in much the same ways. When a settler (at the boundaries of the empire) encountered others like him/her, they had to come up with ways to govern those relationships. I'm not going to go into those mechanisms here--cultural anthropologists have published a lot of theory and case studies about this process. I will say that whatever was negotiated fell into one of two broad categories:
  1. One party was clearly dominant and dictated the terms

  2. The parties created a contract that was seen as mutually beneficial.
Even in the cases of mutually beneficial agreements, there is often a competitive aspect. One of the parties will think, "Well, I had to agree to this but I'm going to stick to the letter of the agreement and if they think I'm going to go out of my way to make their lives easier, they'd better think again."

Fast forward to our modern equivalent. It's easy to see that, at the boundaries of our corporate empire, where the other party is the source of revenue (client or customer) this is counter-productive and a sure path to failure. It isn't quite as easy to see that the same holds true at organizational boundaries and, most importantly, process boundaries. Because of the way businesses operate culturally, each employee is competing with every other employee in the same way that settlers at the frontier were often forced to compete with each other.


The result (Dr. W. Edwards Deming exposed this very effectively) is sub-optimal performance for the process, organization and empire. We can hear this any time we choose to listen. "I know that data is incomplete, but I don't have time. They're the ones who need it--let them clean it up." "Yes, it's wrong but it's what they asked for. They're the ones who will have to do it over."

So here is the role of a governance program. Governance exists, but its goals are not those of the process, organization, empire. In order to replace naturally occurring, organic governance with governance that is aligned with the corporate vision and carefully designed to further the strategies and goals of that vision, the organic governance structures, including the attitudes that created them, must be identified and understood. Then they must be replaced with equally effective structures.

Are you familiar with the idea of a cow path? This picture shows cow paths--no, not the broad "road" that the cows are on--the cow paths are those faint lines that meander across the fall line of the hill. Why are there so many? The cows have their reasons but they aren't talking. Those paths are like the organic governance in your organization. You've heard the expression paving the cow paths, which is not considered a good thing to do.

I'll leave you with a final thought. Is redesigning the cow paths a productive effort? The answer is that it may be and it depends on the objectives, BUT if there is no way to train the cows to use the new 21st century solution, then even the best vision, strategy and goals will be for nought.

Tuesday, March 10, 2009

Oxymorons in Abundance (continued)

Leadership is about Change.
Management is about Effectiveness and Efficiency.
Governance is about Consistency and Stability.

The discipline of Change Management is well worth our time. It consists of theory and practice involved in getting a change implemented. http://www.m2dxtx.com/images/Change_Components.gif makes an excellent reference whether you are a Manager, Governor or Leader. In everyday life, we can find ourselves in situations where there is an atmosphere of confusion around some initiative. As the chart directs, this is evidence that the vision driving the change has not been communicated well enough. In other words, the effort still needs leadership.

If the general mood is one of frustration, then this is where the manager must step in to make certain that sufficient resources are available.

To understand the role of Governance better, let's examine the life of a guerrilla movement such as the early days of our own American Revolution. The various colonies existed under charter from the King of England--not unlike departments in any corporation. As far as the Leadership was concerned, the colonies' purpose (the vision) was to produce wealth to allow expansion of the empire. The colonies were OK with that since they were able to keep a portion of the wealth for themselves.

The Leadership had placed Governors in each of the colonies to make sure that everything functioned well and that the colonist/workers could and did focus on their production. Leaders like to be able to rely on their empire to generate wealth consistently and predictably. The problem was that the Leaders and the Governors were out of touch with life at the boundaries. Governance attenuated pretty rapidly as you moved westward, away from the seaport communication links and seats of governance.

It was hard to focus on making the leaders wealthier when you had to worry about coming back from a hard day in the fields to find your home burned down and your family gone. Even a relatively small thing like an illness meant that you might have to cease all "normal" activities in favor of ministering to the ill or traveling days to either bring the ill to a physician or the physician to the ill.

In all of this people learned to manage their own situation. In so doing, they developed their own leadership and governance skills and processes. They learned to manage the processes and assessed their effectiveness by the stability they delivered. Ineffective processes were modified or abandoned.

The lesson here is that there is little need for governance in the boardroom. Governance is most valuable at the boundaries, where control is weakest. If there is no stability, no consistency and no predictability at the boundaries, then there is no governance. If Leaders attempt to hold Managers and "official" Governors accountable for something that doesn't exist, they will find themselves more and more out of touch as the accountable individuals scramble to create evidence that they are being effective.

What is data governance accountable for? What do we measure? What are the goals? What are the trends? Is business intelligence defined for data governance? Do we have data governance?

Tomorrow: Measuring Data Governance

Monday, March 9, 2009

Oxymorons in Abundance

No Governance in Data Governance.
No Intelligence in Business Intelligence.
No Leadership in Corporate Leadership.

Let me hasten to say that these are not intended to be value judgements. To be fair and truthful (which are tough sells) I should modify these statement a bit.

There is little governance in data governance, little intelligence in business intelligence and little leadership in corporate leadership. The question to be asked is not "why" but "how". Whenever we are faced with something unexpected, we are used to responding, "Why?" I've learned that why? almost always puts people on the defensive and that communication effectively shuts down when people become defensive.

If we change our question to how? we can focus on processes and look for cause rather than fault. So, how does it come about that data governance so often lacks any vestiges of governance?

The first task is to differentiate between leadership, management and governance. This isn't about people--an individual may be capable of doing all three--but it is about tendencies. Here's a breakdown that might help this to make sense.
  • Leadership is about change.
  • Management is about effectiveness and efficiency.
  • Governance is about consistency and stability.

My take, after watching these processes work for many years, is that we find it nearly impossible to keep these three functions separated. When we are doing management while talking about leadership or doing leadership when we are talking governance, we not only confuse ourselves but also the community we are working within.

For example, we make a leadership decision to create data governance. Then we turn the task over to managers. In reality, leadership is required all the way out to the line organizations. Managers cannot make effective or efficient something that they do not understand and have not bought into. A too-early transition from leadership to management will give birth to confusion, frustration, burn out and the failure of the initiative before it even gets to the governance phase.

Continued tomorrow.

Thursday, March 5, 2009

Governance and Data Governance

It occurred to me today that one of the reasons for so much confusion in the data governance ranks today is that businesses have a hard time with governance in general.

The literature I've seen (and I'll admit I'm not ready for a thesis defense) is focused on the what I would call the mechanical aspects.
  • What kind(s) of committee(s) and at what level
  • Who should be members
  • What are the roles of the committee(s)
  • Who holds the "decision rights"
  • What are the decision domains

When discussing committee membership, the choices are framed in terms of role and level within the business.

Nowhere is the question of competency introduced. To me, this is cause to wonder about the purpose of governance. If competency is not a requisite quality of governance, then why do it? It seems clear that, even in areas that most would gladly cede to executive management such as strategy formulation and prosecution, there is an aspect of competence that, if missing, will cause decisions to be ineffective and/or impossible to implement.

We are accustomed to seeing leadership, management and governance used interchangeably when, in fact they are three different activities with three separate purposes.

Leadership has the mission of (productive or positive) change.

Management has the mission of effectiveness and efficiency.

Governance has the mission of stability, consistency and predictability.

I submit that questions about whether a certain initiative should be funded or not is NOT a question for governance but for management. The governance question is whether doing this will upset the applecart. Can we continue to produce expected results if we do this? If we need to do this because of a leadership imperative, how can it be accomplished such that predictability is preserved?

Without intending any disrespect to executives, it is doubtful whether they could productively be involved in answering those questions.

Tuesday, March 3, 2009

Information or Systems?

For those of you who work in I.S. or I.T. or any of the variants, a question. Is your organization about information or is it about systems or maybe it's about technology?

My sense is that many more people are in it for the systems (programming) or the technology (networking, servers, wires, boxes) than for the information.

Just to get all the cards on the table, I'm asking this from the perspective (there's that word again) of someone who has been having his nose bloodied for years because of a stubborn streak that keeps on insisting that it is about the information and that everything else is supporting cast, walk-ons and extras (the Academy Awards are a recent memory).

The term, ontology, has become trendy in the relatively recent past. It simply means a specification for a concept. A concept is an idea and many times it never progresses beyond that. Rarely, an idea like freedom or liberty needs little or no specification to make it useful, Many ideas, like stewardship, on the other hand, need quite a lot of specification before they become useful.

Information Systems/Technology appears to be in need of some onological work. I.S./I.T. are ideas that require a context. They are found in the context of a business. The business, in turn, has a context but we don' need to go that far for the purposes of this discussion.

Businesses need to produce, dispense, store, manage many kinds of things and all of them are physical save one--information. Because information is a concept in its own right, it quite often gets pushed out of the way in favor of the physical things that compete for our attention by virtue of form, color or sound. These things require physical space and unless we do something, they will soon pile up and make it impossible to get anything done.

Quiet information or data, on the other hand makes no demands and is consequently ignored. Remember, though, that the business has an I.S. or I.T. organization because every now and then someone needs a specific piece of data or a chunk of information and needs it now. Sometimes the data has just come into existence and other times it has been languishing in a "data file" for days, months or years.

How do we find that set of ones and zeros and turn it back into the concrete abstraction that the business needs? Friends, that takes data as well. Device names, drives, folders, files, instances, records, fields, indices, values--all of that is data. In I.S., we understand the need to keep that kind of data reliable. We create systems and they are data as well. We understand the need to maintain our system data: product, version, build, component, QA status... and the implications of not doing so.

Frequently the Data people (data administration, data architecture, data stewardship, data governance, database administration...) are part of I.S. or I.T. and we're content with that as long as they are directing their attention outward, toward the business. As soon as they begin to exhibit interest in us and our handling of our own data, we start to feel resentment, frustration and even anger. "Who are they to tell us how to do our job?"

Friends, and I am sincere in my use of the term, programming is programming and data is data. The Data people can help you and they want to help you and, most of all, they need to help you in order to close the loop. They are being held responsible for the quality of the data resource and the processes that create and manage the resource. You represent a huge exposure as far as they are concerned. When you re-learn to associate your system with the information that flows through it, I hope you will also learn to value what the Data people are offering.

Information Systems, Information Services, Information Technology: let's refocus on the reason and purpose of those efforts. You can benefit from the consistency that results from standard processes. You can benefit from better data management capabilities. We can all benefit from understanding our shared purpose--the best information for the business we're part of.