CIO Upfront: Time to rethink how we tackle project risk

The questions have to be asked: What is it that makes ICT projects so risky, and why do we still keep getting surprised?

Comments

Decades after we began deploying computer systems, and despite the best efforts of the project management industry, we still as a sector have a failure rate that wouldn't be tolerated in other industries. The questions have to be asked: what is it that makes ICT projects so risky, and why do we still keep getting surprised?

There seem to be some common themes when chatting to other project troubleshooters. I've split these into three headings:

1. Time, cost and functionality (sometimes called quality)

2. Divergent objectives

3. Reporting obfuscation

The first project management course I went on when I still had hair began with the Time, Cost and Functionality model. The saying goes that you can have two of the three (I'll leave the negativity of that as an expectation for another day – would you fly with a pilot who thought like that?). I prefer to ask which one isn't negotiable. When I try this, discussion tends to oscillate between time and money, but I think the real answer is functionality. If the new solution does nothing useful, the others are irrelevant.

The challenge is that functionality is arguably the hardest to measure. Time and money are fairly easy to represent as numbers, functionality tends to be more qualitative. That's because ICT projects are often a learning process – the functionality delivered at the end is often (wisely) not quite what was envisaged at the beginning, except for the most basic projects. The risk is not that the functionality specified won't be delivered – it is that the functionality won't be what the project has learned should be delivered.

Which brings us to the question of objectives. Even the simplest project objective (say, rolling out a new accounting platform) has many variables. Deployment almost always offers opportunities for change and improvement. In setting objectives I have long adopted the (agile inspired) approach of asking, "how will we know when we have finished?" as a useful tool.

This allows us to express risk in a more useful, business-focused way than simplistic technical checks (they are still required, but can come later). This is a valuable exercise at the executive / leaders table – almost like "why, why, why, why" it can drive clarity around the outcomes and expectations. I've also seen it kill a number of nascent projects before the winds of blind optimism have driven the organisation too far off course.

Next: False comfort