Lessons in defeat

Lessons in defeat

Poor planning may sink IT projects before they even start.

Many organisations are reinvesting in large, multimillion-dollar, long-term technology projects. Many will fail. Indeed, with some recent program failures having been made public it is timely to re-examine the causes. Problems observed in poorly constituted programs include:

  • Shortcuts taken to achieve pre-agreed milestones cause problems that will become evident later in the implementation or worse, after the go-live date;
  • Inadequate or inaccurate status reporting fails to inform executives of the true position of the program of work, preventing action from being taken in good time;
  • Key vendors are not managed properly or do not have enough "skin in the game". For these reasons they fail to meet their commitments and/or lift their costs;
  • Budget blowouts occur owing to functional or technical oversights that should have been picked up earlier in the program;
  • Gaps appear between expectation and reality, causing user dissatisfaction;
  • Much time is spent fixing problems, causing a bad impression of the new system ;
  • The magnitude of the change management effort is under-estimated, resulting in chaos and confusion;
  • Benefits espoused in the business case are loosely defined or unrealistically inflated to gain approval and may not be achievable.

Assurance steps

To reduce the risk of failure, numerous types of assurance steps can be taken. Some are mutually exclusive, others complementary.

1. Pre-program initiation stage gate review(s)

Best considered as pre-implementation reviews, these are aimed at heading off concerns from the outset. Various methodologies and stage gate reviews may be adopted and carried out individually or in combination. Aspects that may be considered include:

a) Concept. Is the program's concept well-founded? Has anything been overlooked, such as essential interfaces with existing legacy systems, either internal or external? What steps have been taken to ensure the proposed solution is not overly complex?

b) Business case. Is the business case solid with benefits properly ascribed? Have critical success factors been identified and agreed?

c) Program schedule. Is the program schedule realistic and achievable? Have sufficient contingencies been built in? Does it fit the organisation's business calendar?

d) People. Does the program team, including the proposed program manager and key vendor personnel, have the right competencies, availability and commitment? How committed are key business representatives to the project?

2. Business readiness assessment

Is the organisation really prepared for change? Does it understand the day-to-day impact of the program and the resistance that may be encountered?

3. Program management office framework

Some organisations do not have a PMO. If the proposed program is considered critical, a PMO will be needed for the life of the project.

For those with existing PMOs, assess roles, responsibilities and proposed outputs from the PMO so it can operate effectively as soon as the program is launched and capture facts on progress.

4. Governance framework assessment

Ensure that the right people are involved and empowered to make decisions about the program and that they fully understand their function and associated powers. Do those so empowered have knowledge of any changes in the accepted standards?

5. Benefit realisation framework

Have all expected benefits been articulated? Are they realistic? Who will be accountable for achieving them? How will they be measured? Who will measure them? When?

6. Three-pass risk analysis

Some organisations now choose to do a three-pass analysis of risks before embarking on a new program. First, using industry conventions of risk and probability, inherent risks to the program are rated (for example low, acceptable, high, very high and critical). Then, mitigation strategies are defined and costed. Having selected one or more of these strategies, the residual risk (the risk as assessed after relevant mitigation strategies have been factored in) is documented and enacted upon as required throughout the program.


When it comes to remediation, the earlier that interventionary steps are taken, the better. Though the focus of this article has been on pre-launch assurance activities, the value of periodic stage gate reviews throughout the entire cycle of program delivery cannot be emphasised too much to assist in ensuring program outcomes are achieved. To remove the risk of bias, these should be carried out by people not involved in the program.

The author is an adviser with IBRS. Email comments to

Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags strategyIBRSanalystrob mackinnon

Show Comments