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.
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.
This section normally refers to a list of deliverables and to the WBS.
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.
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.
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
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.
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.
Figure 5.6. A project organization chart for an outsourced software development initiative.
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.
This information is frequently maintained in a configuration management plan. We will discuss this in greater detail in Chapter 12, "Managing Project Deliverables."
The risk management process can impact the project plan throughout the project because it is a continuous, proactive project management activity.
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.
The formality and detail of each Project Plan section or supplemental plan will vary depending on project need, project size, industry, and organizational culture.
Part i. Project Management Jumpstart
Project Management Overview
The Project Manager
Essential Elements for any Successful Project
Part ii. Project Planning
Defining a Project
Planning a Project
Developing the Work Breakdown Structure
Estimating the Work
Developing the Project Schedule
Determining the Project Budget
Part iii. Project Control
Controlling a Project
Managing Project Changes
Managing Project Deliverables
Managing Project Issues
Managing Project Risks
Managing Project Quality
Part iv. Project Execution
Leading a Project
Managing Project Communications
Keys to Better Project Team Performance
Ending a Project