Projects have a special place in the IT risk portfolio for the obvious reasons that they are unitary, defined activities that can be observed directly, with budgets, start dates and target dates. Projects can fail totally, permanently and irrevocably – and also spectacularly. There are many others that are less than perfectly successful. Newspapers reveal the budget overruns, delays and terminations, usually in bald, budgetary terms. This reporting boosts the reputation damage, but it can seldom reveal the opportunity costs – What if the funds had been applied to some other project? Not only has the capital expenditure been lost, the anticipated benefits have disappeared too.
The failure taints working relationships between IT and business unit heads, as well as any vendors who are involved. It is here that the caustic alternative meaning of CIO originates – ‘Career Is Over’! It is easy and quick to build a poor reputation inside the organization and very difficult to rebuild a good one – easier to move to some other company.
If your organization consistently fails to deliver on IT projects, business unit heads will not regard the IT function, and any associated service providers, as valuable partners in the business – quite the opposite. Over time the slippage in IT services, applications and infrastructure will contribute to putting the organization in a vulnerable position – to competition, takeover or failure.
Over the years many approaches to solving the IT project problem have been developed, many books written, much research, experimentation and investigation conducted. Some of it has worked, for some organizations in some situations, but no panacea has been found. In many cases, simple ‘bad luck’ destroyed all the hard work – the project leader died; some emergency diverted the funds for the project; the programming development environment vendor went broke.
You may argue that these were predictable and could have been planned for – yes, this is true, but the likelihood of each would have been so small that it got under the threshold for contingency plans.
The bureaucratic approach to delivery assurance, favoured by government agencies for example, ties a project to a rigid set of outputs and deliverables at each of many stages. The ‘Structured Systems Analysis and Design Methodology’ (SSADM) adopted by the British and Hong Kong government, for example, stipulates documents that must be signed off before subsequent stages commence.
Developers face the risk of deadlines encroaching while users cautiously hold back signatures. It is also costly to implement and can be inappropriate for some projects. The overhead involved can make such approaches unattractive for internal development.
Some organizations have star teams or star players, who can be left to get on with the job, like the team led by James Gosling at Sun Microsystems that developed the Java toolsets. The excellence of their skills and track record is the way to reduce risk for the project, especially if it is ill-defined or leading-edge.
An alternative approach, less demanding than the bureaucratic one, relies on methods and standards. These can be internally developed or adopted from outside, but their approach to risk is to follow things that have worked in the past. Many organizations will over the years end up with a mish-mash of methods and standards, whose continued adoption may not be warranted.
Project risks can be quite different to other risks. The project may be very large – which is well known as bringing higher risk. This cannot be changed without changing the nature of the project. It may also involve new technology – we simply can’t substitute old technology to reduce the risk. Many publications present ‘laundry lists’ of risk factors, which may unfortunately confuse causes and consequences. We focus on causes and help you to develop a set of indicators that track the movement of the project risk profile, from the day that the project is formally initiated until the day of handover.
— extract from Beating IT Risks, Chapter 1: Thriving on risk —