Successful IT Projects: Getting What You Want

A few days ago, I posted an article in our blog that was written by the CEO of Messaging Architects, Pierre Chamberland, on how CFOs and CIOs can help to minimize the risks associated with major IT projects by understanding the importance of project management. Entitled The 10.5 Essential Steps of Successful IT Projects, the article created a lot of buzz around the water cooler and led one of our Account Managers to forward me the following article as a potential companion piece to Pierre’s earlier submission. The article, entitled Successful IT Projects: Getting What You Want, includes a few more steps to help you make the most of your IT budget. It is reprinted below with permission from the author, James Flowers.

Successful IT Projects: Getting What You Want

Media reports are awash with stories of information technology systems and infrastructure projects gone wrong and cost overruns. This creates an impression that significant IT projects are 'risky', particularly in tough economic times where the emphasis is for IT departments to make the most of their information technology budgets.    

Whilst the success of an IT project can never be 'guaranteed', particularly if it is a complex project, the risks of failure can be greatly reduced, and acquirer's ability to mitigate the consequences of failure greatly enhanced, if that acquirer has satisfied each of the following steps:

1. Scoping the project before approaching the market

If an organisation does not have a clear sense of the outcomes it requires (functionally and otherwise), then inevitably it places greater reliance on the supplier to provide or deliver those outcomes. In such a case, it should never be assumed that the supplier's interests and objectives will be aligned with those of your organisation. A supplier will seek to supply a solution that meets its understanding of the requirements but also maximises the returns to it.

Further, if the customer is relying on the supplier's expertise not only to supply the solution/system, but also to determine what the solution or system should be, it becomes harder for the customer to manage project scope and costs.

The customer should therefore take time to determine what it requires, what is available, and whether the available solution(s) and systems are compatible with its requirements. If your organisation does not have that expertise internally, it could engage a consultant to assist with this process, or undertake a 'request for information' process – a precursor to a request for tender or proposal in which the customer seeks information about possible solutions or systems from the market.

2. Due diligence of suppliers – will the supplier see it through?

Whilst price and technical compliance are clearly important elements in evaluating a proposal or offer from a supplier, the history of IT projects is littered with examples of suppliers offering outstanding solutions or pricing that are too good to be true. The result is that such suppliers are not able to deliver on the solution, either because their proposals are not matched by their capabilities, or they lack financial substance.

Customers need to insist that prospective suppliers demonstrate both technical capability – regarding expertise and depth of resources – and solvency. To the extent that there is doubt on either front, customers should either steer clear of the suppliers, or require that those suppliers produce financial and/or performance guarantees. However customers must then ensure that the guarantor(s) has the capability and solvency that the supplier may lack.

3. Avoiding standard supplier contracts

Increasingly, many suppliers – particularly the large suppliers – are insisting that they will supply goods and/or services only subject to their standard supplier contracts. This may occur even where the supplier is responding to a request for tender.

Not surprisingly, standard supply contracts contain terms that are geared to maximise the supplier's position, usually at the cost of legitimate protections and rights for the customer. However, more fundamentally, if a customer accepts a standard supplier contract, it also accepts that its project will proceed in a manner that is largely mandated by the supplier, and is subject to the supplier's processes.

That may not be what the customer requires. For example, it may wish to ensure that the project is subject to its own project management and governance processes, and it may want to tie payment of fees to receipt of actual outcomes and benefits.

Therefore, at best, customers should challenge the notion that it must engage the supplier under the supplier's own terms. Naturally, if customers want to avoid supplier terms, they will need to develop their own template agreements.

4. Incorporating appropriate governance, reporting and oversight processes

A common feature in projects that 'come off the rails' is that problems or delays identified by one of the parties are not raised with the other party, then discussed and actioned in a forum that enables quick and effective decisions to be made about how to address that problem or delay(s). In many projects – particularly more complex projects – the prospect of unforseen matters and delays is relatively high.

However in the absence of an effective reporting, oversight and governance process, there is a real possibility that one party – usually the customer – will be kept in the dark about the existence of problems and delays, and may only find out about them at a point where the project is delayed, or where the costs have gone well beyond budget.

Appropriate governance will not of itself ensure that projects proceed smoothly, but transparency and effective communication will enable both parties to be more proactive as to how they address problems and delays. IT project contracts should therefore incorporate measures such as mandatory periodic meetings of project principals, and periodic reporting of progress and issues (which also tracks action taken on past issues raised). In projects of strategic importance to the customer, measures such as a governance committee, comprised not just of project principals but also other stakeholders of the party, would be worthwhile.

5. Tying payment to achievement of required outcomes and timeframes

For an organisation that has embarked on a business-critical or expensive IT project, there may be two nightmare scenarios.

It could be that the organisation is either contractually bound to continue paying the supplier for the work it is undertaking (even though the supplier is not delivering the contracted outcomes), or that the organisation has paid the supplier all of the fees and charges due only to discover that the supplier has not yet completed the project. Aside from the fact that the project is not delivered, an organisation in that position has largely ceded all of its commercial leverage: it either has to persevere with its supplier (at additional cost), or cut its losses and potentially have to start again.

From the customer's perspective, the preferable arrangement for payment of fees is that payment of particular amounts is tied to the supplier's achievement of milestones and/or delivery of required outcomes. This is not to say that the supplier should not receive any payment until the project is completed, but that the project should be divided into milestones, with instalments of the overall amount payable then tied to the supplier's achievement of those milestones. The amount received should depend on the relative importance of each milestone.

Nevertheless, the best form of arrangement is one where the bulk of the overall amount payable (at least 50% to 60%) is paid when the project is completed. Instalment payment arrangements do not provide the supplier with much incentive to complete if it has already received 90% of its payment.

6. Proactive contract enforcement

A well-drafted contract will give the customer a range of rights and remedies to address the supplier's failure to comply with that contract. If a customer feels that its proposed contract does not offer it the kind or range of rights or remedies that it would expect, then it should not sign it.

Assuming that the customer has all the contractual 'tools' at its disposal, the question will be which one of those rights it should use in particular cases. Regrettably, many customers feel that exercising any rights given to them to enforce their contract will in some way be a precursor to ending that contract, and so they do nothing. Once again, such an approach cedes commercial leverage to the supplier.

Issuing a notice of default, disputing an invoice and invoking requirements for a party to provide a guarantee are appropriate and usual actions for a customer to take (assuming that it has a right to do so). Customers should not feel that taking such action is a sign of failure. Rather, it should be seen as a proactive attempt by the customer to rectify problems, and a reminder to the supplier that legal obligations must be satisfied, or it will face consequences in the form of financial compensation or other remedies.

If your organisation is contemplating an IT project, it will be the one that has to live with the outcome of that project. It should therefore not be shy about requiring a contract and contracting process that ensures that the outcome aligns with its objectives.

– Debbie Howlett
Debbie Howlett is the Director of Product Marketing at Messaging Architects.