Let us acknowledge that enterprise information management is a program similar to other programs that have been proposed over the past three decades. As such, you will likely find the following within your organizations:

  • A perception that data initiatives (such as CRM and data dictionaries) fail all the time.
  • A perception of wasteful spending on any “pure” information management projects.
  • Hearty criticism of information technology area (IT)
  • Ongoing complaints that the IT data is not “correct” and as a result, business areas need to create accurate data.
  • A growth of stealth or shadow IT in reaction to the poor perception of IT.
  • Plentiful evidence of projects that are implemented with shortcomings with the intention of addressing them later, and of course later never happens.

Rational people can look at the permutations of IT projects and say that they are of value. But the track record of prior projects makes full-scale EIM hard to swallow. The cruel fact is that without a good, solid, money-in-the-bank business case, EIM is a waste of time. History has determined that executives will not pay attention to petitions based on better access to data or single versions of truth. These were promised years ago, and the concepts are now part and parcel of corporate thought and myth. It’s sad but true. Just because the concepts are ingrained in corporate thought does not mean that a business leader will embrace EIM – he or she embraces the ideas that EIM represents. Barring any other influence, the business leader will craft those ideas into the image he or she needs at the time. That image has to be in the form of a solid business vision. To help create the appropriate influence for an EIM program that supports corporate strategy, a solid business case is required.
We know at some instinctive level that EIM is good, and we have talked about information enough to accept that it is an asset that needs to be treated in a formal manner. But due to the abstract features of information and data, we need to be creative in addressing the challenges of bridging those good feelings over to a business case.

Some components of EIM, like the technologies for data movement mechanisms, are, in effect, plumbing. Using an asset metaphor, they are infrastructure and could be valued across the entire enterprise. Other components of EIM or asset classes such as information handling and other applications lend themselves to direct business usage and business touchpoints, so we can likely tie some kind of benefit to their usage.

The asset metaphor therefore needs to determine how to make a solid business case that will focus and direct the entire enterprise and make EIM a philosophical underpinning versus a one-off program that delivers a “chunk” of information management.

Key IT and Business Considerations

The business case must also address IT failures and negative perceptions of IT departments. While perceptions may or may not be grounded in truth, they exist, and an ingrained perception that IT does not deliver will poison EIM. EIM should be delivered by the entire organization with causality spread between business and technology camps. Negative perceptions of IT can stem from many causes.

It is easy to blame IT. Information projects are sold with inflated expectations and therefore an EIM effort needs to develop a business case that not only manages but delivers realistic prospects. The case must also be business aligned and reflect directions required in current and planned business environments. Even if the component parts are plumbing, they need to be kept in the context of a larger organizational mission.

The IM road is littered with projects where IM staffs have locked businesspeople in rooms to draw models and define dimensions. These might be noble efforts, but they are not attention grabbers. To be realistic and accepted, the EIM effort must not be based on abstractions that depict business rules and models leading to nirvanas of business success. IM teams have been selling their techniques and tools as final products, but this is clearly the wrong approach.

Conversely, business needs to empower the IT function. The reality is that when IT projects are successful, IT often gets little or no credit for the benefits. . This particular view of benefits is a result of business not considering IT as part of the business. Nearly all initiatives require data of some sort. A business unit cannot claim all the benefits from an initiative if its objectives were enabled by data or information provided by IT. Even if the data is not from IT, it is still corporate data that cannot be claimed by a department. We should approach EIM with the mindset that benefits from data usage are global.

In cases where a business area leader really wants “better data,” and is willing to push hard and expend political capital, he or she rarely does so without a thoughtful business case that matches responsibilities across business and IT.

  • The business case must address accountability. If the goals are not met, who is responsible? Historically, it has been easy to blame IT for failures to communicate, or to insist on business terminology that communicates requirements poorly. The business needs to share in the accountability of the project, even where execution falls largely to IT.
  • Business leaders are poorly incented to do well at IM projects. We often hear that a good business sponsor is key to the success of an EIM effort, but sponsors also need to be invested in outcomes. The business sponsor can be as excited and supportive as can be imagined. But if, at the end of the year, his/her bonus or compensation is not tied to EIM-related goals, enthusiasm might not hold up to stress or business changes. The business case requires that business accountability be built into sponsors’ objectives and personal targets.
  • Once IT projects are approved and undertaken, there is a tendency for interest to wane or old habits to return. Business areas need to understand that the investments continue beyond deployment, and that effort and will is required to sustain the project’s goals. Therefore, the business case must accommodate the costs and benefits of sustaining the effort and ensuring things change.


Principles play a major role in ensuring EIM success. Understanding business cases means introducing principles ahead of time.

1. All business cases are to be developed upon hard benefits. Soft benefits are added after hard benefits are derived. Rationale: hard benefits address the accountability and measurement issues. Hard benefits also help justify funding additional costs to sustain necessary organizational and functional changes. Even if the program contains infrastructure-type projects, the business must be looking for business gains.

Implications: Many IT staff are not business savvy, especially in areas of finance. Training may be necessary to get the business case developed. At minimum, IT staff will need to interact with financial personnel.

2. Benefits from data projects belong to the enterprise, not the sponsoring department. Rationale: This principle or policy immediately removes objections to IT claiming benefits. IT also reinforces the joint accountability of IT and business; in essence, it makes the convergence of IT and business real.

Implications: Functional area heads will not like this. There will need to be reinforcement from the highest level of an organization. At minimum, policies for incentives and job descriptions may change.

The deployment of these principles is demonstrated in the figure. The left margin shows how organizations can use information and knowledge. (This example came from a client that also folded a knowledge and content management strategy into EIM.) The top shows the means by which we can see benefits. Note that the intersections of these are stated as benefits and none of these benefits can occur without the application of knowledge and information.

Components of Business Cases

Now that we know what roadblocks we may run into and have some principles on hand to assist us, what should be in the business case? Where do the benefits come from?

The basic components of the EIM business case are:

  • Business goals and objectives: These are the quantitative statements of where the business wants to go. If a business wants to improve market share, you need to know what kind of revenue that represents.
  • Business benefits and categories: If the business achieves its objectives, what are the anticipated effects on balance sheets and income statements? Those who believe this cannot be realistically done should consider cost/benefit analysis as a way to connect investments to objectives. For example, think about the case of a medium-sized town that has grown enough to need a larger airport. Airports tend to be infrastructure investments in which certain parties (taxpayers) are asked to fund something that is difficult to link directly to hard dollar benefits. However, it is apparent to all that the region will not grow more tax revenue, more jobs and better schools without the new airport. How, then, is the funding justified? It is traded by adding up the benefits to the region and applying them to the cost of the airport. Does the airport get the money? Not directly. Are there measurable benefits? Yes. Benefits may not be hard in the ROI sense, but they exist and have hard numbers associated with them. The closer to cash flow benefits can be stated, the better.
  • Business usage or business information requirements: This is the business view of what information is required to achieve the goals. These can be in the form of measurements, content or descriptions of data types.
  • Cost to supply usage: The creation, movement and preparation of data to be used incurs cost. This is the mundane part of adding up the project efforts, investments in software, hardware and networks, and cleaning up the data so it is useful. (Cleaning data and data quality will be a separate topic in this series.)
  • Cost to sustain usage: Once up and running, the EIM program will require maintenance.
  • Cost to manage risk: Often data portfolios contain risk – either from potential liability such as privacy concerns, or failure to comply with a regulation. The costs and potential liability need to be stated in financial terms.

All of these added together present a fairly robust picture and provide the raw material to develop the business case for EIM. In my next article, I will provide an example of how these components are folded into a vision that allows an organization to track and manage EIM and ensure the benefits are incurred from treating information as an asset.

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