Operating level agreements (OLA) aren’t exactly new to IT. Unlike service level agreements (SLA) between an IT organization and its service provider, OLAs state how particular parties involved in the process of delivering IT services will interact with each other in order to maintain performance.

“By establishing OLAs between these groups, the IT function can provide the appearance of seamless service to the business,” says Edward Hansen, partner with law firm Baker & McKenzie.

Until recently, OLAs were most often internal to an IT organization or a single large service provider, ensuring that the groups within the organization were working together to deliver IT services. But with the rise of multisourcing, OLAs are back in the spotlight.

“In this context an OLA becomes a record of shared assumptions and interdependencies at the level of processes shared and intersecting between each of the multiple parties engaged in the delivery of services,” says Les Druitt, founding principal of outsourcing consultancy Sourcing Advisory Services. “It is where the rubber meets the road in a multi-party outsourcing.”

“It has become more and more important for the ultimate customer to know that the relationships and interactions among these multiple parties are well-known, documented in clear and precise language, and reflected in binding agreements that can be enforced-if necessary-by the customer,” says partner Robert Zahler, partner in global sourcing group at law firm Pillsbury.

How to Use OLAs in a Multi-Sourced Setting

Establishing OLAs in the multi-sourced environment, however, is inherently more difficult than instituting them within a single organization.

“There is limited understanding of this new role, what level of description is sufficient, the role the OLAs play in validating both pricing and solution assumptions, and in facilitating continuous improvement,” Druitt says. “Creating OLAs for the purposes of documenting and confirming how solutions will play in harmony requires a collaborative process to arrive at a set of documents that all parties respect and support.”

Here are nine dos and don’ts for establishing OLAs in the multi-sourced IT environment.

1. Do expect bumps in the road. “Establishing OLAs requires a service provider to clearly understand their own processes and [to be in] harmonious agreement with peer providers about the role each is to play within those processes,” says Druit. OLAs for mature processes, such as incident management, will be easier to establish than for other areas. “It can be a struggle when process maturity levels differ significantly between providers,” adds Druitt.

2. Don’t let service providers hijack the process. “Often the service providers are most interested in those OLAs that are necessary to support the performance of their delivery against a client’s SLA,” says Druitt.

One provider may not be able to meet an SLA commitment for incident management unless another provider commits to certain hand-offs and time frames. “OLAs are a powerful tool because they document a powerful process. But that process is not talking to your service providers to see how they’re going to behave with each other,” says Hansen.

“The really powerful process involves the internal discussion between the IT groups and the business to determine how the service needs to be provided in a sourcing-agnostic manner,” Hansen says.

3. Do address OLAs before RFPs. “Customers often fall into the process by first executing multiple outsourcing contracts, and only then recognizing that they need to coordinate and integrate activities across these various outsourcing contracts,” says Zahler. “OLAs should not be used after-the-fact to document relationships that have just developed over time. Rather, OLAs should provide the roadmap for how those relationships should be established in the first instance.”

An OLA can be useful in helping to draft an RFP for services, says Hansen of Baker & McKenzie.

4. Don’t outsource accountability. Establishing OLAs between service providers does not absolve IT of responsibility. “The CIO’s organization must be responsible for the service across the board,” says Hansen. “Failing to do this results in finger-pointing and business users who feel at the mercy of outside service providers regardless of the OLAs.”

It’s a good idea to establish internal OLAs first, advises Hansen. “This has nothing to do with how hard or easy you will be on your vendors. It only has to do with making sure that the IT organization and the business realize and internalize that outsourcing does not mean they are off the hook.”

5. Do be clear and concise. It can be tempting to overthink OLAs and litter them with legalese and IT jargon. Resist. “There’s usually no reason to get too bogged down in the formality,” says Hansen. “The most important thing about OLAs is that they have to be readable and understandable by both business and techie readers.”

6. Don’t accept business OLAs. A service provider may push for a customer to accept OLAs against end-user performance, such as requiring a business unit to give full project requirements to the service provider within a certain time frame. Don’t agree to them, advises Druitt.

“While the dependency is certainly there, the underlying agreement is not there,” Druitt says. “The business unit is the customer and should not be treated like a partner in the delivery of service.”

7. Do include all key interactions. “Customers often do not know what to include in an OLA,” Zahler says. “At a minimum, the OLA should identify the particular services covered by the OLA and specify how key interactions will be handled.”

The most important interactions include work planning; provision of operational data, information and reports; integration of activities with the service desk; coordination of changes; handling of the cross-functional services; and governance and dispute resolution.

It also is important that the OLA expressly state that the customer, while not a party to the OLA, is what lawyers call a “third-party beneficiary” of the agreement. “This allows-but does not require-the customer to enforce the OLA in its own name if it desires to,” says Zahler.

8. Don’t manage by OLA. It’s a mistake to “use these additional metrics that come from establishing OLAs as a means to manage the delivery in a whole new way,” says Druitt. “The measures should support the delivery of service and are really for the providers to manage against.” Step in only when providers fail to address underperformance.

9. Do track your OLAs. “OLAs can often provide the metrics that provide the basis for good decision making-if they’re tracked, which they often aren’t,” says Hansen. These metrics are helpful not only in improving service delivery, but they can also provide a solid foundation for future sourcing decisions.

“If you have OLAs that are current and actually tracked, the decision to outsource or not has more integrity,” says Hansen. “If the decision is made to outsource, then documenting legacy SLAs is a snap, which makes the discussion around transition and transformation much easier to have.”