Sourcing Speak

Once the ink is dry on a signed outsourcing contract, the real work begins for the customer and the service provider. Before the customer can start to realize any savings, efficiencies or service improvements, the parties must first complete the critical task of transitioning from the customer to the service provider the day to day responsibility for performing in-scope functions. This transition process can take several weeks or even months.

Each party has a strong incentive to complete the transition on time. Ordinarily, the customer wants to start reaping the benefits of the outsourcing as quickly as possible. Likewise, the service provider wants be in a position to start charging full freight fees for steady-state services as soon as the transition is complete. In addition, appropriately structured contracts often include an additional incentive for timely performance by the service provider: monetary credits to the customer if transition milestones are not completed on time.

Competing with this need for speed (or, at the very least, on time completion) is the customer’s desire to mitigate the operational risks associated with any transition. Complexities abound, especially if the transition involves multiple service towers and geographies, a transfer of personnel and assets, and a physical change in the location from which services are performed. The stakes are high for both parties. In the worse case scenario for the customer, a hasty transition can result in an interruption or degradation of a critical business activity.

In part 1 of this discussion we described two front end challenges that, if not properly anticipated and addressed, can (and very often do) derail successful completion of enterprise projects. We’ll now turn to the downstream transactional considerations that can help position a project for success.

The Right Contract Architecture

Customer’s often grapple with how to develop the appropriate contract for enterprise projects. A statement of work alone is not sufficient to cover all the complexities of the project. Instead, customers should consider entering into a master service agreement (MSA) with the supplier. In addition to establishing a contractual framework (e.g., the form and process for developing statements of work) and the terms and conditions, the MSA should address the governing principles or “rules of engagement” for project delivery. Project delivery – especially in a multi-supplier environment – has its own rules which differ in many ways from those followed in typical managed service arrangements. Examples of rules of engagement might include:

It is one of those sayings that people just love to recite: “The best contracts are the ones that stay in the drawer.” In ten years of advising customers on their outsourcing agreements, I have heard this phrase uttered in just about every large negotiation that I have done (typically with a knowing nod of the head from others at the table, and sometimes with a disdainful look in my direction). And while it may just be a saying, it is a terribly misguided one; and, even as a guiding principle, it typically will produce the exact opposite result of what it is intending to achieve.

In short, the saying centers around the idea that a healthy long-term working “partnership” – especially one that requires trust, sacrifice and evolution, which most outsourcings do – cannot be strictly managed off the static words on a page, but instead through a trusting, mutually beneficial relationship. So, if you are taking the contract out of the drawer, instead of managing via relationship and trust, either it means that you are being adversarial, which is sure to just escalate and lead to a deteriorating relationship; or it is evidence, in and of itself, that you do not have a good relationship. In this way, the contract is seen as a “negative” – some sort of necessary evil on the front end (perhaps to appease Legal and Finance), that somehow can be vanquished once the contract is signed and the real relationship begins.

Earlier in my career, I thought that the danger in this thinking was that it primarily would lead to the customer failing to enforce its negotiated rights – whether due to the outsourcer’s self-interest, the outsourcer’s lack of incentive to do the “right” thing, or just pure lack of knowledge on both parties’ part. And while this may often be the outcome, I have come to realize that the “keep the contract in the drawer” principle is even more dangerous than that, and ultimately will work to the detriment of both parties.

In last two decades, much of the attention of customers and advisors has focused on outsourcing under the managed services model. The outsourcing era began with infrastructure outsourcing, which evolved from time sharing and facilities management. This was followed by outsourcing of applications maintenance and support and, on a parallel track, Business Process Outsourcing. This journey is littered with failed and successful delivery models, pricing constructs and business arrangements (including joint ventures). Some might consider offshore outsourcing as the most disruptive force to shape managed services.

These trials and tribulations have armed customers and advisors with a fairly mature level of knowledge and experience in outsourcing managed services. In contrast, there is a notable lack of maturity in the approach to sourcing and contracting for critical enterprise projects including ERP implementations, ERP consolidations and major ADM projects. Despite decades of experience with these projects, companies struggle to find and leverage the resources and tools necessary to execute them. Instead, they rely on anecdotal guidance from failed implementations. War stories of cost over-runs, time delays and abandoned projects abound.

How can enterprises avoid these mistakes? Let’s explore some of the challenges (and solutions). In this first installment, we’ll focus on two key front end considerations: (1) the role of executive leadership; and (2) proper planning and preparation (leveraging a sourcing “roadmap”)