Continue in 2 seconds

Starting the EIA, Part 2 - Project Initiation

Published
  • July 15 2004, 1:00am EDT

This series of articles focuses on defining, planning and rolling out the appropriate plans, policies and structures to manage information, i.e., information architectures. Part 2 describes key tasks to ensure a good start.

For this third article on enterprise information architecture (EIA) will assume that the go-ahead has been given from management to, at minimum, explore the business case and start to plan the management of information as an asset. Rarely does a CIO/CEO authorize the implementation of EIA without some initial consideration of the business impact. As a result, initiating the EIA project has extra tasks in addition to the normal start-up activities.

Information architecture is the collection of components used to manage valuable enterprise information assets. This includes plans, policies, principles, models, standards, frameworks, technologies, organization and processes that will ensures that integrated data delivers business value and aligns business priorities and technology.

The normal start-up activities are, of course, identification of scope, definition of project objectives, identification of champions/steering bodies, selection of the team/consultants and completion of a project plan. It must be noted that even though these are "typical" of any project, the EIA effort project plan may require explanation to many of the stakeholders before it is signed off. At this point, the EIA team may as well adopt a mind-set that they will constantly be selling and explaining this project. This will factor into the project communications plan, which although typical, is often poorly detailed and not followed.

A normal activity for project initiation, but one we see overlooked often in EIA efforts, is the need to create standards around how things are going to be organized. This includes work files, deliverables, team procedures and policies. For example, projects often start without really collecting past artifacts and getting them in order (let alone read them). Plan to get them if at all possible.

Finally, many projects start with some inventory of current technology and legacy applications. This is encouraged, although we prefer to see an emphasis on a high-level data quality view of the inventory. In any EIA, the sooner data issues surface, the sooner they can be factored in. Extra activity to initiate an EIA effort often stems from the cultural and business impacts of EIA. Several events must happen at this time to present the team with additional information about where to focus extra marketing, education and risk management efforts.

Understand the Culture

First, the team must understand what type of culture is in place at an organization and define how that culture views, treats and uses information. This is crucial. At first blush, one may want to say, "Hey, we are in the same industry as our competitors, so we can use the same EIA approach." This is a mistake. Most often, companies within the same industry have very different information cultures, e.g., insurance company A may be dominated by actuaries and insurance company B may be dominated by marketing. This presents two different information cultures.

In general, the team must classify the culture as to its degree of centralization of information management, its maturity in managing information and how its processes depend on information. For example, again, insurance company B may view information as a lubricant, i.e., make jobs easier in functional silos, whereas A may view information more as fuel for the business engine. (See Part 2 of the series.)

Develop a Business Case

Most of the time, the team is tasked to do a business case that will justify proceeding with the EIA. If done during project initiation, the team has a good grasp of what costs are (they are developing the project plan), and they are positioned to gather business objectives and benefits. Therefore, during this step, the team needs to gather business objectives and goals, and translate those into benefits associated with managing information. This exercise is best done via researching documents (i.e., annual reports, budget documents, etc.) vs. interviews. Interviews at this time will "put off" the executive team.

The business case should be a collection of examples of how information will generate bottom-line benefits and present cash flows, internal rates of returns and Net Present Values of the IT portfolio.

The business case aligns the usage of information to achieve corporate goals with the associated cash flows from the processes that will use the managed information. Yes, you naysayers are now saying, "But we never get the credit for the benefits when information is used to improve the business." That statement is irrelevant at this time. The business case is for enterprise benefits; we will cross the "who gets credit" topic in a future article.

Threat Analysis

The final, unusual step for many projects is a formal analysis of threats and risk to project success. It is best to break these risks into our old comfortable classifications of people, process and technology. Who are the people, internal and external, who can threaten the EIA project? This means taking a hard look at the politics in IT and the company in general. A classic example of risk is the clash between information managers and applications developers, whereas the latter will tend to view the information managers as slowing down the delivery process of applications to users.

Process risks usually stem from companies being very siloed. Many companies are built around hand-offs to other processes, and the cultural view of data integration tends to be one of data synchronization, vis-à-vis integration of processes via good information.

Technology risks will stem from the degree that data is dispersed through the organization, copied and replicated as well as infrastructure challenges, such as geography, time zones, etc. For example, many companies are replication crazy, with redundant subsets of core domain data living in every single department. This presents a risk to EIA given that these departments will not want to surrender their data fiefdoms.

The goal of the threat analysis is to be able to correlate business benefits to the perceived impact on culture. Culture change becomes much more likely if there is a chance to miss tremendous opportunity due to cultural issues.

The project initiation step for EIA must feature the typical steps that happen in any project, but must also pay attention to the cultural and risk components that tend to derail these types of projects. The final PI deliverable will not only feature the EIA project plans and deliverables but also a series of tactics to mitigate the cultural and political barriers. These tactics will affect the choice of techniques and facilitation that occur in the upcoming discovery and design steps.

The contents of this article are Copyright 2003 by DM Review and KI Solutions. Any use, quotation, repurpose, duplication or replication of the diagrams, concepts or content without permission of DM Review and the author is prohibited.

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