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."
