1. Project Plan <Publish Date>
<Project Name>
Project Plan
<Publish Date>
Purpose: The Project Plan is used to review with the team during a kick off meeting or to orientate new team members. Cut and paste information from the templates to fill out the Project Plan. The Project Plan is the major deliverable of the Planning Process, and is the central document of the project management process. The Project Plan is not the MS Schedule document or scheduling tool documents. After the Planning Approval checkpoint review, the information in the Project Plan should be baselined and changes should be managed using the defined change control processes. Examples are used in the Project Plan for clarity.
Benefit: The Project Plan pulls together in one place virtually everything needed to understand the nature of the project, and it provides a uniform presentation of information, supporting consistency in the review process.
Project Plan Defines:
Why the project is being undertaken
What is to be done
How the project will be approached and organized
Who will do the work
When the work will be accomplished
TIP: The level of detail that is applied to the Project Plan will depend on the size of the project.
When: The Project Plan is developed by the project manager during the Planning Process and will be reviewed with the project team and/or used during a Kick Off Meeting in the Planning Process. The program manager records all information developed during the Project Approach activity from the Initiating Process in the Project Plan.

2. Project Plan Components
Project Overview – Description and Strategy
Business Case Summary
Key Deliverables and Scope
Critical Success Factors / Measures of Success
Timelines and Milestones
Project Organization
Resource Requirements
Communications
Key Considerations
Key Risks
Management Approaches
Purpose: An overview of the major areas of the Project Plan. Other pertinent information is attached to the Project Plan:
Project Initiation Document
Business Case
Software Specification Document
Communication Matrix
Roles and Responsibility Matrix
MS Project Schedule
Project Budget
Vendors Statements of Work
Additional Management Plans

3. Project Overview
Project Background – Historical information that relates to this project
<Describe the research that has been completed during the proposal of this project. The business background should provide an understanding of the events leading up to the project. It provides a high level description of the history behind the project.>
Purpose: Used to communicate the project objective, and background.
Cut and paste from the project background information in the Charter section of the PID, and cut and paste from the objectives in part one of the strategic alignment section of the Project Charter.
Delete the words “Strategic Alignment” from the Header, the focus here is part one, the objectives. Strategic Alignment is covered later in this plan.
Guideline: Keep to one page and condense as needed.

4. Project Overview Objectives of the Project Part One
<All projects should support OBR and tie to company strategic goals. The objectives should be SMART>
Purpose: Used to communicate the project objective, and background.
Cut and paste from the project background information in the PID, and cut and paste from the objectives in part one of the strategic alignment section of the Project Charter.
Delete the words “Strategic Alignment” from the Header, the focus here is part one, the objectives. Strategic Alignment is covered later in this plan.
Guideline: Keep to one page and condense as needed.

5. Project Overview Strategic Alignment Part Two Organizational Drivers
Organizational Goals
Group Goals
Program Management Goals
Purpose: All projects should align with the strategic goals of the company.
Cut and paste this information from part two of the strategic alignment area of the Project Charter.
Guideline: List the goals from top down, beginning with OBR’s Drivers. This information will be documented by the project manager in conjunction with the program manager.

6. Business Case Summary Executive Summary
Objective – Opportunity to state your case and gain interest
<State what business need the project is solving>
Purpose: Document the Business Case Summary This is the essential reason for the project. It is the justification or “WHY” the project exists.
Cut and paste from the Business Case Template, from the Executive Summary section.
Guideline: Keep to one page, if you need to, condense summarize the major points

7. Key Deliverables Deliverables – Produced by the team to ensure success
<List the specific deliverables that will be produced by the project team. A deliverable is any outcome that must be produced to complete the project or part of a project. List as many as needed with the most important one first>
Deliverables
<Project Management Guide>
<SD Handbook>
<Web Based Methodology>
<SD Template>
Purpose: List the specific deliverables that will be produced by the project team. A deliverable is any outcome that must be produced to complete the project.
Guideline: Take from the Project Initiation Document and Project Charter, as needed, modify, as appropriate.

8. Critical Success Factors / Measures of Success
Critical Success Factors – Used to determine if the project is successful
<Identify the critical success factors>
<Critical Success Factor>
Purpose: Describe the critical success factors and the measures that highlight what has to happen for the project to be considered successful.
Cut and paste form the Project Initiation Document and Project Charter. Major milestones may be considered measures of success.
Guideline: The project manager with input from the program manager identifies the associated critical success factors and measures. Be sure to incorporate stakeholder and senior management factors of success.

9. Project Timeline
<Use print screen to paste copy of schedule here>
Purpose: A project timeline shows the duration, schedule, and milestone completions of a project. The timeline includes a high level work breakdown with the lifecycle phases which signifies the approach of the project
Milestones are significant events in a project and usually completion of a major deliverable. Milestones should align with a Project Phase. Example: In the Testing Phase a milestone could be when the code is frozen and ready for deployment to the users. Other major milestones are completing each phase. Expand the timeline schedule to show any pertinent milestones.
Guideline: A work plan is developed based on estimated effort hours to complete project activities. Estimates are translated to duration based on scheduling of tasks. Tasks are scheduled according to the selected project life cycle phases.
Task Name
Work breakdown by Project Lifecycle phases. For software development use the following. Concept, Requirements, Design, Development, Documentation and Training, Testing, Deployment, and Post Deployment.
Status:
Red - Requires immediate action. Overall schedule will be impacted if situations are not resolved.
Yellow - Cautionary - Concerns have been raised that could potentially impact the schedule. Mitigating actions are in place.
Green - Project is on schedule to meet milestones and deliverable dates.
Start Date, End Date, and Duration
Dates of the specific project phase and the time to complete
When: The timeline includes the start of the project Initiating to the end of the project Closing. For Software Development Projects, the timeline includes Concept through Post Deployment.

10. Project Organization Chart
<Paste here>
Purpose: An organizational chart is a graphical representation of the people assigned to the project team. The structure indicates the roles and relationship to other members of the team.
Guideline: Indicate all project team members including sponsor, the client, the business and technical team. Illustrate the team organization for various roles and the link to senior management. Only project team members should be listed.
Areas or roles not applicable should not be indicated. Delete and add roles as needed by double clicking on the box.

11. Resource Plan Area Budgeted Hours Business Team <Number>
Consulting
Core Team
Total Hours
Purpose: Document the estimated number of hours per group for the entire project.
Guideline: These hours are the same hours used to calculate the total cost of labor in the Business Case

12. Key Considerations
Assumptions/Constraints – Items believed to be true for the project and project limits
Assumptions
<Assumption>
Constraints
<Constraint>
Related Projects/Affected Systems
<RP/AS>
Purpose: List the assumptions, constraints and related projects/affected systems of the project.
Cut and paste assumptions and constraints form the Project Section of the Project Identification Document from the Project Initiation Document. Cut and paste the Related Projects/Affected Systems from the Project Request Section of the Project Initiation Document.
Guideline: List any assumptions that have been made in this project plan. Document any constraints that are on the project.
Assumptions are items the project team is “assuming” to be true as a basis for their project execution. Assumptions may have to do with resource availability, consistency of support from another area and other factors.
Constraints are typically given to a team. The team has limited ability to change the constraint.
Related Projects/ Affected systems the systems, projects, people and/or organizations along with the associated locations that will be affected or impacted by the proposed need/solution
When: The assumptions, constraints and related projects/affected systems were defined during the Initiating Process in the Project Initiation Document and that list should be further expanded above if necessary.

13. Key Risks
Risk Assessment – Factors that may have a negative impact on the project
<Identify the key risks>
<Key Risk>
Purpose: List the top 5 project risks that were identified during the Initiating Process.
Cut and paste from the Risk Assessment area of the Project Charter.
Guideline: Document the status of the risk: New, Under Review, In Progress, and Completed. List the name of the person responsible for the risk and response plan.

14. Management Approaches
Integration Management
Issue / Change Control / Project Information
Scope Management
Time Management*
Cost Management*
Quality Management
Human Resource Management
Communication Management
Risk Management*
Procurement Management
*required
Purpose: The Management Approaches ensure that all processes are carried out to control project work. The Management Approaches are listed by the industry standard Nine Knowledge Areas:
Integration Management
Scope Management
Time Management - (required for every project regardless of size)
Cost Management - (required for every project regardless of size)
Quality Management
Human Resource Management
Communications Management
Risk Management - (required for every project regardless of size)
Procurement Management
Guideline: List only the Knowledge Areas that are being addressed in the Project Plan. If the other Areas are not addressed, delete as necessary.
When: Each of the Knowledge Areas should be managed throughout the Planning Process and the program manager and project manager should define an approach for each. The approaches should list the role of who will perform the key steps, frequency and the tools used.
Tip: Refer to each of the Knowledge Area Guidelines for specific details.

15. Integration Management Approach Issue Management
Key Steps
Tools
Role
Frequency
Identify Issues
Issue log
Entire team
As they arise
Assess Impact
Project Manager
During identification
Prioritize the issue
During assessment
Resolve the issue
As resolution occurs
Review with team
Project Status Report
Weekly or bi-weekly
Track issues
Throughout the project
Integration Management contains: Issue Management, Change Management, and Project Information Management
Purpose: Issue Management – documenting and managing issues that arise during the course of the project. Delete this slide if not needed.
Guideline: To select or unselect the check box, you must be in the slide show view. Delete the areas that are not applicable. Document the following:
How issues will be managed?
Who will manage? (List the name)
Frequency of management?
Tools used?
TIP: Refer to the Integration Management Guideline for more detail.

16. Integration Management Approach Change Management
Key Steps
Tools
Role
Frequency
Identify Change
Request for Change Form
Entire team
As they arise
Assess Impact
Project Manager
During identification
Recommend Action
During assessment
Authorize Change – based on change control procedures and thresholds
Project Manager/ Project Sponsor
As approval resolution occurs
Review with team
Project Status Report
Weekly or bi-weekly/ As needed
Track issues
Change log
Throughout the project
Purpose: Change Management – systematically identifying, documenting and managing changes to previously approved scope, schedule, or costs. Delete this slide if not needed.
Guideline: To select or unselect the check box, you must be in the slide show view. Delete the areas that are not applicable. Document the following:
How changes will be managed?
Who will manage? (List the name)
Frequency of management?
Tools used?
TIP: Refer to the Integration Management Guideline for more detail.

17. Integration Management Approach Project Information Management
Key Steps
Tools
Role
Frequency
Determine the naming structure for the project files and folders
Project Manager
Start of the Planning Process
Decide space for the project repository and how often information will be uploaded and updated
Company specific standards, procedures, and policies
Start of the Planning Process and updated storage areas weekly or biweekly
Set version control
Assign information owners
Manage information flow
Update the team weekly or as needed
Purpose: Project Information Management – defining the mechanisms that will be used to store, control, and share project information. Delete this slide if not needed.
Guideline: To select or unselect the check box, you must be in the slide show view. Delete the areas that are not applicable. Document the following:
How project information will be managed?
Who will manage? (List the name)
Frequency of management?
Tools used?
Where the project information will be stored?
TIP: Refer to the Integration Management Guideline for more detail.

18. Scope Management Approach
Key Steps
Tools
Role
Frequency
Define and plan scope
Project Initiation Document
Project Manager/ Program Manager
During Initiating Process
Baseline Scope
Project Manager
After the Planning Approval Checkpoint
Update scope as needed – based upon change control procedures and thresholds
Request for Change form/ Change Log
Project Manager/ Project Sponsor
As needed and approved
Baseline and revise
Project Schedule/ Project Budget
Review with team
Project Status Report
Weekly/ biweekly
Purpose: Scope Management is the process for including all the work required, and only the work required, to complete the project successfully. Delete this slide if not needed.
Guideline: Document the following:
How scope will be managed?
Who will manage? (List the name)
Frequency of management?
Tools used?
Baseline will be managed?
TIP: Refer to the Scope Management Guideline for more detail.

19. Time Management Approach
Key Steps
Tools
Role
Frequency
Create schedule
Microsoft Project
Project Manager
During Initiating Process
Baseline schedule
Triple constraint rule – Time, Cost, Schedule
After the Planning Approval Checkpoint
Track hours of work
Time Tracking Tool
Team Members
Weekly
Track progress
Change schedule – based upon change control procedures
Request for Change/ Change Log
As needed and approved
Re-baseline as approved
Project Budget/ Project Schedule
Purpose: To ensure timely completion of the project. This slide is required.
Guideline: Document the following:
How communication will be managed?
Who will manage? (List the name)
Frequency of management?
Tools used?
Baseline Management?
TIP: Refer to the Time Management Guideline for more detail.

20. Cost Management Approach
Key Steps
Tools
Role
Frequency
Create budget
Budget template
Project Manager/ Program Manager
During Initiating Process
Baseline budget
Project Manager
After the Planning Approval Checkpoint
Track time
Time Tracking Tool
Weekly
Monitor budget (Actual vs. Budget)
Budget Template
Change budget
Request for Change/ Change Log
As needed and approved
Review budget
Executive Status Report/ Project Status Report
Purpose: The processes for monitoring that the project is completed within the approved budget. This slide is required.
Guideline: Document the following:
How costs will be managed?
Who will manage? (List the name)
Frequency of management?
Tools used?
Baseline Management?
TIP: Refer to the Cost Management Guideline for more detail.

21. Quality Management Approach
Key Steps
Tools
Role
Frequency
Set quality standards
Quality Assurance Template/ CM Guideline
Project Manager
During Planning Process
Track defects
Defect Tracking Log
Delegated Team Member
Weekly or monthly
Review quality standards with team
SRS/ Project Status Reports
Biweekly
Purpose: The processes required to ensure that the project will satisfy the quality needs for which the project was undertaken. Delete this slide if not needed.
Guideline: Document the following:
How quality will be managed?
Who will manage? (List the name)
Frequency of management?
Tools used?
TIP: Refer to the Quality Management Guideline for more detail.

22. Human Resource Management Approach
Key Steps
Tools
Role
Frequency
On Board Team
Kick Off Meeting/ Project Plan
Project Manager
When assembled
Define team roles
Roles and Responsibility Matrix
As staff is identified
Allocate/ direct and review project work
Project Schedule
Weekly or Biweekly
Review team members and provide feedback
Project Status Reports
Biweekly, monthly or at the end of phases
Purpose: The processes required to ensure to make the most effective use of the people involved with the project. Delete this slide if not needed.
Guideline: Document the following:
How human resources will be managed?
Who will manage? (List the name)
Frequency of management?
Tools used?
TIP: Refer to the Human Resource Management Guideline for more detail.

23. Communication Management Approach
Key Steps
Tools
Role
Frequency
Organize team roles
Organization Chart/ Roles and Responsibility Matrix
Project Manager
During Planning process and as new members are added
Create communication plan
Communication Matrix
During Planning process
Report project progress
Team Member Status Report
Team Members
Weekly or Biweekly
Review progress with the team
Meeting Agenda/ Meeting Notes/ Project Status Report
Review progress with senior management
Executive Status Report
Monthly
Purpose: Communications Management process defines how information is managed communicated, and distributed. Delete this slide if not needed.
Guideline: Document the following:
How communication will be managed?
Who will manage? (List the name)
Frequency of management?
Tools used?
TIP: Refer to the Communication Management Guideline for more detail.

24. Risk Management Approach
Key Steps
Tools
Role
Frequency
Identify Risks
Risk Log
All team members
Entire project
Analyze the impact and plan response
Project Manager
As identified
Risks with level of High need detailed analysis
Detailed Risk Response
As analyzed
Review risk with team
Project Status Report
Weekly or Biweekly
Review risks with senior management
Executive Status Report
Monthly
Purpose: To address events that may adversely impact the project. The foundation of risk management is analysis and contingency planning – to understand the probabilities and to prepare a range of responses, in advance whenever possible. This slide is required.
Guideline: Document the following:
How risks will be managed?
Who will manage? (List the name)
Frequency of management?
Tools used?
TIP: Refer to the Risk Guideline for more detail.

25. Procurement Management Approach
Key Steps
Tools
Role
Frequency
Review work to be delivered
Vendor Statement of Work
Project Manager and Vendor
Prior to vendor start date
Manage vendor communications
Project Status Reports
Project Manager
Weekly or biweekly
Purpose: The processes for acquiring goods and services from outside the organization. Delete this slide if not needed.
Guideline: Document the following:
How vendor relationships will be managed?
Who will manage? (List the name)
Frequency of management?
Tools used?

26. Attachments to Project Plan
Project Initiation Document
Business Case
Communication Matrix
Roles and Responsibility Matrix
Schedule
Vendor’s Statement of Work
Additional Management Plans
Supporting Lifecycle Documents
Requirements or Software Requirements Specifications
Deployment Plan
Attach supporting documentation of the Project Plan.