The Naked CIO: Crunch time for large projects

Project failures suck all the attention away from IT's real contributions. So knowing when to delay or cancel a project is just as important as giving it the green light, says the Naked CIO.

Do large projects make or break a CIO? For some time British Airways IT chief Paul Coby has been one of the guiding lights for CIOs in the UK and for anyone who wants to excel in IT management.

He has achieved that status by transforming BA into one of the most tech-savvy organisations in the world. Heathrow Airport's Terminal 5 was to be his next triumph in a series of successes.

Exclusive column: The Naked CIO

See what this CIO really thinks…

The Naked CIO: Boardroom stereotypes

The Naked CIO: IT staff disloyalty

The Naked CIO: Cut the bull

The Naked CIO: Animal farm

The Naked CIO: Offshore - or off their trolley?

The Naked CIO: Shadow of the job axe

The Naked CIO: Identity crisis

The Naked CIO: Innovation - same old story

We all know the difficulty of developing and implementing large projects on an enterprise level. Such projects require significant engagement from the business and carry high risks.

I have inherited two business-changing projects. Their designs and approaches are flawed yet the key decisions were already made before I arrived. I often wonder if I may soon have to deal with my own T5.

I am working on stabilising the projects, setting and managing clear expectations and delivering them using all the best practice I can muster.

But the key to any project is planning. Before starting a project, a CIO must be satisfied that proper due diligence has taken place and the outcome can be achieved. Unfortunately, I am not in that position.

Having managed large projects in the past I am acutely aware that many projects, especially ones that seek to innovate, are inherently risky. Everyone needs to be made aware of those risks from the outset.

There are times in every project when you reach the point of no return. I sometimes wonder if I would have the nerve to cancel a launch or to cancel a project entirely if I felt success was unachievable.

The challenge we face as an industry is that IT has always been evaluated solely on singular project successes or failures. Our industries and stakeholders must start evaluating the value of IT to an organisation and its contributions over time.

It is short-sighted to base someone's credibility only on one project, the success of which may or may not have been directly related to controllable factors.

We are still at an early stage in our ability to analyse IT contributions in a way that proves their value to the business.

CIOs need to be more focused on ensuring the message is not lost in the chaos of a specific deadline that draws everyone's attention away from IT's ongoing value.

It would be wrong to trivialise failed projects, because we all need to do more to ensure they don't recur. But at the same time we cannot trivialise the efforts of many on one badly executed project.

Another factor here is the definition of failure. The business treats failure in a very rigid fashion when it comes to IT and often doesn't allow for the most valuable part of the project experience to take hold - the ability to learn from mistakes and to snatch victory from the jaws of defeat.

The message is simple: we need to be aware of the cost of deploying something we know is flawed versus the cost of waiting until it isn't. We must have the conviction to act on this awareness.