Some Thoughts About IT Governance

An ongoing theme in this blog is that many of the issues that executives face in managing IT have counterparts in other areas of management, and that IT leaders and business leaders have much to learn from one another about how to address these common issues.

Another kind of insight can be gained within IT by comparing different activities within IT with one another. Outsourcing is a case in point.

I recently attended two seminars on outsourcing. At each of them, there was considerable discussion of the issues that arise in negotiating and managing the outsourcing relationship, both in the sessions and in the breaks. These experiences got me thinking about how managing an outsourcing relationship is different from managing the relationship between an internal IT shop and its user communities, if indeed it is different.

As we shall see, although the goals are always the same – put IT into the service of the enterprise effectively and efficiently – the governance of outsourced IT is quite different from the governance of internal IT. Each mode has something to teach the other.

I use the term “IT governance” to describe the relationships between IT and the users of its services. (This is in contrast to the term “IT management”, which deals with the internal activities of the IT function.)

“Outsourcing” is a state of mind. Business processes are characterized as outsourced when they are moved from the legal and managerial jurisdiction of the users of the processes in question, and placed under the control of an independent entity. Typically most businesses have activities controlled and managed by other companies. Examples come to mind include the company cafeteria, corporate cash management by banks, and operations of office buildings. But we don’t typically call them outsourcing because they seem to be our normal mode of doing business. The outsourcing epithet is only applied when something that has been done internally is moved to external ownership and control.

Note that from a logical point of view, a staff department (say HR or IT) is really an outsourcer to the line department that uses its services.

A few years ago, I had occasion to examine a Request for Proposal (RFP) for outsourcing from a fairly large multinational corporation. The RFP was limited to managing and operating its mid-range servers, with the idea that success at this level would be a prelude to a much larger relationship. The RFP occupied four 8 ½” x 11” three ring binders, each containing about 1,000 pages.

Needless to say, there was no analogous document governing the internal activities that the outsourcing would displace. Apparently the company doing the outsourcing was willing to govern its mid-range servers with much less formality than it would accept from an outside contractor. Why?

Before we address that question, let’s look at two parallel examples.

When United States based companies began to do serious business in Japan about 20 years ago, they encountered an unexpected roadblock. (Actually there were many roadblocks, but I want to deal with only one.) This road block was completely different philosophies of business contracts. The Japanese were accustomed to broad agreements about goals and roles, with details worked out as the work was executed.

United States companies held an almost completely opposite view of what a contract should be. They believed in detailed contracts specifying all activities and all conceivable contingencies. The Japanese type of agreements were viewed by US companies almost as Letters of Intent: statements of broad goals, hopes, and wishes. It has taken years for these differences to be accommodated in the practical world of business.

The analogy with outsourcing is this. Most US companies are willing to use Japanese-style IT governance with their internal IT shops, but insist on detailed US-style contracts to govern outsourced IT activities. Why?

An example from outside the sphere of IT is informative. Globalization of financial markets has pointed up differences in accounting standards between the US and Europe. These differences are usually characterized as European standards stating broad principles and leaving it to companies and their accountants to apply these principles, whereas the US approach is to prescribe detailed rules for all conceivable contingencies. There are currently significant international efforts under way to resolve these differences. Again, why?

The glib answer to Why? is that our culture is different from the culture of Japan and from the culture of Europe. This, of course, is a tautology, because culture is defined, roughly, as “the way we do things around here.”

Another answer to Why? is that being a technology based society, we in the US have come to expect more precision and predictability than the typical letter-of-intent contract provides.

A third possibility is that the US is a litigious society, and lawsuits with vendors and contractors are much more common than lawsuits or their bureaucratic equivalent among divisions of the same legal entity. Detailed contracts are an attempt to prevent litigation; or to provide protection if litigation ensues.

We could go on, but the Why? question is too big for this forum.

Instead, let’s think for a moment about what to do to bring these competing philosophies together in order to do a better job of IT governance in either situation.

Next time you are planning a project for internal development of a new information system, ask yourself what contractual commitments you would require if you were outsourcing the project. You would probably require meeting functional specifications, fixed or computable price, pre-specified time schedule, and rigorous change control. You might even require that certain people be assigned to the project (and that certain others not be assigned.)

Now look at the reverse situation: you are planning to outsource the same kind of development. Would you be willing to give the outsourcing contractor the same flexibility in design and specification that you would give your in-house shop? If not, why not? How would you specify conformance to corporate IT architecture and other standards, things you would expect your internal staff to honor without any discussion?

A good place to start in each of the scenarios above is to focus on the functionalities and benefits to be achieved, rather than on technical and organizational requirements.

Which brings us to a much broader question: how much can you and how should you incorporate the outsourcing company into the operations and decision making processes of your company.

For more than a few years we have been inundated with advice from the organizational and leadership gurus saying that the way to success is to emphasize teamwork in the interests of corporate success, and correspondingly deemphasize the organization’s hierarchy.

The ultimate outsourcing question is this: how far are you willing to go in making your outsourcer a member of your team, a true partner? Or, in other terms, do you want the outsourcer to contribute its creativity to your project, or do you just want a bunch of designers and coders? There will probably be different answers for different projects.

As we observed earlier, internal staff supporting business operations are outsourcers logically if not psychologically. So, when doing a project internally, do you want the IT department to contribute its creativity to your project, or do you just want a bunch of designers and coders? Are you willing to make the IT department a full member of your team?

I think you should.

<><><><><>