Avoiding supplier management problems in SLA's and Contracts

It's a re-occurring theme that we often encounter at IXIF - we are contacted to "help with some supplier management issues", the client (often new to their job) is having significant problems with a key supplier usually the provider of a critical, but outsourced, support service or vital business application.

The three most common problems we encounter are:

• Lack of a common, well understood Service Level Agreement (SLA)
• Contracts that are inappropriate, inconsistent or badly produced
• Unmanageable (unmonitorable/unenforceable) contractual performance criteria
  

Of course it's our job to help and so after the usual commercial niceties we start to work through the issue(s) with our client. Often we very quickly discover that the contract or the SLA have not been examined in some time and that, when they are found, they are both documents of a weight more appropriate to keeping doors propped open than being a 'quick reference' to the details of the working relationship between supplier and customer.

How does this happen? I have a suspicion that too often these contracts and SLA's (and yes - the two are and should be separate documents) are drafted by lawyers for one party or the other. Usually on investigation the biggest, thickest documents are the result of lawyers from both sides working flat out for weeks, producing documents, entire sections of which may never even have been read by the business (although it's rare that people will acknowledge that).

"What's wrong with that?", is the typical response when we make the observation - "surely you're not advocating keeping the lawyers out of the process?". As far as the SLA is concerned, yes, I'm am very tempted to suggest to most clients that their SLA's are not drafted (or even edited) by a lawyer! If a lawyer needs to review the document and make suggestions - of course he/she should. In fact, I believe, that as many senior staff and advisors as possible from within the business should review draft SLA's and comment on them. The SLA is the business definition of what is expected from the deal, it should be in business language, clear, understood by everyone and ideally short. I haven't encountered an SLA recently that couldn't have been written in less than 25 pages.

The contract, of course, will be drafted by the lawyers. The biggest mistake that often happens here is the 'leave the contract to the lawyers' approach. Very few clients are lucky to have a corporate counsel who understands the business requirements as well as they do and fewer still have the funding to ensure that a lawyer is intimately involved in every step of the requirements definition, business case and negotiation. The upshot of this is that a senior representative of business IT needs , whether the IT Director, CIO or Finance Director or the Project Executive or Project Sponsor (where this is a new system) needs to be very involved alongside the Service Level Manager/Service Delivery Manager for the negotiation of every agreement. Often, we find that it is an excellent exercise to take the SLA and then to write a summary of all of the 'non-service' items that are a concern from a business perspective and to use this as the agenda for the first meeting with legal counsel. Hopefully, this outline with the expert input from the lawyer who will have their own list can be developed to form the backbone of the contract. When for reasons of cost, policy or speed a boilerplate contract must be used then I am startled as to how infrequently the business and IT staff responsible have read through, understood and questioned every section of it before they start work on editing and adapting it. Too often it's not clear what every clause means in business terms, not evident that all clauses are necessary and uncertain that the document accurately reflect the needs of the business. The boilerplate contract used by many organizations 'contracts' department may be ideal for a cleaning contract, or for the supply of paperclips - but is it flexible enough, or the right place to start, when the need is to accommodate an IT system that is critical to the business and likely to undergo significant and regular change. Are the savings realised through using a boilerplate SLA or agreement justified given the business importance of the IT service under contract?

Once we've overcome the initial hurdle of finding and understanding the contract and the SLA we sometimes find that this is enough to resolve the problems. Often we find that the 'supplier problems' or 'customer problems' arise from the fundamental lack of working relationship that can so quickly arise when staff on one or both sides have moved on and new people are left (sometimes without understanding of or reference to) the contract and the SLA to manage. If the SLA and contract are adequate, often simply a process of communication, clarification and re-alignment around the agreements can make a real difference. Expectations are everything and both sides must understand the expectations of the other and of the agreement(s) into which they have entered.

Where re-aligning expectations and re-focusing on the original agreement proves inadequate, where renegotiation becomes necessary or when negotiating SLAs for the first time the key is to make sure that the SLA and the contract are 'manageable'.

Chambers 21st Century Dictionary defines:
management (noun) 1 the skill or practice of controlling, directing or planning something, especially a commercial enterprise or activity.

So how do we exercise management within an IT service contract. The keys (from our definition) are:

• control
• planning
• direction

Many of our clients have adopted established 'best-practice' such as The IT Infrastructure Library (ITIL) assist with operational planning and strategic direction of their IT Services, and to provide tested techniques and approaches for control. Others either through neccesity (imposed by regulation e.g. Sarbanes Oxley) or as a matter of improving their own internal governance apply standards for governance (such as COBIT) in order to provide a formal approach in demonstrating good control. All of these 'best practice' approaches require that we effectively manage our Service Level Agreements and third party Underpinning Contracts.

Fundamental to this control, planning and direction is information. Information about the needs of the business, information regarding the availability, capacity and performance of the IT services and about the effectiveness, efficiency and performance of the IT service support.

Often we find organizations that feel that they have 'tight' SLA's where 'target' levels of availability, capacity, performance and even effectiveness and efficiency have been included but where these have not been aligned with the business needs at all. A favorite example of mine is from a colleague who encountered an organisation that had negotiated hard for a 99.98% availability in their SLA (a little over 10 hours per year of downtime), but had permitted 2 hours per week of 'neccesary preventive maintenance' with no limitation on when this was performed. The client then complained when the service provider wanted to perform system maintenance every Thursday afternoon from 3pm to 5pm effectively closing down the entire business. Another client thought that an hour of downtime each week would be acceptable (probably correctly, and saving thousands of pounds on their contract) but then had serious problems with their system when the reliability was poor, the system throwing out all 1000 users five times a day for a week but still achieving their 'uptime' requirement.

Another common problem we see, is a contract imposing tight controls such as a high degree of availability (e.g. less than 2 minutes downtime per week), specifying the maximum number of outages permitted (to overcome the second problem detailed above) and perhaps even maximum durations for any single outage - but implementing no method to measure and therefore manage these parameters. This can lead to expensive and prolonged arguments with service providers, where the customer insists that the SLA is being 'breached' but can only provide anecdotal, 'diary' or Service Desk evidence to support their case.

Recently there has been a trend during the contracting process for customers to insist that their supplier perform monitoring of the systems to be supplied and provide reports on a monthly or quarterly basis at service review meetings. This might initially seem to be a good idea, but, often it just serves to provide the supplier with the ability to charge for something that they should already be doing and unfortunately can increase the temperature and reduce the quality of relationships between the client and supplier. In these cases, service review meetings can degenerate into 'bun-fights' as the client insists that service has been bad and the supplier tables graph after graph and table after table demonstrating their compliance with the letter of the contract.

Without their own contract monitoring data, clients are vulnerable to the few unscrupulous suppliers who are happy to doctor their figures to avoid contractual penalties and worse still to deadlock situations that quickly degenerate into:

Client: "The system has performed very poorly"
Supplier: "As you can see from these 50 graphs as summarised in the tabled RAG report we have met or exceed service levels throughout the period"

These discussions often fail to reach a resolution and leave the customer dissatisfied with the service and the supplier. In our experience when client and supplier both implement their own independent monitoring significant advantages:

• Supplier Proactiveness - Often the very act of introducing client side service assurance (monitoring) prompts a considerable increase in supplier side monitoring leading to an immediate improvement in supplier reaction speed and pro-active problem identification.
• Honesty- Suppliers appear more quick to admit to problems and rectify them (often before service reviews), where there are discrepancies in monitoring both parties can engage 'together' in determining the cause of the difference, agreeing a way forward and either improving service within the contract or enhancing the SLA to facilitate improvement.
  
• Trust & Communication- Customers are able to act quickly and engage with both suppliers and users when problems emerge without waiting for supplier reports. In some instances, integration of monitoring and the Service Desk to provide an Operations Bridge can enable Service Desk staff to become more pro-active in supplier liason and provide better and more accurate communications to users. Rather than heated 'emotionally' driven service reviews, meetings become more objective and fact based.

This leads to a vital conclusion that : SLAs should actively seek to include objectively measurable (business based) determinants of success or failure and should use these as the basis of service reporting, service level reviews, service penalties and of contract and service level negotiation.

In order to achieve this it is important that IT (or our intelligent customer function if much of IT is outsourced) represent effectively our business needs, that the 'measurability' of these needs is determined and approaches for measuring these needs directly or 'proxies' for these needs be developed, and that we involve the legal and contracting team early in order that our contracts are built around our SLA and that we don't simply append the SLA as 'Annex A' to the contract and hope for the best.

Intelligent Customers should develop effective measures of Service Quality and implement ongoing monitoring solutions and reporting systems to record performance and to objectively identify failures and degraded service and to correctly assess the SLA and contractual implications of Service Quality.


Technorati Tags: ITIL , Service Management , Best Practice , Service Delivery , Service Level Management , Service Level Agreement