Rethinking the cost-trimmed approach to outsourcing development
Originally posted on CIO Drive by Oliver Muhr, Seerene’s CEO
For years, companies have turned to outsourced development as a way to increase productivity and scale engineering capacity. According to Gartner, IT services spending will reach $985 billion dollars this year. Despite this being such a massive area of investment, executives still don’t have clear metrics on the value they’re getting for their money. When it comes to software development, companies shouldn’t have to work with outsourcers who cut corners or deliver sub-par work. But for clients, those issues can be hard to catch and even harder to quantify.
In this three-part series, I’ll share some insights I’ve gained from working with global enterprises to help them better leverage their outsourced development — from negotiating contracts, to steering teams, to evaluating the investment.
The current state of vendor sourcing
In many enterprises, the corporate purchasing department gets specifications and requirements from IT, selects the cheapest vendor, and negotiates a contract. They agree on certain penalties for the outsourcer (surrounding issues like late delivery or error rates above a certain threshold), but this cost-centric approach inevitably results in quality issues and project risks that create frustration for business teams. That’s a big reason why nearly 50% of enterprises are dissatisfied with their incumbent IT service provider, according to the Everest Group.
Part of this struggle stems from today’s common contract models. Regardless of who’s leading the negotiation — whether an application manager, IT buyer, or someone in the procurement or sourcing department — there are two primary ways companies typically structure these contracts. Around 30% of outsourcing arrangements are based on time and materials (T&M), while the other 70% are set up as fixed-fee, outcome-driven agreements.
In the T&M model, your company is basically renting developers, and you’re charged for their billable hours. Because of that, there’s a danger of misalignment when it comes to productivity and risk. You may see high levels of rework and bug-fixing compared to internal teams or a revolving door of developers staffed on the project. These issues increase the project scope, cost and timeline without delivering incremental value to the business.
Outcome-based contracts can avoid many of these problems, but only when desired outcomes are well-defined. The challenge with this approach is two-fold. First, how do you accurately estimate the project and ensure you aren’t getting gouged by your vendor? And second, how do you ensure that the vendor doesn’t take quality shortcuts to protect their margins?
It’s time for a more data-driven approach to negotiating outsourced development
Peter Bendor-Samuel, CEO of Everest Group, recently pointed out that, “The way companies learned to define and contract for services over the past 30 years does not work in an agile environment. Today, contracting vehicles should be consumption based and need to describe the organic, changing environment. We need a new contractual structure that incorporates a different set of metrics and a different set of governance vehicles that allows customers to ensure they get what they pay for.”
With this in mind, it’s important to have a clear understanding of the codebase your vendor is going to be working in as you’re negotiating the contract. Be sure to have discussions about how complex the code is, how well-documented, historic velocity, and any key people on their team who are already familiar with the code. In addition, by preparing a retrospective of previous work the vendor has done for your organization, IT managers can make note of how their work stacked up compared to other teams, both internal and outsourced.
These types of insights set the stage for a successful negotiation. If needed, you can use data about the vendor’s historical work to make the case for the higher quality, more expensive option. In addition, having consistent measurements makes it easier to come to an agreement on which specific key performance indicators (KPIs) should be written into the service-level agreement (SLA). It’s crucial to get everyone on the same page about how success will be measured, and what kind of tradeoffs the company is willing to make.
Walking the tightrope: Balancing pressure to innovate with cost-efficiency
With outsourced development, application managers are often squeezed in the middle. They’re responsible for the success of the project and for delivering value to the business, but they’re not deeply embedded with the development team who’s doing the work. More than likely, they’re in another office or on the other side of the world. It doesn’t help that most companies have big transparency gaps when it comes to outsourced software development. These issues are exacerbated by the fact that IT organizations usually work with multiple service providers, each with different methodologies, programming languages, and developer tools.
While many companies hope they can outsource away all of the risk associated with software projects, outsourcing risk is just an illusion. You own the code and are responsible for the application. If services aren’t delivered on time, or the quality of the software is not where it should be, it becomes difficult for internal teams to get the money and resources they need to fix the problem.
In a world where software is driving revenue and valuations, companies need to rethink the cost-controlled approach to software delivery and apply data-driven strategies to the task of managing their outsourced development. Operational excellence requires continuous, clear visibility into your vendors’ code and development efforts, so that you’ll know when there is a quality issue or project risk that requires your attention. The best IT leaders are those who make the time to regularly measure vendor performance, understand cost-per-value, and proactively optimize the organization’s mix of off-shore, near-shore, and in-house development teams.
