 |
 |
 |
 |
 |
 |
 |
 |
   |
 |
 |
| |
. |
|
An ongoing theme in my consulting work 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 that 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 this outside management seems 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 departments that use 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 inernal 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 a completely
different philosophy 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, with few specifics. 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 and 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, rigorous change control
and penalties for non-performance. 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: suppose 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, and for different companies.
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.
<><><><><>
|
|
|