Schedules and Related Documents

Your contract will include a set of appendices or schedules that provide supporting detail referenced by clauses in the contract. The following are likely to be needed for most systems purchases.

Customer Requirements

A list of the customer requirements that the supplier is undertaking to meet. This may be taken from your ITT but it is likely to require some amendment if there are areas where the supplier is unable to meet the requirements as originally stated. It is particularly important to include the specific agreements about areas where the supplier has promised to meet a requirement with a future release of the product.

This is sometimes termed a functional specification or a Statement of Requirements. A more in-depth look at this area is available in the System Selection infoKit.

List of Goods Supplied

Many of the larger systems can be composed of a bewildering array of products e.g. database, operating system, various application modules, reporting tools, workflow tools etc. You need a clear listing of what products (and what versions of those products) you are purchasing. We refer to single or multiple supplier situations above - it may be that during the pre-sales demonstrations you were shown third party products, such as reporting tools, that integrate well with the supplier's product. Now is the time to do a final check that the purchase list includes all the items you expected.

Plan

An outline plan that highlights the key implementation milestones. The plan is bound to be subject to change but you should start with an agreed baseline and adopt formal change control procedures to handle deviation from the plan. If you are unable to develop the plan before you sign the contract, you should at least refer in this schedule to a plan to be agreed and specify a time limit for reaching agreement.

Payment Schedule

A payment schedule that references the milestones in the plan. A piece of software is of no use to you unless it can be delivered as a working solution in your environment. Where you are partnering with a supplier on implementation, it is reasonable to pay against delivery of agreed objectives rather than simply pay up front. This is particularly important in relation to implementation consultancy which can eat up a large proportion of any implementation budget. Staged payments give you some leverage in the event that the consultancy does not deliver the expected results or overruns the agreed budget. Follow this link to read our article on managing consultancy input to projects.

Support

Details of your support agreement with the supplier. This should include a clear set of service standards in relation to:

• Hours of service
• Response times for issues of differing severity
• Method for agreeing problem severity
• Transparent tracking mechanisms
• Escalation procedure