One of the most important tasks for effective information management is setting up the business governance over the program and the projects. Governance will prioritize the often-conflicting business demands. It will take the strategies and goals and help to form them into bounded projects. It will make the very most of the always-limited information management resource availability in targeting important business functions without sacrificing the ability of the infrastructure to support the long-term goals of the business. Governance epitomizes detailed cooperation.

However, many organizations struggle to get their governance programs off the ground. They can’t secure interest, and they lack things to discuss after the initial direction is forged. It can be awkward, and it’s necessary to understand the mistakes I outline here and avoid them. However, no matter where you are with governance, there is a way forward, and it may start with reversing some mistakes that are being made.

1. Not translating IT investments into business objectives. Governance needs to ensure that business objectives underlie all IT efforts. Think of it as governance’s obligation to IT. Keeping IT principled toward the bottom line maintains its relevance to the organization. It keeps jobs intact and prevents resources from being dedicated to dead-end projects that fall out of favor with the organization. Business objectives, even to the point of ROI calculation, facilitate project prioritization and prevent other mistakes such as scope creep.

2. Thinking of governance as a technical function. Be careful how governance is presented to those targeted for the group. Just a few keywords like “data warehouse,” “technical platforms” and even “information technology” can immediately turn people off. Many in upper management (the target audience for governance) find such matters more appropriate for others to handle, either because of the perception that a high technical skill set is necessary for governance (not true) or that dealing with such matters does not properly position them in the company as decision-makers. As time goes on, fewer organizations reward executives for being hands-off, but that mentality still remains.

While this is all detrimental enough to governance, many of the governance champions in IT cave in at this point and make governance into an ineffective technical function composed of technical architects. There are many routes to this kind of governance, all building on early mistakes.

3. Scope creep. The scope creep problem I’ve observed in governance is twofold. One, governance takes responsibility beyond the strategic to the tactical implementation level and extends itself to include the architects, database administrators, modelers, etc. This organization inevitably migrates to the implementation and execution of the strategy, rather than its formation. The day-to-day needs always take precedence, so it is important to separate out the strategy or it will fall by the wayside.

The second scope creep problem is the passing of the baton of prioritization to the implementation team(s). If governance does nothing else, it must prioritize and differentiate the projects according to business strategy. Don’t get it confused with data stewardship (business participation as part of the development team) or a business intelligence competency center (technical strategy).

4. A revolving door of membership and participation. Sure, there will be a period of settling in and some discussion along the lines of: “We need Joe here” and “I really don’t belong” during the formative first quarter. Other than occasional changes mainly due to organizational position changes, if membership change is predominant after year one, there is a problem.

Probably a bigger problem is sustaining participation among the members. And the biggest reason for this is the lack of stimulating topics put forth by the governance leader. While some meetings and some periods are going to be more significant than others, governance should never go stale. The programs always need important guidance at any point in their lifecycles, and furthermore, governance is an opportune time to practice avoidance of one of the top reasons for the failure of any of these projects: the semantic communication gap between what is delivered and what is expected.

I have used the governance downtimes to demonstrate anticipated user interfaces, review data quality scores, talk about movements in the market, recognize important contributors on the team and take the clarification of previous decisions to another level of detail. You can never do too much of any of these.

5. Assuming everything will work out right and everyone will follow governance’s maxims. Determining the decision-making process and how exceptions will be managed, including the communication process, are just as important as the decisions that actually are made. Between-meeting communication protocol could avoid insular decision-making that should have been handled by governance.

No committee can foresee the future perfectly or knows it all. If governance waits until it does, it will never make any decisions. At some point, it is better to make the decision. However, unless an exception process backs that decision, either it will not be appropriate enough to stand as a decision, or exceptions will occur anyway.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access