9 tips for how to use operating level agreements in multisourcing
- 15 February, 2013 20:18
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."
Read more about outsourcing in CIO's Outsourcing Drilldown.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.
Trust issue looms large for tech companies capitalizing on personal data
5 women who've made it in IT
Five trends affecting legal CIOs
CIO Roundtable: The changing face of security
Bitcoin malware count soars as cryptocurrency value climbs
Pathways Course Curriculum 2014
Developed by the CIO Executive Council, Pathways is a unique, flexible, self-managed, self-paced 12-month professional development program that brings together best practices, thought leadership and business insights for today’s most promising ICT professionals. Pathways is designed and delivered by leading local and global CIOs; enabling participants to capitalise on mentor CIOs personal experiences, expertise and knowledge.
Traversing Energy Markets
For a number of industries, there is room for delays caused by poor performance of IT infrastructure, and the importance of a solid monitoring system has never been greater. Read about how the Midcontinent Independent System Operator was able to tackle this challenge and effectively administer one of the world’s largest energy markets.
ERP Selection: Finding the Right Fit
Finding a needle in a hay stack is hard, but the task pales in comparison to finding a specific needle in a pile of needles. Selecting the ideal Enterprise Resource Planning (ERP) solution can feel just as daunting. ERP represents a serious investment for any organisation and is vital to future success. This report explores the strategies organisations are employing to find the right ERP fit that will give them the tools they need to thrive.