Project Management Templates

South Western Sydney Centre for Education and Workforce Development (SWSCEWD)
© Ministry of Health

This work is copyright. It may be reproduced in whole or in part for study training purposes subject to the
inclusion of an acknowledgement of the source. It may not be reproduced for commercial usage or sale.
Reproduction for purposes other than those indicated above, requires written permission from the NSW
Ministry of Health.

Published February 2017

These templates have been developed by South Western Sydney Centre for Education and Workforce
Development (SWSCEWD) for the purposes of the Diploma of Project Management. These resources are
made available for SWSLHD staff for use as appropriate.

SWS Centre for Education and Workforce Development Page 1 of 45

Table of Contents

Introduction...................................................................................................................3

Guidelines on how to use these templates...................................................................3

Project Charter..............................................................................................................4

Project Management Plan.............................................................................................8

Risk Management Plan................................................................................................11

Communication Plan...................................................................................................14

Stakeholder Management Plan...................................................................................20

Human Resource Plan.................................................................................................23

Scope Management Plan.............................................................................................25

Time/Schedule Management Plan..............................................................................31

Work Breakdown Structure (WBS)..............................................................................33

Cost Management Plan...............................................................................................37

Quality Management Plan...........................................................................................39

Project Finalisation Report..........................................................................................41

Additional Documentation as required.......................................................................42

Change Request Form.................................................................................................42

Change Request Register.............................................................................................43

Project Status Report..................................................................................................44

SWS Centre for Education and Workforce Development Page 2 of 45

Project Charter
Introduction
A Project Charter formally recognises the existence of a project and states the scope of the project, gives
the Project Manager authority over the project, provides summary milestones, states the project budget
and identifies funding sources.

Content of a Project Charter may vary to meet individual project needs. Standard information included in a
Project Charter include information in the headings provided in this template.

1. Project Title
2. Approvals and sign-off
3. Broad Stakeholder Identification
4. Consolidated Project Initiation Documentation
5. Documented Objectives
6. High-Level Project Deliverables
7. High-Level Risk Assessment
8. Project Assumptions and Constraints
9. Project Mandate
10. Source of Project Authority

A template is provided on the next page for the participants to complete.

SWS Centre for Education and Workforce Development Page 3 of 45

 PROJECT NAME

Approvals and Sign-Off

Authorising Date of
Sponsor Name & Authorisation
Designation
Authorising
Sponsor Signature
Broad Stakeholder Identification
Name of Stakeholder Stakeholder Role

Consolidated Project Initiation Documentation

Name of Documentation Approved by Authorising Sponsor

Project Objectives
Objectives Approved by Authorising Sponsor

High Level Project Deliverables

Deliverables Approved by Authorising Sponsor

High Level Risk Assessment

Forecasted Risk Recognised by Authorising Sponsor

Project
Assumptions
Project Constraints
Project Strategic
Alignment

SWS Centre for Education and Workforce Development Page 4 of 45

 Project Proposal
(Please expand as required)

Project Title

Background
a. Provide the rationale for your project. What has prompted the need for your project?

b. Include links to your LHD Strategic Plan or your Department/work area Operational Plan

c. Describe the current situation

d. Benefits – describe the benefits of successful completion of the project to the work
area/organisation

Project Outcomes (List the project objectives/outcomes)

Barriers to the project (List the barriers that could prevent you from completing your project successfully)

Project Scope (In the table below, define the Scope of your project. Give thought to activities that may be
related but will not be part of the project.)

Activities In Project Scope Activities outside Project Scope

Budget
 Does your project have an allocated budget or is the cost of the project included in ongoing
operations for your department/service?

 If your project has an allocated budget, please provide details.

Project Governance (include information about the project governance structure in relation to approvals and
issues resolution)

Key stakeholders

In the table below, list all the Project Stakeholders that will influence or be influenced by your Project

Key Project Roles Name Role in the Organisation

Executive/Authorising Sponsor
Project Manager
Project Team Member/s
Subject Matter Experts (SMEs)
Other Stakeholders

Project Timelines (include information about the project start and finish timelines and forecasted dates for

SWS Centre for Education and Workforce Development Page 5 of 45

major deliverables within the project)

Your Role in this Project (include information about your role in implementing this project)

SWS Centre for Education and Workforce Development Page 6 of 45

Project Management Plan
Purpose

The Project Management Plan provides a detailed description of what the project is about, its delivery method and controls
to realise its defined scope and objectives. The project management plan provides context and guidelines for the conduct of
the project and its interaction with stakeholders, the project team, sponsors and other entities. The document will also make
reference to the corporate or departmental plans that govern the initiation of the project.

It is the formally approved, authoritative reference that defines how the project is to be executed, monitored and
controlled. Accordingly, it will be maintained throughout the life of the project as a living document. As new or revised
elements of the management of the project are approved, the changes will be reflected in this plan. The project
management plan is subject to formal change control, this means the change request form and change register (log) will be
used for all changes to the project management plan once it has been signed.

Project Management Plan

Project Name:
Project Sponsor:
Project Manager:
Position:

Version Control

Version Version Author Modifier Revision Reason / Description

Date
V1 Initial Draft

Document Approval

The signatures below indicate approval for the Project Management Plan. All parties have reviewed the
document and agree with its contents.

Project Manager Date

Project Sponsor Date

SWS Centre for Education and Workforce Development Page 7 of 45

Project Aim
The goal of the project is to improve the.....

Project Objectives (Key Performance Indicators KPIs)

Record the measurable SMART objectives (see below) that have been identified for this project, indicate the specific
section of the organisational plan that is driving this project and identify the target for success for each objective.

Key Performance Indicator Target

Reduce …
Improve ...
Increase …
Maintain ...

Objectives need to be SMART

 Specific – clearly identify the what is to be achieved
 Measurable – define how we will measure & monitor any progress or change
 Attainable – is achievable within the timeframe and with resources available; realistic
 Relevant – in keeping with the goal & scope
 Timely – establishes a timeframe when object will be achieved

Project Background
Why is the project proposed? How has it come about? Why is the project needed? Briefly describe the
current situation. Briefly describe the consequences of not changing/ undertaking the project?

Project Approach
Broadly describe the phases and timings of the project – what methodologies will be used.

Project definition
Define the project that applies to this project management plan.

Project scope
The scope defines the boundaries of the project. Identifying the deliverables (what the project will deliver).
It is important to list the inclusions (what is included) as well as the exclusions (what is not included) for this
project.

Roles and Responsibilities

This section details the roles and responsibilities of the whole project team. It will define who the project
leader is as well as the executive sponsor, project team and stakeholders.

SWS Centre for Education and Workforce Development Page 8 of 45

Governance structure
This section details the relationship between the project team and the governing groups or entities that
may affect the project.

Implementation plan
The implementation plan should describe the approach for implementing the change to become normal
practice. This should include the resources required, the tasks need to be done and by whom, any
additional communications that will take place, and any other information required.

Appendices
List any supporting documents required

SWS Centre for Education and Workforce Development Page 9 of 45

Risk Management Plan
The Risk Management Plan describes how risk management will be structured and performed on the
project. It is a subset of the project management plan. The risk management plan does not detail the
planned responses to individual risks within the project. This is recorded in the Risk Response Plan or the
Risk Register itself.

The Risk Management Plan is responsible for determining:

1. How risks will be identified
2. How quantitative analysis will be completed
3. How qualitative analysis will be completed
4. How risk response planning will happen
5. How risks will be monitored
6. How ongoing risk management activities will happen throughout the project life cycle.

The risk management plan includes a methodology, a list of roles and responsibilities, budgeting
requirements, scheduling needs, risk analysis scoring, risk categories, definitions of risk probability and
impact, a probability impact matrix, thresholds, revised stakeholders’ tolerances, reporting formats,
tracking and using a risk management plan template.

The methodology is concerned with how the risk management processes will take place. The methodology
asks the following:

1. What tools are available to use for risk management?

2. What approaches are acceptable within the organisation?
3. What data sources can be accessed and used for risk management?
4. What approach is best for the project type and phase of the project and which is most appropriate
given the conditions of the project?
5. How much flexibility is available for the project, given the conditions, time frame and project
budget?

The job of the project manager and team members is to ensure success by managing risk. There are two
simple tools that can—and should—be used on every project to manage risks and issues to prevent
disaster. One is the risk register; the other is the issue log. These two documents are often conflated, but
they are distinct documents that should contain different information and drive different actions.

Risk Register

The Risk Register is a document that contains the results of the qualitative risk analysis, quantitative risk
analysis and risk response planning. The risk register details all identified risks, including description,
category, cause, probability of occurring, impact on objectives, proposed responses, owners and current
status. The risk register is a component of the project management plan.

The risk register is a means of capturing risks that we want to monitor over the life of the project so that we
can take action before they have a negative impact on the project. These are conditions that you have
decided not to explicitly work into the plan, but don’t want to let “slip under the radar” to create big issues
for you later.

The Risk Register is to be updated on an ongoing basis to ensure any risks that are identified throughout
the lifespan of the project are recorded, mitigated or have strategies in place to manage the risk if not
eliminated.

SWS Centre for Education and Workforce Development Page 10 of 45

An example of the Risk Register matrix is shown below:

Risk Identification Qualitative Rating Risk Response

Risk Risk Category Probability Impact Risk Score Risk Ranking Risk Response Trigger Risk Owner
                 
                 

Issues Log/Register

When something goes wrong—deviates from the plan—it stops being a risk and becomes an issue that
must be addressed to ensure success. Issues are those conditions that are having a negative impact on your
ability to execute the project plan. You can easily identify them because they directly cause schedule
slippage and extra work.

The issue log is fundamentally about corrective actions. The project has deviated from the plan, and now
we need to get back on course to complete the project on time, on budget and with the agreed goals. The
issue log is used to capture this information. While the cause of the problem is often obvious, it is always a
good idea to probe for deeper, systemic causes that could lead to further delays. Asking “why?” five times
in order to permanently and irrevocably fix a problem doesn’t take very long compared to the total delays
that a project can experience.

The issue log is where you record any problems that were not accounted for in the plan and that threaten
to delay the project, push it off budget or reduce the scope (e.g. reduce product performance).

An example of the Issues Register matrix is shown below:

Issue Log
Project: Date:
Issue Description Priority Category Reported Assigned Status Date Resolution/
(H,M,L) By To Resolved Comments
This should Detailed High, Assign to Who Who is What is What date What was the
be a description Medium a reported the issue the was the resolution or
standard of the issue. or Low category. the assigned status issue what is being
numbering priority. issue? to? of the resolved? done to
system. issue? resolve the
issue?

In addition to the detail included in both documents, shown below are some of the key distinctions
between the two documents.

Issue Log Risk Register

Description of the issue Description of the risk
Underlying problem or cause of the issue Risk profile—sources of uncertainty and the
potential impact
Action plan Potential actions
Priority or scheduling Monitoring plan
Who is responsible for assuring this issue is resolved Who is responsible for monitoring
Date opened and date resolved, sometimes a tracking number Date last updated, tracking ID
or other ID

SWS Centre for Education and Workforce Development Page 11 of 45

The Risk Management Plan must include information in the following key areas:

1. Risk Identification Approach

2. Risk Context

3. Roles and Responsibilities in relation to Risk Identification, Monitoring, Response Planning & Escalation

4. Quantitative Risk Analysis Approach, Tools & Resources

5. Qualitative Risk Analysis Approach, Tools & Resources

6. Response Strategies Standard

7. Risk Response Planning (Input, Tools & Techniques, Output {Risk Register})

8. Ongoing Risk Monitoring Approach

9. Issues Register

SWS Centre for Education and Workforce Development Page 12 of 45

Communication Plan
Introduction
The purpose of the Communications Management Plan is to define the communication requirements for
the project and how information will be distributed. The Communications Management Plan defines the
following:

1. What information will be communicated—to include the level of detail and format
2. How the information will be communicated—in meetings, email, telephone, web portal, etc.
3. When information will be distributed—the frequency of project communications both formal and
informal
4. Who is responsible for communicating project information
5. Communication requirements for all project stakeholders
6. What resources the project allocates for communication
7. How any sensitive or confidential information is communicated and who must authorize this
8. How changes in communication or the communication process are managed
9. The flow of project communications
10. Any constraints, internal or external, which affect project communications
11. Any standard templates, formats, or documents the project must use for communicating
12. An escalation process for resolving any communication-based conflicts or issues

Communication Management Approach

Give considerable thought to how you want to manage communications on this project. By having an
effective communications management approach you’ll find that many project management
problems can be avoided. In this section give an overview of your communications management
approach.

Communications Management Constraints

All projects are subject to limitations and constraints as they must be within scope and adhere to
budget, scheduling, and resource requirements. Project planning and documentation are no
exception to this rule. There may also be legislative, regulatory, technology, or organisational policy
requirements which must be followed as part of communications management.

These constraints must be clearly understood and communicated to all stakeholders. While
communications management is arguably one of the most important aspects of project management,
it must be done in an effective manner and within the constraints of the allocated budget, time, and
resources.

SWS Centre for Education and Workforce Development Page 13 of 45

Stakeholder Communication Requirements
Most projects consist of a broad range of stakeholders all of whom may have differing interests and
influence on the project. As such, it is important for project teams to determine the communication
requirements of these stakeholders in order to more effectively communicate project information.

There are a number of methods for determining stakeholder communication requirements; however,
it is imperative that they are completely understood in order to effectively manage their interest,
expectations, and influence and ensure a successful project.

Roles

There may be several members involved in your project. It is important to clearly state the roles of each
member involved in your project to define role permissions and limitations.

Some of the key roles to define would be as follows. There may be more or less roles with your project
however, the Project Sponsor, Authorising Sponsor, Key Stakeholders are the core requirements.
 Project Sponsor
 Project Manager
 Key Stakeholders
 Authorising/Executive Sponsor/s
 Project Team
 Technical lead

Project Team Directory

The following table presents contact information for all persons identified in this communications
management plan. The email addresses and phone numbers in this table should be used to communicate
with the identified members.

Role Name Title Organisation/ Department Email Phone

Project Sponsor
Authorising/Executive
Sponsor
Project Manager
Stakeholders
Project Team
Technical Lead

SWS Centre for Education and Workforce Development Page 14 of 45

Communication Methods and Technologies
Many times, the methods and technologies used to communicate are just as important of a
consideration as the information being communicated. Imagine a large project with many stakeholders
who all have different technological capabilities. Some may have access to a share drive while others do
not. Some may have access to video teleconferencing and others only have telephone and email
capabilities.

In order to be effective, project information must be communicated to everyone involved by some

method using available technology. Determining communication methods and what technologies are
available should be part of determining stakeholder communication requirements.

Communications Matrix
The following table identifies the communications requirements for this project.

Communicatio Objective of Medium Frequenc Audience Owner Deliverable Format

n Type Communication y

Communication Flowchart
Flowcharts provide a visual representation of a process or processes which often allow a better
understanding of how the process is intended to work. Project communications may be extremely
complex depending on the size and scope of the project and the number of stakeholders.

A flowchart provides all stakeholders with a better understanding of the steps involved with the
distribution of all project communications. This may/may not be necessary depending on the
complexity of your project.

SWS Centre for Education and Workforce Development Page 15 of 45

Guidelines for Meetings

Meeting Agenda
Meeting Agenda will be distributed 5 business days in advance of the meeting. The Agenda should
identify the presenter for each topic along with a time limit for that topic. The first item in the agenda
should be a review of action items from the previous meeting.

Meeting Minutes
Meeting minutes will be distributed within 2 business days following the meeting. Meeting minutes
will include the status of all items from the agenda along with new action items and the Parking Lot
list.

Action Items
Action Items are recorded in both the meeting agenda and minutes. Action items will include both the
action item along with the owner of the action item. Meetings will start with a review of the status of
all action items from previous meetings and end with a review of all new action items resulting from
the meeting. The review of the new action items will include identifying the owner for each action
item.

Meeting Chair Person

The Chair Person is responsible for distributing the meeting agenda, facilitating the meeting and
distributing the meeting minutes. The Chair Person will ensure that the meeting starts and ends on
time and that all presenters adhere to their allocated time frames.

Note Taker
The Note Taker is responsible for documenting the status of all meeting items, maintaining a Parking
Lot item list and taking notes of anything else of importance during the meeting. The Note Taker will
give a copy of their notes to the Chair Person at the end of the meeting as the Chair Person will use
the notes to create the Meeting Minutes.

Time Keeper

Communication Standards

Standardisation is a proven way to simplify the complexities of project management communications.

You can develop and use standard templates or formats for the various communication tools used
throughout projects. Standard templates and formats may be applied to certain types of project
meetings or specific types of communication (i.e. emails, status reports, etc.). By using
standardisation, you can ensure that your project teams and stakeholders have a thorough
understanding of what is expected and achieve consistent and effective communications.

In addition to standard templates and/or formats, you may standardise file naming or sharing
convention or use Share Point or some other type of Web Portal/Network tool (blogs, message
boards, etc.) as a standard platform from which to share information and communicate. Additionally,
you may have standard file naming conventions for stored data on internal share drives. These
standardisation methods are most effective where team members and stakeholders often spread
over wide geographic areas. Standardisation provides a level of simplicity to an organisation’s
communication platform and improves effectiveness and efficiency.

SWS Centre for Education and Workforce Development Page 16 of 45

Communication Escalation Process

As issues or complications arise with regards to project communications it may become necessary to
escalate the issue if a resolution cannot be achieved within the project team. Project stakeholders may
have many different conflicting interests in a given project. While escalations are a normal part of
project management, there must be a documented process that defines how those escalations will take
place.

Here is an example of the Communication Escalation Process matrix that can be followed for your project
communication escalation process.

Priority Definition Decision Timeframe for Resolution

Authority
Priority Major impact to project or business Vice Within 4 hours
1 operations. If not resolved quickly there will President or
be a significant adverse impact to revenue higher
and/or schedule.
Priority Medium impact to project or business Project Within one business day
2 operations which may result in some Sponsor
adverse impact to revenue and/or schedule.
Priority Slight impact which may cause some minor Project Within two business days
3 scheduling difficulties with the project but Manager
no impact to business operations or
revenue.
Priority Insignificant impact to project but there may Project Work continues and any
4 be a better solution. Manager recommendations are submitted via
the project change control process

SWS Centre for Education and Workforce Development Page 17 of 45

Glossary of Communication Terminology

It is important to have a glossary of all the terminology used within the project to ensure all members
involved in the project interpret the terms appropriately.

An example is shown here:

Term Definition
Communication The effective sending and receiving of information. Ideally, the information received
should match the information sent. It is the responsibility of the sender to ensure this
takes place.
Stakeholder Individuals or groups involved in the project or whose interests may be affected by
the project’s execution or outcome.
Communications Portion of the overall Project Management Plan which details how project
Management Plan communications will be conducted, who will participate in communications,
frequency of communications, and methods of communications.
Escalation The process which details how conflicts and issues will be passed up the management
chain for resolution as well as the

SWS Centre for Education and Workforce Development Page 18 of 45

Stakeholder Management Plan
Introduction
Stakeholders are individuals or groups whose role is intrinsic to shaping the success or failure of the project.
They have a key interest (stake) in the project’s outcome because it is going to impact on their wellbeing,
authority, status, and/or day-to-day operations. Most projects have more than one stakeholder or
stakeholder group with direct or indirect involvement and it is up to the project manager to discover what
level of involvement they will need to have.

The Stakeholder Management Plan will include a range of action areas as follows:
1. Stakeholder Identification
2. Segmenting Stakeholders
3. Stakeholder Management
4. Interests and Influences
5. Stakeholder Analysis
6. Stakeholder Management Actions
7. Stakeholder Performance Reviews
8. Stakeholder Communication needs

Please provide your response to each of the activities based on your simulated project activity and your
workplace project. Additional information on Stakeholder Analysis and Interests and Influences is provided
on following pages.

SWS Centre for Education and Workforce Development Page 19 of 45

Stakeholder Analysis Report
Stakeholder analysis is a process of gathering information to determine whose interests should be
taken into account when planning and scoping a project. Characteristics that are been examined
include things such as knowledge of the project, their ability to influence the project, their ability to
influence other people and their stand on the project (whether they are in agreement or not).

By knowing more about your stakeholders you can build support or consensus, develop strategies for
those that may have a negative influence and implement appropriate plans to increase
communication, advocacy and negotiation.

Stakeholders may be primary, secondary or key stakeholders.

 Primary stakeholders are the people or groups that stand to be directly affected, either positively
or negatively, by the project.
 Secondary stakeholders are people or groups that are indirectly affected, either positively or
negatively, by the project. 
 Key stakeholders may be primary or secondary stakeholders and may positively or negatively by
impact on the project.

One way to develop a stakeholder analysis report is to develop a Stakeholder Matrix. This plots each
stakeholder against two variables. These variables could be importance/influence, interest in
outcomes/interest in content, commitment to project/resources available to them.

Importance of stakeholder
Unknown Little/No Some Significant
importance importance importance
Influence of stakeholder

C
Significant influence

Somewhat influential
A
D
Little/No influence

Unknown
B
Boxes A, B and C are the key stakeholders of the project. The implications of each box is summarised below:

Box A – ‘Allies’
These are stakeholders appearing to have a high degree of influence on the project, who are also of high
importance for its success. This implies that the implementing person will need to construct good working
relationships with these stakeholders, to ensure an effective coalition of support for the project.

These people should be monitored closely as they will be the promoters or your allies for the project.

Box B – ‘Friends’
These are stakeholders of high importance to the success of the project, but with low influence. This
implies that they will require special initiatives if their interests are to be protected. An example may be

SWS Centre for Education and Workforce Development Page 20 of 45

traditionally marginalised groups (e.g. Indigenous people, youth, seniors) who might be beneficiaries of a
new service, or see benefit to the project, but who have little ‘voice’ in its development.

It is important to keep this group of people informed as they could become the project defenders.

Box C – ‘Potential Blockers’

These are stakeholders with high influence, who can therefore affect the project outcomes, but whose
interests are not necessarily aligned with the overall goals of the project. They might be financial
administrators, who can exercise considerable discretion over funding disbursements. This conclusion
implies that these stakeholders may be a source of significant risk, and they will need careful monitoring
and management to keep them satisfied with the project and maintain their positive influence.

Box D – ‘Potential Irritants’

The stakeholders in this box, with low influence on, or importance to the project objectives, may require
limited monitoring or evaluation, but are of low priority. They still require monitoring as people can change
their minds and may begin to be influenced by interested people.

Another way to analyse the stakeholders is by filling in the following table. The first two lines have been
completed based on a project to enhance school attendance.

Stakeholder Primary/ Current level What do you What’s How could What is
(name and Secondary/Key of support want from important to stakeholder your
role) Stakeholders (Low-Med- stakeholders? stakeholders? s block your strategy for
High) efforts? enhancing
stakeholder
support?
School age Secondary Medium To attend Been engaged at By truanting Consult with
children school school or refusing them
Develop
strategies
with school
Parents Primary Low To enforce their Keeping child By not Support and
child to attend happy – keeping enforcing and discussion
the peace at reinforcing
home the strategies
given

These templates could be used together or individually depending on the project, the team and the project
manager. Once the stakeholders have all been placed on the table then a report can be written based on
the information in the table.

SWS Centre for Education and Workforce Development Page 21 of 45

Human Resource Plan
Introduction
The purpose of the Human Resources (HR) Plan is to ensure adequate human resources to meet the goals
and operational plans of your organisation – the right people with the right skills at the right time. The
introduction to the HR plan will provide a general description of what the plan includes and explain how the
project manager and project team can use the plan to help them manage the people involved in the project
effectively.

Roles and Responsibilities

Roles and responsibilities of team members and stakeholders must be clearly defined in any project. Depending
on the organisational structure, project team members may represent many different groups/departments and
act in the interest of different functional managers. Additionally, team members may have varying degrees of
authority and responsibility. When listing roles and responsibilities the following should be included:
 Role – description of the portion of the project for which the member is accountable
 Authority – the level at which the member may make decisions, apply project resources, or make approvals
 Responsibility – the work a team member must perform to complete assigned work activities
 Competency – the skill(s) required to complete assigned project activities, including support that may be
required.

Project team Role Authority Responsibility Competency

member name

Project Organisational charts

The Human Resource Plan also provides a graphic display of the project tasks and team members.
The purpose of this is to illustrate the responsibilities of team members as they relate to the project
tasks. Tools such as the responsible, accountable, consult, inform (RACI) (or responsibility assignment
matrix) may be used. These allow all of the stakeholders to understand the responsibilities and
accountabilities of each person within the team. While smaller teams can have more informal rules to
keep track of responsibilities, in bigger teams with cross-department and inter-organizational
collaboration, it is very important to create a more formal process to track responsibilities. This helps
reduce confusion and leads project to faster completion.

SWS Centre for Education and Workforce Development Page 22 of 45

 Team Member
Activity Name Name Name
Define & Plan


Execution


Completion



Key
R = Responsible C = Consulted A = Accountable I = Informed

SWS Centre for Education and Workforce Development Page 23 of 45

Scope Management Plan
Scope Management Approach

It is important that the approach to managing a project’s scope is clearly defined and documented in
detail. This section of the Scope Management Plan provides a summary of the Scope Management Plan
in which it addresses the following:
1. Who has authority and responsibility for scope management
2. How the scope is defined (i.e. Scope Statement, WBS, WBS Dictionary, Statement of Work, etc.)
3. How are scope creeps actions identified, measured and documented for inclusion/exclusion
4. How the scope is measured and verified (i.e. Quality Checklists, Scope Baseline, Work
Performance Measurements, etc.)
5. The scope change process (who initiates, who authorises, etc.)
6. Who is responsible for accepting the final project deliverable and approves acceptance of
project scope

Use the Scope Management Plan Template to complete your simulated/workplace project scope
activities.

Roles and Responsibilities

In order to successfully manage a projects’ scope it’s important that all roles and responsibilities for
scope management are clearly defined in the Scope Management Plan. This section defines the role of
the Project Manager, Project Team, Stakeholders and other key persons who are involved in managing
the scope of the project. It should state who is responsible for scope management and who is
responsible for accepting the deliverables of the project as defined by the projects’ scope. Any other
roles in scope management should also be stated in this section.

The Project Manager, Sponsor and team will all play key roles in managing the scope of this project. As
such, the project sponsor, manager, and team members must be aware of their responsibilities in order
to ensure that work performed on the project is within the established scope throughout the entire
duration of the project. The table below defines the roles and responsibilities for the scope
management of this project.

Name Role Responsibilities

John Doe Sponsor  Approve or deny scope change requests as appropriate
 Evaluate need for scope change request
 Accept project deliverables
Jane Doe Project  Measure and verify project scope
Manager  Facilitate scope change requests
 Facilitate impact assessments of scope change requests
 Organize and facilitate scheduled change control meetings
 Communicate outcomes of scope change requests
 Update project documents upon approval of all scope changes
Bob Jones Team Lead  Measure and verify project scope
 Validate scope change requests

SWS Centre for Education and Workforce Development Page 24 of 45

Name Role Responsibilities
 Participate in impact assessments of scope change requests
 Communicate outcomes of scope change requests to team
 Facilitate team level change review process
John Team  Participate in defining change resolutions
Smith Member  Evaluate the need for scope changes and communicate them to the project
manager as necessary
Tom Team  Participate in defining change resolutions
Brown Member  Evaluate the need for scope changes and communicate them to the project
manager as necessary

Scope Definition

The scope definition section details the process of developing a detailed description of the project and
its deliverables. This can only be completed after the requirements have been identified and defined
during the requirements definition process.

This section of the Scope Management Plan should explain the process you followed to develop the
detailed description of the project and its deliverables. If you used other documents such as the Project
Charter, Preliminary Project Scope Statement or Requirements Documentation you should identify
them and all other documents used. You should tie the scope definition process back to the
requirements definition as the projects’ scope answers the requirements for the project.

You should also document the tools and techniques used to define the project scope such as expert
judgment, industry analysis, alternatives identification or facilitated workshops.

Scope Statement
The project scope statement details the project’s deliverables and the work necessary to create these
deliverables. The Project Scope Statement should contain the following components:
 Product Scope Description – describes what the project will accomplish
 Product Acceptance Criteria – describes what requirements must be met in order for the
project to be accepted as complete
 Project Deliverables – detailed list of deliverables the project will result in
 Project Exclusions – description of work that is not included in the project and outside of the
scope
 Project Constraints – lists limits on resources for time, money, manpower, or equipment
(capital)
 Project Assumptions – describes the list of assumptions the project team and stakeholders are
working under to complete the project

Additionally, the scope statement includes what work should not be performed in order to eliminate
any implied but unnecessary work which falls outside the of the project’s scope.

Use the Scope Statement Template to complete your simulated/workplace project scope activities.

SWS Centre for Education and Workforce Development Page 25 of 45

Scope Verification

Scope verification discusses how the deliverables will be verified against the original scope and how the
deliverables from the project will be formally accepted. The deliverables for the project should be
formally accepted and signed off on by the authorising sponsor throughout the lifecycle of the project
and not held back as a single deliverable at the end of the project.

Scope Control

Scope control is the process of monitoring the status of the scope of the project. This section of the
Scope Management Plan also details the change process for making changes to the scope baseline.

If a change to the project scope is needed the process for recommending changes to the scope of the
project must be carried out. Any project team member or sponsor can request changes to the project
scope. All change requests must be submitted to the Project Manager in the form of a project change
request document. The Project Manager will then review the suggested change to the scope of the
project. The Project Manager will then either deny the change request if it does not apply to the intent
of the project or convene a change control meeting between the project team and Sponsor to review
the change request further and perform an impact assessment of the change.

If the change request receives initial approval by the Project Manager and Sponsor, the Project
Manager will then formally submit the change request to the Executive Sponsors for approval. If the
Executive Sponsors approve the scope change the Project Sponsor will then formally accept the change
by signing the project change control document. Upon acceptance of the scope change by the Change
Control Board and Project Sponsor the Project Manager will update all project documents and
communicate the scope change to all project team members’ stakeholders.

Use the Scope Change Control template to complete your simulated/workplace project scope
activities.

Work Breakdown Structure

The Work Breakdown Structure (WBS) and Work Breakdown Structure Dictionary are key elements to
effective scope management. This section of the Time/Schedule Management Plan should discuss how
the project milestones are to be subdivided into smaller timeframes in the WBS and how these smaller
components are managed during the life of the project.

WBS assists in clearly defining the work necessary for project completion. WBS can be an independent
document supporting the Scope Management Plan. Develop the WBS to meet this plan’s
requirements.

SWS Centre for Education and Workforce Development Page 26 of 45

Scope Management Plan

Project Name:
Prepared by:
Date:
Describe how project scope will be managed:

Assess the expected stability of the scope of this project (how likely is it to change, how
frequently and by how much?):

How will scope changes be identified and classified?

Describe how changes in project scope will be integrated into the project:

Additional remarks:

SWS Centre for Education and Workforce Development Page 27 of 45

Scope Statement

Project Name:
Prepared by:
Date:
Project Justification

Project Description

Project Deliverables

Deliverable A

Deliverable B

Deliverable C

Project boundaries

Project objectives

Cost objectives (quantify)

Schedule objectives (start

and stop dates)

Quality measures (criteria

that will determine
acceptability)
Other objectives

SWS Centre for Education and Workforce Development Page 28 of 45

Scope Change Control System Development Checklist and Worksheet
Project Name:
Prepared by:
Date:
Determine those responsible for approving or rejecting proposed scope change:
Be sure to provide for appropriate review of all changes.

Define any types of scope changes qualifying for automatic approval without review:

Describe how scope change control will be integrated with the integrated change control
system:

Define steps by which project scope may be changed, including:

Paperwork

Tracking systems

Dispute resolution procedures

Approval levels required

SWS Centre for Education and Workforce Development Page 29 of 45

Time/Schedule Management Plan
Introduction
This section highlights the purpose and importance of the time/schedule management plan. It
provides a general description of what should be included in the plan. These items should be
described in more detail later in the plan under each corresponding section.

Time/Schedule Management Approach

This section provides a general framework for the approach which will be taken to create the project
schedule. This includes the scheduling tool/format, schedule milestones, and schedule development
roles and responsibilities.

You can specify the development of the Work Breakdown Structure as a tool to track all scheduled
activity, milestone timelines and their achievements.

Time/Schedule Control
This section defines how the project’s schedule will be controlled throughout the life of the project.
This includes the frequency of updates and schedule reviews as well as communicating the schedule
and progress. This section also defines roles and responsibilities as they relate specifically to project
schedule control.

Time/Schedule Changes and Thresholds

As the project schedule is created it is important that boundary conditions are set by the project
sponsor to establish the schedule parameters within which the project is expected to operate. Any
event which may potentially cause a schedule change (project time creep) which exceeds these
boundary conditions must have a schedule change request submitted and approved by the sponsor
before the schedule change is made.

Scope Change
Occasionally, approved changes to the project’s scope may result in the schedule needing to be re-
baselined. These scope changes may include new deliverables or requirements that were not
previously considered as part of the original schedule’s development.

In these situations the project manager and team must consider the current status of the project
schedule/timelines and how the scope change will affect the schedule and its resources as the project
moves forward. How you handle scope change must be clearly documented in the Time/Schedule
Management Plan.

SWS Centre for Education and Workforce Development Page 30 of 45

Work Breakdown Structure
The Work Breakdown Structure (WBS) and Work Breakdown Structure Dictionary are key elements to
effective scope management. This section of the Time/Schedule Management Plan should discuss how
the project milestones are to be subdivided into smaller timeframes in the WBS and how these smaller
components are managed during the life of the project.

WBS assists in clearly defining the work necessary for project completion. WBS can be an independent
document supporting the Time/Schedule Management Plan. Develop the WBS to meet this plan’s
requirements.

Gantt Charts
A Gantt chart is one of the most popular and useful ways of showing activities (tasks or events) displayed
against time. On the left of the chart is a list of the activities and along the top is a suitable time scale. Each
activity is represented by a bar; the position and length of the bar reflects the start date, duration and end
date of the activity.

This allows you to see at a glance:

 What the various activities are
 When each activity begins and ends
 How long each activity is scheduled to last
 Where activities overlap with other activities, and by how much
 The start and end date of the whole project

To summarise, a Gantt chart shows you what has to be done (the activities) and when (the schedule). Gantt
Charts can be as complex or as simple as is necessary to track the project. The complexity may also depend
on the capabilities within the project team to develop the Gantt Chart. Gantt Charts may be developed
using Microsoft Excel or Microsoft Project Manager software.

An example of a simple Gantt Chart is shown below:

Participants can refer to the user guide provided in the class, on how to create Gantt Charts using Microsoft
Excel.

SWS Centre for Education and Workforce Development Page 31 of 45

Work Breakdown Structure (WBS)
Introduction

The Work Breakdown Structure (WBS) and Work Breakdown Structure Dictionary are key elements to
effective scope management. This section of the Time/Schedule Management Plan should discuss how
the project milestones are to be subdivided into smaller timeframes in the WBS and how these smaller
components are managed during the life of the project.

WBS assists in clearly defining the work necessary for project completion. WBS can be an independent
document supporting the Scope Management Plan and the Time/Schedule Management Plan.

The WBS can be developed in different formats. Some of the formats are shown in this document and
can be adapted for your simulated/workplace project activities. The format examples include:
1. Outline View Style
2. Hierarchical Structure Style
3. Tabular View Style
4. Tree Structure Style

It is recommended that you utilise one of these styles to develop your WBS. A WBS must be created to
support your Scope and Time/Schedule Management Plans.

WBS - Outline View style

The outline view presents an easy to view and understand layout for the WBS. It is also a good layout to use
when developing the WBS because you can easily make changes, especially since the Microsoft Word auto
numbering feature updates the WBS Code automatically.

1. Widget Management System (project name)

     1.1 Initiation
         1.1.1 Evaluation & Recommendations
         1.1.2 Develop Project Charter
         1.1.3 Deliverable: Submit Project Charter
         1.1.4 Project Sponsor Reviews Project Charter
         1.1.5 Project Charter Signed/Approved
     1.2 Planning
         1.2.1 Create Preliminary Scope Statement
         1.2.2 Determine Project Team
         1.2.3 Project Team Kickoff Meeting
         1.2.4 Develop Project Plan
         1.2.5 Submit Project Plan
         1.2.6 Milestone: Project Plan Approval
     1.3 Execution
         1.3.1 Project Kickoff Meeting
         1.3.2 Verify & Validate User Requirements
         1.3.3 Design System
         1.3.4 Procure Hardware/Software
         1.3.5 Install Development System
         1.3.6 Testing Phase

SWS Centre for Education and Workforce Development Page 32 of 45

         1.3.7 Install Live System
         1.3.8 User Training
         1.3.9 Go Live
     1.4 Control
         1.4.1 Project Management
         1.4.2 Project Status Meetings
         1.4.3 Risk Management
         1.4.4 Update Project Management Plan
     1.5 Closeout
         1.5.1 Audit Procurement
         1.5.2 Document Lessons Learned
         1.5.3 Update Files/Records
         1.5.4 Gain Formal Acceptance
         1.5.5 Archive Files/Documents

WBS - Hierarchical Structure style

The hierarchal structure is similar to the outline view but without indentation. Although this format is more
difficult to read, it may be useful where you have many levels and indenting each level would make the
table too large to fit into a document.

Leve WBS Code Element Name

l
1 1 Widget Management System (Project name)
2 1.1 Initiation
3 1.1.1 Evaluation & Recommendations
3 1.1.2 Develop Project Charter
3 1.1.3 Deliverable: Submit Project Charter
3 1.1.4 Project Sponsor Reviews Project Charter
3 1.1.5 Project Charter Signed/Approved
2 1.2 Planning
3 1.2.1 Create Preliminary Scope Statement
 

SWS Centre for Education and Workforce Development Page 33 of 45

WBS - Tabular View style
The Tabular View is a nicely organised table view of the WBS. It is a good option for teams which prefer
table formats.

Level 1 (Project Name) Level 2 Level 3

1 Widget Management 1.1 Initiation 1.1.1 Evaluation & Recommendations
System 1.1.2 Develop Project Charter
1.1.3 Deliverable: Submit Project Charter
1.1.4 Project Sponsor Reviews Project Charter
1.1.5 Project Charter Signed/Approved
1.2 Planning 1.2.1 Create Preliminary Scope Statement
1.2.2 Determine Project Team
1.2.3 Project Team Kickoff Meeting
1.2.4 Develop Project Plan
1.2.5 Submit Project Plan
1.2.6 Milestone: Project Plan Approval
1.3 Execution 1.3.1 Project Kickoff Meeting
1.3.2 Verify & Validate User Requirements
1.3.3 Design System
1.3.4 Procure Hardware/Software
1.3.5 Install Development System
1.3.6 Testing Phase
1.3.7 Install Live System
1.3.8 User Training
1.3.9 Go Live
1.4 Control 1.4.1 Project Management
1.4.2 Project Status Meetings
1.4.3 Risk Management
1.4.4 Update Project Management Plan
1.5 Closeout 1.5.1 Audit Procurement
1.5.2 Document Lessons Learned
1.5.3 Update Files/Records
1.5.4 Gain Formal Acceptance
1.5.5 Archive Files/Documents
 

SWS Centre for Education and Workforce Development Page 34 of 45

WBS - Tree Structure style
The Tree Structure View is the most popular format for the Work Breakdown Structure. It presents an easy
to understand view into the WBS; however, it is also tricky to create without an application specifically
designed for creating this structure. The Tree Structure below was created using the Microsoft Word and
the SmartArt graphics option under the insert menu.

SWS Centre for Education and Workforce Development Page 35 of 45

Cost Management Plan
Introduction
The Cost Management Plan clearly defines how the costs on a project will be managed throughout the project’s lifecycle. It
sets the format and standards by which the project costs are measured, reported and controlled. The Cost Management
Plan:
 Identifies who is responsible for managing costs
 Identifies who has the authority to approve changes to the project or its budget
 How cost performance is quantitatively measured and reported upon
 Report formats, frequency and to whom they are presented

Cost Management Approach

In this section you explain your approach to cost management for your project.

The Project Manager and Project Team in consultation with the Project Sponsor/s should determine which level of the WBS
the project manager should most effectively manage the project’s costs from. The further down in the WBS you go, the more
detailed your cost management is. However, you should balance the granularity at which you want to manage costs against
the amount of effort it takes to manage at that level. The more granular your cost management, the more work is necessary
to manage it.

Reporting Format
Reporting for cost management should be included in the monthly project status report. This report should include a section
labelled, “Cost Management”. This section should contain information on all cost variances outside of the thresholds
identified in this Cost Management Plan including any corrective actions which are planned. Change Requests which are
triggered based upon project cost overruns will be identified and tracked in this report.

Cost Variance Response Process

This section of the Cost Management Plan defines the control thresholds for the project and what actions will be taken if
the project triggers a control threshold. As a part of the response process the Project Manager typically presents options
for corrective action to the Project Sponsor who will then approve an appropriate action in order to bring the project back
on budget. The Project Manager may propose to increase the budget for the project, reduce scope or quality, or some
other corrective action.

Cost Change Control Process

Typically the change control process follows the project change control process. If there are special requirements for the
cost change control process, they should be detailed in this section of the Cost Management Plan.

SWS Centre for Education and Workforce Development Page 36 of 45

Project Budget
Information in this section may/may not be approved for visibility to all members of the project. This
should be checked with the Project Sponsors prior to publishing the information in regular project
status reports. Information included in this section may include details under the following headings:
Fixed Costs: $xxx,xxx.xx
Material Costs: $xxx,xxx.xx
Contractor Costs: $xxx,xxx.xx
Total Project Cost: $xxx,xxx.xx
Management Reserve: $x,xxx.xx

The Cost Breakdown Structure (CBS)

Costs are allocated to the lowest level of the Work Breakdown Structure (WBS). The tasks at this level
can often be subdivided into discrete activities to be completed by different departments therefore
one task may have several costs elements. Once costs have been assigned to tasks, it is possible to
monitor the project in terms of actual, forecast and earned cost on a task.

In order to be able to summarise costs within projects across projects a CBS needs to be developed.
The majority of organisations have a standard CBS that is applied across all projects and is nearly
always determined by the finance department. Finance often refers to the structure as the code of
accounts which includes other elements over and above pure costs. With some computerised tools, a
separate CBS is set up which is normally a simplified version of the code of accounts so that it can be
understood more easily by non-financial managers and enables the Project Manager to track project
cost.

Sample of a simple CBS following the WBS is shown below. Your CBS can be as complex or simple as you
prefer depending on the complexity of your project.

SWS Centre for Education and Workforce Development Page 37 of 45

Quality Management Plan
Introduction
The Quality Management Plan is an integral part of any project management plan. The purpose of the
Quality Management Plan is to describe how quality will be managed throughout the lifecycle of the
project. It also includes the processes and procedures for ensuring quality planning, assurance, and
control are all conducted. All stakeholders should be familiar with how quality will be planned,
assured, and controlled.

Quality Management Approach

This section of the Quality Management Plan describes the approach the project team will use for
managing quality throughout the project’s life cycle. Quality must always be planned into a project in
order to prevent unnecessary rework, waste, cost, and time. Quality should also be considered from
both a product and process perspective. The organisation may already have a standardised approach
to quality, however, whether it is standard or not, the approach must be defined and communicated
to all project stakeholders.

If monitoring, recording and reporting on quality is an activity that has to be assigned to a project
team member or a quality manager, this should be specified in this section.

Quality Requirements/Standards
This part of the Quality Management Plan should describe how the project team and/or quality group
will identify and document the quality requirements and standards. Additionally, there should also be
an explanation of how the project will demonstrate compliance with those identified quality
standards. The quality standards and requirements should include both the product and processes.

Quality Assurance
Here the Quality Management Plan should explain how you will define and document the process for
auditing the quality requirements and results from quality control measurements in order to ensure
that quality standards and operational definitions are utilised and met. This section should also
document the actual quality assurance metrics used for this project.

SWS Centre for Education and Workforce Development Page 38 of 45

Quality Control
In this section the Quality Management Plan describes how you will define and document the process
for monitoring and recording the results of executing the quality activities to assess performance and
recommend necessary changes. Quality control applies to the project’s product as opposed to its
processes. It should include what the acceptable standards and/or performance are for the product
and how these measurements will be conducted.

Quality Control Measurements

This section of the Quality Management Plan should contain a sample or useable table/log to be used
in taking quality measurements and comparing them against standards/requirements. The most
important aspect of this log is to provide documentation of the findings in the Quality Management
Plan. If actual measurements do not meet the standards or requirements then some action must be
taken. This may be done in regularly scheduled project status meetings or as necessary throughout the
project lifecycle.

All identified variances and measures taken to bridge the gap must be recorded in the log.

Quality Control Log/Register

Quality Check Quality Check Benchmark Identified Variance Resolution /

Conducted on Conducted by Timeframe

SWS Centre for Education and Workforce Development Page 39 of 45

Project Finalisation Report

Introduction
The Project Finalisation Report is developed after the Project Closing Process is completed. Once the
closing process is completed and the project manager has received acceptance from the project
sponsor, the project manager and the project team conduct a post-project review, evaluate
performance and document lessons learned and archive all project related documents.

The Project Finalisation Report includes information under the following headings:

1. An Executive Summary
a. Background
b. Reason for Project Closure
c. Highlights and Innovations
d. Recommendation Summary

2. Project Performance
a. Performance mapped against objectives
b. Performance mapped against outcomes
c. Performance mapped against outputs
d. Performance mapped against schedules
e. Performance mapped against budget
f. Recommendations

3. Lessons Learned – Summary

a. Successes
b. Areas for Improvement
c. Recommendations

4. Closure Activities
a. Project Staff
b. Issues Management
c. Risk Management
d. Financial Management
e. Asset Management
f. Records Management
g. Post-project Responsibilities
h. How to use this report

5. Recommendations

6. Appendices

SWS Centre for Education and Workforce Development Page 40 of 45

Additional Documentation as required
Change Request Form
If the project scope is well defined, a project may not require many changes to its scope, however, mid to large level projects
(particularly information technology based projects) require some change to its initial scope or the system design. It is critical
for a Project Manager to ensure such changes are formally requested, documented and a register is maintained of all Change
Requests within the pool of project documentation for current and future project success.

Change request forms are the primary project management tool used for requesting any changes to a specific project and are
one piece of the change management process. All project managers must manage change carefully and implement a
thorough change control process to ensure project’s remain within their approved constraints. Some projects have many
stakeholders with varying levels of interest in the project and change is an inevitable part of any project lifecycle.

The change request form is filled out by the individual who identifies the need for a change and submitted to the project
team in accordance with the change control process. The project manager then leads the team in identifying the impacts of
the change, whether or not it will benefit the project, and if it will allow the project to proceed within its approved
constraints. The request is then submitted to the Executive/Approving Sponsors with the project team’s findings where it is
reviewed and either approved, rejected, or deferred until clarification can be sought.

If the change is approved, all project documentation must be updated accordingly and the change must be communicated to
all stakeholders. Some changes may also require re-baselining of the costs, schedule, or scope.

Below is one example of a thorough change request form. Reference to Change Board can be replaced with
Executive/Approving Sponsors.

SWS Centre for Education and Workforce Development Page 41 of 45

Change Request Register

Change Request Register

Project: Date:

Change Description Priority Category Requested Submitted To Status Date Deferred Comments
Request (H,M,L) By

This should Detailed High, Assign to Who Who is the What is the When is the CR Additional
be a description Medium a requested authorising/approving status of the planned for comments
standard of the CR. or Low category. the CR? sponsor CR? implementation?
numbering priority. Approved /
system. Rejected /
Deferred?

The Change Request Register is created only if there are approved changes to the Project Scope, Time,
Budget or Quality constraints.

SWS Centre for Education and Workforce Development Page 42 of 45

Project Status Report
Purpose
The purpose of the Project Progress Report is to keep others informed of the progress of your project. The project manager issues
regular reports on progress against budget, schedule, scope, and quality. The people who should receive this progress report
include project sponsor, budget holder, senior users, team members, stakeholders and end-users. A progress report is designed to
be a brief summary of progress and should not exceed one to two pages in length.

The following template could be used, but the project progress report should include; report date, overall status, project summary,
key issues, identified risks, tasks and next steps, decisions needed, budgeted cost and spent to date.

Template

Name of project: ______________________________________

Name of project manager: ______________________________

Date of progress report: ____________________

Summary of progress
Deliverables Targets not met yet Targets met Ahead of Targets


Project phase: Define & Plan  Execution  Completion

Progress:
Provide a brief overview of the project from commencement to date including; deliverables achieved,
milestones reached risks managed, stakeholder and team involvement.

Issues:
Provide a brief overview of any issues (anticipated and unexpected) that have occurred, resolutions that
have been implemented, and their success.

For completion:
Identify outstanding work, time and budget required to complete the project. Include proposed changes,
escalation of issues, potential delays and risks that may affect the completion of the project as originally
specified.

Updates:
Provide updated documents with evidence of adjustments made to any documents required for the project
to be completed (may include ‘project proposal’, ‘project plan’, ‘risk register’ and ‘change request log’).

SWS Centre for Education and Workforce Development Page 43 of 45