Legal Aspects of Project Management

This guide to Legal Aspects of Project Management has been prepared by the Computer Law Group of Clark Holt, Commercial Solicitors. Project management is an under-rated art. This is ironic in view of the fact that there is a chronic shortage of skilled project managers in this country. This guide concentrates on the legal aspects of project management, particularly in relation to the computer industry, and aims to provide some suggestions to help avoid a project turning into a disaster. 1. Risk Management

There will always be a chance that a project will not turn out as expected. Successful completion of a project therefore requires that this risk should be considered and evaluated. A risk management plan should be drawn up to show how each significant risk will be controlled. A "top ten" list of risks in software projects is shown in the Appendix at the end of this guide with, in each case, various suggested risk management techniques. Some of these techniques are implemented through the contract for the project itself. 2. Project Contract

It is in the drafting of the project contract that lawyers will generally make their greatest contribution. In many cases it will be vital that ALL pre-contractual documentation is referred to in the contract. Such documentation should include the Statement of Requirements ( SoR) or the Request for Proposal (RFP) or the Invitation to Tender (ITT) and the suppliers response. Arguably, the lawyer will have completed half of the responsibility of protecting the user if this is achieved. Some of the documentation may have been superseded so only the most recent version should be used. The documentation does not have to be attached - a cross reference to the most recent version is sufficient, provided that the parties can readily indentify it. The contract must contain provision for change control and progress review meetings. 3. Change Control

Changes to the project are almost inevitable. They can be divided into (1) those instigated by the supplier and (2) those instigated by the user. Changes requested by the supplier are generally caused by a weakness or uncertainty in the design. Examples include a weakness in the design architecture or an over optimistic projection by the designers of the performance of the system. Or perhaps an innovative solution may turn out to be more impractical or more difficult than originally envisaged. Changes to requirements are normally the responsibility of the user. Such changes should be discouraged because, apart from the cost implications (which increase the later the change is made), any design modification is disruptive and too much change may de-stabilise the project. The project contract must contain a detailed change control procedure which allows changes to be proposed, costed and settled. Sometimes the cost of estimating the additional costs of the change are borne by the user if the user decides not to proceed with a change it has proposed. All agreed changes should be documented and numbered for future reference.
1

4.

Progress Review Meetings

These are vital in a well-run project and will become more frequent as the project progresses. They may have a variety of causes such as:(a) (b) (c) periodic reports (eg. every two weeks); the completion of a particular stage (ie. an "end of stage" meeting); or a requirement for an outside independent appraisal of the projects progress.

The aims of such meetings will include: (1) (2) (3) (4) comparing progress with the planned schedule; deciding how to tackle actual or potential problems; forecasting progress; and examining costs.

Such meetings should be properly documented and minuted (with the minutes going to all parties). An agreed list of action points arising from each meeting and their times for completion should be prepared and reviewed at following meetings. 5. Restrictions on the Supplier

It is common to impose restrictions on a supplier under the project contract and so it should be considered what restrictions are appropriate. One obvious restriction is to require the supplier to keep confidential any confidential information given to it by the user. Another is to prevent the supplier from "poaching" any of the users staff or customers. If the project involves specialised techniques it is sensible for the user to consider a restriction on the supplier against providing the same techniques to the users competitors. 6. Restrictions on the Suppliers Liability

It is standard practice for consequential and indirect losses to be totally excluded from computerrelated agreements. Suppliers will always seek to ensure they are only liable for direct losses ie. those reasonably foreseeable as a result of a breach of contract. Most customers accept the exclusion of consequential loss and it is only worth debating the point if there is a particular principle involved. Suppliers will also seek to have a financial cap on their liability under the contract. For such a cap to be enforceable in court generally it must be reasonable. One factor which courts look at in determining this is the insurance cover that the supplier has, so consequently that level often determines the amount of the financial cap.
2

Project Management properly carried out can have a significant effect on both the costs and time of completion of a project. The legal aspects of project management can be very useful in establishing appropriate procedures and parameters within which such management can be carried out. __________________________________________________

Appendix MANAGEMENT OF SOFTWARE PROJECTS A top-ten list of software risk items:Risk Item Personnel shortfalls Unrealistic schedules and budgets Risk Management Technique Staff with top talent; team/morale building cross training; pre-scheduling key people Detailed/checked cost and duration estimates; design to cost; incremental development; re-use of software; requirements scrubbing Organisation/mission analysis ops concept formulation; user surveys; prototyping; early user manuals Task analysis; prototyping; scenarios; user profiles (functionality, style, workload) Requirements scrubbing; prototyping; costs-benefit analysis; design to cost; value engineering High change threshold; information hiding; incremental development (defer changes to later increment) Benchmarking; inspection; expediting; reference checking; quality auditing; compatibility analysis Reference checking; pre-award audits; fixed price contracts; competitive design/prototyping; team building Simulation; benchmarking; modelling; prototyping; instrumentation; tuning Technical analysis; cost benefit analysis; prototyping; reference checking

Developing wrong functionality

Developing wrong user interface Gold plating Continuing changes to requirements

Shortfalls in procured components Shortfalls in sub-contractual tasks

Shortfalls in real-time performance Straining the capabilities of computer science

Source Boehm, B.W. A spiral model of software development and enhancement. Computer, May 61-72. The Institute of Electrical and Electronics Engineers.