One area where nearly every project manager and nearly every project team ever assembled needs help is in the realm of project planning. I’m not professing to be an expert in project planning, but what I have I’ve learned along the way is don’t take it lightly, allow enough time for it, use your team to your advantage while doing it, and never feel too comfortable like you’ve covered all your bases. Let’s look a little further at some thoughts on effective project planning.
Plan to plan
It is always difficult to get people together to develop a plan. The planning session itself should be planned, or it may turn into a totally disorganized meeting like those that plague many organizations. This means that an agenda must be prepared, that the agenda should be time-limited to the degree possible, and that people should be kept on track; if someone gets off on a tangent, the meeting facilitator should get the person back on track as quickly as possible.
The project implementers should be the planners
The people who must implement a plan should participate in preparing it. Otherwise, they may feel no sense of commitment to the plan, estimates for their work may be erroneous, and major tasks may be forgotten.
Expect the unexpected
Because unexpected obstacles will crop up, always conduct a risk analysis to anticipate the most likely ones. Develop Plan B just in case Plan A doesn’t work. Why not just use Plan B in the first place? Because Plan A is better but has a few weaknesses. Plan B has weaknesses, also, but they must be different from those in Plan A, or there is no use in considering it as a backup.
Ask what could go wrong
The simple way to do a risk analysis is simply to ask, “What could go wrong?” You should do this for the schedule, work performance, and other parts of the project plan. Sometimes simy identifying risks can help avert them; if that is not possible, at least you can create a backup plan. One caution: if you are dealing with very analytical people, they may go into analysis paralysis here. You are not trying to identify every possible risk- just those that are fairly likely. Identify project risks, and develop contingencies to deal with them if they occur.
Look at the purpose
Begin by looking at the purpose of doing whatever is to be done. Develop a problem statement. All actions in an organization should be taken to achieve a result, that is, to solve a problem. Be careful here to identify what the end user really needs to solve the problem. Sometimes a solution is developed that the project team thinks is right for the client but that is never used, resulting in significant waste to the organization.