Minimizing the Risk of IT Project Failure
by Duncan Card and Melissa Ross
Last issue Denis Desautels provided advice on managing IT projects from an accountability point of view. This issue, Duncan Card and Melissa Ross provide advice based on well established business and legal principles as well as best procurement practices.
Almost 75% of public sector IT transactions that occurred between 1994 and 1998 failed or were ‘challenged’ as being operational but over-budget, over-time and less functional than originally estimated, according to the Standish Group's CHAOS Reports. Have we improved in the past seven years?
The City of Toronto's Computer Leasing Inquiry, which has now reported on the $43 million IT procurement transaction that ballooned to more than $80 million, is one of the more recent and visible examples of large IT project failure. (The report of Madam Justice Bellamy, Commissioner, is at www.torontoinquiry.ca.) In the face of hundreds of millions of dollars that have been wasted across Canada's public sector in recent years as a direct result of IT project delays, cost overruns and failures, the Government of Ontario commissioned a special task force in 2004 to better understand IT projects risks and ways to improve their success rates.
In an age where so much is at stake in large IT projects, there is tremendous demand for improved procurement practices that take risk management to new levels of project management. There are clear proactive strategies that can be followed to minimize the risk of IT project problems and to drastically improve the chances of overall success.
PREPARE A BUSINESS CASE
A thorough business case is the starting point for any IT transaction, and it must be prepared with ‘brutal honesty’ concerning the quality, and limitations, of the internal skills and experience of the department undertaking the project. The business case should involve a detailed needs assessment, and include a list of specific (and verifiable) transaction objectives, performance requirements, as well as realistic budget limitations. A business case is not a wish list of expected outcomes, nor is it a statement of how ‘the vendor’ will solve specified problems. It is a detailed analysis of realistic needs and objectives and how the IT project will deliver those outcomes. The business case must define the department's interests in the transaction – business, administrative, operational, policy or financial – and should include the department's threshold of tolerance for risk in all of those areas. Each of those requirements will serve as the cornerstone for future commercial negotiations.
The key team players must be assembled at this early stage – HR, expert consultants, legal, finance, operations and other constituents who will need to be consulted during the transaction. Identifying constituent interests as early as possible will avoid many unexpected problems at a later date. From the outset of an IT project, one of the most important risk management strategies is a business case that is: clearly written, definitive, empirically verifiable and outcome specific. If all management has to rely on is a high level proposal (or ‘project plan’) for why a particular IT project ‘makes sense’, then the department is probably not ready to engage in that project.
SPECIFY PERFORMANCE OBLIGATIONS
Perhaps the most obvious and frequent cause of IT project disputes, problems and even ‘melt down’, lies in the failure of the parties to use the business plan to determine detailed operational, functional and even technical performance specifications and requirements. The success or failure of any IT project can only be measured against such empirical criteria. Therefore, before an IT transaction begins, create a ‘blueprint’ of your project by specifying those performance requirements in clear terms. A detailed description of that endeavour would constitute an article in itself. The simple rule is to be as specific and as encompassing as you possibly can, and as early as you can. Trying to structure and negotiate a transaction without following this rule will, almost certainly, result in material problems in your project.
In our experience, identifying those needs as the transaction progresses does not work. The customer's failure to understand and know exactly what they require prior to the transaction being structured and negotiated is the number one cause of transaction risk, dispute and litigation for IT projects in Canada. Without clearly defining those obligations from the outset, it is impossible to settle pricing, timeframes, service levels, or to even know if you have ultimately achieved the business case.
In that regard, the biggest mistake (and with the most disastrous consequences for IT project risk) in structuring IT projects involves the failure of the parties to entirely separate the ‘define & design’ phase from the ‘build & implement’ phase. For example, in large ERP (Enterprise Resource Planning) or even outsourcing projects, I continue to see parties engage IT vendors and service providers with a ‘design it as we build it’ approach with no clearly defined business process structures, operational requirements, technical (service level) specifications or other deliverables. What $100 million building project would ever begin construction without first hiring an architect to create a definitively detailed blueprint of the exact structure desired? And yet, IT projects of far greater value can be contracted with no such blueprint, and based on only vague ideas of desired outcomes.
There should be no procurement of IT products or services before those specific requirements and specifications have been defined in detail. If those requirements change, then rely on the contract's Change Management Protocols to address those issues. In most circumstances, departments that have not had the time, resources or planning experience to first define the business processes, operational requirements and technical specifications are not ready to undertake that IT project.
PERFORMANCE MONITORING AND RESPONSE PROTOCOLS
It is trite to remind managers that almost all IT project problems start off as small problems – and most often, with unmistakable warning signs. In our experience, the vast majority of IT project problems and disputes could have been easily mitigated, avoided or resolved if they had been identified and elevated for executive resolution when they were small problems. Performance monitoring, verification and response protocols are essential for successful IT project management, and all performance review mechanisms should be expressly set out in the governing contract.
Consider including such monitoring mechanisms as:
(a) regular Joint Management Committee meetings, with minutes and follow-up assignments for future reporting;
(b) contract breach reporting, including even minor service level failures or missed time requirements;
(c) asking operational managers for improvement suggestions (which will indirectly identify problems);
(d) periodic services reports, which delineate exactly the information you will need to spot troubles early on;
(e) customer satisfaction surveys; and,
(f) performance audits to identify small problems early on.
In addition, a response protocol should be stipulated in the contract to ensure management accountability. Performance reporting alone will be meaningless without stipulating who is responsible for dealing with that information, when and how.
DISPUTE ESCALATION PROCEDURES AND REMEDIES
The IT project's Joint Management Committee should deal with all performance issues, dispute resolution, change management and project governance. There should be internal controls for each party that provide for an ‘up the chain’ escalation procedure that moves from the Joint Management Committee to senior executives to efficiently exhaust internal dispute resolution mechanisms before resorting to outside resources.
We also recommend the use of expert third parties who have extensive IT project or transactional experience to assist in those deliberations. As a part of the ‘know yourself’ honesty required to create a business plan, many departmental project managers should recognize that their large IT project experience may be limited, whereas outside IT professionals may have structured, negotiated, and helped to govern dozens of engagements.
Once internal options for all of those matters have been exhausted, the contract should expressly provide for specific avenues for external resolution, such as third party evaluation, mediation, arbitration, etc. In both the internal and external processes, there should be stringent notice provisions, response timelines, and escalation protocols to be followed in order to maintain momentum and bring the issue to resolution as quickly as possible.
Remedies should also be stipulated in the contract and tailored to the original business case. Financial compensation clauses (through damages, liquidated damages, penalty clauses or negative financial incentives) are required, but are not always sufficient to help the department achieve the desired business case. Financial remedies do not address performance issues directly. Performance remedies designed to correct the problem and make the project successful are essential to the business case, and include: access to alternative assistance or providers; additional vendor resources; personnel changes; supplier additions or changes; access to source code; perhaps a mechanism to wind-down the IT project in an orderly manner; and even making changes to the scope of the IT project.
CONCLUSION
As a matter of sound governance and risk management, there is a wide range of well established transaction ‘best practices’ that are designed to promote IT project success and reduce the unacceptably high failure rate that currently exists. The proactive adoption of the strategies discussed will radically change the ability of IT project managers to achieve their business case on spec, on time and on budget.
Duncan Card is a partner, and Melissa Ross is a senior associate, of Bennett Jones LLP. Duncan is widely recognized as one of Canada's leading IT procurement lawyers. He was interviewed as an IT procurement ‘best practice’ witness at the Toronto Computer Leasing Inquiry, and he was the only IT procurement lawyer among the total of 83 witnesses to the Ontario Large IT Project Task Force during their investigations (cardd@bennettjones.ca). The Report of Ontario's Special Task Force on the Management of Large-Scale Information & Information Technology Products, released in July 2005, is available at http://www.itac.ca/Library/PolicyandAdvocacy/Procurement/05JulOntarioSpecialTaskForce.pdf.
