Severity Omega - the It Project Crisis Management Handbook - A Toolbox for Handling Crises in It Projects

“No plan survives first contact with the enemy”
Helmuth von Molkte the Elder

This chapter aims to answer the question: What is a project crisis and what is a disaster?

Since you most probably are a project manager, you will have been through the “what is a project” discussion before, but you might not have thought about how you define a crisis.

First let me point out that one person’s crisis can be another person’s tough difficulty – and vice versa. Whether or not the time is right to declare an emergency situation very much depends not just on the state of the technical delivery, the budget or the organization, but also very much on the experience and confidence of the project manager.

Very often senior management might not agree with you that you are in a crisis, since changing the project plan always results in difficulties somewhere else, and frequently also in the loss of face.

The actual nature of a crisis can also be relative to the individual perspective. The same crisis could be described as several different problems, depending on who you are:

• “The developers are not delivering”
• “The specification for this feature is not making sense”
• “My project manager can’t handle this situation”

Every project will run into snags. That is why we have project managers in the first place. Very few projects are smooth sailing from end to end, and very few projects can be planned in detail for their entire duration – even if we pretend that they can.

To put it simply, we don’t know where we are going before we get there. This is a very rough generalization, but it is also a fact. It is of course mitigated by factors such as project management experience, the organization’s general familiarity with the actual subject matter of the project, internal and external conditions etc., but generally it is part of classical project dogma that we make big decisions in the beginning of the project based on very limited knowledge – as you can see the in the diagram.

Such a dilemma is normal, and even if many non-project managers believe that it is possible to completely and fully analyze and scope a project before carrying it out, they are wrong.

This means that the condition of not knowing everything in advance or the appearance of surprises and the need for minor adjustments of the project plan are not crises as such. Plans are meant to be changed, in fact not changing your plan when something unexpected happens, is one of the ways to ferment a crisis – and quite possibly a disaster.

The Merriam-Webster dictionary defines a crisis in several ways, but the one that is relevant to our purposes is this one:

Wikipedia has a longer definition:

So we will define a crisis as something bad and unexpected that might lead to a disaster.

This of course leads us to define the word disaster in relation to IT projects. If we go back to the two sources mentioned above, we get these definitions:

Merriam-Webster:

Wikipedia:

We will use two different disaster-related terms in this book:

• Project disaster
• Strategic disaster

Traditionally, we describe the ideally successful project as a temporary organization that delivers the desired product limited to the planned cost and the expected time.

Project management thus normally regards a project as being constrained by the three interrelated and interdependent dimensions time, cost (resources) and scope (deliverables) in the model known as the “Project Triangle” or the “Iron Triangle”.

It has been argued by several modern project theorists that we should actually look at a project as constrained by four dimensions in order to determine whether or not it is successful.

By adding the dimension “Strategic objective” as a corner in an “Iron Tetrahedron” we get a new discussion about what is a successful project and what is a failed project.

This book defines a project disaster as a project that ends up with major or critical deviations from the traditional constraints Time, Scope or Cost.

The term strategic disaster is used when the project does not result in the change that motivated it.

From the point of view of the Iron Tetrahedron model, a project can be riddled by crisis, and even overrun on all three classical constraints, but still be regarded as a strategic success.

Depending on what your role is in relation to the project, you might focus on one or the other.

When we look at project crises in this book, we look at bad, unexpected things that might lead to either project disasters or strategic disasters, and in many cases both.

Two historical examples for clarification:

Japanese attack on Pearl Harbor in World War II

Project success: Excellent planning of resources, time schedules and delivery. Operation Z was a stunning tactical masterpiece that got the entire world’s attention.

Strategic disaster: Quite possibly the greatest strategic blunder in world history. The attack got the Americans into the war and this eventually lead to the firebombing and nuclear bombing of Japanese cities, downfall and defeat.

Allied invasion of Europe in 1945

Project Crisis: Delayed several years. Plagued by political uncertainty, change of plans and terminology. Name changed from Operation Roundup to Sledgehammer (jokingly referred to as “Operation Roundhammer”) and eventually replaced by the different Operation Overlord. Many false starts and changes in mid-level management. Open bitter rivalry and contempt between prima donna middle managers. Bad communications and mistrust between allies. Severe cost overruns in terms of equipment and lives. The top manager, general Dwight D. Eisenhower, later described Overlord as a 50% overall success.

Strategic success: Overlord eventually lead to allied triumph, a devastated Germany, the death of Adolf Hitler and saved the world from the scourge of Nazism.

It is always more than a technical problem

Basically, IT project management disasters are mostly management disasters. Technology is a major part of what the projects are about, but most of the reasons why a project goes bad are about the way that things are done.

Many IT project crises are blamed on the underlying technology. It is very easy to point the finger at “technical errors”. If that doesn’t cut it, organizations often blame the suppliers or the developers. As a last resort, we can always blame the faceless corporate dynamics.

Be wary of explanations of what lays behind a crisis. Note that very often people who have left your organization are the ones who will be blamed. Your project might be the continuation of a different project and you need access to knowledge to get things going. That might be very difficult if most of your colleagues are interested in forgetting the whole thing and moving on.

Often senior management trying to get a crisis project under control will look for a single, clear root cause that can be corrected or eliminated and thus avert disaster.

But just as often the reason why things have gone bad is a whole series of problems, a network of root causes, accelerated by the way they are being handled.

In a few, fortunately very rare, cases management in the shape of the project sponsor/owner is more a part of the problem than of the solution. This can be one of the most difficult project crisis variations to solve. In such a situation the crisis project manager must make up his/her mind and decide if there is a way to divert a destructive senior manager’s attention from the project, if some other manager at the same level can replace that person’s role, if the project manager can insert himself as a buffer between management and the project organization (at considerable personal risk, that is) or some other similar workaround can be employed.

...