How to structure an outsourced IT project for less risk, more leverage

Large-scale IT outsourcing deals are doomed to fail if you don’t structure the project properly. Therefore, it’s imperative that during the negotiating and contracting phase you lay the groundwork to mitigate the risks and maintain leverage.

outsourcing contract ts
Credit: Thinkstock

In 2015, big, monolithic outsourcing deals are regarded just about as negatively as huge, enterprise IT projects: They are seen as lengthy, costly and practically doomed to fail. Just as IT organizations have broken down their large IT tasks into more discrete deliverables, they’ve also dissolved their mega outsourcing deals among multiple providers.

Today, the prospect of outsourcing a major technology project to a single vendor may seem like an antiquated notion. And the risks of such an approach abound.

“There are several reasons that one provider may not be the best decision for a long-term project,” says Andrew Alpert, principal with business optimization and outsourcing consultancy Pace Harmon.

“First, there may be aspects of the projects that require specific domain expertise and functional, technical, organizational change, or industry specific knowledge that are not available from a single provider. Second, providers that have strong business requirements and design expertise may not be the most effective and efficient development and testing organization or the best development and testing provider may have comparatively weak change management teams.”

In addition, locking in one IT service provider can limit a customer’s ability to minimize costs, ensure commercial and performance accountability, and maintain resource quality.

But … sometimes having one vendor is the only option

Yet IT organizations still must take on transformative, enterprise programs. And farming that work out to a variety of IT suppliers isn’t always feasible. Certain specialized software expertise may reside only with a certain vendor, for example. “Indeed, this is especially the case when implementing specialized software solutions where the marketplace expertise tends to reside only with the software provider,” Alpert says.

Certain types of enterprise projects may naturally lend themselves to the one partner approach. “This comes into play when implementing a software-as-a-service platform,” says Alpert. “In these implementations there is typically a much smaller software development and testing lifecycle and more focus on agile configuration and testing.”

An IT organization may also like the clarity that can accompany working with a sole provider. Unfortunately, “the perceived accountability benefits of ‘one throat to choke’ are typically unrealized due to poor commercial structure and provider unwillingness to accept real risk,” explains Alpert. “With a single provider, future phases of work are often overpriced due to lack of competitive leverage, and the project scope is not yet well defined to determine the discrete schedule, deliverables, requirements, and timeline to hold the provider accountable.”

Mitigating risk when structuring a large-scale IT outsourcing project

However, there are ways to structure an outsourced large-scale IT project that mitigates the risks of the project and maintains an IT organization’s leverage with the sole provider. And that groundwork must be laid during the negotiating and contracting phase.

Specifically, when approaching a major, single-sourced program, IT organizations should contractually commit only to the work that can be discretely specified, scoped and planned in the near term.

“We recommend that buyers limit the scope of work to that which can be defined with specific activities and deliverables that are within the control of the provider,” Alpert says. “With this, the provider can commit to a fixed or capped fee for a known quantity of work that is within their control. In exchange, buyers receive the comfort of knowing what they will get in the form of deliverables and budget certainty.” Then they can use the traditional design phase of the project to identify detailed functional specifications.

These deliverables “enable the client to scope and potentially compete the next phase of work (for example, technical design and build) vs. [creating] a higher-level of design with provider promises to ‘capture the additional design detail during the next phase of work,’” says Alpert. In this way, buyers will ensure that project milestones are structured to maintain the ability to compete future phases of work if the incumbent provider is not “staying hungry,” Alpert explains.

The goal is to make the most of the single-sourced approach while managing the inevitable drawbacks of locking into one supplier. “The optimal approach is to leverage the potential scale of the project to create a comprehensive structure that provides for committed rates, discounts, governance structure, resource and staffing requirements, commercial terms, and performance structure,” says Alpert.

To comment on this article and other CIO content, visit us on Facebook, LinkedIn or Twitter.
Download the CIO October 2016 Digital Magazine
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.