CIO CORNER

This is the MIT CIO Symposium blog. We invite participation from speakers, sponsors, attendees, and interested parties.

IT Governance – Issue 3

By donflinn | December 8, 2009

With this issue we begin the journey into the details of IT Governance.  Since IT is such a large topic we first need to break the task into workable categories.  These categories should be associated with both business and IT as well as encompass the major contributions of IT that are critical to the IT/Business relationship.  Having such a breakdown we can then more easily set direction for and control of IT.

We will use the IT governance decision categories as well as some of the concepts and research carried out Weill and Ross of MIT Sloan Business School 1 :

IT Governance Categories:

  • Principles
  • Architecture
  • Infrastructure
  • Business Applications
  • Investments

Next we will define who has responsibility for making the decisions in each category and who contributes input for use by the decision makers.

This issue of IT governance will discuss the first category, IT Principles, as well as who are the decisions makers and who are the contributors of information needed to create the principles.

IT Principles

In order to set direction for IT there first must be an overall set of objectives that the company determines are important for IT. These are what we classify as IT principles.  They are derived from the corporate priorities established by the Board of Directors and further refined by top management. (See our previous blog.)

An example of such a principle is the high level priority laid down by State Street Bank, a large and successful bank, with revenue of $2.2 billion.  In 2001, David Spina, the new CEO, said that State Street should be seen by its clients as “One State Street”. What he meant is that, even though the bank has many different business units and services, the organizational lines should be invisible to its customers.

Every part of State Street was affected by this principle – business units world wide were to cooperate in taking care of existing clients while expanding globally, with the overriding priority that the various business units appear as one.

The effect on IT was just as consequential.  Previously, IT was highly decentralized, but under the new principle the bank created a single community of IT across the company and instituted an emphasis on enterprise-wide applications and justification for new efforts. State Street also established a new key decision making body for implementing these changes, namely the ITEC, IT Executive Committee, which was comprised of senior C-Level executives.

MeadWestvaco, a large manufacturer, is a second example from a different industry, which developed different business priorities, such as, ‘leverage economies of scale’ and ‘standardize processes’.  For IT these became the principles – ‘lowest total cost of ownership’ and a ‘standardized architecture’.

As becomes clear from these examples, business level principles filter down to IT, which result in unequivocal direction, setting their behavior in line with business imperatives.

From these two examples, another important point becomes clear.  Pertinent principles are dependent on the type of business. State Street, a financial institution, determined that customer centric activity was its important business principle, while MeadWestVaco, a manufacturing firm, determined that cost control and standardization were most important.  Different IT principles resulted from these two different operating models.

Wait, you say, “This is getting complicated. My IT governance principles depend on the type of business I’m in?”  We’ll come back to this and other important variations and exceptions in a later blog, but first we will complete the examination of IT Governance using the most common procedures of the successful companies and the best research. (We never said that corporate governance was easy, but getting maximum business value from IT should be a strong motivator.)

Let’s return to establishing a procedure for developing IT principles.  First we’ll list the steps, and then explain each step.

Steps to Creating IT Principles

  • Derive IT specific strategic policies from strategic business policies
  • Reformulate the resulting IT policies to a few encompassing principles
  • Establish committees to carry out the processes
  • Establish reporting processes and procedures

We will describe the specifics of the steps for establishing IT Principles next.

Description of Steps

As we discussed in the previous blog, high level policies are formulated by the Board of Directors with input from top management. Since the BoD is responsible for long-term planning and ensuring long-term business value of the company, the policies that they generate will or should have these same business-centric characteristics.

Once corporate strategic policies are formulated, top management begins work on determining how these policies affect the different business units. In the IT case, the management team is responsible for shaping the policies so that they apply in an IT context.  From these, they formulate a set of IT Principles.

Returning to our State Street Bank example, the “One State Street” directive was translated into a series of principles directing IT to modify their behavior as to how customer information should be delivered.  This greatly affected IT’s structure, future direction and output. Among other changes, instead of separate IT groups for each business unit , they established an enterprise-wide IT group to control and direct the IT activities of each business unit.

Since IT Principles are high-level directives about how IT is to be used in the company, they influence how the details of each of the other four categories are constructed and used.  Consequently, IT Principles are the linchpin that determines how IT aligns with corporate business values throughout all its activities and sets its strategic direction.

Establishing the correct principles is critical to setting the desired direction for IT and influencing its behavior.

Principles about the Principles

There should be a small number of clear, abstract principles.  Use of a limited number of clear statements is important because too many and/or vague principles lead to confusion and poor governance.  An optimum number of principles are five or less.  We use the term abstract in the sense of getting to the essence, which allows each principle to cover a wider span of cases, which in turn supports the requirement for few principles.  Furthermore, it is critical that the principles capture the full meaning of the top-down business policies.  Albert Einstein’s quote – “Make things as simple as possible, but no simpler” – is most appropriate here.

Who has Responsibility?

There are two separate teams, or committees, which have different responsibilities in transforming business policies to IT principles.  There is the decision making group, which decides what principles are created for IT and a committee that supplies input to the decision makers.

C-level executives make up the decision committee in most of the companies with outstanding IT governance.  This is because of the critical importance of the resulting principles in driving future direction of IT and the far-reaching effect that the resulting principles will have on the business value of IT to the company.

Turning to the input committee, IT CIO’s and top IT personnel are important contributors to this group since they have the technical knowledge to advise on whether the technology is available at a reasonable cost to accomplish what the principles dictate, to help explain the principles in a language that IT can relate to and to make the business people aware of new technical capabilities that can support business goals or new business direction.  Additionally, business unit management contributes specific business principles related to their business units. Finance and human resources may also contribute in their respective roles.

Cross fertilization is important in transmitting valuable information from the input committee to the decision group and in assuring that the input committee has a firm understanding of what is intended by the resulting IT Principles.  Companies can accomplish this by having a member of each team attend the meetings of the other as a liaison, supplying the minutes of each group to the other and/or occasionally having joint meetings.  For example, the two groups could have separate adjacent meetings and then a short joint meeting.

Decision meetings should not be too long, nor too frequent as you are taking the time of the company’s top talent.  One way to accomplish this is for the decision team to charge the input committee with doing the leg work, such as gathering and condensing information.  The input committee may, in turn, have some of their employees carry out the more rote tasks. As the initial principles are worked out you will find that the frequency of these meetings can be reduced. On the other hand, if a new direction in policy is instituted, the frequency should increase.

Another important criterion is that the CEO should be involved.  It’s an old, but true canard that it is necessary for the leader to back critical functions, if the functions are to succeed.  It is not necessary for the CEO to attend all the meetings, except for maybe the initial meeting and ones where the principles have been worked out and are to be announced.  The CEO should make the final principle announcements, lending his or her authority to the principles.  In any case, the CEO should be kept fully informed and engaged.

Finally, there is the metrics committee whose responsibility is to follow up on announced principles to assure that they are understood and implemented.  An important activity of this group is the gathering and reporting of metrics, including the business value of IT.  This committee is composed of first-rate employees, but not high-level managers.  However, it is important that this committee be given authority from the top.

Without measuring the success or failure and the compliance with the IT principles, the principles are nothing more than a wish.  Metrics are necessary to make corrections as needed or, in some cases, set new direction.  Note that there will be a  metrics committee for each of the five categories.  Personnel may overlap,  but the different categories may need  individuals with specialized knowledge.

Our next blog will delve into IT Architecture.

1. Peter Weill, Jeanne Ross, “IT Governance”, 2004 Harvard Business School Publishing

Topics: IT Governance | No Comments »

Leave a Reply