David Downie, Partner, McCullough Robertson.
Use of scenarios to determine adequacy and effect
As a CIO, when determining which service levels to include in an agreement you should:
(a) run through scenarios of possible problems to ensure that the supplier will have failed to have complied with the service levels in circumstances in which the customer wishes to have a remedy;
(b) consider whether or not service levels that are not outcomes based are necessary i.e. does the interim step or measurement matter if there is an end-to-end service level that will be breached if the interim step fails?;
(c) be careful not to ask for a higher service level than is required, as generally the cost of complying with the service level will be factored into the fees payable under the agreement; and
(d) be conscious that the cost of monitoring and managing excess service levels is also likely to be reflected in the fees.
Device level and network level service levels
Where multiple devices are the subject of a service level consideration should be given to whether or not the service level is to be measured on a per device level or across the ‘network' or all devices. For example, it may appear acceptable that 99.9 per cent of desktops are available but if your organisation has 10,000 desktops then ten desktops can be permanently unavailable without there being a breach of a service level (try telling that to the CEO when he or she reports their desktop is permanently down!). By contrast, if the 99.9 per cent availability service level is to apply to each desktop then each desktop could be down for a maximum of just over 40 minutes per month assuming the metric is measured on a 24 hour basis. It may be that a combination of both device and network level service levels are applicable, although a CIO must be careful of overloading the supplier with monitoring and reporting obligations if service levels are used at a device level.
Classification of incidents
Service levels often depend on the classification of a situation. For example, a software error may be minor, important or critical depending on how it is classified (often by reference to a table in a schedule). Different response times may be specified depending on the classification. Ideally you will have the ability to classify the situation yourself rather than be subject to the classification of the supplier.
Monitoring of performance
Ideally suppliers would also be required to monitor performance against the service levels and provide reporting each month in a form acceptable to you. Sometimes suppliers are required to point out what steps they are taking to ensure the failure does not reoccur.
Change over time
As business requirements change ideally there would be some mechanism for changing the service levels in a contract over time. This may be by way of:
(a) a continuous improvement obligation under which service levels automatically improve each year; or
(b) by way of a change request or other scope control mechanism under which you have the ability to require the supplier to price a change.
Hard and soft service levels
It is important to look at the enabling words in the body of the agreement, as well as the words used in the service levels themselves, to determine whether or not the service levels are ‘hard', in the sense that they must be met, or if they are ‘soft', in the sense that they are targets only that the supplier must endeavour to meet. Obviously it is preferable that the services levels be binding on the supplier.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.