The Digital Teenager in Year 2000

The Digital Teenager in the Year 2000

by William B. Bierce

As a teenager, I learned that date calculations in a foreign language do not always compute in the same manner as in English. Thus, in French, once you register sixty-nine, the next number is sixty-ten, and from sixty-nineteen you must jump to four-twenties, leading you to four-twenty-one and all the way to four-twenty-nineteen before attaining one hundred.

As "digital" teenagers (in the year nineteen hundred four-twenty-sixteen), today's population confronts the unknowns of translating between languages where meta-numbers may be required to make the transition to the next one hundred year marker.

As a technology lawyer, I recently concluded a breakthrough contract involving Year 2000 assessment, management and remediation for a global client with tens of thousands of software programs, tens of thousands of computers and a global telecommunications infrastructure. This article addresses some of the key legal and business issues which vendor and user will need to address.

Scope: Inventory and Assessment of Infrastructure Items. Consulting contracts contemplating the assessment, management and remediation of Year 2000 compliance for a company's electronic infrastructure need to start out with the definition of scope and what constitutes a satisfactory result.

The scope should include all electronic infrastructure items. When these items are limited and already inventoried, the process can proceed to management of the remediation function. However, no one has an inventory, vendor and user face the unknown together. In the face of this specter, the parties must allocate responsibility for any failure to obtain Year 2000 compliance which is attributable to an incomplete inventory.

To minimize this risk, the parties should start out with a list of asset classes which can then be used to look for hidden individual assets. Asset classes can include software applications, network operating software, middleware, telecommunications software, and hard-programmed date functions embedded in everything from an elevator announcement message to the guidance system for a corporate jet.

Success: When is an Infrastructure Item in Compliance? In contracts, the first place to look for the key issues is in the section containing the definitions. The critical definition in a Year 2000 consulting agreement is what constitutes compliance of an infrastructure item with the Year 2000 date. In general, this is the standard against which the user will assert a claim of warranty repair, and against which the vendor will stake its reputation for technological expertise in the years to come.

In my view, an infrastructure item must comply with several functions before it can be certified.

It must run without error the same baseline functionality that it has in processing calculations dated in the Year 2000 as it does now for processing calculations based on a date in the Nineteenth Century.
It must run without error during the Year 2000, based on such baseline functionality.
It must interoperate with other sources and destinations of inputs and outputs, when such sources and destinations provide or must receive dates of 2000 and beyond.
It must be compliant in such a time as to enable the outsourcing vendor (or its user, if the vendor is merely providing assessment, management and remediation services) to identify and resolve the interdependencies prior to any lost functionality attributable to date calculations.

Because of a global interdependency of inputs and outputs, interoperability could be the greatest challenge. If an outsourcing vendor or user knows now which inputs and outputs (especially in relating to its suppliers and customers, as well as governmental regulators) are likely to be unable to handle a four-digit year date, then no amount of housecleaning internally will enable that vendor or user to handle the Year 2000 date. It is this interdependency which suggests the prudent solution of chasing this problem early, so that dependent data feeds can be accommodated.

Pricing. Early adopters of Year 2000 consulting solutions may be able to obtain price protections through "most-favored-customer" clauses. A more difficult issue is the allocation of ownership of resulting tools developed, in whole or in part, at the user's expense, and the ability of the vendor to offer the same services, using the same skills developed for the early adopter, as for the early adopter's competitors. For this reason, early adopters should take special care to craft a suitable price protection so as to prevent the vendor from giving their competitors a price break.

Risk Allocation. Structuring a proper risk allocation between user and vendor requires some balancing of interests as well as commitments.

The easiest risk to allocate is who bears the risk that the vendor's remediation efforts on a known, given infrastructure item will fail to achieve Year 2000 compliance. A vendor's warranty is normally provided, which may be subject to the usual limitations on liability for consequential or indirect damages. The user may reserve certain claims against the vendor to have unlimited liability, such as for intellectual property infringement, gross negligence, willful misconduct, etc.

The greater unknown is the truant infrastructure item. The vendor and user jointly bear the risk that a truant infrastructure item will, like a teenage counterpart in the Year 2000, will fail to get the remedial training necessary to cope with Year 2000 date calculations. A properly drafted Year 2000 consulting agreement, or outsourcing agreement, will define who will be responsible for:

omissions in inventory, and
timely remediation, especially when the discovery of truancy is made late in the game.

A truant officer must be appointed. Perhaps jointly, vendor and user combine their efforts as truant officers, and share the risk of omissions.

Structuring a legal agreement to cover these risks involves a certain ambiguity. For the reason, a project management framework can work to delineate with specificity the tasks ahead, and the milestones and outcomes desired.

Conclusion. Year 2000 compliance poses technological and legal issues. Transition to the year 2000 is not just a question of time, it's a matter of coming of age.

Back to Main Menu