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.

Why does change fail?

Successfully bringing about worthwhile change, irrespective of the size and extent, is often extremely difficult. In fact, some research suggests over 80% of business transformations fail.

Change is imperative: whether driven by market forces, the state of the economy, government legislation and direction, newly available technology, or the need for growth, no organisation can stand still.

There are many causes of failing to achieve the expected outcome from a change plan. The bigger the change, the more problems that can occur.

The common causes of failure can be grouped into four categories: failing to define strategic objectives properly, failing to relate actions to those objectives, failure to deliver projects satisfactorily, and failure to manage the people issue. Even a single project should relate to a strategic objective, even if that objective is simply survival or to stay within legal obligations. The following diagram illustrates the stages of a major transformation; at each step, things can begin to go wrong. The diagram illustrates the descending connection from Strategic Objective to Implementation. Each lower level must be clearly and directly related to achieving the objectives of the higher level: for example, no projects should exist that are not part of a programme, which is part of an action plan which is designed to deliver a strategic objective.

What should be done?

Firstly, the people and processes are the framework within which all change planning has to take place. Without the right people being available, adequately involved and concerned, supported by processes for change (as opposed to processes for business as normal), no transformation can be carried out effectively, if at all. There is no point in developing a strategic objective that can never be delivered. For example, if the objective requires skills the organisation does not have in its work force and cannot easily acquire, or will require things outside its workforce's job descriptions, or believes that it has the power to bring about change merely by demanding it, failure beckons.Strategic Objectives should be clear, unambiguous, agreed, achievable and of course resourced. If different people have different understandings of what an objective means, it will never be accomplished. Each objective should be expressed succinctly, and be defined wherever possible with measures, so that everyone can see how it has been met. Vague or unmeasurable wishes are not realisable objectives.

Whilst imposing objectives from on high can sometimes work, better results occur if everyone affected is committed and understands what the objectives actually are and why they matter. This requires communication and explanation to obtain agreement.

Objectives

Each Objective must be capable of being delivered. There is little point in aiming for things than cannot be achieved in the timescale, or at all. Over ambition, objectives that depend on factors outside the organisation’s control, and objectives that far exceed previous achievements are unlikely to succeed. Times and milestones should be realistic, and recognise dependencies properly.

Adequate resources must be made available: finance as required, appropriate skills and expertise, and enough time and people. There is little point in willing the end without also willing the means.

Each Objective must have clearly defined, evaluated and quantified benefits to be realised by achieving the Objective: what is the point of doing anything if there is no clear benefit from it?

Action Plans

Each Action Plan should be clearly connected to one or more strategic objectives. Some research suggests that about 40% of action plans are not related to any objective at all. Creating effective and deliverable plans is not easy, but failing to do so is the commonest cause of failing to achieve the objectives. Comprehensive planning is critical. There should be a comprehensive and comprehensible definition of the benefits expected from the Action plan, that directly come from the Strategic Objective definition.

Programmes

Each Programme should be designed to deliver one or more action plans, and be connected and achievable. Ideally, each programme should be organised around related objectives and activities, and consist of projects that can be planned and delivered. There should always be a clear end state that a programme should deliver.

Projects

Every Project should be defined and capable of delivery. The business needs and requirements should be enabled by Information Technology and the Internet where appropriate. Each person involved in each project should understand their role in the work and the project development process. Extensive planning is essential, and should be connected to the overall programme plans where relevant.

People

All change and every step are dependent on People: those who are carrying out the change, and most importantly, those affected by it. Every change ultimately depends on all the people involved not only understanding and accepting the change, but being enabled by appropriate process and tools to deliver. Many change programmes ultimately fail because the needs and views of the people at the end of the line: those facing the customer, making the product or delivering the service, were not properly considered, and processes not redesigned as needed.

Change is essential and unavoidable. It involves effort, and risks. To achieve the benefits change must be properly planned, designed and executed: there are no short cuts.

Some ideas that can help

Planning:

Inadequate initial planning of actions, programmes, projects, can often doom an entire change plan from the start. Whilst the desire to start and get some quick wins is reasonable enough, planning comprehensively from the start is imperative. And plans must be kept up to date - regularly revised in the light of new circumstances, and as each part is delivered.

Monitoring:

the need for effective monitoring of progress throughout is essential. And monitoring does not mean just creating or receiving reports, it means taking action and making decisions. If progress is not maintained as planned, the reasons should be found, the effects identified and corrective action taken - as soon as possible.

Communicating:

Failure to communicate with key stakeholders - regularly, comprehensively, clearly - will inevitably lead to problems. No-one will feel involved, or become committed, if they don’t know what is happening. This also means listening as well as telling!

Structure:

The application of structured methodologies, such as Prince2 for projects and MSP (Managing Successful Programmes) at the very least will provide checklists and some ideas of best practice. They are not an answer, but they are a guide, and because they are well established, many people will already know them. They also help everyone involved understand their roles and what is expected of them.

Benefits:

Throughout the entire change and transformation exercise, the benefits must be managed, and individual, named people made responsible and accountable for realising them. Losing sight of the benefits is the commonest cause of ultimate change failure: even if the changes have been implemented on time and to budget, if the benefits are not realised the whole exercise was pointless. As a quick reality check, every benefit defined as part of a project plan should also appear as a benefit of the programme, the action plan, and the strategic objectives. If it does not, there may be a problem, although sometimes there are subsidiary benefits from aspects of a project that are not part of its purpose or justification. The reverse is imperative: every strategic objective benefit must appear in at least one project as well.