S2

Introduction

This week’s article is: “9 IT Outsourcing Mistakes to Avoid” by Stephanie Overby. This is an excellent CIO.com article to read if you are interested in learning more about some of the complexities customers encounter in IT Outsourcing contracts. You can find it here. As usual, I will provide additional perspectives for your consideration and will close with a final thought.

Outsourcing Background

Also known as Managed Services, IT outsourcing is the term used to describe a contractual relationship with a third party to take over the day-to-day operations and maintenance of some or all of your IT environment. This can be relative to IT infrastructure, application development and/or application maintenance, or user support. Infrastructure may include mainframes, distributed servers (running Windows, UNIX, Linux, or legacy OS), storage systems, networking and the end-user computing environment.

Why do this? Two reasons are common. The first, often called “your mess for less,” refers to clients who struggle with a complex and costly environment that has evolved organically over time and their desire to leverage the skills and scale of a managed services provider to deliver a better IT service experience at a lower cost. The second motivation is recognition that managing some portion of your infrastructure may be less critical to you than developing a new service capability, and so you want to focus your in-house staff and their institutional knowledge on this new requirement and turn over the less critical (but still important) management of the existing infrastructure to a managed services provider.

IT outsourcing services and their costs are defined by complex multi-year contracts with extensive terms, schedules and exhibits. Maintaining a good relationship with your managed services provider is essential but not always easy. A good governance process that guides how decisions get made and how issues are resolved is also essential. One of the biggest challenges customers face with their outsourcing contracts is the rigidity that those contracts create in the service delivery experience for an IT environment that increasingly needs to be agile in meeting today’s digital demands.

Outsourcing Pitfalls

Our subject article starts out by stating outsourcing is entering its third decade and that some clients are more mature in how they are entering into better contracts. Four examples are given: creating better service level measurements, focusing on service integration and process alignment, keeping strategic elements in-house, and developing more flexible contracts. These are all good examples to follow. For example, creating better service level measurements provides a better match between the user experience and those measurements and makes service level improvements easier to deliver. Other examples mentioned in the article include shorter contract terms and the use of multiple managed services providers.

In my experience, there will be times during the contract where one or the other side feels they are getting the “wrong end of the stick.” This is a common human condition in any relationship. The obvious solution is good communications and a clearly defined path for resolving differences of opinion. For this reason, I would say mature IT outsourcing partners recognize the need for a strong governance process and work hard to establish this and then manage it on a continuous basis.

The common pitfalls mentioned in the article are:

  • Switching providers instead of addressing root causes,
  • Focusing on solutions rather than problems,
  • Contracting for innovation,
  • Relying on an outsourcing template,
  • Playing hardball on terms and conditions,
  • Underestimating the human impact,
  • Insufficient focus on transition,
  • Inadequate investing in governance, and
  • Managing by SLAs.

This is a good list. I have seen each of these pitfalls cause issues for clients and providers I have served. I could add to it, but my additions would likely fit into these same 9 pitfall areas.

As I have done in past articles, I will pick some of these (highlighted) to share my perspectives.

Find the Root Cause

Switching providers to address concerns you might have is not always a good option. As the article says, sometimes the root cause for the concern is endemic to your own environment and you would likely experience the same concern with another provider. Without focusing on the root cause of your problem, you are likely to go through an expensive change that risks your IT service delivery only to end up in the same place with a whole bunch of end-users and executives doubting your leadership.

A case in point: your environment may be brittle because you have extensive diversity in hardware, operating systems, and utility software. If so, this will be a problem for any provider including your own IT operations department, particularly when making changes to the environment. The root cause here is brittleness and, unless your contract spells out how your provider is going to address this and how you are going to support the provider in this effort, you are dooming your provider and yourself to a difficult service experience.

Focusing on solutions not problems

Our author highlights some typical problem areas: “The most common mistake is a technology focus” and “buying the latest shiniest toy” and “focusing on procuring the lowest price for predefined solutions.” These are all great examples. I have seen all three many times and have witnessed the consequences. Often, there is a common perceived need to jump to solutions and an equally common unwillingness to deal with the core issues. If providers and customers would only embrace their difficult issues with more enthusiasm, outsourcing relationships would be much healthier. You cannot correctly find a solution for a problem unless you understand it with great clarity.

Good IT leadership knows to avoid the allure of shiny objects.

Contracting for innovation.

Every client that enters into an outsourcing contract is thinking in the back of their mind that they will get innovation as a byproduct of their relationship with a managed provider. After all, the provider knows how to “do innovation” and has certainly done it before. During contract negotiations, the managed provider may implicitly act as if your beliefs are well-founded, and yet, unless there are explicit terms in your contract for innovation, it’s not likely to happen.

Providers are driven by the terms in their contracts.

Here is the rub: how do you contract for innovation? It turns out this is nearly impossible to do, a point the author makes: “Clients complain they do not get creativity or innovation from their providers.” This should not be a surprise when your procurement organization ran the RFP process in a rigid fashion with an eye toward holding the provider’s feet to the fire. In my experience, contract negotiations start off a relationship on a confrontational footing. It’s not a good way to begin. I could not agree more with the author’s observation: “In many cases, it’s not the service providers but the enterprises that are the true limitations for achieving innovation.”

Playing hardball on terms and conditions.

Our author astutely observes: “Insisting on overly stringent terms can impact the provider’s business model and come back to bite the customer.” Here’s an example: I had one client who negotiated a penalty clause that essentially said if there were 3 or more service disruptions in any given month, a credit of $750,000 would be applied to that month’s bill. Imagine for one moment you are the person responsible for the contract’s financial performance. There would be a significant hit to your financials if the penalty occurred.

What did this team do to offset the risk? They made their outage windows 3 times what they needed to be because the contract didn’t limit how much time the provider could take for an outage window. By giving themselves more time to effect changes to the environment (and test these changes), they reduced the risk of having a contract performance issue. The consequence to the end-users is they were without a service for much longer than what might have otherwise occurred had the contract been better defined.

What I observed over many years is that both parties tend to play with the contract terms in such a way as to create advantage for their respective sides. This is to be expected given the large sums of money involved. It leads, however, to relationship issues. Usually one side or the other ends up believing they are getting the “short end of the stick.”

Summary

In closing, IT outsourcing contracts and relationships have always been difficult to get right. This has become even more the case with the advent of sourcing alternatives (cloud computing), and the focus on agility to meet new demands (digital transformation). IT outsourcing providers need to make adjustments in how they go to market. There is a tendency for the customer to want a greater share of resources to be onshore, limiting the provider’s ability to exploit cheaper labor markets abroad. The latest focus is in the use of automation to further reduce labor cost, but this doesn’t come without its challenges too.

The article encourages a focus on solving issues versus creating solutions. That’s great advice. I would add that remembering this is a relationship; treating it with the care that you treat other relationships in your lives will serve you well. Sometimes compromise and a healthy respect for the partner is the best course of action going forward.

How Can Chordia Consulting Help?

At Chordia Consulting, we (and our partners) have extensive experience in outsourcing contracts and service delivery. Our IT/CBM model provides a framework for evaluating a client’s situation and identifying opportunities for improvement in a fact-based way. Our Sourcing Advisers initiative with US Advanced Computing in Chicago, expands our capabilities to include transformation and assessments of a current situation to identify possible changes in sourcing strategy.

Leave a Reply

Your email address will not be published. Required fields are marked *