In this installment, we look at the firm’s mind-set as it embarks on this sort of project. We then cover some of the principal legal and commercial points that every Utility Computing contract must cover, just to establish the outlines of the project. In coming weeks, we will deal with the issues involving possible collisions between vendor and user, the major employment issues, and some of the special concerns involving differences between Anglo-Saxon practices versus those on the European Continent.

Avoiding the ‘Eyes Wide Shut’ approach

Any contract spells out the division of risks and the division of roles. Thus, first and foremost, neither party can forget its respective primary role. The customer must maintain control over strategic planning. The supplier from its side must manage the supply over the long-term.

It can otherwise go badly wrong. And while it may be too soon to draw many lessons from the course of Utility Computing projects, the same cannot be said for outsourcing projects, with which Utility Computing projects can be said to be largely analogous.

In April this site reported a study published by IT consultant Gartner that European companies in 2002 wasted EUR 6 billion due to poor deal structures and poorly managed relationships with IT outsourcing companies (Gartner Says Outsourcing Grows in Declining European IT Services Market, UtilityComputing.com 2003/04/28).

That means that the management of both user and supplier in those projects dropped the ball. According to Gartner, the cost of that fumble amounted to up to 15% of the whole project.

Doing it right requires up front investment in time and resources. What’s needed from both parties before the first keystroke on the contract is the mobilization of long term skills, processes, resources and governance structures. A successful project will run for years, with all the changes and uncertainties that will bring. That requires diligence and on-going effective management.

“Who does what to whom for how much?”

Preparation aside, those eight words may be the key in getting the project contract right. Oddly enough, lawyers are as much to blame as anyone for not paying enough attention to an adequate scope description. There is a tendency, we’ve found, to think of scope as a technical matter. Yet it lies at the heart of the relationship.

Closely related are the Service Level Agreements. As the processes that are the subject of the project can be critical to the functioning of the user, the user must know before-hand the maximum amount of downtime it can expect in any given period.

Here, disincentives for poor performance are not necessarily the best or only solution. Properly designed incentives for good performance, coupled with the payment mechanism, reporting requirements and escalation can also be effective to avoid unplanned blackouts.

Perhaps the knottiest problem of all is the question “for how much?” Companies embrace Utility Computing in large measure for promised cost savings. The cost savings, we’re told, will come from economies of scale and utilities’ classic pay-as you-go approach.

Yet it is that very analogy to utilities that set off alarm bells for MIT economist Michael Schrage. He wrote at CIO.com that understanding the cost structures of how the old classic utilities provided service was nigh-on impossible. He blamed them for “concealing, manipulating and cleverly reallocating their costs, at least until some serious competition comes along” (The voodoo economics behind Utility Computing, CIO.com 2003/05/15).

All the more reason, then, for the users to do their pricing homework. They need first to establish a baseline. How much does IT cost now? Only then can they intelligently talk about how to price it during the project. Benchmarking offers a possibility to test the pricing structure during the project and signal the need for an adjustment, but it implies, of course, that there’s something comparable in the market against which to benchmark.

Many companies have found that careful “financial engineering” is a way to help structure and pay for the deals. For instance, offshore structures, special purpose vehicles, partnership structures and securitization of income flows are becoming more common. One thing is clear. One size in this area does not fit all.

A hallmark of these projects is that they are long term. That has the effect of driving the unit cost down, but at the same time, driving up uncertainty and risk. The parties must build in a system for agreeing to and implementing changes, while at the same time, controlling the costs of those changes.

Another given is that the user has legacy equipment in house. These may have come from, and are being maintained by, third party suppliers. Undoubtedly the programs being run are under license from other third parties. If it’s functionality that the user needs outsourced, then something must be done about the legacy equipment, and the many license arrangements that were left hanging or that will come into being. If the legacy equipment will be used in the project, then it may have to be maintained by someone not party to the project contract. If licenses must be secured for the new arrangement, then the supplier must be able and willing to get all the concerned parties on board to the extent necessary.

A good beginning needs a good end

One final provision that can’t be overlooked in the beginning is the ending. How can the user terminate the relationship with the provider without disrupting the enterprise? The user must know before-hand how it will migrate to a new system, and to what extent the provider will help.

The considerations sketched here outline some of the important elements that define the nature and shape of the project. Getting it right requires the effort to be applied ahead of time. But the process pays off. The parties go into the project with eyes wide open.

Alan Steele-Nicholson is head of the IT-Telecom law department in the Rotterdam, the Netherlands, office of the global law firm Simmons & Simmons, and can be contacted on alan.steelenicholson@simmons-simmons.com. Peter Brudenall is Senior Lawyer in Simmons & Simmons’ London office, and can be contacted on peter.brudenall@simmons-simmons.com. Both are specialists in IT and telecom outsourcing law.