Protecting Against Failures in Outsourced IT Projects

ZDNet blogger, Michael Krigsman, reported recently that nearly 70% of IT projects fail in some important way: An eye-popping number!

There can be endless debate on the actual failure rate of IT projects – the answer most likely depends on the criteria used to define “failure” – but a couple points are clear:

• An unacceptably large percentage of IT projects are not delivered on time or on budget or fail to produce the desired outcomes.
• This is a chronic problem in the industry that has not materially abated over time despite extensive commentary describing “best practices” for reducing the incidence of failure.

Engaging an external supplier to perform an IT project, whether as part of a larger outsourcing or as a standalone initiative, adds a further layer of complexity. Not only does the customer need to focus on the internal challenges to achieving success (e.g., clear articulation of objectives / requirements, strong executive / project leadership, setting realistic expectations with users), it must integrate a third party – whose interests are not fully aligned with those of the customer – into the project.

Given the high failure rate of IT projects, customers are advised to spend the time required to negotiate contracts that provide appropriate protections against financial and contractual risks. While there are many elements that should be addressed, the following deserve special attention:

Specifications – the more detailed and specific the better. IT projects are typically priced on a fixed fee, capped time and materials or straight time and materials basis. Under a fixed fee or capped time and materials model, the pricing structures are intended to provide the customer greater certainty as to the cost of the project by shifting the risk to the supplier of the cost of performance. However, a fixed fee or cap is only as good as the specifications on which it is based. The same is true for committed completion dates. High level, inaccurate or incomplete specifications usually result in numerous unanticipated pricing increases and schedule adjustments through change orders.
To the extent practicable, customers should invest the time upfront (i.e. prior to committing to a particular supplier) to develop a detailed set of business and functional requirements for the project and include those specifications as part of the Statement of Work (SOW). This will enable the parties to establish realistic expectations concerning the cost, schedule and outcomes for the project at the outset.

There is one notable exception to bear in mind. Some IT projects – particularly those related to large ERP implementations – may not be susceptible to fixed or capped fee arrangements at the very early stages of the project (e.g., for the macro design or blueprinting stages). If sourced at the very early stages of these projects, a straight time and materials model may turn out to be the more commercially feasible approach for the front-end work. After the early phase work is completed, however, the supplier will have been intimately involved in framing the specifications and downstream requirements and, therefore, should be able to commit to fixed or capped fees for many (if not all) of the subsequent project phases (e.g., technical design, coding, implementation). See SourcingSpeak’s earlier post for further discussion of pricing and contract structures for ERP projects.

Change Control – even with detailed specifications, there will inevitably be some changes along the way. Some of these changes will have a meaningful impact on the supplier’s cost of performing the project and ability to meet scheduled completion dates. In these cases, the supplier should be entitled to reasonable adjustments to its fees and the project schedule. However, many changes are relatively minor (e.g., a modification to a screen layout) and unless they cumulatively become significant should be treat as “background noise.” Contractually, there should be a materiality standard – either a general principle of materiality or a defined threshold – before adjustments to specifications trigger adjustments to pricing or schedule. Absent a materiality standard, the customer may find itself subject to a seemingly endless series of incremental price increases and schedule delays through the change control process.

Acceptance – sign-offs and acceptances of interim deliverables should be provisional pending acceptance of the final integrated suite of deliverables for the project. Suppliers typically characterize interim deliverables (e.g., the technical design for a systems implementation) as subject to “acceptance” by the customer. That’s fine for purposes of determining whether a particular payment milestone has been met, but should not prejudice the customer’s right to ultimately accept or reject the final project deliverables (e.g., the fully implemented system) or to require the supplier to perform re-work on components parts that were previously “accepted” by the customer but later found deficient (e.g., through systems integration testing).

In most cases, the customer will not have sufficient knowledge or expertise to fully evaluate whether interim deliverables may have deficiencies that will impact the final integrated work product, particularly if the project involves the customization or implementation of a proprietary product of the supplier. (The one notable exception would be the customer’s business and functional requirements where it is generally reasonable for suppliers to expect the customer’s sign-off to be final). Because acceptance is an important demarcation point in determining the customer’s contractual rights and remedies, the contract should provide that the final set of project deliverables – including all previously “accepted” component parts – are subject to final acceptance or rejection by the customer.

Excuses – do not allow a general assumption that the customer will do everything it promises to do or broad or open-ended statements in the SOW of the customer’s retained responsibilities. SOWs prepared by suppliers typically include overly broad statements of the customer’s responsibilities and a general assumption that the customer will properly perform all of those responsibilities in a timely manner. This assumption will almost always prove to be incorrect in some respect and, as a result, create uncertainty regarding the supplier’s accountability for successful completion of the project.

While suppliers should not be held responsible for unavoidable delays caused by customer performance failures, the circumstances under which the supplier is granted relief need to be carefully circumscribed.

• Clear & Precise Definition – Care should be taken to describe with as much specificity as possible in the SOW the commitments and resources that are required of the customer to support the supplier’s performance of the project. Statements like: “The customer will provide timely access to all customer resources and subject matter experts required for completion of the Project . . .” should be avoided as it subjects the customer to open-ended obligations, which in turn offers fertile ground for the supplier to claim an excuse from performance (and a basis for an increase in price or change in schedule).
• Prompt Notice – The supplier should be required to notify the customer promptly and in writing of the customer’s failure and its potential impact on the project. The notice should spell out the specific failure and its impact on the project. Besides being good project management (i.e. addressing issues sooner rather than later), the supplier should not be allowed to wait until the project has fallen off the rails to shift responsibility to the customer based on issues the supplier did not bother to bring to the customer’s attention when they arose.
• Workarounds – The supplier should be required to use reasonable efforts to work around the customer’s performance failure and remain on schedule. In many circumstances, the supplier can easily work around a customer performance failure. For example, if the customer is a few days late in reviewing a particular deliverable, there is a good chance the supplier can fill those days with other project activities that are not dependent on the customer’s input on the deliverable.

Only if these conditions are satisfied should the supplier be entitled to an adjustment to the project schedule (and potentially project fees). The contract should provide that any adjustment be no more than is reasonably required to account for unavoidable delays caused by the customer’s performance failure.

Remedies – both “Plan A” and “Plan B” remedies should be addressed. When the supplier fails to produce conforming deliverables in a timely manner, the best option (Plan A) is usually to have the supplier correct the problem as quickly as possible at no additional cost. The contract should include mechanisms to ensure that the supplier is motivated to do so. While there are various approaches (e.g., holdbacks, milestone payments), if the failure causes schedule slippage, a common mechanism is to provide for financial credits for delay. The longer the delay, the larger the financial credit.

If the problem is big enough and the delay is long enough, the customer may lose confidence in the supplier and decide to invoke Plan B, which is to pull the plug on the supplier’s continued participation in the project (or cancel the project in its entirety). There are gradations to Plan B remedies ranging from:

• Engaging a third party to complete the project (where feasible) with the supplier being responsible for incremental costs incurred by the customer.
• Accepting the deliverables in their deficient state and equitably adjusting the supplier’s charges to reflect their diminished value.
• Rejecting the deliverables and seeking a refund of amounts paid to the supplier.

It is preferable that the appropriate remedies be spelled out in the contract rather than left to the murky realm of common law remedies.

* * * * *
The contractual protections outlined above are not intended as a substitute for following non-contractual “best practices” for avoiding project failures. When engaging a supplier to perform a project, however, securing appropriate contractual protections is an essential element of risk mitigation.