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.​

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, a company basically renting developers is 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," he said.

With this in mind, it's important to have a clear understanding of the codebase a vendor is going to be working in as the contract is being negotiated. 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 an 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, data about the vendor's historical work can be used 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 vendors' code and development efforts, so that it will be known when there is a quality issue or project risk that requires 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.