Recently there have been some discussions amongst those of us involved in IT and other outsourcing projects as to whether existing contract models are sufficient given the rapid evolution in technologies available today. In particular, some have attacked the “rigid” nature of IT contracts and the difficulties that arise with things like change control mechanisms.
The principal problem area is the specification of the product or service that is being bought in under an outsourcing arrangement. It is argued that a specification, to be effective, needs to be lengthy and detailed, and it is in that fact where its weakness lies; its details are fixed at the time the contract is signed, and it is therefore difficult thereafter to get those details changed. If the customer wants a more up to date IT solution incorporated part way through the contract then the supplier may well hold the customer to ransom and insist on a major price hike before it agrees to the change. If no change (at a reasonable price) can be agreed, the customer risks being stuck with an outsourced solution that is decreasing in efficiency compared to those solutions used by its competitors.
One way that lawyers acting for the customer get around this sort of difficulty is to insert change control mechanisms into the contract which effectively oblige the supplier to agree to any change requested by the customer, with price issues being referred to an independent third party if the supplier and the customer cannot agree. The difficulty here, however, is that in practice such a mechanism is clumsy at best and divisive at worst, ultimately undermining a business relationship that is likely to be of considerable importance to both parties.
It is undoubtedly true that the validity of a fixed technical specification of any product or service will diminish over time; a customer signing up to a five-year outsourcing deal may not want to be stuck with the same technical solution throughout that time, and it is likely that few suppliers will want to be obliged to support outdated IT for one customer when all of its other customers have long since upgraded.
As a result, some have argued that a fixed technical specification in an IT outsourcing contract is redundant, probably causing more harm than good. They say that the contract should not include a specification, and indeed should not include a change control mechanism at all. Other traditional concepts such as acceptance tests also fall by the wayside since there is no specification against which such tests can be run. Instead, it is argued that the customer should start with a list of desired features for the service or solution which it wishes to purchase. This list, however, is not part of any contract, and can be changed and updated by the customer at any time throughout the life of the project unless and until individual items in the list are agreed by the customer and supplier to be “fixed”. The delivery of the solution is broken down into a series of time boxes which are fixed and can never be extended. At the end of each time box the supplier delivers whatever it has produced against the customer’s list, and the work in each subsequent time box is based on the work completed in previous time boxes. The work is iterative and incremental. The nature of acceptance tests for individual items on the customer’s list are agreed when those items become “fixed”.
It is probably fair to say that the pricing model to be used with such an approach can be something of a challenge. The iterative nature of this mechanism tends to point towards a time and materials model, but obviously this favours the supplier and leaves the customer at the beginning of the project somewhat in the dark as to how much the whole thing is going to cost. The approach also arguably encourages the supplier to spin things out, taking more time and thereby earning more money.
For me, a more fundamental flaw in this approach is highlighted by the litmus test of “if it all goes wrong, whose fault is it?” It is the answer to this simple but basic question that is at the heart of every contract – parties undertake obligations and must fulfil them, otherwise they will be in breach of contract and will be at risk of adverse consequences under the law. Without that fundamental underpinning the relationship between the customer and supplier seems to be akin to two people tied together in a three legged race, one wanting to go north (saving money) and one wanting to go south (earning money). A specification (together with related issues such as acceptance tests) provides the two racers with a clear track down which to race; without that track, they are unlikely to get anywhere fast.
Less radical iterative approaches do of course have their place in software development scenarios, but when it comes to outsourcing services in general the approach described above in my view misunderstands what outsourcing should be about; it is not about the precise methodology (this software application over that software application) but about the delivery of the solution (that data, on-time and in a form we can immediately use). In my experience customers do better out of outsourcing when their requirements are expressed in reasonably high level terms – specifying what they really want as an end product – and leaving it to the supplier to figure out how that end product should be achieved. If during the lifetime of the contract the supplier figures out a cheaper, faster way of delivering the end product, then both the supplier and the customer will be pleased (with the customer even more pleased if it has succeeded in inserting a contractual provision allowing it to benefit from lower costs as well). A correctly written specification can (and often does) lead to the win-win scenario both parties are looking for.
© Taveners 2011