Building a Project Plan

The first step in building a project plan is to validate the elements of the project definition document. Depending upon the length of time between acceptance of the project definition and the start of detail planning, you may 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

As you visit with stakeholders during detail planning, make sure to validate their project definition understanding and expectation.

Re-confirm that the business case for the project is still valid after the detailed project planning exercise is complete.

• 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 re-validate 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 of the work that is required to complete the project. This process is explained in greater detail in Chapter 6, "Developing a Work Breakdown Structure."

  This section normally refers to a list of deliverables and to the WBS.

  tip

  

  To simplify the review process and to 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.

• Determine acceptance criteria This information can be part of other components, such as deliverables list, WBS, project approach, or quality management plan, and may 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 is for each deliverable and for each project phase.
• Determine resource needs Based upon 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 experience.

  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.2. Basic example of a resource management plan.

  

• Acquire resources After the resource needs are documented, you 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?
  • 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 of 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, we review this in greater detail in Chapter 7, "Estimating the Work."
• Develop the schedule Now that we understand the required resources and estimated effort for each work task, we are now 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, we review this in greater detail in Chapter 8, "Developing the Project Schedule."

  At a minimum, schedule information should be available in at least one summary form (such as a milestone summary listed in Figure 5.3) and always available in complete detail.

  Figure 5.3. Example 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. Once 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.4. A 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.5. A partial RASIC responsibility matrix.

   

  This summary map is a powerful tool to help stakeholders clearly understand their roles and what is expected of them.

  tip

  

  The 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.

  RResponsible

  AAccountable

  CConsulted

  IInformed

  RResponsible

  AApprove

  SSupport

  IInformed

  CConsulted

• Update project organization Also previously mentioned in the project definition document, this section lists all of 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.6. A project organization chart for an outsourced software development initiative.

  
• 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. We will discuss this in greater detail in Chapter 9, "Determining the Project Budget."

  tip

  

  To 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.

• 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, and/or in the quality management plan. We will discuss this in greater detail in Chapter 10, "Controlling a Project."
• 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 impacts 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. We will discuss this in greater detail in Chapter 11, "Managing Project Changes."
• Plan for project information There are two primary objectives of this step:
  • 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. We will discuss this in greater detail in Chapter 12, "Managing Project Deliverables."

• Plan for issues All projects have issues and action that must be taken to resolve them. The difference on 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. We will discuss this in greater detail in Chapter 13, "Managing Project Issues."

  

  The risk management process can impact the project plan throughout the project because it is a continuous, proactive project management activity.

• Plan for quality Another proactive management approach 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 impact the project schedule and the project budget. We will discuss this in greater detail in Chapter 15, "Managing Project Quality."

  caution

  

  The 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 communications A proactive management approach 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. We will discuss this in greater detail in Chapter 17, "Managing Project Communications," and in Chapter 18, "Managing Expectations."
• Plan for team management While we have already taken key steps to laying 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 too, including training needs and performance evaluation. We will discuss this in greater detail in Chapter 19, "Keys to Better Project Team Performance."
• Plan for procurements This step is closely linked to resource planning. If resources will 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. We will discuss this in greater detail in Chapter 21, "Managing Vendors."

The formality and detail of each Project Plan section or supplemental plan will vary depending on project need, project size, industry, and organizational culture.