Hide this madness

Why Outsourcing Yields Successful Projects

Twenty-four years at this game gives you some perspective, as you gaze through your graduated lenses. I started out in a team-based, custom-software-development consulting company. And for the past eight years, I’ve been happily working at another — Jonah Group. In between, I worked for product companies, financial institutions, and consulting companies. Throughout the course of all this — and, in particular, during various consulting gigs — I’ve seen many ways of structuring the control touchpoints of the relationship between the development team and the stakeholders. Some approaches are good, some less so. I have noticed that outsourcing often results in excellent results. Why? What are the origins of the benefits that outsourcing has on project control and, ultimately, on project success?

One surprising source of benefits to stakeholders is the outsourcing contract. The contract? Usually people regard it at best as a nuisance; at worst, as a necessary evil. Who wants to wade through — or, even worse, define — dull language, and quibble over the fine points? Why spend precious time and energy on that, when you could be moving ahead with the requirements?

But taking that time to put in place a well-structured contract pays off down the road, because it specifies and enforces responsibilities and outcomes in a way that less precisely-defined engagement definitions simply cannot, and it motivates and shapes the strategies of key stakeholders and delivery personnel for the duration of the project. You want to deliver on-time and on-budget? Write a contract!

The natural goal of the contract for a custom software-development project is to delineate all three sides of the Iron Triangle: the contract should specify what will be built, how long it will take, and how much it will cost (quality expectations may be treated as part of the “what”). This defines clearly the task of the development team, and it also specifies the upside for both stakeholders and the delivery team: the stakeholder upside is to acquire a known system by a known time and for a reasonable, agreed-upon price; the upside to the delivery team is to receive fair compensation for talent and effort.

This is a good start, but the specification of the Iron Triangle and the associated upsides of success is not quite enough: inevitably, the contract must also spell out the downsides of performance failure: pressures must be identified to hold both contractual signatories to their responsibilities. Vendor-side pressures typically include warranty clauses and late-delivery payment penalties. Client-side penalties may include late-payment penalties, but performance penalties may also be spelled out.

Client-side performance penalties? Why would that be needed?

Projects are never outsourced completely to the vendor. Client-side delivery participation invariably exists, always including: requirements specification; subject-matter expertise; and user acceptance. Additionally, clients may participate in project management, architecture, design, deployment, and development. So clients necessarily have skin in the delivery game, too, and so there are performance expectations that can and should be specified contractually and measured during execution. Typical client-side performance penalties specify the relaxation of one or more sides of the Iron Triangle.

So a balanced contract puts pressure on all members of the delivery team — from both the vendor and the client — to stick to that Iron Triangle. Since time is money and scope is value, ultimately the pressure is financial. The overall delivery team is placed in a starkly clear position: here’s what we have to do, by when, and for how much. End of story. And the contractual relationship spells it all out, with benefits and penalties, giving stakeholders a stick against which to measure performance along the way.

The fuzziest of the three sides of the triangle is always scope. Cost and time are trivial to define and measure; while scope delineation is never easy. You can do more or less, depending on your appetite for risk, but it is important that it be managed attentively in all phases of the project lifecycle, defining it clearly near the outset and keeping it in-hand throughout the build.

It is all too easy to punt on the initial scope definition. Everyone’s busy, so it’s tempting to say “We’ll cross that bridge when we come to it.” But that’s a trap that will bend the delivery team’s triangle out of shape later, attracting the (unwanted) attention of stakeholders. If you do find yourself in a situation in which you’re faced with the analysis of particular functionality for which procrastination is truly the lesser of evils, carve that bit out into a separate triangle that will be analyzed, scoped, sized, and contracted later on. Isolate the risk!

Even when scope is well defined up front, it can easily go awry later. While there are always detailed decisions to be made during construction, and little things that were missed, and while these need to be attended to, you mustn’t let the nice-to-haves distract you from the larger goal. The penalties which are spelled out in the contract should motivate the entire delivery team to avoid significant scope creep as if it were the plague (because it is the plague!). If you absolutely have to add scope, carve it out as a separate triangle (e.g. via a contractual Change Request). And when that happens the delivery team should rightly expect criticism from stakeholders, because they deserve it for having missed something big!

So why can’t contractual-style formalism be applied to projects that are executed purely in-house? Well, it could be, but it almost never actually is. Because there is no “outsider” (vendor) to manage — and no associated external risk — there is rarely enough motivation to take the time and considerable mental effort to do the requisite hard slogging to define scope sufficiently in the inception phase, and to estimate the delivery. Sure, a budget is established and timelines are identified; but a triangle can’t be specified by the lengths of only two sides. The true scope isn’t known, but the team is formed and it plunges haphazardly into the build. Everyone in delivery knows that they can collude to bend scope later, because there is no clear accountability and no spelled-out downside.

If everyone on the delivery team understands from the start that future scope creep will cause future pain, they’re all motivated to define clear borders before construction starts, and thereafter to patrol those borders. Conversely, if you’re lackadaisical at the start, that attitude will persist throughout the project and subsequent scope creep will not be recognized as the malevolent force that it can be. Whups, your project is off the rails.

What really makes the contract work is the distance between the signatories. When projects go seriously off the rails, pressure builds and needs an outlet. If it’s an in-house project, the typical consequences are to disrupt one or two careers and then for the remaining team to tarry on, in increasing distrust, simmering resentment, and continued poor performance. But if the project is out-of-house, the penalties can be much higher, and can include permanent relationship breach and lawsuit. Happily, alert and wise oversight will typically have intervened before it reaches those dire straits.

In these past twenty-four years I have never participated in a contractually-specified project that foundered seriously. They’ve all succeeded, despite the bumps along the way. But I have been part of in-house projects that were strongly challenged or that failed outright. A contracts embodies a formal, bipartisan agreement to move forward for mutual benefit, and the precise definitions which they necessarily capture, together with the carrots and sticks that are attached to those definitions, focus people towards success in ways that more casual structures cannot!

Add a comment

Comment feed
The better to greet you with
No one will ever see this
Your pride and joy
The reason this comment form exists

The crew behind ASOT

We're a team of interactive, software, and business intelligence experts skilled in the design, construction, and management of online enterprise systems.

Visit The Jonah Group site

Get in touch with us