Lurking somewhere in most IT infrastructure outsourcing agreements – often in an appendix to the pricing schedule, and sometimes buried even more deeply than that – is a list of what are usually referred to as ‘resource units’ (or RUs). Put simply, a resource unit is what gets counted in calculating the charges. Resource units are the ‘Q’ in a P*Q pricing model or, more commonly in the outsourcing context, the items that are counted and compared against a baseline volume to determine whether an additional resource charge (ARC) or a reduced resource credit (RRC) is applied to the base charges.
A well-constructed set of resource units can help to ensure that the charges reflect the value of the service to the customer and incentivise the right behaviour on the supplier’s part. Equally, poorly constructed resource units can undermine the entire commercial deal. Customers often make much of the fact that they want an ‘output-based’ service and draft a service description and a set of service levels with this in mind. But this whole approach is thoroughly undermined if the supplier is nevertheless entitled to charge based on technical elements of the service over which the customer exercises no control and that bear no relation to the value delivered to the customer.
In this article, we’ll consider how to ensure that resource units reflect the customer’s objectives and incentivise the right behaviour. A couple of preliminary points. First, this article is largely written from the perspective of the customer rather than the supplier. Suppliers may well have different views on a number of the issues discussed here, but the basic principle that both parties should have the same understanding of how the pricing model operates ought to be uncontroversial. Secondly, we assume that the customer is prepared to give the supplier a measure of control over the architecture and design of the services and to focus instead on outputs. If the customer is determined to micromanage the architecture and design of the services, the supplier will have a stronger case for basing the resource units on the technical elements of the services, since that will reflect more closely how the customer is driving demand.
Defining resource units
The most important point is that the resource unit definitions should be clearly drafted. This may sound obvious, but the resource units are too often considered ‘technical’, ‘commercial’ or ‘financial’ subject matter in which lawyers have no business getting involved. If there’s one thing to be taken away from this article, it’s that this approach is likely to give rise to disputes and should be avoided.
There should also be a clear connection between the resource units and the services, and ideally specific services within the service description. Again, this may sound obvious, but resource units are often defined without any reference to any particular service (or even to the services at all). This fails to take advantage of the work done by the parties in drafting the service description and can lead to inconsistency between what is supported through the services and what is charged for. In an extreme case, and in the absence of a clear connection between the resource unit definitions and the services provided, a supplier could be entitled to count (and charge for) items that fall within the definition of a resource unit but that have not been requested by the customer and are not even supported through the services.
For example, “a GB of allocated storage” is not ideal drafting for a resource unit definition. It raises questions about which storage is to be counted for these purposes, how it is to be allocated and who allocates it. In contrast, a definition that both refers to the specific service through which the storage is provided and makes clear that the allocation of the storage must have been requested by the customer (e.g. through a catalogue request or a request for service) leaves less room for disagreement about what falls within the resource unit, and less scope for the supplier to charge for items that the customer has not specifically requested.
What makes a good resource unit?
The basic rule is that the resource units should be driven by customer demand rather than by design choices made by the supplier. If the resource units measure aspects of the service that are determined by the supplier rather than by the customer, then at best the charges may not reflect the value that the service is delivering to the customer, and at worst the charges are susceptible to manipulation by the supplier and incentivise inefficient service design.
As an example, within a data centre service tower, it is preferable to count only application and database servers (that is, servers hosting applications and databases) than to count infrastructure servers (servers hosting infrastructure services such as Active Directory, file and print services and network services such as DNS and DHCP). The reason is straightforward: whereas the customer’s applications team will directly request the provision of application servers, thereby determining the number of applications servers deployed, this is not the case with infrastructure servers – the customer will expect to receive an infrastructure service (e.g. Active Directory), with the number and configuration of the servers providing that service left to the supplier. In agreeing to a pricing model that counts the number of infrastructure servers deployed, the customer either needs to retain a degree of oversight and control of the design of the service (such as prescribing a maximum number of servers for a given user population), or else cede control of this element of the charges to the supplier, who can determine the number of infrastructure servers deployed.
Similarly, whereas a customer would reasonably expect to pay for storage that has been allocated to database servers and provisioned at the customer’s request, the customer would not typically expect to pay for storage consumed by (for example) swap files or page files, the size of which is determined by the supplier. So, as with servers, storage resource units should count only storage allocated and provisioned at the customer’s request, and not count storage provisioned at the supplier’s discretion.
None of this is to say that the supplier should not be able to recover its costs of providing infrastructure servers and associated storage – no reasonable customer would expect these to be provided free of charge. The point is that these costs should be recovered through resource units the quantity of which is determined by customer demand, with the supplier using its expertise to make some reasonable assumptions about the likely magnitude of these costs (for example, the number of Active Directory servers that will be required to support a given number of end users).
Avoiding double-charging
Some services directly or indirectly consume other services. Take, for example, an email service: the resource unit would typically be a user (each user with a mailbox). However, underpinning the email service is a number of email servers – for example, Microsoft Exchange Server, running within a Windows Server environment. Can the supplier merely charge for each email user? Or can they, in addition, charge for each server running Microsoft Exchange Server (on a per-server basis), for the storage consumed by each mailbox (on a per-GB basis), and for every other underlying service that has an associated resource unit? This is often left unspecified, but obviously can lead to substantially different outcomes.
Getting the granularity right
There comes a point in the construction of a pricing model when somebody realises that the baseline volumes for a number of resource units are the same. For example, within an end user tower, the number of end user computing devices (such as a desktop or laptop device), mobile devices, users receiving deskside support and email users may well be the same, on the basis that each user receives all of these services. The natural response to this is to collapse these resource units into a single resource unit – end users – reducing the number of items to count.
The difficulty with this approach is that it makes it much more difficult to separate out the individual services in the future. Take, for example, email. The customer may well want to migrate from an on-premise solution to a cloud-based solution. If there is a separate resource unit for the email service, then the customer can simply terminate the email service for convenience and remove the email resource unit (more on this later). However, if there is a single resource unit for end users, whilst the customer can terminate the email service for convenience, the number of end users will remain the same and, because the charges are determined by the number of end users, there will be no automatic reduction in the charges.
The mechanics of counting
One area that can sometimes give rise to disputes is exactly how resource units are to be counted. Even where the parties have a clear agreement about what constitutes a resource unit, and the resource unit definition itself is unambiguous, the parties may disagree about how many of those items are actually deployed and supported at any one time. Unsurprisingly, this tends to be an issue in large, complex, global IT estates, where adopting different methods of counting (such as using automated discovery tools as opposed to tracking installations and de-installations against an assumed starting-point) can lead to radically different results.
Partial termination
Finally, and returning to partial termination, contracts often focus on the customer’s right to terminate individual components of the services (for example, by dividing the services into service towers, or a level below that), with termination compensation allocated between those components accordingly, but fail to make clear exactly which base charges are removed along with each component. However, if terminating a component of the services does not also remove a corresponding component of the charges, there is often very little point in exercising that right. The customer will have to pay another third party for the replacement service (or bear those costs itself in the case of insourcing), whilst still paying the incumbent supplier for a service the customer is no longer receiving.
