​6 ways to avoid tech contract disputes

IT project failures have not abated. Many have common themes. There are some practical steps you can take to better protect your legal position in the event of a problem, and which may even reduce the risk of your technology project going belly up.

Most distressed technology projects have a number of common root causes which can often be traced back to key issues that arose in the very early stages of an initiative.

While it is not uncommon for these issues to be overlooked in the haste of commencing a project, by keeping in mind the tips below, the chances of the project succeeding can be significantly improved.

Tip 1: Use the right contract

This seems an obvious observation, but is ignored surprisingly often. For example, trying to adapt a building construction contract for a technology implementation project is not a good idea.

It is worth investing the time up front to prepare and utilise a contract that is fit for purpose. This will save significant effort when it comes to administering the contract, and will avoid disputes over the application of clauses that are clearly irrelevant.

A common pitfall is including a fixed end date for a system implementation project where there is no capacity to extend the date for delays. Having the legal team (either internal or external) involved early in the procurement process is important.

Tip 2: A balanced contract is better than an onerous contract

Customers often insist that a vendor accept an extremely one-sided contract, particularly in the context of a competitive tender process. While this might seem like an effective approach to managing risk, having an unusually onerous contract that does not reflect market practice is often counter-productive to the completion of a successful project.

A vendor’s willingness to invest in a project is generally proportionate to the benefit that it receives as part of the project, and its incentives to perform.
A contract that strikes a fair balance between risk and reward will almost always be more effective in encouraging positive performance than a heavily one-sided agreement. That’s not to say a counter balance is to accept onerous vendor positions; it’s not.

There are balances to be struck on the most difficult clauses, even on the risk allocation issue, provided the parties are reasonable.

Tip 3: Don’t neglect the schedules

The source of many technology disputes is the content of, and lack of clarity in, the schedules (which will contain the key information relating to what is being provided, by when, how it is being provided, and for how much).

Leaving the completion of the schedules until the very end of the project and then compiling them in a rush is a recipe for dispute. The schedules should be completed in parallel to the contract. It is also critical that the schedules can be easily understood.

A complex pricing and service credits regime may make sense to the individuals putting the contract together, but they need to be capable of being understood by the individuals who will be administering the contract (and who may not have been involved in crafting the original deal).

Tip 4: Have clarity on what is being provided and for how much

As a general proposition, the specifications and scope of what is being provided should be clearly understood and articulated at the time of signing the contract, as well as the delivery model that is 14582509/1 page 2 being adopted (e.g. is the contract input or output based).

A good test is to consider whether you can easily explain the deliverables and the costs to the board (i.e. “we are contracting with vendor A to deliver system ‘X for Y’ dollars”). There may be circumstances where this isn’t possible.

For example, where the initial work of the vendor is to design and specify the deliverables that it will be providing. If this is the case, the contract should include a mechanism that allows the customer to walk away with minimal expense if the design and specifications cannot be agreed.

Alternatively, the arrangements could be structured so that a vendor is appointed to develop the specifications, and then these specifications are used as the basis of another tender.

A ‘chunked’ approach to delivery with regular milestones and ‘go/no go’ gateways is a useful way of helping to manage the risk associated with unclear or moving specifications. This is assuming, of course, the traditional delivery model is being adopted.

Some service delivery models, like Agile, demand a more flexible approach to delivery, but one that requires definition nonetheless. Don’t let the vendors skate over this one.

Tip 5: Compare apples to apples when selecting a vendor

Cheapest is not always best when it comes to selecting a technology vendor.

There are numerous examples of failed technology projects where a customer has appointed a vendor that is significantly cheaper than its competitors, only to be hit by change requests which have the effect of making the total fees more than what the competitors quoted in the first place.

Often an estimate that is much less than the market reflects a misunderstanding of the scope of work involved, or is heavily caveated with assumptions.

Where possible, a customer should include detailed specifications of the deliverables in the tender, and should provide vendors with sufficient access and technical information as they may require to formulate a proposal.

Vendors should also be required to consolidate all of their assumptions in one place, and then to reduce this list by confirming assumptions through a due diligence process. This will help the customer in making an informed comparison.

Tip 6: Adopt a strong governance framework

A strong governance regime will act as an ‘early warning system’ to help identify potential issues in their early stages.

While there are many structures that can be adopted when creating a governance framework, the most important characteristic of the framework is that the composition and role of each of the governance bodies be clear, and that the structure be easy to apply.

Separating the governance model into three streams focused on technical governance (which manages overall performance), strategic governance (which manages the business relationship), and operational governance (which manages day to day delivery) is often a useful way of delineating responsibilities.

Customers will need to be careful about recoding minutes of meetings and the content of communications both internal and external, concerning any technology delays and failures. These documents are often discoverable in legal proceedings and may impact your legal rights.

The effectiveness of the governance regime is dependent on ensuring that the right individuals are involved, and that there are clear escalation triggers (e.g. requests for scope changes or extensions of time are dealt with through the agreed contractual procedures).

Creating a short ‘contract manual’ after signing that identifies the key milestone dates and payments, deliverables, key personnel and which summarises the process of addressing scope changes, delay and contractual variations will often assist in ensuring that the project is governed in accordance with the contract, and will mitigate the risk of the contract being locked away in a bottom draw somewhere.

Phil Catania is a partner and Arvind Dixit a senior associate at law firm, Corrs Chambers Westgarth.