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. They may even reduce the risk of your technology project failing.

Most distressed technology projects have common root causes which can be traced back to issues that arose in the early stages of a project. While it is not uncommon for these issues to be overlooked in the haste of commencing a project, you can significantly improve your project's chances by keeping in mind these simple tips.

Tip 1: Use the right contract

This seems obvious, but it's 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 the time up front to prepare a contract that is fit for purpose. This will save 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 project's successful completion.

A vendor's willingness to invest in a project is generally proportionate to the benefit that it receives, and its incentives to perform. A contract that strikes a fair balance between risk and reward will 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 are 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 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 focussed 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 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 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.

This article was first published by CIO. You can view it on the CIO website here.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.

Most awarded firm and Australian deal of the year
Australasian Legal Business Awards		 Employer of Choice for Women
Equal Opportunity for Women
in the Workplace (EOWA)