When managing an outsourcing contract, there is a lot to consider when you’re introducing a new component/service, partially exiting a service, creating an interface to the cloud or simply adjusting an existing KPI. Whilst major outsourcing contracts will usually specify a contract change process, this is limited to identifying stakeholders, terms & conditions and the like and does not deal with content. Identifying and ensuring that all aspects of the change have been accounted for before signing on the dotted line is not easy.

To ensure that any contract change is thoroughly validated, contract managers on both the supplier and customer side need to be alert. Although both may not be capable of validating all aspects of the change, they are usually held responsible and need to engage the necessary resources to do so. Having been responsible for both supplier solutions and customer contracts in various roles over the past 20 years, I offer you a brain dump of my ‘do not forget’ items. As always in my posts, please feel free to add or comment on the content so that everyone can benefit from your experiences.

Now, despite most organizations having substantial process management in place, contract managers tend to be engaged at different steps in the process. Sometimes, very early, whilst the change has not even been developed beyond anything more than an idea. More often, once the solution is on the table and needs to be deployed, demanding a contract change to be done yesterday. The latter is often caused by higher level executives who also make high risk changes with high value but have less information to validate the change process. However, no matter when you are engaged, the following list can either be applied as a checklist or given as advice to those preparing to make the change (for them to consider and hopefully provide answers to before the pressure is on to sign the change).

Commercial aspects:

Does the price include all variables and if not, which variables present a risk? Example: consider an email service that offers 5GB of email storage for $2 per month. Storage is a variable that may be exceeded. Is the 5GB an aggregate amount across all mailboxes in the organization, or will you need to pay extra once a single user exceeds the 5GB limit? How much does the extra storage cost. Basically, anytime that you see a value being stated, whether capacity based, user volumes or number of reports, ask yourself ‘what if that needs to change in future and what will it cost?’.

Does the price include the evolution of the product/service? Whilst this aspect may be covered in more general T’s & C’s, or not be applicable due to a short lifespan, it’s worth checking if version upgrade(s) is included in the price. Being hit with project costs for an upgrade two years after signing a deal is never an easy topic to sell to the CFO. And double check what a ‘version’ or ‘upgrade’ really means in the contract. Many suppliers deviate in their definitions in this respect.

Does the price follow the contractually agreed fluctuations and open market? There are multiple items in this category, such as:

1. Consider the impact of COLA (cost of living adjustment) or ECA (economic cost adjustment). Depending upon the location of service delivery, there may be an annual increase in costs between 1.5% and 5%. Validate the location of delivery of the new service in comparison to what is already be agreed and when ECA/COLA should be applied (normally, a given price is valid for a year and ECA/COLA is applied the year after, but a good negotiator may be able to delay application of ECA/COLA for an additional year)
2. Determine if COLA/ECA is applicable to the whole of the service/product that you are changing. If not, specify the percentage to which it is applicable. This may already be stated in your contract for existing services, but the new change may demand revision of such an agreed value.
3. Ensure that there is an annual productivity gain. This should exceed and/or off-set the ECA/COLA. If there is no annual reduction in price, why not? Continuous improvement should be driving down incident volumes. Process improvement should be removing waste from the process. Automation/robotics should be reducing costs. A supplier needs a very good reason for keeping prices flat.
4. If you have a Price x Quantity (PxQ) based agreement, is there a bandwidth applicable to the quantity? Validate if/when that bandwidth may be exceeded and what the consequences are. Alternatively, if a fixed price is agreed, determine when a drop or increase in consumption can lead to a price renegotiation.
5. Is the service or product readily available in the market? If so, what’s the price? Of course, every organization has special requirements (or at least suppliers will tell you this after signing a contract with them) that may influence the price, but this is unlikely to cause a deviation of more than few percentage points from the market price.

Can or should the change have any influence on agreed penalty/bonus mechanisms? It’s very difficult to amend penalties after a contract has been signed because they are often considered as a risk by suppliers and are therefore negotiated as part of the whole deal. However, changes need to consider this and can sometimes dilute the value of, or place restrictions on, the possibility of imposing a penalty. From a customer perspective, the most important rule is to determine if product/service failure by the supplier will really cause pain and if so, what aspect of failure will drive this. Once identified, this can drive a KPI discussion and help determine the value of an applicable penalty. Suppliers will be more inclined to limit discussion to one-off penalties or bonus for transitional aspects.

Are exit fees being adjusted, applied or introduced? Depending upon the structure of your exit agreement, it’s likely that termination fees are defined along with when they are to be applied. Suppliers often have internal formulas for calculating these fees based on potential lost revenues (this causes a termination for convenience fee to reduce over time), wind-down fees (cost of re-allocation of resources) and other sunk investments (software costs, network connectivity, etc.). Any change to these fees needs to be extremely transparent as such fees play a role in benchmarks and are usually allocated as a risk in business cases. Be especially careful when a change reduces the service/product consumption as suppliers will tend to retain the existing termination fee (based on the original volume), knowing that claiming a partial termination will be difficult to prove. Whilst this is a short-term advantage to a customer, this poses a larger future risk in the case that termination is made later when the fees are no longer proportionate to the lower value service/product.

Transitional aspects:

Cost to achieve: Whilst some contract changes are neutral in cost, the majority will have a cost to implement. This cost is on both supplier and customer side, but ultimately paid for by the customer either as a one-off fee or embedded in the service fees. Try to gain transparency of these fees in terms of both costs and resources. Many changes are made using the resources whom already deliver the services and whilst these are then put under more pressure to deliver, they are seldom back filled to achieve the change. A discussion on the cost to achieve change should precede the decision on how to pay. Once cost is understood, it can be attractive from a business case perspective to absorb the transition costs into the service fees, removing the initial obstacle to achieve change. If done however, validate that this is contractually recorded so that the embedded transition fee can either be seen to be removed from future years or benchmarks can account or a potentially higher than market-based fee (due to the inclusion of transition fees). If a supplier always absorbs change fees, consider running your benchmark sooner…nothing is free.

When is the service/product ready? Signing a contract change doesn’t make something happen overnight in most cases. Unless the change is done in retrospect it needs to be clear when the service or product will become effective. Consider if a single date is actually applicable, or if a more phased approach should be documented. For instance:

1. When do KPI’s take effect?
2. When is reporting available? Consider the reporting cycle may not be near real-time and run a month behind.
3. When is the consumption reporting valid (if you have a consumption-based agreement) or should a temporary agreement be made for a specific consumption to enable payment?
4. Are penalties/bonus’ applicable and if so, when? Maybe define a grace period to allow the service to stabilize.
5. When is documentation ready? Or transferred to the future supplier if dealing with a change for exiting a service.
6. If the service/product is replacing an existing service/product, is the wind down and wind up timeline of both defined and which obligations apply to each during the period? 

Duration and validity:

Is this known to be an interim change? It’s not uncommon to see contract changes being made to amend a service/product, whilst knowing that the same service/product is being planned to be replaced or demised in the near future. Whilst this keeps contract managers in business and is still a good practice to help optimize what you have, knowing this can help to focus on the right aspects during negotiations. For example, optimizing your email service whilst the company plans to move to an externally hosted email service within two years means that your focus needs to be clearly placed on ensuring exit terms are optimized and that the impact of reduced consumption over time is minimized.

The lifespan of a service/product may deviate from existing ones. Some agreements create a framework into which services can be introduced without the need to renegotiate the cumbersome terms and conditions, opening the door for new services/products to be added during the lifespan of the framework. This makes many aspects of contract management easier, but also introduces the risk of inheriting obligations implicitly. The lifespan of a service/product is an important factor in this respect. If a framework agreement is valid for 5 years and the initial services/products are designed to operate for 5 years, then any interim changes will assume the same unless otherwise defined. If your new/changed service is to have a shorter lifespan this needs to be explicitly stated along with which terms do not apply (e.g. termination fees at that time). A service which may be intended to overrun the duration of the framework will need even more attention as this will either need renegotiation or specific clauses to ensure that existing T’s & C’s may be inherited/transferred into a revised agreement upon termination of the existing agreement.

Cross interference of contract changes. If you are managing a substantial outsourcing contract, it is likely that you will have anything between 5 and 20 contract changes being processed in parallel at any given time. Whilst most will be specific to only one aspect of the agreement, there is a risk that they can interfere with each other. Both supplier and customer contract managers need to carefully track this to ensure that the signed changes are valid and have not undermined or prevent conclusion of a parallel contract change. I have been lucky in the past to have a team lead (with a brain, the size of a planet and organizational skills to match) who could deal with this, but for those less fortunate, the teams need to intensively discuss the impact of their respective changes.

Other concerns:

Whilst the above are key considerations in almost every contract change, it’s worth mentioning a few additional items that may slip your mind:

1. Exit agreements: consider any additional aspects of the change that may not be covered in your framework agreement such as software source code (ESCROW requirements), ownership of orphaned assets, license transfer, etc.
2. Intellectual property: Whilst most agreements contain generic clauses on ownership categorization, the contract change needs to stipulate which category is to be applied.
3. Impact on transferred resources: As with most outsource agreements, people transfer can be extremely complex and a costly component of the agreement. Validating if the change affects this requires inclusion of the HR department.
4. Benchmarking: Depending on the duration of the agreement and intended lifecycle of the service, it’s good to stipulate when a benchmark may be applied for the first time if this deviates from the generic agreement.
5. Security and compliance: depending upon your industry and geographical coverage, this may actually be one of the most important concerns. Remember to have security and data protection validate the end-to-end solution that underpins a service or product. Even if your company data may only reside in one country and access is safeguarded, those wonderful automation processes being used by your supplier may be sending significant parts of your data around the world in order to notify the support teams of incidents, including data that may fall under the data protection act.

Understanding that some of the above items may not be evaluated thoroughly whilst under time pressure, these need to be documented as risks with a potential value and chance of occurrence before finally searching for approval to make the contract change effective.

In a perfect world, contract managers will be supported by architects that can speak non-technical language, legal advisors who understand IT, financial teams that understand the balance between cost and value add/quality, and service managers/owners at a minimum. Nowadays, security and compliance officers are becoming more of a necessity in the diversifying IT environment, with ever sharpening data protection regulations. However, if you work in an imperfect world, feel free to reach out and ask for my support…I may be able to help.