Negotiating a contract
Once you have selected a preferred supplier you are likely to be very keen to get on with implementing your VLE but you still need to take considerable care over the process of contracting with them. A well drafted contract will protect both parties interests.
Suppliers have told us that the higher education sector as a whole is getting much better and more businesslike at procurement and that universities and colleges are much less likely to sign up to suppliers standard terms and conditions than they were in the past.
It goes without saying that establishing a contract with a supplier is a task that requires specialist input from your own legal advisers. This section merely offers one or two pointers to think about.
Recognise that your standard contracts may need some customisation and be aware that contracts for software as a service (SaaS) may look very different to those for desktop software.
Allow suppliers to say what their fixed constraints are and offer alternative language that allows you to meet the same objectives as your own contract.
There may be a number of areas where you are entering into a contractual obligation with the supplier and the 'contract' itself may be made up of a variety of different documents covering areas such as:
- Customer requirements - you are likely to want to include your specified requirements and the supplier's response to them as part of the contractual documentation. Your original specification may require some amendment if the supplier is unable to meet the requirement exactly as stated or has committed to future delivery of functionality.
- Implementation plan - this may be required if you are purchasing consultancy services from the supplier. At this stage it can only be an outline plan but there should be agreed change control procedures for deviance from it.
- Payment schedule - staged payments may give you some protection should things not go according to plan but may only be possible where the supplier is also providing implementation services.
- List of goods supplied - where some or all of the infrastructure is hosted on site you may be purchasing a bewildering array of products and need a clear listing of what products (and what versions of those products) will be supplied.
- Use of the system - there are likely to be licensing terms with regard to who can use the system, numbers of concurrent users in particular environments and, particularly if there is any form of social networking component, there may also be some form of acceptable use policy.
- Service level agreement - including a clear set of service standards and compensation arrangements if the standards are not met. This usually excludes responsibility for service outages from such causes as scheduled maintenance or internet connectivity problems. The compensation is likely to be in the form of a credit for future use of the supplier's service and you are likely to have to apply for such credit.
- Support agreement - providing details about service response times, upgrade schedules etc. You need to check whether the contract restricts the number of people who can contact the supplier's support team. Some suppliers require you to identify only one or two named individuals who can contact them and there are additional charges if anyone else logs a support request.
Understand how your supplier calculates system availability.
Providers typically advertise availability promises as uptime percentages ranging from 99.5% to 100.0%. These are strong claims, and care is needed to understand how these percentages are calculated. Often, the percentage applies to the number of time intervals within a billing cycle (or longer periods such as a year) in which services are not "up" for the entire interval. Examples of time intervals used by prominent providers are 5 minutes, 15 minutes, and 1 hour. For example, if a provider specifies an availability interval of 15 minutes, and the service is not functional for 14 minutes, 100% availability is preserved using this metric. Generally, the definition of “up” is intuitively defined as service responsiveness, but in some cases, multiple cloud subsystems must fail before the service is judged as unavailable.
US National Institute of Standards and Technology, Cloud Computing Synopsis and Recommendations 2012, p3-1