Planning Your Project

James Lewis

The Need for Project Planning

In my previous column, I pointed out that projects often do not succeed because of a failure to define the problem. Another major reason for project failure is inadequate project planning. To demonstrate the importance of this, recent surveys repeatedly find that only about 15 percent of all projects meet their performance, cost, time and scope targets. And the main reason for this is poor project planning.

When you consider that a project manager must control a project so that these targets are met, then the need for project planning becomes clear. Control is defined as: comparing where you are to where you are supposed to be, so you can take corrective action to get back on track when there is a deviation from the target.

Because it is your project planning that tells you where you are supposed to be, it follows that if you have no plan, control is impossible, since you do not know your target. The net result of this is that many projects run at a normal three sigma level, which means that as much as 30 cents of every project dollar are wasted due to rework. This goes for Six Sigma projects that are not properly planned. It seems to me that practitioners of a discipline aimed at improving performance of processes in an organization must focus on improving their own processes (that is, Six Sigma projects) before they can expect others in an organization to be interested in improving other processes.

Project Planning: Strategy, Tactics and Logistics

With any project planning you must deal with three major elements: strategy, tactics and logistics. Strategy refers to the overall approach you will use for your project. For example, do you have the luxury to have a dedicated team, or must you work on the project after hours, piecemeal, etc.?

Tactics are those activities that must be conducted to execute your strategy. What data must be collected? How will it be analyzed? When must each task be completed? Which ones are on the critical path in the project schedule?

Finally, logistics refers to the need to have proper equipment, supplies, a place to meet and so on. Teams can’t succeed without adequate material. It is the job of the project manager to ensure that this is addressed.

Project Planning: Roles and Responsibilities

Your project planning should also clearly define the roles and responsibilities of every member of the team. Failure to do this leads to role conflict and role ambiguity. Role conflict occurs when members of the team disagree about their roles. You hear this when someone says, "That’s not my job."

Role ambiguity occurs when a person is not certain what he or she is supposed to be doing. The result of either conflict or ambiguity causes role stress, and people do not perform well under such conditions. This can be another factor causing the project to operate at a three sigma level.

When role conflict occurs, you should get together with the individuals who disagree and carefully define their roles. When ambiguity exists, meet with the people who are unclear about their jobs and define it for them. To be sure that people really understand roles, it is a good idea to have them state their roles in their own words. Otherwise, they will nod their heads to say that they understand, when in fact, they actually do not. For more guidelines on these issues, you may want to refer to my book, Team-Based Project Management.

A Few Important Guidelines for Project Planning

The first rule of project planning is that the people who must follow the plan should participate in preparing it. If the project manager develops the plan and "throws it over the wall" to the people who must execute it, you can be sure there will be problems. Not only will the plan be faulty, but there will be very little commitment to it as well. My experience is that a project manager is optimistic in estimating durations of tasks to be performed by other people. In addition, no individual can think of everything to be done, so the plan will probably omit some critical tasks.

Another rule of project planning is to plan only in as much detail as you can manage. I violated this rule in one of my projects and lived to regret it. I planned a product development project to the nearest day, and it was off schedule almost as soon as I released it. The reason? We couldn’t control development work that accurately. In hindsight, it should have been to the nearest week. So you must determine to what time increments you can control the work, and plan accordingly.

The next rule of project planning seems obvious, but it is amazing how often it is broken. A plan is only of value if it is followed. So you must work to the plan, and when events occur that require you to change the plan, do so, and then begin following the revised plan. This rule is often misunderstood. I have had people say they aren’t going to have the plan tell them what to do. They aren’t. The plan didn’t create itself. The people created it, and now they are simply referring to what they said they were going to do.

If you are going to actually control your project, you must have project planning, and as project manager you should have members of the project team help you prepare the plan. Then follow it. When it must be revised, make the changes, issue new copies of the plan and begin following the revised plan. And consider this—if you are trying to get organization processes down to a Six Sigma level, shouldn’t one of those processes be the manner in which you run your projects?