Building a Project Plan

The first step in building a project plan is to validate the elements of the Project Definition document. Depending on the length of time between acceptance of the project definition and the start of detail planning, you might need to confirm that there have been no changes in the purpose, objectives, success criteria, and scope of the project with your key stakeholders.

 Tip

To simplify the review process and minimize future document modifications, capture any information that is shared, needs to be reviewed separately, or is likely to be updated frequently in its own document.

Common examples are assumptions, WBS, communications plan, project schedule, requirements, project organization chart, and responsibility matrix.

• Validate project definition—This section should reference the Project Definition document and includes all required elements of a Project Definition document. The key task here is to revalidate the business case for the project. This is especially important if there has been a time lag between project definition and detail project planning, or if the planning exercise results in time and cost estimates significantly greater than originally estimated during project definition.
• Determine what needs to be done—This section should provide any additional details regarding the project approach (how this will be done), the targeted deliverables that will be produced, and all the work that is required to complete the project. This section normally refers to a list of deliverables and to the WBS.
• Determine acceptance criteria—This information can be part of other components, such as the deliverables list, WBS, project approach, or quality management plan, and might not be its own section. However, to validate that all required work has been identified and to improve the quality of work estimates, it is best to clearly document (somewhere in the project plan) what the acceptance criteria are for each deliverable and for each project phase.
• Determine resource needs—Based on the tasks and activities that need to be performed, determine the type and quantity of resources needed. Resources include people (roles), facilities, and tools. These resource needs should be determined when developing the WBS with the team members who will be doing the work.To assist the acquisition and management of these resources, all resource needs should be documented (resource management plan). For people resources, document the role description and the prerequisite skills, skill levels, and experiences.As part of the scheduling process, the timing of resource needs should be noted and finalized in the resource management plan. A sample resource management plan is illustrated in Figure 5.2.FIGURE 5.2Basic example of a resource management plan.
• Acquire resources—After the resource needs are documented, we can now begin the process of acquiring those resources. The key questions to be answered here are
  • Will I be able to get the quality of resource requested? NoteThe responsibility matrix is often referred to as a RACI (“Ray-Cee”) matrix or RASIC (“Ray-Sick”) matrix. The acronyms represent each level of potential responsibility.R—ResponsibleA—AccountableC—ConsultedI—InformedR—ResponsibleA—ApproveS—SupportI—InformedC—Consulted
  • Will I be able to get this resource in-house, or will I need to obtain it from an external supplier/vendor?
  • Will the resource be available when needed?
  • How will this impact my cost estimates and budget?
• Estimate the work—After we know what all the work activities are, and we know what level of resource will be doing the work, we can now estimate the effort and duration for each activity. Due to the critical importance and difficulty of this step.
• Develop the schedule—Now that we understand the required resources and estimated effort for each work task, we are in position to identify the relationships between these tasks and build a schedule to complete the work. Due to the critical importance and common errors in this step. “Developing the Project Schedule.”At a minimum, schedule information should be available in at least one summary form (such as a milestone summary, an example of which is depicted in Figure 5.3) and always available in complete detail. TipTo help identify relevant stakeholders, make sure to understand the complete business workflow process(es) and how each person involved is impacted by your project objectives.FIGURE 5.3Example of a milestone schedule summary that tracks any approved schedule variances.
• Update roles and responsibilities—This step has two parts:First, if any new role has been identified, then update the stakeholder-role description table (first mentioned in the Project Definition document) with the name of the required role and the specific responsibilities that role has. After specific individuals are assigned to roles, the project role responsibility chart can be updated to reflect role assignments. An example of a partial project role responsibility chart is presented in Figure 5.4.FIGURE 5.4A partial role responsibility chart for a software development project.Second, for each significant work package listed in the WBS, map the responsibility level that each role has regarding that item. This mapping is routinely captured in a responsibility assignment matrix. An example of a partial project responsibility assignment matrix is presented in Figure 5.5.FIGURE 5.5A partial RASIC responsibility matrix.This summary map is a powerful tool to help stakeholders clearly understand their roles and what is expected of them.
• Update project organization—Also previously mentioned in the Project Definition document, this section lists all the individuals, business units, and organizations involved in the project, the role(s) each is expected to play, and an indication of how they relate to one another. A project organization chart as shown in Figure 5.6 is highly recommended here.FIGURE 5.6A project organization chart for an outsourced software development initiative. NoteThe risk management process can impact the project plan throughout the project because it is a continuous, proactive project management activity.
• Determine project costs and budget—Now that we have our resource needs and a preliminary schedule, we can tabulate estimated project costs and a phased project budget.
• Determine project control system—Specifically, we need to get agreement on how the performance of the project will be measured, how often, and how it will be reported. In addition, we need to determine how performance variances should be managed. Frequently, this information is documented in either the project plan itself, the project communications plan, or the quality management plan.
• Plan for change—All plans are subject to change. The difference with successful projects is that they anticipate the changes and establish procedures in advance to review, assess, and manage any request or any factor that affects the key performance factors (scope, quality, time, and cost). These procedures help to ensure that the right people are involved in the process and that the right people are informed of any change decision.
• “Managing Project Changes.” CautionThe project plan document and its components are living documents and can be updated to reflect the evolving circumstances, issues, and needs surrounding the project.Changes are okay. The changes just need to be announced, reviewed, and approved by the relevant stakeholders.
• Plan for project information—There are two primary objectives of this step, which are to determine the following:
  • Where will the project repository be located? Who can access it? Who controls it?How will changes to project deliverables be managed and controlled?
  This information is frequently maintained in a configuration management plan. “Managing Project Deliverables.” NoteThe formality and detail of each Project Plan section or supplemental plan varies depending on project need, project size, industry, and organizational culture.
• Plan for issues—All projects have issues and actions that must be taken to resolve them. The difference with successful projects is that they establish a process in advance to closely track these issues and establish a procedure in advance to escalate any critical issue to the appropriate management stakeholders.
• Plan for quality—Another proactive management approach is to determine the quality standards and policies that project deliverables and processes must meet. For planning, the significance is that additional roles, work activities, and costs will likely affect the project schedule and the project budget
• Plan for communications—Another aspect of proactive management is to determine the information and communication needs of each project stakeholder. These needs should be determined as part of the stakeholder analysis. The work efforts associated with delivering project communications should be accounted for in both the WBS and the project schedule.
• Plan for team management—Although we have already taken key steps to lay the groundwork for an effective project team by involving them in the planning process, establishing clear role descriptions, and scheduling clear assignments, there are additional steps to consider, including training needs and performance evaluation. “Keys to Better Project Team Performance.”
• Plan for procurements—This step is closely linked to resource planning. If resources need to be obtained externally, then the work to manage the procurement process must be planned and added to the WBS, project schedule, and project budget.