Projects

Change Control Process

There are several contractual methods of protecting against "scope creep" in projects ie having to deliver more than you intended when costing the project. The most obvious is inclusion and use of a change control process. With the correct contractual drafting together with experienced project management, change management can prove to be an effective revenue stream. Obviously the specification agreed for a development and the change control process are closely interlinked, and it is important that this relationship is recognised and addressed in the contract.

Delivery

There are several contractual protections that you can build into your development agreements to minimise your liability in the event that you fail to deliver in accordance with fixed date milestones. These can often prove to be one of the most important risk management provisions in the contract, and you should ensure that your delivery team contributes fully to the content of the contractual provisions set out below.

Customer Obligations and Dependencies

Each development project should itemise each of the obligations and dependencies of the customer. Whilst project plans often contain risk registers to aid risk management of the project, these risk registers do not provide you with risk management of your contractual obligations unless the necessary drafting provides for this. Timely sign off and decision making by customers and, access to customer staff and systems should be included as standard provisions and for each project the delivery team should document the specific obligations and dependencies on which the timely delivery of the project rests and these should be included in the contract.

Having ascertained what the obligations and dependencies are, and ensuring that your customer is contractually bound to deliver them, the contract should ensure that you are not liable for any delay or failure by them so to deliver. Additionally, if they are liable for delay in delivering a milestone in respect of which you should receive payment, the contract should ensure that you will still receive the payment on the contracted milestone date regardless of the fact that the milestone has yet to be delivered.

The contract should contain all third party obligations and dependencies on which your project delivery relies.

The key contractual imperative in respect of third parties is to ring fence your delivery obligations and ensure that you do not assume any integration or interoperability obligations unless you have scoped them and costed to do so. If you do not make it clear that your system might not work with the customer's legacy or other supplier systems without some interface coding or similar integration work, you may well find yourself liable to ensure that it does so, without having the right to charge for such work.

Acceptance

If your deliverables are subject to acceptance testing, it is vitally important that the contract dictates a process that provides you with sufficient protections and assurance that your charges will be paid.

The contract should stipulate what measurements the product will be tested against ie you should agree and document, before the commencement of the contract, who will write the acceptance test scripts, what documents they are intended to measure the performance of the product against, who will conduct the tests and what will constitute acceptance.

This is obviously most significant if payment of all or part of your charges are linked to acceptance, however even if the charges are not directly linked to acceptance, you will need to ensure that the acceptance process is documented and complied with in order not to fall foul of revenue recognition policies.

If the customer either drafts the acceptance test scripts, or conducts the tests, the contract should provide for you to have input into customer's processes to ensure that the acceptance tests are limited to testing the delivery of the product that you have contracted to deliver rather than, for example, testing a whole solution of which your product only forms part.