How to Avoid IT Project Failure

Four steps to help you beat the paltry success rate of 16.2 per cent

TOO MANY LARGE IT implementation projects are still materially late in delivery or significantly over budget. The latest statistics are sobering; for example, the 2014 CHAOS report from the Standish Group found that “Overall, the success rate [for IT projects] was only 16.2 per cent, while challenged projects accounted for 52.7 per cent, and impaired (cancelled) for 31.1 per cent.”

Given the sad state of affairs in the major IT project space, it is very much worth asking what parties to these transactions can do to help improve the chances of success.

What follows are three recommendations for your IT project contract, and the suggestion that you build into your IT project governance a “major project facilitator.”

Supplier Staff Continuity

In my experience which includes having acted for a number of parties in litigation over failed IT implementation projects a key factor that leads to supplier failure or significant sub-standard performance in the implementation of large IT projects is the lack of continuity of the key staff of the supplier. That is, when one or more key people on the supplier team leaves the project part way through (for example, a departure of the supplier’s “solution lead” six months into an 18-month project), this causes great risk to the IT project because, however expert the replacement, the new person simply will not have the “personal institutional knowledge” gained of the customer over the first six months of the project. And then this knowledge deficiency produces sub-optimal decisions, which then lead to the project running (sometimes significantly) over budget or behind schedule.

Accordingly, you should consider trying to solve for this risk by adding to the Master Services Agreement (“MSA”) between the parties (or whatever the relevant contract is called) a very strong “key personnel continuity clause”, that essentially prohibits the supplier from removing a key staff member from the project, unless the staff member resigns or is medically incapacitated. For example, the clause would prevent a supplier from shifting the key personnel on a customer’s project to a larger or more strategic project/client.

Fairly often, however, a supplier will want the customer to waive this clause. I counsel extreme caution in response. Again, it is not a question of the quality of the new person being proposed, but rather the inevitable setback to project progress should the then existing person be removed. Therefore, it is often best for the customer, when confronted with such a request, to push back very firmly, and not allow the departure of the supplier’s key staff member who has the critical experience with the customer. In short, it is important that the customer administer the staff continuity provision promptly and forcefully. Doing so will materially increase the likelihood of success for the project.

Avoiding Scope Creep

Many large IT implementation projects are done on a fixed-price basis; that is, there is a defined set of requirements or specifications (often referred to as the “initial scope”), and the supplier agrees to implement a system that conforms to the initial scope for a fixed price. This is a “best practice” method of contracting for an IT system, because it gives the customer certainty over cost and functionality early on, when the contract is signed.

What often happens, however, in these projects is that when the first phase of the new solution (perhaps the base, “out-of-the-box” software, which will subsequently be customized by the supplier) is delivered and unveiled by the supplier, the staff of the customer begin to use the base software. The result is that very quickly before the overall system is even installed the staff become enamoured of the new system, and immediately they begin to suggest ways the implementation can be “improved” by adding yet further business requirements to the initial scope. And while many suggested additions would indeed increase the utility and value of the system (at least once the system is up and running successfully), the reality is that such “add-ons” can put significant additional strain on the technology, the core business processes being automated, or the implementation team, thereby causing the project to experience greater completion risk.

The colloquial word for adding further wish list items to the initial project blue print is “scope creep.” And while adding increased functionality to a software platform would seem like an innocuous exercise, it is not. Invariably the scope creep causes a logarithmic, rather than a linear increase in complexity and risk. Moreover, if the scope creep is material, it will inevitably put at risk the original delivery or Go Live date, and it will add costs wholly out of proportion to the incremental value represented by the marginal increase in added functionality.

Responding Promptly to Customer Deficiencies

Invariably, in order for the supplier to complete a complex or sophisticated IT project on time and on budget, the supplier’s customer also has to perform certain roles, duties and obligations. For example, if the supplier is customizing some standard software to meet the specific requirements of the customer, then there will be a need for the supplier to discuss those customizations with so called “subject matter experts” (or “SMEs”) from the customer. Therefore, if the SMEs do not attend meetings, or do not approve interim deliverables reasonably promptly, the project will not be able to move forward as planned.

Accordingly, I try to ensure that the relevant Statement of Work (“SOW”) lists with some precision what the obligations are of the customer for the project (i.e.- what are the precise expectations on the customer’s SME’s in terms of meetings, sign-offs on drafts, etc.), and then the MSA goes on to say that if these customer obligations are not being met, the supplier must promptly notify the customer’s senior manager involved with the project.

Therefore, the point to keep in mind here is that the business people at the customer must understand clearly what obligations the customer has under the MSA and SOW, so that they can make arrangements to ensure those obligations are carried out. For example, if a particular SME is already 100 per cent engaged on a previous project, then arrangements must be made within the customer to free up some of the SME’s time by shifting some of the SME’s “regular” work to another employee of the customer, etc. And, most importantly, the customer must ensure that the customer obligations undertaken in the MSA and SOW are indeed being carried out promptly and fully during the course of the project.

In short, it is not enough to negotiate “best practice” contract provisions into large IT project transaction agreements. In addition, after contract signing, those provisions must be administered and managed proactively in a manner that delivers maximum value for the customer.

Major Project Facilitator

Whether you are a customer or a supplier, to reduce the risk of large IT project failure, you should consider retaining a Major Project Facilitator (“MPF”) at the earliest stage of your project. The MPF’s role is to act as a neutral who can detect early on if the project is beginning to go off the rails, and can help both parties course correct in order to keep the project on track.

In order to function effectively, an MPF must have deep strategic and tactical expertise in major IT project planning, management, and execution from both the client’s and supplier’s perspective; be a good listener and facilitator; have superb people skills, in order to quickly gain the confidence of both the client and the supplier and then to maintain this trust throughout the project implementation; and be adept at delivering difficult messages in various circumstances.

These would be the terms of engagement for the MPF Service mandate. The MPF is jointly retained and paid by both parties (the MPF does not represent either party, but rather has a mandate to serve as a bridge and conduit among and between the parties, in order to identify and help rectify small problems before they grow into big problems). Each party agrees to provide the MPF with full and unhindered access to the party’s people and information; often a root cause of major IT project failure is the inability of senior decision makers to fully understand the status of the project from their own staff – an important role for the MPF is to ferret out the truth as to what is really going on, including the bad news that no one on the respective teams is willing to disclose otherwise. In addition, both parties agree in advance that neither will be able to call the MPF as a witness in any subsequent litigation or dispute resolution related to the project. The MPF is also under very strict rules of confidentiality. The notes taken by the MPF are completely confidential, and may never be used in any forum of dispute resolution – this ensures that senior and other members of the parties can confide in the MPF without reservation. Further, the MPF is entirely free of any conflict of interest. The MPF is retained under a written agreement signed by both parties and the MPF, and the MPF is paid an hourly rate for time spent on the project. The amount of time spent with the parties, both jointly and in one-on-one sessions with each party, varies depending on the mandate and the particular stage of the project. Typically, the MPF’s activity will be heavier in the earliest stage(s) of the project and reduced later on, unless the parties hit a difficult stretch where the involvement of the MPF can intensify.

Finally, in contrast to an IT project “health check” (where typically a disgruntled customer brings in an IT consultant when a major problem threatens the project), the MPF is retained at the very beginning of the project so that relationship, communication and other potentially fatal problems can be identified at the earliest, embryonic moment, and nipped in the bud, before they become confidence destroying drivers of failure.

George Takach is a senior partner at McCarthy Tétrault LLP and the author of Computer Law.