Project Life Cycle Activities in the Planning Phase

Many of the activities in this phase will have been started in the concept phase and, perhaps, even completed, depending on how well the customer's requirements are stated. But generally, this is the phase during which project plans and project team composition is refined and finalized. The first task during this phase is to complete and assemble the project team.

The Project Team

Resource requirements are determined from the requirement definition exercise and the high-level WBS development. The earlier the team is assembled, the better, but how fast this activity can be accomplished is purely a function of how well the project requirements are stated and understood from the beginning. It usually takes longer to assemble the team for projects that are generated from within the organization because of the lack of detailed and well-stated requirements. On the other hand, projects that result from competitive bids are better defined. Consequently, it is easier to establish minimum skill and experience levels for them. In fact, some customers, particularly from the public sector, often attach a key personnel clause to the contract, which specifies the minimum skill and experience qualifications the key members of the team must possess. The key personnel requirements, incidentally, become a part of the evaluation criteria when the customer is deciding who the bid winner will be.

Once the team is assembled, their first task should be to finish development of the WBS, because it is the tool upon which all the rest of the project planning depends.

The Detailed Work Breakdown Structure

The WBS may only require some refinements. As with every other aspect of the project at this stage of development, however, the completeness of the WBS is a function of how well stated the requirements are. But with most projects, the best that can be expected at this point is a high-level WBS. The team should finish its development. Even if the project manager and her peers have managed a rather detailed treatment of the WBS, it should be reviewed once more by the team, project manager, and the customer to ensure that all tasks have been captured. Remember, if it is not in the WBS, it is not in the project.

The WBS is the single most important tool in the project manager's arsenal because it is the basis of everything the project team will do for the remainder of the project. Without it, or without a complete one, good budget and schedule estimates cannot be developed, executable and achievable plans cannot be written, and there will be no accurate baseline against which to measure the project's progress.

It is important that the entire project team be involved in this final push to complete the WBS to ensure completeness and accuracy. This effort also serves as the first team buy-in and team-building opportunity. Finally, the customer should always approve the WBS because it is the instrument that captures all the requirements as well as the supporting project activities. If the customer decides that he does not want to pursue any part of the project, as a result of seeing the effort described by task, then now is the time to make adjustments in the project direction.

The next project team activity is the network analysis, which must be accomplished before budget and schedule estimates can be developed.

The Network Analysis

The network analysis is a tool that is basic to determining the schedule and, consequently, the cost of a project. Incredibly, many project teams and organizations do not do a network analysis: They just make an estimate at the schedule and build their project plans around that estimate. Without a network analysis, it is not possible to optimize the schedule, nor is it possible to identify points of resource conflict that may cause delays in the schedule. If everyone clearly understood its uses, no one would attempt a project without a complete network analysis.

The network analysis has several functions. First of all, it graphically shows all the task dependencies in a project or even in smaller components, such as a phase. The network should be constructed using task-level activities. If it is constructed at a higher level, say at the summary level, it will not reveal the source of problems, should they exist. Second, the network analysis is often the first opportunity to identify risk areas, such as resource conflicts or task dependencies, that might contribute to schedule delays if one or more of the tasks are late. Third, the network analysis identifies the critical path, which is the shortest duration that the project can be accomplished. The critical path, furthermore, defines the project schedule. From the network analysis, the project schedules can be developed.

Project Schedules

Project schedules are estimated from the network analysis, and, in fact, are basically a bar chart depiction of the network itself. It is crucial to develop as accurate a schedule as possible because the other key elements for project success—budget estimation and resource allocation—are dependent on it.

The project can have several schedules. If the project is a large and complex one, the project manager will need a master schedule that provides an overview of the project milestones. The master schedule is particularly important for communicating with the stakeholders and for providing general progress updates. The project manager will also need a schedule that shows each task so that actual progress can be tracked. In addition, the Gantt chart can be used to show milestones, meetings, deliverable dates, and any other information that assists the management process.

The reason that an accurate schedule is important is not so much because of the necessity of accurate progress tracking, although that is certainly important, but rather because there is no way to develop a reasonably accurate budget without it. Hence, the sequence is clear: network analysis to determine the critical path and other task dependencies, schedules by which the progress of each task, deliverable, milestone, and any other requirement can be monitored, and the budget for every aspect of the project. Once these key elements of the project are determined, the project plan can be written.

The Project Plan

The project plan is in some ways a misnomer because it implies one simple, straightforward document. The fact is, the project plan is neither simple nor straightforward. To be sure, there are templates from which a plan can be developed, and there are even software programs that aid in the writing of such plans. But although each plan should have pretty much the same parts, every project, being unique and different, will have to be described in a way that reflects its unique nature. So there really is no way to reduce the project to a routine activity. If that were possible, then project management would be simply an administrative function. Furthermore, the project plan is an amalgamation of several plans. That is, the project plan consists of the general description of how the project will be accomplished, and it also contains all the other plans necessary to support the project.

A key project management activity is the kickoff meeting. Ideally, the project kickoff occurs after the project team has completed defining the project to a significant degree, but that almost never happens.

The Kickoff Meeting

When is the best time to have a kickoff meeting? The right time is when there is enough information available to make the meeting meaningful, informative, and when most, if not all, the stakeholders can attend. This "right" time needs to be early in the project life cycle, ideally at the end of the concept phase or the beginning of the planning phase. However, the tendency is to schedule a kickoff meeting immediately after project approval. Often the pressure to schedule the meeting early comes from senior management because a meeting gives an appearance of activity that the planning function just cannot provide. Having the kickoff meeting too soon, though, can be counterproductive.

The problem with having a kickoff meeting too soon is that it defeats the purpose of the meeting. A kickoff meeting is an opportunity to provide a statement of the project's scope and general schedules, an indication of the most likely technical approach, an approximation of the resources needed, and an introduction of the stakeholders to the team members. But often the team is well into the planning phase before enough information about the project and project deliverables is available or clear enough to warrant discussing them at a kickoff meeting. However, waiting too late to have the meeting is just as dangerous as having the meeting too early.

Some organizations insist that the kickoff meeting should not be conducted until all the detailed planning is completed. Their rationale is that until the details are known, the project cannot be discussed with any authority. The problem with this kind of thinking is that by the time all the detailed planning is completed, the meeting is no longer a kickoff to the project—it becomes a status meeting. In addition, one of the primary purposes of a kickoff meeting is to get buy-in from the stakeholders.

The project manager and the project team are busy during the planning phase putting the finishing touches on the plans that will ensure project success. Key to developing these plans is the final product architecture.