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."
Sign up for Computerworld eNewsletters.