The Phases of a Project

There are many different models for the phases a project goes through during its life-cycle. One of these captures the all-too-frequent nature of projects that are not managed well, and is shown in Figure 1-2.

I have shown this diagram to people all over the world, and they invariably laugh and say, “Yes, that’s the way it works.” I suppose the comfort I can take is that we Americans are not the only ones who have the problem, but the bad news is that there are a lot of dysfunctional projects if everyone recognizes the model.

At the simplest level, a project has a beginning, middle, and end. I prefer the life-cycle model shown in Figure 1-3, but there are other versions that are equally valid. In my model you will notice that every project begins as a concept, which is always “fuzzy”, and that the project team must formalize the definition of the job before doing any work. However, because of our ready-fire-aim mentality, we often start working on the job without ensuring that we have a proper definition or that the mission and vision for the job are shared by everyone. This invariably leads to major problems as the project progresses. This is illustrated by the example which follows.

Definition Phase

Some years ago a project manager in one of my client companies called me and said, “I’ve just had a conference call with key members of my project team, and I realized that we don’t agree on what the project is supposed to accomplish.”

I assured him that this was common.

“What should I do?” he asked.

I told him that he had no choice but to get them all going in the same direction by clarifying the mission of the project. He asked me to facilitate a meeting to do this, and I stood in front of a flip chart and began by saying, “Let’s write a problem statement.” Someone immediately countered by saying, “We don’t need to do that. We all know what the problem is.”

I was unmoved by this comment. I said, “Well, if that is true, it’s just a formality and will only take a few minutes, and it would help me if we wrote it down, so someone help me get started.”

I’m going to be a little facetious to illustrate what happened next. Someone said, “The,” and I wrote the word on the chart, and someone else said, “I don’t agree with that!”

Three hours later we finally finished writing a problem statement.

The project manager was right. They did not agree on what the problem was, much less how to solve it. This is fundamental—and is so often true that I begin to think we have a defective gene in all of us that prohibits us from insisting that we have a good definition of the problem before we start the work. Remember, project management is solving a problem on a large scale, and the way you define a problem determines how you will solve it. If you have the wrong definition, you may come up with the right solution—to the wrong problem!

In fact, I have become convinced that projects seldom fail at the end. Rather, they fail at the definition stage. I call these projects headless-chicken projects because they are like the chicken that has had its head chopped off and runs around spewing blood everywhere before it finally falls over and is “officially” dead. Projects work the same way. They spew blood all over the place, until someone finally says, “I think that project is dead,” and indeed it is. But it was actually dead when we chopped off its head in the beginning—it just took a while for everyone to realize it.

Once the project is defined, you can plan how to do the work. There are three components to the plan: Strategy, tactics, and logistics. Strategy is the overall approach or “game plan” that will be followed to do the work. An example of strategy was related to me by a friend who is into military history.

Strategy

During World War II, defense contractors were under great pressure to build weaponry at an intense level. To accelerate construction of ships and planes in particular, many new assembly methods were invented. Avondale shipyards, for example, worked on the method of building ships. The traditional way had always been to build the ship in an upright position. However, ships built from steel required welding in the bottom, or keel area of the boat, and this was very difficult to do. Avondale decided to build their ships upside down, to make the welding easier, and then turn them over to complete the structures above the top deck. This strategy was so effective that they could build boats faster, cheaper, and of higher quality than their competitors, and the strategy is still being used today, nearly 60 years later.

Implementation Planning

This phase includes tactics and logistics. If you are going to build boats upside down, you must work out the details of how it will be done. A fixture must be constructed that will hold the boat and allow it to be turned over without being damaged. This is called working out the tactics. It also includes the sequence in which the work will be done, who will do what, and how long each step will take.

Logistics deal with making sure the team has the materials and other supplies needed to do their jobs. Ordinarily we think about providing them with the raw materials they need, but if the project is in a location where they can’t get food, it will soon come to a grinding halt. So provisions must be made for the team to be fed—and possibly housed.

Execution and Control

Once the plan has been developed and approved, the team can begin work. This is the execution phase, but it also includes control, because while the plan is being implemented, progress is monitored to ensure that the work is progressing according to the plan. When deviations from the plan occur, corrective action is taken to get the project back on track, or if this is not possible, the plan is changed and approved, and the revised plan becomes the new baseline against which progress is tracked.

Closeout

When all the work has been completed, the closeout phase requires that a review of the project be conducted. The purpose is to learn lessons from this job that can be applied to future ones. Two questions are asked: “What did we do well?” The second is, “What do we want to improve next time?”

Notice that we don’t ask what was done wrong. This question tends to make people defensive and they try to hide things that may result in their being punished. In fact, a lessons-learned review should never be conducted in a blame-and-punishment mode. If you are trying to conduct an inquisition, that’s different. The purpose of an inquisition is usually to find who is responsible for major disasters and punish them. Lessons-learned should be exactly what the words imply.

I have learned during the past few years that very few organizations do regular lessons-learned reviews of their projects. There is a reluctance to “open a can of worms.” And there is a desire to get on with the next job. The problem is that you are almost sure to repeat the mistakes made on the previous project if no one knows about them or has an understanding of how they happened so that they can determine how to prevent them. But perhaps most importantly, you can’t even take advantage of the good things you did if you don’t know about them.

It has been said that the organizations that survive and thrive in the future will be those that learn faster than their competitors. This seems especially true for projects.