The Titanic Sails at Dawn!

That line, from Bob Dylan's Desolation Row, is for me the best succinct definition of hubris there is. And hubris is the cause of an awful lot of project failures. Here are a few forms of hubris, and pride before a fall, that you will probably recognise.

'See the conquering hero comes'

When the project manager, and often many of the same team, come to a new project fresh from one that was recognised as a great success, they are given the benefit of the doubt, and questioned and monitored less vigorously, than lesser mortals. They themselves usually believe that their success is at least as much due to their skills as to chance or any other factor. The problem is that success with one project does not guarantee success with an entirely different one. That's not to say that good project managers don't perform better than average or poor ones, but that they are still fallible. In fact, they may be too cocky for their own good!

Everyone makes mistakes, and projects are full of uncertainties that need decisions. The temptation to believe that the successful project manager's decisions ought to be right, and the work of the team the best way to proceed, can lead to things not being properly and objectively evaluated. By the time it becomes clear that mistakes were made, a lot of time and treasure can have been wasted. The moral is: have the same, effective monitoring and evaluation procedures for every project, and apply them the same way every time.

'Never mind the quality, feel the width'

There are four constraints affecting every project: time, budget, scope and quality. Many projects have a greater emphasis on one, and that can lead to disaster as the others are forgotten. A project designed to accommodate a forthcoming legislation change will be seen as having the deadline as most important – the organisation cannot break the law -, and maybe cost is not a factor because there is no choice about the project. But costs still need to be controlled, the scope of the project needs to be maintained, and above all the quality, that is the fitness for the intended purpose should not be compromised. A bit pointless to deliver on time, if the project does not deliver compliance with the law, for example. A good example is the Millennium Dome fiasco, where the obsession with meeting the deadline meant that the project completely lost touch with its purpose: to create an attraction that people would want to visit. On time, but still an enormous and overwhelming failure on every other count.

Penny pinching to meet the budget at the expense of the project quality is another serious error, that is repeated far too often. If lack of money impacts on delivery dates, the project usually ends up costing even more, in direct and opportunity costs, and is still late as well.

The usual solution is to preview and test the effects of changes affecting the constraints, with the project sponsors when planning the project. What is the relative importance of the constraints, which can be allowed some slippage if essential to comply with the others, what scope can be removed, what objectives can be eliminated or postponed to another project? Knowing the priorities enables the project team to deal with problems early, and appropriately. If they know that budget is more important than scope, if estimates were wrong, or circumstances change, they can work out sensible actions to propose.

'Wishing and hoping, and hoping and wishing'

All too often, some problems are just left to the end. A lot of wishing and hoping that events will not happen, or solutions to problems will somehow turn up, or the supplier will actually be able to perform the essential miracle in time, and it will be all right on the night. 'After all, we are professionals, and know what we're doing.' Never happens.

The commonest situation is that slippage on times and milestones reduces the time for thorough testing, especially with IT and construction projects, and the project team hoping and wishing that there will be no last minute bugs and snags that they hadn't discovered. There always are.

An example is Heathrow Terminal 5, where the project team clearly hoped that the limited testing they had done could be scaled up to full operation in one go, without any problems. We know what happened. Not enough car park spaces for the workers, so many were very late; too many people not adequately briefed; no contingency plans for the volume of staff not present; no testing of the effectiveness of the equipment under sustained heavy load. And so on, and so on.

The fundamental rule is: if something has not been fully tested for real life, it does not work. Compromising on testing is compromising on success. And as a project manager, if you are going to go live with a big bang, rather than piloting and incremental delivery, ensure you are wealthy enough never to have to work again.

In conclusion, never trust yourself, your project team, your sponsor, or the world outside,and do not rely on the past as a guide to the present. Check, evaluate, test.