Project Charter - swslhd.health.nsw.gov.au€¦ · Web viewA Project Charter formally recognises the existence of a project and states the scope of the project, gives the Project

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 44

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


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-off3. Broad Stakeholder Identification4. Consolidated Project Initiation Documentation5. Documented Objectives6. High-Level Project Deliverables7. High-Level Risk Assessment8. Project Assumptions and Constraints9. Project Mandate10. Source of Project Authority

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


PROJECT NAME

Approvals and Sign-OffAuthorising Sponsor Name & Designation

Date of Authorisation

Authorising Sponsor SignatureBroad Stakeholder IdentificationName of Stakeholder Stakeholder Role

Consolidated Project Initiation DocumentationName of Documentation Approved by Authorising Sponsor

Project ObjectivesObjectives Approved by Authorising Sponsor

High Level Project DeliverablesDeliverables Approved by Authorising Sponsor

High Level Risk AssessmentForecasted Risk Recognised by Authorising Sponsor

Project AssumptionsProject ConstraintsProject Strategic Alignment


Project Proposal (Please expand as required)

Project Title

Backgrounda. 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 OrganisationExecutive/Authorising SponsorProject ManagerProject Team Member/sSubject Matter Experts (SMEs)Other Stakeholders

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


major deliverables within the project)

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


Project Management Plan

Purpose

Project Management Plan

Project Name:Project Sponsor:Project Manager:Position:

Version Control

Version Version Date

Author Modifier Revision Reason / Description

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


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 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 TargetReduce …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 BackgroundWhy 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 ApproachBroadly describe the phases and timings of the project – what methodologies will be used.

Project definitionDefine the project that applies to this project management plan.

Project scopeThe 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 ResponsibilitiesThis 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.


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

Implementation planThe 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.

AppendicesList any supporting documents required


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 identified2. How quantitative analysis will be completed3. How qualitative analysis will be completed4. How risk response planning will happen5. How risks will be monitored6. 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.


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 (H,M,L)

Category Reported By

Assigned To

Status Date Resolved

Resolution/ Comments

This should be a

standard numbering

system.

Detailed description of the issue.

High, Medium or Low

priority.

Assign to a

category.

Who reported

the issue?

Who is the issue assigned

to?

What is the

status of the issue?

What date was the

issue resolved?

What was the resolution or what is being

done to 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 riskUnderlying problem or cause of the issue Risk profile—sources of uncertainty and the

potential impactAction plan Potential actionsPriority or scheduling Monitoring planWho is responsible for assuring this issue is resolved Who is responsible for monitoringDate opened and date resolved, sometimes a tracking number or other ID

Date last updated, tracking ID


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


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

informal4. Who is responsible for communicating project information5. Communication requirements for all project stakeholders6. What resources the project allocates for communication7. How any sensitive or confidential information is communicated and who must authorize this8. How changes in communication or the communication process are managed9. The flow of project communications10. Any constraints, internal or external, which affect project communications11. Any standard templates, formats, or documents the project must use for communicating12. An escalation process for resolving any communication-based conflicts or issues

Communication Management Approach

Communications Management Constraints


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.

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.

Stakeholder Communication Requirements

Roles

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


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.

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

Communication Methods and Technologies

Communications Matrix

The following table identifies the communications requirements for this project.

Communication Type

Objective of Communication

Medium Frequency

Audience Owner Deliverable Format

Communication Flowchart


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.

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.

Guidelines for Meetings

Communication Standards


Meeting AgendaMeeting 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 MinutesMeeting 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 ItemsAction 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 PersonThe 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 TakerThe 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

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.

Communication Escalation Process

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

Priority Definition Decision Authority

Timeframe for Resolution

Priority 1

Major impact to project or business operations. If not resolved quickly there will be a significant adverse impact to revenue and/or schedule.

Vice President or higher

Within 4 hours

Priority 2

Medium impact to project or business operations which may result in some adverse impact to revenue and/or schedule.

Project Sponsor

Within one business day

Priority 3

Slight impact which may cause some minor scheduling difficulties with the project but no impact to business operations or revenue.

Project Manager

Within two business days

Priority 4

Insignificant impact to project but there may be a better solution.

Project Manager

Work continues and any recommendations are submitted via the project change control 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.

Glossary of Communication Terminology

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 Management Plan

Portion of the overall Project Management Plan which details how project 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


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.

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 Identification2. Segmenting Stakeholders3. Stakeholder Management4. Interests and Influences5. Stakeholder Analysis6. Stakeholder Management Actions7. Stakeholder Performance Reviews8. 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.


Stakeholder Analysis Report

Importance of stakeholderUnknown Little/No

importanceSome

importanceSignificant

importance

Influence of stakeholder

Significant influence C ASomewhat influential

Little/No influence D BUnknown

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


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.

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 (name

and role)

Primary/ Secondary/Key Stakeholders

Current level of support (Low-Med-

High)

What do you want from

stakeholders?

What’s important to

stakeholders?

How could stakeholders block your

efforts?

What is your

strategy for enhancing

stakeholder support?

School age children

Secondary Medium To attend school Been engaged at school

By truanting or refusing

Consult with them Develop strategies with school

Parents Primary Low To enforce their child to attend

Keeping child happy – keeping the peace at home

By not enforcing and reinforcing the strategies given

Support and discussion

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.


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

Project team member name

Role Authority Responsibility Competency

Project Organisational charts


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.

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.

Team Member Activity Name Name NameDefine & Plan

Execution

Completion

KeyR = Responsible C = Consulted A = Accountable I = Informed


Scope Management Plan

Scope Management Approach

Roles and Responsibilities

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 Manager

Measure and verify project scope 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


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 management2. 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/exclusion4. 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.

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

Participate in impact assessments of scope change requests Communicate outcomes of scope change requests to team Facilitate team level change review process

John Smith

Team Member

Participate in defining change resolutions Evaluate the need for scope changes and communicate them to the project

manager as necessary

Tom Brown

Team Member

Participate in defining change resolutions Evaluate the need for scope changes and communicate them to the project

manager as necessary

Scope Definition

Scope Statement


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.

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.

Scope Verification

Scope Control

Work Breakdown Structure


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

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.

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:


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


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


Time/Schedule Management Plan

Introduction

Time/Schedule Management Approach

Time/Schedule Control

Time/Schedule Changes and Thresholds

Scope Change


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.

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.

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.

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.

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.

Work Breakdown Structure

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.



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.

Work Breakdown Structure (WBS)

Introduction

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



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 Style2. Hierarchical Structure Style3. Tabular View Style4. 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.

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.

Level WBS Code

Element Name

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


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 System

1.1 Initiation 1.1.1 Evaluation & Recommendations1.1.2 Develop Project Charter1.1.3 Deliverable: Submit Project Charter1.1.4 Project Sponsor Reviews Project Charter1.1.5 Project Charter Signed/Approved

1.2 Planning 1.2.1 Create Preliminary Scope Statement1.2.2 Determine Project Team1.2.3 Project Team Kickoff Meeting1.2.4 Develop Project Plan1.2.5 Submit Project Plan1.2.6 Milestone: Project Plan Approval

1.3 Execution 1.3.1 Project Kickoff Meeting1.3.2 Verify & Validate User Requirements1.3.3 Design System1.3.4 Procure Hardware/Software1.3.5 Install Development System1.3.6 Testing Phase1.3.7 Install Live System1.3.8 User Training1.3.9 Go Live

1.4 Control 1.4.1 Project Management1.4.2 Project Status Meetings1.4.3 Risk Management1.4.4 Update Project Management Plan

1.5 Closeout 1.5.1 Audit Procurement1.5.2 Document Lessons Learned1.5.3 Update Files/Records1.5.4 Gain Formal Acceptance1.5.5 Archive Files/Documents


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.


Cost Management Plan

Introduction

Cost Management Approach

Reporting Format

Cost Variance Response Process

Cost Change Control Process


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

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

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.

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.

Project Budget

The Cost Breakdown Structure (CBS)

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.


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.xxMaterial Costs: $xxx,xxx.xxContractor Costs: $xxx,xxx.xxTotal Project Cost: $xxx,xxx.xxManagement Reserve: $x,xxx.xx

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.

Quality Management Plan

Introduction

Quality Management Approach

Quality Requirements/Standards

Quality Assurance


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.

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.

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.

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.

Quality Control

Quality Control Measurements

Quality Control Log/Register

Quality Check Conducted on

Quality Check Conducted by

Benchmark Identified Variance Resolution / Timeframe


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.

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.

Project Finalisation Report

Introduction

The Project Finalisation Report includes information under the following headings:

1. An Executive Summarya. Backgroundb. Reason for Project Closurec. Highlights and Innovationsd. Recommendation Summary

2. Project Performancea. Performance mapped against objectivesb. Performance mapped against outcomesc. Performance mapped against outputsd. Performance mapped against schedulese. Performance mapped against budgetf. Recommendations

3. Lessons Learned – Summarya. Successesb. Areas for Improvementc. Recommendations

4. Closure Activitiesa. Project Staffb. Issues Managementc. Risk Managementd. Financial Managemente. Asset Managementf. Records Managementg. Post-project Responsibilitiesh. How to use this report

5. Recommendations

6. Appendices


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.

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.

Change Request Register

Change Request Register

Project: Date:

Change Request

Description Priority (H,M,L)

Category Requested By

Submitted To Status Date Deferred Comments

This should be a standard numbering system.

Detailed description of the CR.

High, Medium or Low priority.

Assign to a category.

Who requested the CR?

Who is the authorising/approving sponsor

What is the status of the CR? Approved / Rejected / Deferred?

When is the CR planned for implementation?

Additional comments

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


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 progressDeliverables 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’).
