Having just completed a 40-page report titled "Creating an Enterprise Data Strategy: Managing Data as a Corporate Asset," I thought his results make a good supplement to my findings. While I focused more broadly on data management and data quality issues, he honed in on critical success factors for managing data governance programs.

In particular, he correlated successful data governance programs with the following characteristics:

• A data governance mission statement
• A clear and documented process for resolving disputes
• Good policies for controlling access to business data
• An active risk register
• Effective logical models for key business data domains
• Either business processes defined at a high level or fully documented at several levels and available for data governance
• Data quality assessments that were undertaken on a regular basis
• A documented business case
• A link between program objectives and team or personal objectives
• A comprehensive training program
• A Web site alongside a broader range of communication methods

This isn't rocket science for sure. But it does take a lot of work to implement all or even some of the tasks or practices listed above. And if the program truly manages cross-functional data, then the process is that much more challenging since departmental politics begins to encroach. For that reason, I think the most important success factor in Andy's list is a "clear and documented process for resolving disputes."

Documenting the business case is also important, but it's something few organizations do. Most are just glad to get permission (or tacit approval) to launch a data governance program, citing that as justification enough. Usually, executives endorse such programs because they've suffered a major problem due to lack of clean, consistent data and recognize that data governance is simply a cost of doing business. However, without a clear cost/benefit analysis, it's too easy for data governance programs to be swept aside by changing currents in the organization, such as a new executive, an acquisition, or a new strategy.

I normally counsel people in these circumstances to be patient; sooner or later, the organization's data delinquency will come home to roost, and it will stumble in the marketplace. The Board will bring in a new slate of executives who need to measure performance rigorously and want to enhance the organization's information infrastructure. If you have stayed the course, this is your time to shine.

But some times it doesn't pay to be stoic. You are too ambitious, your executives are too entrenched, your organization is too complacent, and better opportunities exist elsewhere. And when push comes to shove, you just can't take it anymore, personally, professionally, or emotionally. Then, it might be wise to seek greener pastures, and a corporate environment that possesses a data-driven, decision-making culture.

The following is a list of symptoms that might indicate that it is time to polish your resume.

• Your BI/DW team is "invisible" to corporate executives until you make a mistake.
• Executives make decisions based on analyst spreadsheets rather than data warehousing reports that contain the same information.
• Executives continually approve the acquisition of new applications with embedded BI products that run counter to your established BI standards.
• The BI/DW group never has the funds to hire enough people (or the right people) to stay ahead of project backlogs, reinforcing business perceptions that the BI team is slow and incompetent.
• The BI/DW group doesn't have a manager or one who is knowledgeable about BI.
• The BI/DW group Is viewed as another IT group whose members are interchangeable.
• The project management office insists that the BI/DW team follow traditional software development lifecycle (SDLC) and project management methodologies.
• ERP implementations take the lionshare of business attention and IT resources.
• You are an order taker who delivers what the business requests rather than an advisor who helps the business understand what they need and then builds it.
• During requirements sessions, users repeatedly say they "want all the data."
• Users use the BI tools as glorified extraction mechanisms to dump data into a spreadsheet or desktop database.
• Users still question the validity of data more than a year after you've delivered a new report.
• The BI/DW team doesn't track usage or know the degree of user satisfaction with BI.

Reasons to Resist

Change can be personally threatening. If someone's prestige, authority, or career path is baked into the old ways, they will resist change, sometimes vociferously, doing or saying whatever it takes to undermine a new program. Similarly, change connotes uncertainty, and, when it comes to our working lives, most humans prefer to know what to expect rather than live for the moment.

Change can also be time consuming. Today's busy executives and workers have less time and more pressure than prior generations of employees and often don't want to spare the time or mental energy to learn new ways of doing things. They often prefer the old, less efficient way of doing things because it's less disruptive to their schedules and rhythms of work.

"Resistance is normal," says John Ladley, president if IMCue Solutions, a data management consultancy and author of Making Enterprise Information Management Work for Business (Morgan Kaufmann, 2010).

Symptoms. In his book, Ladley describes many ways the businesspeople exhibit resistance:

• Foot dragging


• Bargaining for exemption


• Retreating to old ways of doing things


• Poor attendance at meetings or increased absenteeism


• Hostile or cynical comments


• Lack of endorsements


• Acts of political sabotage

And he writes that people resist a data governance initiative (or any other issue for that matter) for a variety of reasons:

• Loss of identity, power or prestige


• Personality traits (introvert vs. extrovert, capacity to embrace change)


• They are overloaded with current responsibilities, with no time to learn new skills


• They feel there's no value in changing for them personally ("What's in it for me?")


• No one sought their input to devise the solution or program


• Past initiatives failed

Managing Change

Create a Plan. Given the extraordinary lengths that most workers go to avoid change, it's imperative that you create a change management plan as part of any IT initiative. These plans identify who is going to be affected by the new program and craft communications, education and incentive strategies to get those employees to adopt new behaviors.

Identify Problem People. It's wise to identify individuals who will openly or covertly undermine the program and craft special strategies to deal with them. Sometimes, it might make sense to put them on the organizing committee if such participation might soften their parochial outlook. For lower level workers, it pays to spend extra time presenting the program to them, soliciting feedback, and reconvening at a later date to show how their input shaped the program.

Seek Help. Finally, it pays to seek counsel from your organization's marketing department to help craft a detailed plan that segments and describes end-user constituencies and devises a communications strategy tailored to each. The plan should define which messages get delivered to which constituencies via which channels at what times.

These days managing change is an entire industry. For more insight into managing change in a BI environment, check out these past blogs of mine:

- "How to Rein In a Renegade BI User (Like Me!)"
- "Managing Change: The Case of the Missing Wallet"

When implementing an IT program, be alert for the symptoms of resistance to change and be ready with a marketing and communications plan to thwart resistance before it sabotages the project.