But use of consultants can also be disappointing and risky. What are the potential legal pitfalls associated with the use of IS consultants, and how can problems be minimized?

The place to start is to put the full relationship in writing. A written document clarifies the expectations and responsibilities of the parties and extends the time during which the consultant can be held responsible if problems develop. In addition, a written agreement may be essential to secure certain legal rights, including the ownership of the resulting work product, such as computer programs.

The following six core elements are important in a successful IS consulting contract:


SERVICE/WORK DESCRIPTION

A clearly written description of the consultant's scope of work can go a long way toward avoiding later problems. The description should contain a statement of general work scope, plus a listing of specific deliverables, expected outcomes and responsibilities of the parties.

In a software development project, the description should include detailed specifications for the software program, or it should describe a process for specification development and acceptance prior to further work. The business hiring the outside consultant should remain flexible to reasonable changes as the project progresses. It should expect to pay for changes or added costs caused by a change or expansion of its requirements.


SCHEDULE

Sophisticated IS projects need to be managed. Think of the schedule as a management tool, not just as a series of due dates. Develop progress points, interim benchmarks and critical path analysis to guide the project.

A written schedule provides early warning signals for problems and can require corrective steps by the parties. If the agreement provides for IS system or software implementation, the schedule should identify and logically sequence conversion, testing, cut-over and any parallel operations requirements.


ACCEPTANCE CRITERIA/PROCEDURE

A complement to the service/work description, this provision details the checkpoints along the way to an acceptable final result. The acceptance procedure should verify whether a project is successful, based upon the work description. It may also suggest corrective actions if there is a problem and identify performance shortfalls.

Software acceptance testing should almost always involve testing in a production setting. As with the schedule, a creatively structured acceptance process can identify problems before corrections become too costly. For example, a software development contract may provide for stand-alone testing of key modules before they are incorporated into a larger and more complex system.

Because final acceptance typically triggers a final payment, the business usually needs all significant corrective work to be done before final acceptance. The IS consultant must guard against unreasonable delay in getting paid occasioned by endless testing cycles, unreasonable correction requirements, and/or ill-defined or overly subjective acceptance standards.


OWNERSHIP

We hear it all the time: "I paid for it, so it's mine — right?" In truth, probably not. If the parties are silent on ownership, the consultant is likely to own the copyrights (e.g., literary works, graphics or computer software) and/or rights to patent that may apply to the work product. The company may only get a nonexclusive right to use the work product. This is not ownership.

For a technology-dependent company, a failure to own or control the work product may be fatal. Conversely, a consultant who yields all ownership and control of the work product may be unfairly precluded from use of general know-how, methodologies and techniques in subsequent consulting assignments. Only a written agreement can provide certainty regarding ownership and control of the work product and divide it between the parties as appropriate to the particular consulting assignment.


COMPENSATION

Beyond specifying the elements of compensation and reimbursable expenses, a company can creatively provide an IS consultant with appropriate incentives for successful project completion. Final payments should almost always be big enough to serve either as a carrot to induce completion, or to pay for any additional or replacement work that may be required.


WARRANTY

The warranty provisions set the standards of both performance expected of the consultant and quality by which the finished work is to be judged, and give assurance of unrestricted rights of ownership and/or use. Warranties go further than simple acceptance criteria. They give continuing comfort that unacceptable work will be corrected, even if a problem is discovered after acceptance.

Warranty issues usually arise after the work is in use by the business. Therefore, remedies for a breach of warranty should be meaningful, practical and effective. For example, a mission-critical software system cannot be taken off-line for lengthy fixes without potentially disastrous results for the business.

In this case, the warranty arrangement might provide for a back-up or parallel system, or off-hours corrective work and testing. So too, businesses need access to source code, schematics and programming notes to facilitate software maintenance and fixes if the consultant doesn't fulfill these obligations.

In summary, putting the arrangement in writing reinforces the need to establish clearly the objectives and challenges of the project and the obligations of each party. A written agreement can settle key legal matters (such as ownership/use rights), reduce the risk of serious disputes, and increase the probability of a successful project for the business and the consultant.