Learner Guide: BSBPMG521Human Computer Interaction
Manage project integration
BSBPMG521 LEARNER GUIDE 1 | P a g e Version 3.0

Version control
Version No.	Date	Dept.	Change
1.3	11/11/2015	Training	Original
2.0	06/04/2016	Training	Updated content
2.5	01/07/2016	Training	Updated content
3.0	24/10/2016	Training	Updated content

 

Copyright Statement
© Copyright National Training
Disclaimer	All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, scanning, recording, or any information storage retrieval system without permission in writing from National Training. No patent liability is assumed with respect to the use of information used herein. While every effort has been taken in the preparation of this publication, the publisher and authors assume no responsibility for errors or omissions. Neither is any liability assumed for damages resulting from the use of information contained herein.

BSBPMG521 LEARNER GUIDE 2 | P a g e Version 3.0
Contents
Contents…………………………………………………………………………………………………………………….. 2
BSBPMG521 Unit Description …………………………………………………………………………………………….. 6
Application of Unit……………………………………………………………………………………………………………. 6
Elements and Performance Criteria …………………………………………………………………………………….. 6
Performance Evidence ………………………………………………………………………………………………………. 7
Knowledge Evidence …………………………………………………………………………………………………………. 7
Section 1 Establish project……………………………………………………………………………………………… 8
1.1 Identify, clarify and prepare project initiation documentation …………………………………………… 8
Project management …………………………………………………………………………………………………….. 8
Project initiation documentation …………………………………………………………………………………….. 8
Project management framework …………………………………………………………………………………….. 9
Project methodology …………………………………………………………………………………………………… 11
Client or customer requirements …………………………………………………………………………………… 12
Concept proposal………………………………………………………………………………………………………… 13
Feasibility study ………………………………………………………………………………………………………….. 14
Broader organisation strategies and goals………………………………………………………………………. 15
Relationship between the project and broader organisational strategies and goals ……………… 16
1.3 Negotiate and document project objectives, outcomes and benefits ……………………………….. 17
Project objectives………………………………………………………………………………………………………… 17
Project outcomes ………………………………………………………………………………………………………… 18
Project benefits…………………………………………………………………………………………………………… 18
Negotiate project objectives, outcomes and benefits ………………………………………………………. 19
1.4 Negotiate project governance structure with relevant authorities and stakeholders ………….. 22
Project governance ……………………………………………………………………………………………………… 22
Organisational governance policies and procedures ………………………………………………………… 24
Roles and responsibilities……………………………………………………………………………………………… 25
Financial delegations……………………………………………………………………………………………………. 25
Reporting lines ……………………………………………………………………………………………………………. 27
Subordinates………………………………………………………………………………………………………………. 28
Task descriptions…………………………………………………………………………………………………………. 29
Team culture values…………………………………………………………………………………………………….. 29
Negotiating project governance structure with relevant authorities and stakeholders …………. 30
1.5 Prepare and submit project charter for approval by relevant authorities ………………………….. 31
BSBPMG521 LEARNER GUIDE 3 | P a g e Version 3.0
Project charter ……………………………………………………………………………………………………………. 31
Preparing and submitting the project charter………………………………………………………………….. 33
Section 2 Undertake project planning and design processes ……………………………………………….. 35
2.1 Establish and implement a methodology to disaggregate project objectives into achievable
project deliverables ………………………………………………………………………………………………………… 35
Project deliverables …………………………………………………………………………………………………….. 35
Disaggregate project objectives into deliverables…………………………………………………………….. 35
Achievable project deliverables …………………………………………………………………………………….. 36
2.2 Identify project stages and key requirements for stage completion against client requirements
and project objectives……………………………………………………………………………………………………… 37
Project stages……………………………………………………………………………………………………………… 37
Stage completion ………………………………………………………………………………………………………… 37
Client requirements and project objectives …………………………………………………………………….. 39
2.3 Analyse project management functions to identify interdependencies and impacts of
constraints …………………………………………………………………………………………………………………….. 46
Project management functions……………………………………………………………………………………… 46
Communications …………………………………………………………………………………………………………. 46
Cost…………………………………………………………………………………………………………………………… 47
Human resources ………………………………………………………………………………………………………… 48
Procurement and contracting ……………………………………………………………………………………….. 49
Project integration ………………………………………………………………………………………………………. 49
Quality ………………………………………………………………………………………………………………………. 52
Risk……………………………………………………………………………………………………………………………. 54
Scope ………………………………………………………………………………………………………………………… 54
Time ………………………………………………………………………………………………………………………….. 55
Triple constraints ………………………………………………………………………………………………………… 55
2.4 Develop a project management plan that integrates all project-management functions with
associated plans and baselines …………………………………………………………………………………………. 65
Project management plan…………………………………………………………………………………………….. 65
Contents of a project management plan ………………………………………………………………………… 65
2.5 Establish designated mechanisms to monitor and control planned activity ……………………….. 68
Monitoring and controlling planned project activity ………………………………………………………… 68
2.6 Negotiate approval of project plan with relevant stakeholders and project authority …………. 70
Finalise project plan and gain approval…………………………………………………………………………… 70
Project management plan approval……………………………………………………………………………….. 71
BSBPMG521 LEARNER GUIDE 4 | P a g e Version 3.0
Section 3 Execute project in work environment ……………………………………………………………….. 72
3.1 Manage the project in an established internal work environment to ensure work is conducted
effectively throughout the project…………………………………………………………………………………….. 72
Managing the execution of the project…………………………………………………………………………… 72
3.2 Maintain established links to align project objectives with organisational objectives throughout
the project …………………………………………………………………………………………………………………….. 76
Project versus organisational objectives…………………………………………………………………………. 76
Align project and organisational objectives throughout the project life cycle ………………………. 77
3.3 Within authority levels, resolve conflicts negatively affecting attainment of project objectives
…………………………………………………………………………………………………………………………………….. 79
Conflict………………………………………………………………………………………………………………………. 79
Avoiding conflicts………………………………………………………………………………………………………… 80
Conflict resolution……………………………………………………………………………………………………….. 81
Section 4 Manage project control ………………………………………………………………………………….. 84
4.1 Ensure project records are updated against project deliverables and plans at required intervals
…………………………………………………………………………………………………………………………………….. 84
Records ……………………………………………………………………………………………………………………… 84
Project records……………………………………………………………………………………………………………. 86
Project management information software…………………………………………………………………….. 87
4.2 Analyse and submit status reports on project progress and identified issues with stakeholders
and relevant authorities…………………………………………………………………………………………………… 89
Monitoring and controlling …………………………………………………………………………………………… 89
Project reports ……………………………………………………………………………………………………………. 89
Preparing and producing reports …………………………………………………………………………………… 90
4.3 Analyse and submit impact analysis of change requests for approval, where required ……….. 92
Impact analysis……………………………………………………………………………………………………………. 92
Changes……………………………………………………………………………………………………………………… 93
Approvals for change requests ……………………………………………………………………………………… 94
4.4 Maintain relevant project logs and registers accurately and regularly to assist with project
audit……………………………………………………………………………………………………………………………… 96
Project logs and registers……………………………………………………………………………………………… 96
Procedures for capturing and filing records…………………………………………………………………… 100
Why is auditing important?…………………………………………………………………………………………. 102
4.5 Ensure associated plans are updated to reflect project progress against baselines and
approved changes…………………………………………………………………………………………………………. 103
Project baselines ……………………………………………………………………………………………………….. 103
BSBPMG521 LEARNER GUIDE 5 | P a g e Version 3.0
Updating associated plans to reflect project progress against baselines and approved changes
……………………………………………………………………………………………………………………………….. 103
Approved change requests …………………………………………………………………………………………. 104
Section 5 Manage project finalisation …………………………………………………………………………… 106
5.1 Identify and allocate project finalisation activities………………………………………………………… 106
Project finalisation activities ……………………………………………………………………………………….. 106
Allocating finalisation activities……………………………………………………………………………………. 107
5.2 Ensure project products and associated documentation are prepared for handover to client in
a timely manner……………………………………………………………………………………………………………. 108
Project products………………………………………………………………………………………………………… 108
Associated documentation …………………………………………………………………………………………. 108
Handover process ……………………………………………………………………………………………………… 108
5.3 Finalise financial, legal and contractual obligations ………………………………………………………. 110
Financial obligations ………………………………………………………………………………………………….. 110
Legal obligations ……………………………………………………………………………………………………….. 110
Contractual obligations………………………………………………………………………………………………. 111
5.4 Undertake project review assessments as input to future projects…………………………………. 112
Project review assessments ………………………………………………………………………………………… 112
Benefits realisation review………………………………………………………………………………………….. 112
Outcomes evaluation …………………………………………………………………………………………………. 113
Post-implementation review ………………………………………………………………………………………. 113
Lessons learned…………………………………………………………………………………………………………. 114
Input into future projects……………………………………………………………………………………………. 115
References …………………………………………………………………………………………………………………… 117
BSBPMG521 LEARNER GUIDE 6 | P a g e Version 3.0
BSBPMG521 Unit Description
Application of Unit
This unit describes the skills and knowledge required to integrate and balance overall project management
functions of scope, time, cost, quality, human resources, communications, risk and procurement across the
project life cycle; and to align and track project objectives to comply with organisational goals, strategies and
objectives.
It applies to individuals responsible for managing and leading a project in an organisation, business, or as a
consultant.
No licensing, legislative, regulatory or certification requirements apply to this unit at the time of publication.
Elements and Performance Criteria

1. Establish project	1.1 Identify, clarify and prepare project initiation documentation 1.2 Identify relationship between the project and broader organisational strategies and goals 1.3 Negotiate and document project objectives, outcomes and benefits 1.4 Negotiate project governance structure with relevant authorities and stakeholders 1.5 Prepare and submit project charter for approval by relevant authorities
2. Undertake project planning and design processes	2.1 Establish and implement a methodology to disaggregate project objectives into achievable project deliverables 2.2 Identify project stages and key requirements for stage completion against client requirements and project objectives 2.3 Analyse project management functions to identify interdependencies and impacts of constraints 2.4 Develop a project management plan that integrates all project-management functions with associated plans and baselines 2.5 Establish designated mechanisms to monitor and control planned activity 2.6 Negotiate approval of project plan with relevant stakeholders and project authority
3. Execute project in work environment	3.1 Manage the project in an established internal work environment to ensure work is conducted effectively throughout the project 3.2 Maintain established links to align project objectives with organisational objectives throughout the project 3.3 Within authority levels, resolve conflicts negatively affecting attainment of project objectives
4. Manage project control	4.1 Ensure project records are updated against project deliverables and plans at required intervals 4.2 Analyse and submit status reports on project progress and identified issues with stakeholders and relevant authorities 4.3 Analyse and submit impact analysis of change requests for approval, where required 4.4 Maintain relevant project logs and registers accurately and regularly to assist with project audit 4.5 Ensure associated plans are updated to reflect project progress against baselines and approved changes
5. Manage project finalisation	5.1 Identify and allocate project finalisation activities 5.2 Ensure project products and associated documentation are prepared for handover to client in a timely manner 5.3 Finalise financial, legal and contractual obligations 5.4 Undertake project review assessments as input to future projects

BSBPMG521 LEARNER GUIDE 7 | P a g e Version 3.0
Performance Evidence
Evidence of the ability to:
 Work closely with others to integrate all project management functions across a project life
cycle according to organisational objectives
 Negotiate with internal and external stakeholders
 Create accurate project management documentation
 Make suggestions for improvements to managing project integration in the future.
Note: If a specific volume or frequency is not stated, then evidence must be provided at least once.
Knowledge Evidence
To complete the unit requirements safely and effectively, the individual must:
 Summarise project governance models
 Describe range of methodologies to break project objectives into achievable project deliverables
 Outline role of project life cycle stages, phases and structures relevant to industry and project
context
 Identify and describe appropriate organisational documentation for recording strategies and
goals for integration processes.
BSBPMG521 LEARNER GUIDE 8 | P a g e Version 3.0
Section 1 Establish project
1.1 Identify, clarify and prepare project initiation documentation
Project management
Project management was first introduced in the 1950s when large organisations with a number of
different departments and business activities realised that they needed structured and formal
management plans to co-ordinate their various projects. Projects vary in size and duration but all go
through the same processes from the conception to the completion.
Project initiation documentation
Before you can even think about making a general plan for a project, essential information is
required to determine the nature of the project. A project initiation document (PID) is the
foundation of the project; it sets out what the project is about, why it is being undertaken, and what
will be delivered, by when, by which methods, and by whom. It is the premise of the project that is
agreed by the project manager and the client/sponsor/steering committee.
Careful consideration and time should be taken when compiling the PID as it will save time and
resources later in the project. The PID should be sufficiently detailed and relevant to your project,
not just a generic box ticking exercise, to ensure that all relevant stakeholders understand what the
project is about.
The purpose of a project initiation document is to provide the following information:
 Why the project is being undertaken
 What will be delivered
 Who will be responsible for relevant aspects
 How the project will be delivered
 When the project will be delivered
 The risks, constraints and potential issues
 Estimated cost of the project.
Business plan
The PID would take shape from the business plan. A project
management team is not usually the author of the business plan as companies often bring in project
managers to bring to life their goals in a more cohesive and expert manner than they could manage
to achieve themselves. The business plan may be the first piece of information the project
management team will look at.
Scope
A scope statement is a written document that sets out the limits of the project to which all that are
involved agree, prior to the project beginning.
The scope would include:
 Justification – why the project is necessary and valid
 Deliverables/objectives – what the project will produce
 Acceptance criteria – conditions to which the project and all those involved must
adhere for the completion of the project
BSBPMG521 LEARNER GUIDE 9 | P a g e Version 3.0
 Project exclusions – what the project will not do or produce
 Constraints – any envisaged issues that may hinder the project
 Assumptions – how anomalies within the life of the project will be addressed.
Resources needed and costs
All the resources required for the project including materials, the work force, and specialist support
such as permits and licences. The cost of all the resources needs to be as accurate as possible at this
stage as this will form the vast majority of the budget.
Timeline
This will be the most difficult piece of information to get right and time should be afforded for
problems and delays. The time frame will also quite probably change as the project gets going.
Estimated cost/budget
Costs include materials, labour and anything else the project requires. At this stage it is important to
identify hidden costs if possible. If estimates are wildly inaccurate the life and completion of the
project may be jeopardised.
Potential risks
Risks vary from project to project and could be minor and major depending on the nature of the
project. If any legislation applies to the project this should be assessed in detail.
Dependencies
These are the relationships between tasks within the project in that if one task is not complete,
another cannot begin, for example a roof cannot be erected on a house before the walls have been
built. It is essential that all dependencies are considered at the initial stages in planning as they can
cause serious delays and expense if they are not planned correctly
Project initiation documentation may include:
 Agreed project management
framework
 Agreed project methodology
 Client or customer requirements
 Concept proposal
 Contract documentation
 Executive team instructions
 Feasibility study
 Life cycle approval gateways
 Output from prior project.
Project management framework
The framework is the way in which a project is managed from start to finish, or the life cycle of the
project.
BSBPMG521 LEARNER GUIDE 10 | P a g e Version 3.0
It is commonly agreed that the five stages in the life cycle of the project are:
Initiation
Defining the aims and objectives and the nature and scope of the project.
Usually a team of people will be employed to define the project and set out in the project charter
the following details:
 Business plan
 Scope
 Objectives
 Deliverables
 Resources needed
 Timeline
 Estimated cost/budget
 Potential risks
 Dependencies.
Planning and design
Considerable time is spent planning the details of the project and considering all eventualities so as
to effectively manage risk throughout the life of the project. The planning stage involves:
 Developing the scope of the project
 Developing the work schedule
 Costing the project
 Identifying and recruiting the team
 Identifying deliverables
 Planning for risks and contingencies
 Communication planning.
Initiation
Planning and design
Execution
Monitoring and controlling
Closing
BSBPMG521 LEARNER GUIDE 11 | P a g e Version 3.0
Execution
The activities necessary to realise the end goal of the project. Project integration plays a huge role
during this process to ensure that all parties involved know what, how, when and why they should
be doing particular tasks.
Monitoring and controlling
The progress of the project is tracked throughout so as to quickly identify and rectify any problems
and is monitored against the management plan for efficiency.
Closing
It is important to officially close a project once it is completed and this is done by finishing all
activities, signing off the project team and signing the contract off with the customer.
Throughout the life of a project all activities and resources need to be co-ordinated and integrated
seamlessly in order to achieve the project objectives.
Project methodology
A project management methodology is simply the way in which you run and monitor your project
progress.
There are a number of different project management methodologies available that set out their
own themes and principles, including:
 Agile Methodology
 Waterfall Methodology
 Agile Versus Waterfall
 Change Management
 Risk Management
 Quality Management
 PRINCE2®
 PMBOK
 Six Sigma/Lean Six Sigma.
For more information on these methodologies visit the Bright hub project management website at
http://www.brighthubpm.com/methods-strategies/67087-project-management-methodologieshow-do-they-compare/
In order to determine which methodology you use you must consider how suitable it is for the
nature of your project as some methodologies lend themselves better to certain projects.
Considerations to determine a project methodology may be:
 With which methodology are you most familiar?
 With which methodology have you had most success?
 Which methodology best suits your project?
 Which methodology best suits your project team and stakeholders?
 The size and scale of your project.
BSBPMG521 LEARNER GUIDE 12 | P a g e Version 3.0
Client or customer requirements
A client has employed the services of your project team to realise their business objectives because
they believe you can do a more efficient job than they could do themselves. Whilst it is your project,
it is their dream and it must be done to their specific requirements and expectations. You may find
that they will need guidance and may have to be told that some of their stipulations are impossible
or very difficult to achieve within their specified budget, but you should try wherever possible to
accommodate their requirements.
Gathering client and customer requirements will involve a significant amount of time consulting with
them, face to face, to ensure you have taken on board all of their needs and expectations.
Clients will have requirements in all manner of project activities including:
 Time scale
 Budget
 Quality of supplies, resources and raw materials
 Vendors
 Working practices
 Types of contracts used
 Corporate social responsibility
 Preferred communication methods
 Style and method of reporting
 Authorities for decision making
 Other idiosyncratic matters.
In the initial stages of a project it is incredibly important that you start as you mean to go on in the
way you handle and develop your relationship with your client.
Tips for handling clients within your project:
 People buy people – even in the world of business, people inherently prefer to work
with people they like and respect. Go the extra mile to establish and develop your
client-project team relationship. Take an appropriate interest in their lives outside
of their business and what motivates them within it. Not only does this
demonstrate to the client that you value them as more than just a client, but it also
enables you to understand their personalities and motivations which can be
beneficial throughout the project when you need to address issues with them
 Communicate regularly, especially when addressing problems – communicate
directly with the client wherever possible and in a timely manner. The more open
and transparent you are the more they will trust you to make decisions on their
behalf
 Come to an agreement on all of their requirements – this does not mean that you
should agree to impossible demands, it means that where there are inconsistencies
of expectations, negotiations need to occur and a solution reached that both you
and the client agree to. Lack of agreement in the initial stages of the project will
inevitably lead to much more serious problems later on
BSBPMG521 LEARNER GUIDE 13 | P a g e Version 3.0
 Counsel you client – listen to them carefully and advise them appropriately and
honestly. This will build and strengthen their trust in you with the project
 Talk money – regularly discuss budgetary requirements, openly and honestly. You
both need to understand where the project stands financially at all times.
Concept proposal
The concept proposal documents the need for the project to improve a function within the
organisation that is inadequate or requires improvement. It is a persuasive document that
demonstrates the need for the project by highlighting the relevant function within the business that
is underperforming.
The concept proposal can be used to:
 Persuade stakeholders to invest in the project
 Highlight the part of the organisation that is underperforming
 Demonstrate/project the impact the area of underperformance is having/likely to
have on the organisation’s strategic goals
 Justify the need for the project
 Suggest the preferred materials, suppliers, and resources for the project and the
reasons these have been selected.
It should also outline the following information:
 Investment required – this should include the
type of investment, the source, and the
necessary timings
 Impact of the project – detail the benefits that
will be enjoyed by the completion of the
project within the organisation, community,
local economy, environment, etc.
 Resources required – a breakdown of all
resources required to complete the project
should be included, costed where possible.
Contract documentation
At this initial stage, contract documentation will probably be limited to the contract between the
client and the project team as suppliers and resources have not yet been identified let alone
procured. However, there may be documentation about the types of supply contract the project and
the client would like to employ and perhaps basic contract templates in place.
Executive team instructions
These will vary according to the size of the organisation and project and may refer to all manner of
working practices. The executive team is usually the highest level of authority within an organisation
with decision making capabilities on serious matters within the project. These are written
instructions, as opposed to verbal requests, that may be required to provide clarification on specific
issues or give more guidance where necessary.
BSBPMG521 LEARNER GUIDE 14 | P a g e Version 3.0
Feasibility study
A feasibility study is an evaluation of how realistic the project proposal is in terms of all aspects of
the proposal before any capital is invested. It should be a balanced view of the proposal evidenced
by accurate facts and figures and is often conducted by a project manager. It may not necessarily be
solely about the feasibility of the project as a concept, but the processes and procedures within the
project itself.
A feasibility study should include the following information:
 Description of the project
 Project objectives
 Timeline
 Costs and budgeting
 Purpose
 Market analysis
 Resources required
 Proposed methodology
 Management and team structure
 Observations
 Outcomes which should include:
o potential problems
o impact of the project on the organisation, community, environment, etc.
o alternative suggestions
o assessment.
Life cycle approval gateways
As we saw earlier in this chapter, the five stages in the
life cycle of the project are initiation, planning and
design, execution, monitoring and controlling, and
closing. As the project progresses to the next stage in
the cycle there will need to be approvals in place to
ensure that all activities and phases within the stage
have been completed to specified standards and in
prescribed time frames. Different levels of authority and
varying procedures may be required for different stages.
Output from prior project
You may have documentation relating to previous similar projects such as reviews, reports,
evaluations, observations, and lessons learned reports that will assist in the initial planning stages of
this project.
BSBPMG521 LEARNER GUIDE 15 | P a g e Version 3.0
1.2 Identify relationship between the project and broader organisational
strategies and goals
Broader organisation strategies and goals
Project objectives should relate directly to the broader organisational strategies and goals as the
project is intended to enhance the business in these areas and this forms part of the justification of
the project. The project may not relate to all of the strategic goals, particularly if it is a small, niche
project, but it must relate to at least one.
Broader organisational strategies and goals may include:
 Market focus – the area of the market the organisation serves. It could be that the
organisation wants to increase its share in the market or expand into a different
market and the project is a vehicle to start or complete this expansion
 Organisational mission statement – the mission statement is a broad definition of
the purpose of the organisation and its over-riding vision and/or goals. It is designed
to unite and motivate stakeholders towards a common goal and usually sets out the
company’s values and
beliefs. It contains:
o the target market of
the organisation
o the geographical
limits of the
organisation
o how the organisation
intends to survive,
grow and prosper
o the organisation’s
philosophy
o the desired image of
the organisation
 Strategy plans – the strategic plan is the medium to long term and overall objectives
of an organisation, often correlating with the mission statement but an extended
version. That said, it is not a detailed or lengthy document, rather it serves as a
framework for more detailed business plans and projects. It gives direction and
thought to the future of the organisation that would be lost without it. Many
businesses either fail or tread water without strategic planning as they exist in the
here and now without any thought for future existence. Strategy plans should be
reviewed regularly and modified to reflect changes within the organisation. A
strategy plan should:
o set out goals for the medium term (two to four years)
o be completed by the organisation’s director or owner
o contain strategic goals and not focus on day to day issues
o be realistic, balanced and critical
o be reviewed regularly
o documented
 Values and ethics – the values and ethics of an organisation underpin the way in
which it conducts its business, the expectations of behaviour of employees and
BSBPMG521 LEARNER GUIDE 16 | P a g e Version 3.0
other representatives, and its mission statement and strategic goals, in nonmonetary terms. It is often referred to as corporate social responsibility and
includes consideration for:
o the environment
o the community
o diversity
o charity work
o global issues.
Relationship between the project and broader organisational strategies and goals
The project should have been conceived as a result of the organisation’s strategic plan and mission
statement. It will also be related to the market focus of the organisation. The whole project will be
governed by the values and ethics of the organisation, for example, if the organisation is committed
to improving environmentally sustainable working practices a constraint placed on the project may
be that all resources must be locally sourced. In many ways, all of the broader organisational
strategies are intrinsically linked because they reflect the ideology and beliefs of the organisation.
The project is an extension of these goals thus all project activities must reflect all of them wherever
possible.
It is important that the project team, if external to the organisation, must understand the broader
organisational strategies and goals in relation to the project and keep them at the forefront of their
minds throughout the life of the project. The project governance plan will ensure that this is
monitored carefully at all stages in the life cycle of the project.
If the project stakeholders, including investors and sponsors, are new to the organisation, they
should also understand and agree to the organisational strategies, mission statement and values and
ethics. Discrepancies at the beginning of the project over these issues will cause much greater
problems later on in the project. If stakeholders do not buy in to the overall aims of the organisation
you should seriously question their inclusion within the project.
If the project has been initiated to bring about a change in organisational strategies and goals, such
as to expand into a different market area or to introduce a new form of corporate social
responsibility in a venture to employ groups of disadvantaged people in a new store in the local
area, for example, the strategy plan and mission statement must be changed to reflect this in order
to keep the project in line with the organisational goals.
BSBPMG521 LEARNER GUIDE 17 | P a g e Version 3.0
1.3 Negotiate and document project objectives, outcomes and benefits
Project objectives
The project objectives are the reasons for completing the project and the result of the project
activities. As you know, a project is initiated because a function of the organisation is
underperforming, or a new function needs to be implemented, a number of activities may need to
be undertaken during the life of the project in order to reach the objective. The project activities are
not the objectives, for example an objective may be to increase the customer base in a specific
ethnic minority, the subsequent advertising and promotional project activities are not the
objectives.
Project objectives can be split into three sections:
 Main objective – the main reason(s) for doing the project
 Additional objectives – indirect results/benefits to the
organisation/community/stakeholders as a result of completing the project
 Non-objectives – side effects from the project that may be expected as a result of
completing the project but that will not happen, for example by installing a new
technology system, stakeholders may expect production costs to be reduced but
this will not happen as the objective was to improve the quality of the product.
Each objective should be clearly stated with no technical jargon or acronyms that could cause
confusion amongst team members. Each objective should have a measure attached to it in order to
monitor and evaluate progress throughout the life of the project. Objectives may be short or long
term and you must remember to include all objectives otherwise they will not be completed.
As with all targets you set, the objectives must be SMART:
 S – specific, significant
 M – measurable, meaningful
 A – attainable, achievable, acceptable, actionoriented, agreed upon
 R – realistic, relevant, reasonable, rewarding,
results-oriented
 T – time-based, time-bound, timely, tangible, trackable.
Specific
The objective is clearly defined and clear to all involved in the goal.
Measurable
There will be various indicators that track how much of the task is complete and clarity when it is
actually complete.
Attainable
There is no doubt that the objective can be achieved.
Realistic
Similar to attainable, but taking into account resources and ability of those involved.
Time-based
Sufficient time is set to achieve the objective, and not too long so time is not wasted.
BSBPMG521 LEARNER GUIDE 18 | P a g e Version 3.0
Project outcomes
The outcomes of the project are the impact that the project has on organisation and related
environments and domains. They could be changes to knowledge, actions and behaviour, and/or
conditions. Outcomes and benefits are the result of your work within the project and directly related
to the project objectives. It is worth bearing in mind that whilst you are planning your expected and
wanted outcomes and benefits, you may also encounter some unexpected and unwanted outcomes
that are detrimental as opposed to beneficial.
There is a fine line between objectives and outcomes; the aim of the project is the change you want
to realise, the objectives are the methods in achieving the change and the outcomes and benefits
are the changes themselves.
Outputs are the tangible products or services that are created as a result of project activities and are
much easier to measure and quantify than outcomes and benefits but may not have an impact the
desired impact on the outcomes.
Project benefits
Benefits are the positive impacts an organisation enjoys as a result of project outcomes. There are
two different types of benefits; hard and soft benefits.
Hard benefits include:
 Improved/increased production
 Improved collaboration within organisation
 Improved awareness and attitude of the team within
the organisation
 Improved skills and knowledge within the organisation.
Soft benefits include:
 Catalyst for further change within the organisation or industry
 Improvement in image and reputation of the team funding the project
 Improvement in image and reputation of the organisation
 Improvement in image and reputation of the project management team.
Benefits start to occur in the initial planning stages, develop during the life cycle of the project and
continue long after the project has been completed.
Why are benefits important?
Benefits are important in all stages of the project for a number of reasons.
In the initiation stage of the project, expected benefits can:
 Strengthen the project bid for investment
 Help to create a way of measuring effectiveness of the project
 Create investment from employees and other stakeholders in terms of buying into
the project.
During the execution of the project benefits can:
 Form part of the project management plan in terms of time scales and milestones.
BSBPMG521 LEARNER GUIDE 19 | P a g e Version 3.0
On the completion of the project benefits can:
 Assist in the completion of the final report and evaluation
 Establishes long term goals for the organisation to improve and develop benefits
 Be used to evaluate and improve the balance of investment with benefits.
Benefits management
Benefits are not automatically achieved at the conclusion of the project, they may take place over a
period of time. There is a danger that you deliver a successful project but the real benefits are never
realised because the change the project was designed to make does not get embedded within the
organisation because the project is complete and the project management team has moved on to
another project. For example, if a complex technology system is implemented into an organisation
that completely changes the way in which the whole organisation produces its products but only a
handful of employees out of 3,000 understand how to operate it, the benefits are unlikely to be
realised, at least not in the short term.
Benefits management should be included as part of the project plan and should be considered in the
initial stages and in negotiations when determining the project objectives, outcomes and benefits.
Benefits management includes considering the following actions after the project is complete:
 Carrying out demonstrations and presentations
 Delivering workshops and training
 Preparing marketing materials
 Organising product and service launches
 Arranging and chairing meetings
 Finding creative solutions to problems
 Championing the cause
 Driving change.
Project objectives, outcomes and benefits may include:
 Expected benefits to be achieved for organisation and business
 Measurable project product statement
 Short and long-term outcomes for the organisation.
Negotiate project objectives, outcomes and benefits
You need to consult with your stakeholders to determine their suggestions and expectations for the
project objectives, outcomes and benefits. Stakeholders are people or groups of people that have a
genuine interest or concern in an organisation.
Stakeholders can include:
 Clients
 Employees
 Directors
 Shareholders
 Investors
 Creditors
 Suppliers
BSBPMG521 LEARNER GUIDE 20 | P a g e Version 3.0
 Contractors
 The community served by the organisation.
Frequent and appropriate engagement with all involved is essential to the smooth running of the
project as it is their interest, and most crucially their funding in terms of the client, investors and
sponsor, that will keep the project going. Without valued input into the objectives they may get
disheartened with the project management team and pull their investment.
The expectations and suggestions received from each stakeholder and/or client will be different
depending on their interest and level of authorisation. The suggestions and expectations of clients
and investors may be idealistic and those of employees and the community may be more pragmatic.
All are valid and should be taken into consideration when determining the project objectives,
outcomes and benefits.
In an ideal world the project objectives, outcomes and benefits will be readily and happily agreed by
all key stakeholders. Unfortunately, it is not an ideal world and you will often have to go through a
series of negotiations in order to arrive at an outcome agreeable to all parties.
There may be specific aspects to the objectives, outcomes and benefits that stakeholders are
absolutely adamant must be included. You may also have conditions from which you will not budge
that may have arisen from previous successful projects. This is where negotiations occur.
Good negotiators
Negotiating is a skill that can take a long time to perfect with the ideal outcome being a win-win
solution for both parties. It is a process that can take a long time.
Best practice for negotiations:
 Identify the factors upon which each stakeholder is insistent
 Identify areas for negotiation on all sides
 If you do not have the authority to make decisions upon negotiations within your
project, identify who is and what information they require from your negotiations
to make an informed decision
 Identify the decision-maker for each stakeholder (if there is more than one person)
and try to deal directly with them from the start of negotiations so as not to waste
time trying to negotiate with someone who has no authority to make decisions
 Identify with whom the balance of power lies in terms of bargaining strength
between the stakeholders and the project team – which has more evidence for
their case than others?
 Be prepared for all eventualities when you enter negotiations with stakeholders so
you are not caught off guard
 Always use reliable facts and figures that are accurate and cannot be questioned
 Prepare an agenda prior to the meeting and ensure all members of your team are
briefed and provided with sufficient information so as not to compromise the
negotiations
 Start with a wide ranging proposal as opposed to small details to leave plenty of
room for manoeuvre
BSBPMG521 LEARNER GUIDE 21 | P a g e Version 3.0
 Do not continue the meeting if communications or negotiations are breaking down
– call a recess or rearrange the meeting for another time
 Be fair and reasonable
 Ensure all negotiations are documented and recorded clearly, and wherever
possible signed by all parties, so that you have an audit trail and an accurate record
of the agreement should it be disputed at a later date.
A successful negotiation should result in all parties feeling confident and happy with the outcome.
BSBPMG521 LEARNER GUIDE 22 | P a g e Version 3.0
1.4 Negotiate project governance structure with relevant authorities and
stakeholders
Project governance
Broadly speaking, project governance refers to the rules and regulations used to run a successful
project and puts in place procedures to ensure compliance with these standards for the smooth
running of the project. The rules and regulations will correspond with the project objectives and be
in line with any relevant industry standards and/or regulatory measures and legislation.
Project governance provides a framework that establishes the following:
 Management system with designated personnel and their roles and responsibilities
to include:
o boards
o committees
o working groups
o reference groups
o advisory groups, sponsors
o project managers
o project team members
o stakeholders
 Statements of roles for project management bodies and participants
 A decision-making framework which includes a code of ethics
 Identified authority levels assigned to groups and individuals
 A stakeholder management strategy
 A quality management strategy
 A project organisation chart that clearly defines the relationship between all
persons involved in the project
 Procedures and criteria for reporting on project status and key performance
indicators
 A monitoring and evaluation procedure for progress of project against project
objectives
 Procedures for obtaining approvals for project activities
 Procedures for managing risks and uncertainties
 Procedures for managing change
 Issue-escalation procedures
 Conflict resolution models.
It is important to separate the project organisation chart from the structure of project governance.
The organisation chart sets out each team member’s role and responsibilities and the management
structure of daily project activities, or what needs to be achieved, whereas the project governance
structure identifies how these activities should be achieved.
Steering group
The steering group, or committee, is a group of people that decides upon the priorities of an
organisation or a project. They are often made up of a number of stakeholders with wide ranging
interests in, knowledge of, and expertise in the project in order to make balanced decisions
BSBPMG521 LEARNER GUIDE 23 | P a g e Version 3.0
throughout the life of the project. It may be that the steering group determines and implements the
governance plan.
A typical steering group consists of:
 Senior management
 Employee representative
 Trade union representative
 Work health and safety manager
 Human resources representative
 Occupational health person
 Line manager.
The expectations of each stakeholder and/or client will be different depending on their interest and
level of authority. Clients and investors may have higher standards for the governance of the project
because they are funding it and they may require a more frequent and detailed flow of project
information than an employee, for example, and may also require more authority in decision-making
processes. Employees may suggest procedures and processes that could be used in the governance
of the project that had not been thought of by management. Trade union representatives may insist
on specific industry standards or regulations as part of the governance plan. All expectations need to
be considered to form a balanced governance plan.
Depending on the size and scale of your project there may be more than one body involved in the
project governance hierarchy:
 Project team – including general workers, line managers, supervisors and middle
management
 Project management – deals with compliance to project governance on a practical,
day to day basis such as logistical issues, conflict resolution, communications,
progress reports and may include managers of:
o overall project
o communications
o procurement
 Project governance – determines the project governance plan and oversees
compliance of project activities to the plan through reports from the project
management team. Groups may include:
o steering committee – responsible for reviewing the progress of the project at
specified intervals to ensure compliance to project governance plan. Guide
and approve changes to the project activities through governance policies
o business committee – provide specific industry and business related guidance
to the project team to ensure project activities comply with governance
policies
BSBPMG521 LEARNER GUIDE 24 | P a g e Version 3.0
 Corporate governance – in large organisations with multiple outlets you may find
that governance is ultimately overseen by another group which may seem far
removed from project activities and may include:
o shareholders
o investors
o board of directors
o sponsor
o regulators
o creditors.
Organisational governance policies and procedures
Organisational governance policies and procedures may include:
 Acceptable language and terminology – detailing procedures for dealing with team
members who cause offence by using expletives, profanities or derogatory
terminology
 Financial delegations – establishing who is responsible for specific financial
decisions and budget approvals, and the procedures used to make these decisions
 Formal authority levels – clearly defined levels of authority held by individuals and
in relation to what within the project
 Frameworks and methodologies – there are a number of different project
governance methodologies available that set out their own governance themes and
principles, including:
o PRINCE2 – Projects in Controlled Environments – specifically developed for
project governance in the IT industry
o PMBOK – Project Management Body of Knowledge
o Agile
o MSP – Managing Successful Programmes
o PMO – Project Management Office, based largely on the principles of
PRINCE2 and PMBOK
o MSF – Microsoft Solutions Framework
o MoV – Management of Value
 Quality-management requirements – how the organisation evaluates quality in
different areas of the project such as:
o customer satisfaction
o resources used including supplies and work force
o contracts
o suppliers/vendors
o procurement
o communications
o efficiency of project activities
o environmentally sustainable working
practices
o value for money
BSBPMG521 LEARNER GUIDE 25 | P a g e Version 3.0
 Preferred organisational models – the project governance hierarchy (see diagram
below for an example).
This governance model is taken from the Duraspace website at
https://wiki.duraspace.org/display/VIVO/Project+Governance
Roles and responsibilities
Project governance roles and responsibilities may include:
 Financial delegations
 Reporting lines
 Subordinates
 Task descriptions
 Team culture values.
Financial delegations
It will come as no surprise that making effective financial decisions is vital to the success of a project
regardless of how small or large it is. When planning project governance roles and responsibilities
for procurement activities you must bear in mind that all financial procedures must be accurate and
transparent for auditing purposes.
Keeping accurate, honest, and up to date records of all business activities is essential for reporting,
confidentiality and audit requirements. It allows managers and owners to ensure that policies and
procedures are being followed by employees and also allows identification of areas for improvement
to make the business more efficient.
BSBPMG521 LEARNER GUIDE 26 | P a g e Version 3.0
It is even more important in procurement because essentially the procurement team is spending the
organisation’s capital which has an impact on the bottom line. Where financial activities are
concerned, all reporting and auditing processes have to be followed to the letter to avoid any fraud
or other wrongdoings. Any anomalies within procurement activities will be easily highlighted during
an audit. It is therefore vital that decision making and approvals for all procurement activities are
assigned to the right delegate(s).
Things to consider when assigning financial delegations:
 Ethical behaviours within procurement, such as:
o managing all business relationships with respect, honesty and integrity
o avoiding causing harm to others as a result of business decisions
o treating all stakeholders fairly and impartially
o not discriminating or favouring in supplier selection
o actively supporting, promoting and leading in corporate social responsibility
o employing procurement strategies that help to eliminate unethical practices
in the supply chain
o making procurement decisions that consider the impact on the environment
o embedding ethical policies and procedures within
procurement processes
o keeping employees appraised of expected ethical
behaviour involved in supplier selection
o ensuring procedures are in place to report unethical
practices and behaviours

o	reporting any unethical business practices such as:
   	bribery fraud corruption abuse of human rights such as modern slavery and child labour

 Limits of authority – your governance model or hierarchy structure will probably
already have bestowed specific authorities upon each rank or level of seniority. In a
large project there may be a number of different limits of authority which may
include the project manager, finance department and the CEO, whereas in a smaller
project all decisions about procurement might be made by the project manager
only. You may decide to assign procurement officers a monetary limit of authority
for making procurements without obtaining approval, and for any procurements
over this limit they will have to seek authority from a more senior financial
delegate. The designated limit will depend upon the scope of your project
 Organisational policies and procedures – all organisations have in place set policies
and procedures that must be adhered to for all business practices but they are
exceptionally important in any financial activity as all accounts are audited and must
not breach any legal requirements
 Prescribed decision escalation – similar to limits of authority in financial spending,
some decisions about procurement will have be made by designated persons. The
types of decisions will vary according to each project and the authorities held by
each member of the team
BSBPMG521 LEARNER GUIDE 27 | P a g e Version 3.0
 Compliance with Australian Standards – compliance of products and services with
Australian Standards is voluntary unless regulated by the government. Industries
that are regulated by the Australian Competition and Consumer Commission (ACCC)
on behalf of the government include:
o airports and aviation
o communications
o energy
o fuel
o postal services
o rail
o water
o waterfront and shipping
o wheat export.
For more information on products and services regulated within these industry sectors visit the
ACCC website at: https://www.accc.gov.au/regulated-infrastructure
Reporting lines
When assigning roles and responsibilities for reporting lines you will need to liaise with the
communications manager as the communications team will be instrumental in preparing and
delivering reports to relevant stakeholders. The communications plan should be determined in close
collaboration with project governance policies and procedures.
Project reports
During the life of the project there will be a number of reports to prepare, produce and release for
different aspects of the project and for different stakeholders which must be taken into account
when negotiating roles and responsibilities for reporting lines.
Reporting lines need to be established for the following project reports:
 Project status reports – this report details the progress of the project including:
o current status
o next steps necessary to move the project along
o any obstacles or problems that are preventing progress
o key metrics of the project
 Risk register – self-explanatory, the risk
register is an ongoing document that reports
the following:
o potential risks to the life or progress of
the project
o the extent of the potential negative
impact on the project caused by the
risks
o contingency plans to deal with the risks
BSBPMG521 LEARNER GUIDE 28 | P a g e Version 3.0
 Issue log:
o a document that reports and records risks that have been realised and
unexpected events that have occurred and interrupted the project
o it documents the way in which the incident has been dealt and the impact it
has had on the project
o the accuracy of these reports is important for auditing purposes
 Executive summary – a detailed report that provides in depth information about the
status of the whole project and the impact it is envisaged to have on the bottom
line of the organisation
 Everything else report – these reports are specific to each individual project and can
be about anything and everything associated with it.
Subordinates
Subordinates are the people that make up the project team; the employees, the contractors, the
subcontractors, and possibly volunteers, and are the people who get the job done. They may consist
of general assistants, team leaders, middle managers and departmental managers, depending on the
size of the organisation. They may be outsourced third parties. It is important that each member of
the project team has their role and responsibilities made clear to them at the start of the project.
Organisation chart
An organisational chart is a diagram that depicts the structure of an organisation in terms of
authority and hierarchy. It also demonstrates the relationships between each member of the
organisation. They are usually pyramid shape with the director at the top followed by senior
management, middle management and employees at the bottom. People are usually denoted by a
rectangle; the bigger the rectangle the more authority that person has. An organisational chart can
be used to map out roles and responsibilities of each member of the project team and each
department if your project is on a large scale. It might be that you have more than one
organisational chart for different functions within the project.
BSBPMG521 LEARNER GUIDE 29 | P a g e Version 3.0
This organisational chart is taken from the website of the University of Saud:
http://pharmacy.ksu.edu.sa/en/pages/departments/quality/?page_id=16
Work breakdown structure (WBS)
A WBS is a way of breaking down the project into smaller, manageable sections in order to identify
the resources needed for each activity and to allocate roles and responsibilities for each project
team and member. Making it a visible diagram, like the organisational chart above, ensures that
subordinates know their own roles and responsibilities. It also enables you to identify potential risks
in each section and put in place contingency plans should the risk be realised.
Task descriptions
Within a project task descriptions could be written for a variety of purposes including:
 Specific project activities
 Evaluations and reporting on project activities and progress
 Job descriptions for individuals that determine their roles and responsibilities
including all stakeholders
 Task descriptions for use on requests for quotation, proposal, or tender in order to
furnish potential suppliers with sufficient information about the brief.
Deciding who should write each task description should take into account their knowledge on the
subject and their authority within the organisation. For example, a procurement officer would not
write a task description for the communications team.
Team culture values
Determining and promoting team culture values is an
important role within a project team to ensure that each
member of the team is working towards common goals with
the same positive work ethic. The team culture values can also
be described as a code of conduct or business ethics which
determines the expectations of acceptable behaviour and
underpins the core values of the organisation.
Business ethics are the moral principles that govern an organisation to ensure corporate
responsibility, quality assurance and customer satisfaction. When combined, a code of conduct and
business ethics defines the morality of an organisation and sets the standard for the behaviour and
work ethic of its members. It should incorporate that all members of the organisation will be given
equal opportunities and treated equally and fairly regardless of any differences.
A code of conduct and business ethics policy will normally be a written document that can be easily
accessed by all members of the organisation. It should form part of the induction process for all new
employees and be used for existing employees for refresher training at regular intervals.
A code of conduct and business ethics policy must be enforced consistently if it is to have any effect
or if it is going to be valued by those it governs. If employees that breach the code in any way are not
dealt with accordingly, other employees will have no faith in the system and may lead to increased
unethical behaviour.
BSBPMG521 LEARNER GUIDE 30 | P a g e Version 3.0
Determining team culture values
When deciding upon what the team culture values will be, the team must be consulted and be an
integral part of establishing and agreeing on the values. If the team culture values are not their own
based upon their own experiences in the workplace and do not reflect what they believe to be
important, they will have a negative and demotivating impact on the workforce. The person tasked
with establishing and promoting the values should be someone in authority but in touch with the
project team at ground level whom the team respects and should embody all of the core values
important to the team.
Team culture values will vary according to each organisation but general values include:
 Accountability and responsibility for own actions
 Integrity
 Respect
 Maintaining healthy work-life balance
 Collaboration and empowerment
 Quality
 Community, embracing diversity, equal opportunities for all
 Innovation, continuous improvement, efficiency
 Team is valued by management.
Negotiating project governance structure with relevant authorities and
stakeholders
Determining the project governance structure should be done with relevant authorities and key
stakeholders to ensure the structure implemented is clear and unambiguous and agreed to by all.
Relevant authorities may include:
 Project management team
 Departmental managers such as finance and human resources
 Senior management
 Sponsor, investors, shareholders
 Steering group
 Project governance team
 Corporate governance team
 Regulatory bodies
 Industry standards.
In an ideal world the project governance structure upon which you have decided will be readily and
happily agreed by the relevant authorities and stakeholders. Unfortunately it is not an ideal world
and you will often have to go through a series of negotiations in order to arrive at an outcome
agreeable to all parties.
There may be specific aspects to the project governance structure that the authority is absolutely
adamant must be included and you may also have conditions from which you will not budge. This is
where negotiations occur.
BSBPMG521 LEARNER GUIDE 31 | P a g e Version 3.0
1.5 Prepare and submit project charter for approval by relevant authorities
Project charter
The project charter is a critical document for all projects, however big or small. It describes the
project, outlines the intended approaches, and documents all the stakeholders involved. It is integral
to the initiation and planning stages of the project and will be referred to throughout the life cycle of
the project. It acts as a contract between all stakeholders and once it has been agreed it cannot be
changed without agreement from all stakeholders.
The project charter is the starting point for project planning by drawing together all of the vital
information that will guide the project to completion.
The project charter includes the following information:
 Business plan – why the project is necessary in relation to organisational needs and
broader organisational strategies and goals and why it is needed now
 Scope – a scope statement is a written document that sets out the limits of the
project to which all that are involved agree, prior to the project beginning and may
include:
o justification – why the project is necessary
and valid
o deliverables – what the project will
produce
o acceptance criteria – conditions to which
the project and all those involved must
adhere for the completion of the project
o project exclusions – what the project will
not do or produce
o constraints – any envisaged issues that
may hinder the project
o assumptions – how anomalies within the life of the project will be addressed
 Documented objectives – negotiated and documented in chapter 1.3, the project
objectives must be sufficiently detailed, unambiguous, and in line with broader
organisational strategies and goals
 High-level product deliverables – in high-level project management, the senior
management team expect to be kept informed of progress. The project manager
should be reporting on interim product deliverables throughout each stage of the
project, not just the final deliverable on completion
 Resources needed – all the resources required for the project including materials,
the work force, and specialist support such as permits and licences. The cost of all
the resources needs to be as accurate as possible at this stage as this will form the
vast majority of the budget
 Timeline – this will be the most difficult piece of information to get right and time
should be afforded for problems and delays. The time frame will also quite probably
change as the project gets going
BSBPMG521 LEARNER GUIDE 32 | P a g e Version 3.0
 Estimated cost/budget – costs include materials, labour and anything else the
project requires. At this stage it is important to identify hidden costs if possible. If
estimates are wildly inaccurate the life and completion of the project may be
jeopardised
 High-level risk assessment – risks vary from project to project and could be minor
and major depending on the nature of the project. If any legislation applies to the
project this should be assessed in detail. You may consider using a risk management
project management methodology. You should have in place a changes and risk
management policy and procedure. A high-level risk assessment should be
conducted by senior management and they will need to be kept up to date with all
potential risks throughout the life cycle of the project
 Dependencies – these are the relationships between tasks within the project in that
if one task is not complete, another cannot begin, for example a roof cannot be
erected on a house before the walls have been built. It is essential that all
dependencies are considered at the initial stages in planning as they can cause
serious delays and expense if they are not planned correctly
 Project assumptions and constraints – how anomalies within the life of the project
will be addressed and any constraints, either wanted or unwanted, imposed on the
project, for example the stakeholders may have agreed that 50 per cent of all
energy used in the project must be provided by green energy suppliers
 Indicators of success – how are you going to measure the successes within the
project? What milestones are you going to use?
 Broad stakeholder identification and their respective roles and responsibilities – an
organisation chart should be used to identify each stakeholder and their level of
authority within the hierarchy, and a work breakdown structure to detail the roles
and responsibilities of each project team member
 Consolidated project initiation documentation (PID) – all initial project
documentation that was gathered in chapter 1.1 will have been put together in one
document to form the PID. The PID details all the major aspects of the project and
the way in which it will be managed. The PID is the document that is sent up to
senior management and stakeholders for approval and sign off before the project
can begin. Some smaller projects may not use a PID, preferring to use the project
charter as the document that governs the management of and approach to the
project. A PID typically contains the following information about the project:
o project goals
o scope
o project organization
o business case
o constraints
 Approvals and sign-off – details that determine the delegated authorities for
approvals within the project such as procurement activities and methods of
BSBPMG521 LEARNER GUIDE 33 | P a g e Version 3.0
communication, and designated authority for signing off activities, stages and
completion of the project
 Project mandate – this is the document that triggered the starting up of the project.
It is written by the organisation and/or sponsor commissioning the project and
details the reasons for and objectives of the project, estimating costs and time
scales, to assure key stakeholders that the project is justifiable and that it will be a
rewarding venture
 Source of project authority – the charter should set out a structured management
hierarchy that determines who is the owner of the project and who are the
delegated authorities for decision making.
Preparing and submitting the project charter
Some project charters are incredibly short containing only basic essential information. Others are
much more detailed. The organisation will determine the length and the content required in you
project charter and will probably have a standard template on which to document it. The
organisation will also determine to whom the project charter must be submitted for approval and
the method of and deadline for submission.
BSBPMG521 LEARNER GUIDE 34 | P a g e Version 3.0

Project Charter
Project name
Authorisations	Name	Function	Date	Signature
Author	Project manager
Approved	Project sponsor
Project context and background
Stakeholders
Expected benefits
Proposed start date	Proposed end date
Project objectives
Deliverables
Scope
Includes
Excludes
Success criteria
Methodology
Resources
Steering group
Sponsor
Project manager
Project team
Other
Estimated costs
Issues and risks
Assumptions
Constraints and dependencies
Approvals and sign off
Reporting	Frequency	Who?
Meetings
Steering committee	Steering Co and PM
Project team	PM and project team
Reports
Progress reports	Sponsor and steering co
Closure report	Sponsor and steering co

BSBPMG521 LEARNER GUIDE 35 | P a g e Version 3.0
Section 2 Undertake project planning and design processes
2.1 Establish and implement a methodology to disaggregate project
objectives into achievable project deliverables
Project deliverables
You have determined your project objectives and you now need to break them down in order to
identify achievable project deliverables. Deliverables are the tangible products and/or services
produced by the project, also known as outputs. Each objective must have at least one deliverable
relating to it. If an objective has no associated deliverable you must question the importance and
relevance of that objective. You may find that you discard that objective or identify another
deliverable to satisfy it. Equally, each deliverable must meet an objective; again, if it doesn’t, is it
really necessary to the project? If you believe that the deliverable is crucial to the project but there
is no associated objective in the project charter, it might be that you have missed a crucial objective
and further discussions with key stakeholders will need to take place.
Project deliverables may include:
 Definable product, service or document
 Discrete components of the overall project outputs
 Specified products of the project
 Time, quality and cost.
Disaggregate project objectives into deliverables
The easiest way of breaking down project objectives into
understandable and achievable project deliverables is to
complete a work breakdown structure (WBS). A WBS is a
deliverable-based hierarchical structure that breaks
down the objectives into the deliverables and subdeliverables required to realise the objectives. It
resembles an organisation chart but deliverables replace
the names and roles of employees. A WBS should not be
confused with a project schedule which documents the
project tasks and activities required to produce the
deliverables. A WBS is a simple document that
determines the deliverables only. In doing so it maps out
the scope of the project by only containing deliverables
that are within the scope; any out-of-scope and
unnecessary deliverables will cause confusion and waste
project resources. It is therefore important that you
check the alignment of deliverables with objectives.
The following work breakdown structure is taken from www.matchware.com:
http://www.matchware.com/en/example/wbs-template-construction-of-a-house-del.htm
BSBPMG521 LEARNER GUIDE 36 | P a g e Version 3.0
Notice that all deliverables are relevant and crucial to the overall objective; the construction of a
house. There are no other deliverables within the structure that are irrelevant. It is a simple
structure, but quite clear and all deliverables are in alignment with the objective.
Achievable project deliverables
You may need to consult with specific members of the project team to determine realistic
deliverables because you may not have the expertise and/or knowledge to understand what subdeliverables are required for each main deliverable. By consulting in the planning stages you ensure
that all necessary deliverables are identified before work begins. You may also wish to consult
lessons learned reports and other documentation from previous similar projects about the
deliverables employed and how effective they were on the success of the project.
Deliverables also concern the outcomes and benefits you determined in chapter 1.3. Bear in mind
when consulting with stakeholders about their expected deliverables, that their expectations are
relevant to the project’s objectives and not just beneficial to them.
Before completing your work breakdown structure you need to ensure the deliverables you have set
are realistic and achievable. As with all goals and targets you set, deliverable have to be SMART;
specific, measureable, achievable, realistic and to an agreed time frame. The completion of subdeliverables will impact on the main deliverable as each sub-deliverable must be complete for the
deliverable to be complete. You may also find that deliverables impact on others, not necessarily in
terms of one depending on another for materials but for resources, both human and technological.
BSBPMG521 LEARNER GUIDE 37 | P a g e Version 3.0
2.2 Identify project stages and key requirements for stage completion against
client requirements and project objectives
Project stages
It is generally accepted that there are five stages in project management which are:
 Initiation
 Planning and design
 Execution
 Monitoring and controlling
 Closing.
Some organisations will include a stage before the initiation stage called the definition in which the
reason for the project is documented and the scope is set; this is normally included within the
initiation stage. You may also have additional stages that are unique to your project.
Stage completion
All aspects and requirements in each stage must be completed, and usually signed off by a delegated
authority before the project can progress to the next stage. The specific key requirements for stage
completion within your project will be determined by client expectations and the project objectives
and will vary the most between one project to another in the execution and controlling stages as
project activity is unique to each project.
Generic key requirements for completion of the initiation stage are:
 Consolidation of project initiation documentation
 Feasibility study
 Assignation of a project manager and team
 Project scope
 Project charter.
Generic key requirements of completion of the planning and designing stage are:
 Reviewing and revising the scope if necessary to prevent “scope creep” which is
where the parameters of the project expand without making relevant changes to
budget, time frame, resources etc.
 Work breakdown structure
 Organisational breakdown structure
 Resource allocation:
o roles and responsibilities
o budget allocation
o materials and human resources required
 Project schedule:
o milestones
o time frames
o reporting and meeting schedules
o who is responsible for what tasks
 Budget allocation
BSBPMG521 LEARNER GUIDE 38 | P a g e Version 3.0
 Governance plan which would include:
o Procurement management plan
o Communications management plan
o Change and issues management plan
o Issues escalation plan
o Conflict resolution/relationships management plan
 Risk assessment
 Finalising the plan and obtaining approval.
Generic key requirements for completion of the execution stage are:
 Time management – the project manager ensures that all tasks are being
completed according to the project schedule
 Cost management – the PM ensures that all activities have been completed
according to allocated budgets
 Quality management – the PM ensures that the deliverables meet the required
quality standards of the stakeholders
 Change and issues management – the PM ensures that any changes or issues are
dealt with effectively and efficiently so as not to impede the success of the project
 Relationships management – any problems between any members of the project
team, including employees, stakeholders, management, suppliers, and contractors,
are resolved without impeding the progress of the project.
Generic key requirements to the completion of the monitoring and controlling stage are very
similar to the execution stage as they run concurrently. They include:
 Monitoring and reviewing all of the processes in the execution stage
 Identifying and preventing risks
 Minimising changes to the project.
Generic key requirements to the completion of the closing stage are:
 Producing a closing report that includes:
o sign off
o budget analysis
o schedule analysis
o releasing project staff
o lessons learned from the
project
o overall outcome of the project
 Redistribution of resources and/or
equipment used in or leftover from
the project
 Completing any relevant administrative work for the project
 Recording any next steps for the next or future projects.
BSBPMG521 LEARNER GUIDE 39 | P a g e Version 3.0
Client requirements and project objectives
For each of these requirements, your client will probably want to attach additional constraints
before the stage can be deemed as complete and signed off in order for the next one to begin. For
example, in the closing stage, and equipment leftover from the project that is still fit for purpose
may be required by the client to be disposed of as waste. The project objectives, however, may
include a goal to improve environmentally sustainable working practices, and therefore suggest that
the leftover equipment should either be recycled or donated to a charitable organisation.
Negotiations may have to take place in these situations.
Initiation stage

Generic requirement	Client requirement	Project objective issues	Agreed outcome
Consolidation of PID
Feasibility study
Assignation of a project manager and team
Project scope
Project charter
Other

BSBPMG521 LEARNER GUIDE 40 | P a g e Version 3.0
Planning stage

Generic requirement	Client requirement	Project objective issues	Agreed outcome
Review and revision of scope
Work breakdown structure
Organisational breakdown structure
Resource allocation

BSBPMG521 LEARNER GUIDE 41 | P a g e Version 3.0

Generic requirement	Client requirement	Project objective issues	Agreed outcome
Project schedule
Budget allocation
Governance plan

BSBPMG521 LEARNER GUIDE 42 | P a g e Version 3.0

Generic requirement	Client requirement	Project objective issues	Agreed outcome
Risk assessment
Finalising the plan and obtaining approval
Other
Other

BSBPMG521 LEARNER GUIDE 43 | P a g e Version 3.0
Execution stage

Generic requirement	Client requirement	Project objective issues	Agreed outcome
Time management
Cost management
Quality management
Change and issues management
Relationships management

BSBPMG521 LEARNER GUIDE 44 | P a g e Version 3.0
Monitoring and controlling stage

Generic requirement	Client requirement	Project objective issues	Agreed outcome
Monitoring and reviewing all processes in execution stage
Identifying and preventing risks
Minimising changes to project

BSBPMG521 LEARNER GUIDE 45 | P a g e Version 3.0
Closing stage

Generic requirement	Client requirement	Project objective issues	Agreed outcome
Producing closing report
Redistribution of resources
Administrative work
Next steps for future projects

BSBPMG521 LEARNER GUIDE 46 | P a g e Version 3.0
2.3 Analyse project management functions to identify interdependencies and
impacts of constraints
Project management functions
All projects, however large or small, need to be managed through nine integrating functions in order
for the project to be successful. In small projects, the project manager may be responsible for all
nine functions whereas in large scale projects there may be separate managers for each of the
functions and the project manager will usually be responsible for project integration, ensuring that
all functions run smoothly together as per the project schedule. In this chapter you need to analyse
your own nine project functions to identify how each depends on the other and how each is affected
by the triple constraints.
The nine project management functions are:
 Communications
 Cost
 Human resources
 Procurement and
contracting
 Project integration
 Quality
 Risk
 Scope
 Time.
Communications
Communications is the life blood of a project as everyone involved needs to know exactly what they
should be doing and when, and how their roles and responsibilities feed into the project as a whole.
Risks, issues and changes need to be communicated through the appropriate channels in a suitable
and timely manner, and stakeholders need to be kept updated on the progress of the project. This
chapter asks you to identify interdependencies within the nine project functions and communication
has an integral role to play across all functions. It is thought that a project manager spends 80 per
cent of his time communicating to the project team and key stakeholders.
A communications strategy may include:
 List of which team member is responsible for particular communication activities
 Methods and protocols for communicating information which may include:

o	verbal communication:
    	on site in person at meetings informal briefings over the telephone/internet/video conferencing press conferences

BSBPMG521 LEARNER GUIDE 47 | P a g e Version 3.0

o	written communication:
         	email letters invoices purchasing orders legal applications update reports audits inventories newsletters advertisements

 Which stakeholders need what information and their responsibilities within the
communication flow
 When information is communicated – the frequency of regular forms of
communication throughout the life of the project
 How sensitive and confidential information is handled taking into account the
Privacy Act 1988
 Potential constraints affecting the flow of communication
 The resources allocated to communication
 Standard forms or templates for specific forms of communication
 A procedure for channels of communication hierarchy
 Processes for resolving any communication based conflicts or issues
 Communications networks and their uses.
Cost
Project cost management is a dynamic function that is incredibly difficult to manage accurately,
particularly if the duration of your project is extensive. Estimates for project costs start out very
broad in the initiation stages because you simply do not know how much the project is going to cost
until it gets underway and the deliverables start being produced; you cannot predict the future and
you do not know what situations may change or what issues may occur and the costs they incur.
A good estimate will contain the following:
 Defines the objectives of the project and what it will
accomplish
 Any assumptions made such as that the project will
be completed in four months from June to September
 For how long the estimate is valid
 How much the project will cost based on current
information and a budget range
 Honest and transparent information so that all
stakeholders are aware of all estimated costs up front
 Any potential hidden costs.
BSBPMG521 LEARNER GUIDE 48 | P a g e Version 3.0
The problem with estimating the cost of the project is that each project is unique and it is impossible
to state accurately how much something that has never been done before will cost. Factors change
during the life cycle of the project such as time schedules, resource allocation and vendors’ prices
which alters the estimated cost of the project; the estimate may sometimes be less than originally
thought but it is usually more.
Cost management involves three different estimates:
 Rough order of magnitude (ROM) – this is an initial estimate in the initiation stage
of the project and should not be relied upon to be accurate. The range of this
estimate can be huge, from minus 25 per cent to plus 75 per cent, because it is just
unknown how much the project will cost in the early stages
 Budget estimate – this is a little more accurate than the ROM in that it formulates
the estimate from lessons learned from previous similar projects. The range of this
estimate is from minus 10 per cent to plus 25 per cent. It is a quick way of
formulating an estimate, but not very accurate as it is not really based on your
specific project
 Definitive estimate – this is the most accurate estimate but takes the most time to
formulate because it uses the work breakdown structure to estimate the cost of
each deliverable. It takes into account every resource that is required for producing
each deliverable including materials, labour, training, consultants, and any other
costs entailed. The range is much less than the other estimates, minus five per cent
to plus 10 per cent, because every deliverable within the project has been
accounted for. In a large project this will be a highly time consuming process but
will be worthwhile when presenting the estimate to key stakeholders.
As the project progresses the estimates will have to be reviewed and revised and it won’t be until it
is completed that the true cost of the project will be known.
Changes to estimates can occur for several reasons including:
 Changes in material costs
 Time schedules for completion of activities were wrong
 Bases for decisions were wrong
 Customer demands new deliverables
 Stakeholders change the scope of the project.
Changes to deliverables and scope are never a good thing for project cost managers because they
almost always require more money and the money has to come from somewhere. Changes also
have to be communicated to key stakeholders and the reasons given for the changes must be
justifiable in order to obtain more money from whichever pot is agreed. Change can be the downfall
of a project because there simply isn’t enough money to support it, particularly if the investors have
taken the ROM or the budget estimate to be hard fact.
Understandably, all of the other eight project functions have an impact on cost because they all cost
money.
Human resources
All projects need a team of people, called the project team, to realise the project. The human
resources manager is responsible for organising the project team and attending to their welfare.
BSBPMG521 LEARNER GUIDE 49 | P a g e Version 3.0
The project team needs to be:
 Recruited and acquired
 Trained where and when necessary and
records kept of courses undertaken and
qualifications obtained
 Organised into categories with designated
roles and responsibilities – an organisation
chart is a useful tool
 Motivated and empowered
 Kept updated with project news and information
 Performance managed including professional development plans
 Re-allocated to other project activities where necessary
 Kept safe and well according to Work Health and Safety legislation
 Treated fairly in alignment with anti-discriminatory legislation.
Procurement and contracting
The role of the procurement team is to purchase or acquire the best possible resources for the
lowest possible price and negotiate the supply contracts.
Procurement and contracting is concerned with the following aspects of the project:
 Acquiring and/or purchasing resources such as:
o land and property
o natural resources
o raw materials
o labour
 Ethical behaviour within procurement
 Determining supply contracts
 Compliance with Australian and International Standards.
Procurement is dependent upon all of the other eight project management functions.
Project integration
Project integration is the management of all project functions to ensure that the project runs
seamlessly and on schedule. The project manager is responsible for ensuring that each function
within the project is working to the project schedule and at an agreed standard, producing
deliverables to agreed time frames and quality. The project manager spends around 80 per cent of
his time integrating each of the eight other functions and reporting to key stakeholders on the
progress of the project. Any issues that arise must be reported to the project manager so that any
necessary adjustments can be made to the other functions. The task of project integration is not
easy as you have many acts to balance at all times.
Responsibilities of the project integration manager include:
 Development of the project initiation documentation and project charter
 Development of the preliminary scope
 Development of the project plan
BSBPMG521 LEARNER GUIDE 50 | P a g e Version 3.0
 Directing and monitoring the execution of the project
 Controlling the project
 Integrating any changes to the project
 Closing the project.
Evidently, all eight of the other project functions depend upon the project integration manager to
operate cohesively. The project integration manager must have full knowledge of all of the other
project functions and must have a firm grip upon their activities. Organisation is key to this role and
a number of tools and technologies will be used to maintain the smooth running of the project
including GANTT charts and a project management information system.
A Gantt chart is a visual representation of a project schedule that shows you what has to be done
within your project and when it needs to be done by. By laying out the project tasks and events in
the order they should be completed in, the Gantt chart helps to sequence those events and tasks. It
will show the project activities displayed against time and the time is broken down into increments;
days, weeks or months. To the left of the chart is the list of activities and along the top there is a
suitable time scale. The activities are represented by bars and the position and length of that bar
reflects the start date, duration and end date of each activity. This chart uses the horizontal lines to
show the amount of work that is done in certain periods of time in relation to the amount of time
that was originally planned for those periods.
A Gantt chart allows you to easily see:
 The start and end date of the whole project
 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 Gantt chart is the most common and easiest way to create dependencies and to show
predecessor and successor relationships.

W/C 1st	W/C 8th	W/C 15th	W/C 22nd	W/C 29th	W/C 6th
Briefing
Research
Writing
Editing
Distribution

 

Week 1	Week 2	Week 3	Week 4	Week 5
Task A
Task B
Task C
Task D
Task E

BSBPMG521 LEARNER GUIDE 51 | P a g e Version 3.0

Week 1	Week 2	Week 3	Week 4	Week 5	Week 6
Task A
Task B
Task C
Task D
Task E

 

Week 1	Week 2	Week 3	Week 4	Week 5	Week 6
Prepare
Research
Write
Check
Send

Project Management Information Systems (PMIS)
You will probably use a project management information system to assist you in reporting on
performance and issues arising from governance arrangements. A project management information
system is a database that provides project managers with techniques and tools to collect, combine
and disseminate information through electronic and manual channels during the planning, execution
and closing stages of a project. A PMIS is the vehicle through which senior and middle leaders of the
project communicate with one another. It can be as simple as a Microsoft office file to a bespoke
PMIS enterprise package. There are also web-based PMISs.
During the planning stage, a PMIS is used to set all the frameworks for the project and defines the
scope baseline. It is used to set out the objectives and time lines of the project so that during the
execution stage all of the accomplishments of the project can be measured against the initial plan at
different stages and reports generated for stakeholders. It also enables project managers to manage
materials, keep a record of financial data, and keep a record for auditing and reporting purposes. At
the close of the project the PMIS is used to review the project against the goals and objectives to
check if all objectives have been achieved and also to highlight areas for improvement in efficiency
for future projects. It can then be used to produce a final report on the project.
A project management information system:
 Is a means of communicating knowledge about the project including:
o scope
o timeframes
o financial costs
o quality assurance
o human resources
o communications
o risk
o procurement
o governance
o change and issues management
o stakeholders
BSBPMG521 LEARNER GUIDE 52 | P a g e Version 3.0
 Provides a systematic approach to the storage, searching and retrieval of
information relevant to the project so that information is easily accessible. A PMIS
automatically controls the following processes in relation to data:
o input
o storage
o processing
o output
o control/security
 May include:
o access authority levels
o complex computer-based systems
o data ownership considerations
o modified systems to cater for unique project requirements
o privacy considerations
o simple manual systems.
A PMIS sets a standard protocol for storing information ensuring that it is gathered, collated and
recorded in a consistent manner throughout the life of the project. Procedures and formats for
documenting information will be dictated by the PMIS so that all who input information will do so to
the agreed standard. The consistency makes analysing and comparing information throughout
different stages in the project much more efficient and accurate.
A PMIS will usually be managed by a designated person or a team of designated people responsible
for different areas of the project. The information within the PMIS will be quality assurance checked
by them to ensure accuracy and relevance of information communicated to stakeholders.
A PMIS helps to keep information relevant and up to date. When reporting during the project the
information that is communicated must be real-time and accurate at the time of reporting. A PMIS
can generate automatic updates of specific measures within the project. A simple manual system
does not have this facility and is open to human error.
Having access authority levels, data ownership and privacy considerations all help to preserve the
integrity of the information held on the PMIS.
The following governance report is taken from the website of Best Outcome, a project management
software manufacturer, and can be found at: http://www.bestoutcome.com/project-governancegateways.html
Quality
Successful quality management throughout a project ensures that the end product and outcome
meets or exceeds the expectations and needs of the clients and stakeholders which are determined
during the initiation and planning stages of the project. Quality management is an ongoing process
and may result in changes being made to a number of factors within the project such as timescale
and allocated resources, both of which may impact on all of the other eight project functions.
BSBPMG521 LEARNER GUIDE 53 | P a g e Version 3.0
Effective quality project management will include the following:
 Definition of quality – the definition of expected quality will be determined by the
stakeholders at the beginning of the project and will refer to the end result ad the
deliverables, and also the processes and procedures adopted during the course of
the project
 Quality characteristics – the deliverables, technology and equipment used to
produce the deliverables, and the processes and procedures used during the project
will be measured against certain characteristics such as:
o performance
o suitability
o consistency
o reliability
o functionality
 Quality plan – a clear quality management plan should be set out that determines
all the activities required to meet the determined quality standards including:
o quality definitions
o management responsibility
o design and document control procedures
o purchasing requirements
o procedures for inspection testing, nonconformance, and corrective actions
o how quality records are kept and maintained
o quality assurance – schedule for quality audits
and procedures for reporting back to
stakeholders
o training requirements
 Quality improvement (or continuous improvement) – this is the process of
constantly evaluating the quality of a product, system, process, procedure or
material to find ways to make it better and more efficient. It is the responsibility of
every member of the project team to strive to improve the quality of every aspect
of their work
 Quality control – the evaluation of the quality of the end result in terms of the
expectations of the stakeholders. If the quality expected is not met the end result
may be rejected and more work will need to be undertaken to meet the
requirements. This is why continuous improvement and quality audits are
important throughout the execution of the project
 Cost of quality – this relates to the methods and procedures used to produce
deliverable to the expected level of quality and also the costs of failing to meet
expectations and any waste in the course of the project.
As with the previous project functions, quality has an impact on all other functions.
BSBPMG521 LEARNER GUIDE 54 | P a g e Version 3.0
Risk
Risk management is an incredibly important aspect of project management and should be
embedded thoroughly into the project plan. Even the most thoughtfully and carefully considered
plans will face potential risks and issues during the life cycle of the project because nobody can
predict the future. Dealing proactively with potential risks and issues by minimising threats to the
project and maximising opportunities that arise is the key to risk management, and in some cases
can enhance the success and prosperity of the project.
Effective risk management should include the following:
 Make risk management part of the project plan – risk management should be
embedded in the plan and risks and issues expected, not hoped that they will not be
encountered. It should also be included in daily briefings, team meetings and
reviews throughout the life of the project
 Identify risks early in the project – accepting that your project is going to encounter
risks and issues allows you to identify potential risks in the planning stages. Use
lessons learned from previous similar projects, members of the project team, and
external experts to identify potential risks. Also consider possible risks in the
documentation of the project
 Communicate risks – every member of the team should be responsible for
communicating risks to the relevant authority as soon as they emerge. Risks can
only be dealt with if the project manager is aware of them. Risks should be included
on the agenda of all meetings with all stakeholders and serious threats should
always be communicated to the sponsor
 Consider threats and opportunities – some issues that occur can be golden
opportunities to improve the project. Don’t always take risks to be negative
 Designate ownership of risks – once you have identified a potential risk, assign
accountability to a member of the project team. This makes those members more
aware of the risks and subsequently more proactive in dealing with them, especially
if a lot of money is at stake
 Analyse and prioritise risks – you will not have time to deal with each risk in the
same manner; identify the most serious risks and deal with these first and
thoroughly
 Plan and implement a risk response – put in place procedures for dealing with risks
and issues. Responses include risk avoidance, risk minimisation, and risk acceptance
 Maintain a risk register/log – keeping a register allows you and your project team to
review and monitor risks and is useful when completing the lessons learned report.
A risk register should contain:
o a description of the risk
o cause and effect of the risk
o ownership of the risk
o risk response
o outcomes
Scope
The project scope is determined in the initiation and planning stages and sets out the limits of the
project, what it will do and what it won’t do. As with most plans, the scope may change as the
BSBPMG521 LEARNER GUIDE 55 | P a g e Version 3.0
project progresses and stakeholders want to move the goal posts. Modifying the scope changes the
rest of the project plan and schedule and should be done with caution and consideration.
Effective scope management includes:
 Project scope must be based on project objectives – all project activities and
deliverables must be aligned with the objectives. If stakeholders decide they want
to add more or change deliverables this must be done in accordance with project
objectives. Additional or alternative deliverable will have an impact on the other
functions of the project
 Scope must have an integrated control – scope is bound to change over the project,
but how these changes are implemented must be done in an integrated manner by:
o understanding the root cause of the change needed
o identifying the cause and effects and risks of changes
o preventing unnecessary changes
 Scope should be reviewed and verified by stakeholders at regular intervals, such as
on completion of key deliverables and project milestones, to ensure that
deliverables are in line with objectives and irrelevant deliverables are not being
produced.
Time
Time management is essential in project management and the project schedule should have detailed
time frames for all activities, milestones and key deliverables. The length of time a project takes can
be affected by all of the other eight project functions in both a
positive and negative way. Effective performance can reduce the
time the project takes just as poor performance can extend its
duration. Time, as they say, is money and the longer your project
goes on the more it is costing the bill payer and the less satisfied
the client will be.
A good project integration manager will be highly effective at time management by:
 Focusing on the project schedule and making the project team aware of their time
frames
 Streamlining meetings – set an agenda and a time frame and stick to it. Only invite
relevant team members to the meeting and do not allow discussions to run on
unnecessarily, if need be arrange another meeting for the appropriate people
 Not micromanaging – a good project manager will trust his team to get on with
their tasks without interrupting
 Not doing the work – it is tempting to get involved in the physical project activities
but this means you are taking your focus away from the overall project.
As you can see, all of the nine project functions are intrinsically
linked and each can have a huge impact on the other.
Triple constraints
The triple constraints within project management are:
 Cost
 Scope and quality
 Time.
BSBPMG521 LEARNER GUIDE 56 | P a g e Version 3.0
Triple constraints are also known as the Project Management Triangle.
In most projects one or two of the triple constraints will be fixed and the remaining one or two will
be flexible. Usually, the time will be fixed so that the deadline must be met and the quality and
scope of the project with depend upon the amount of money available to spend on the project.
In some projects, two of the constraints may be fixed, such as the time and the cost, meaning that a
deadline must be met within a specified budget at the detriment of the quality and scope.
Some projects have all three constraints fixed which requires an incredibly proficient project
manager. Triple constraints have an impact on all of the project functions as for each function you
must decide how much time is given to that area of the project, how much money is allocated to it,
and the quality and scope of each function.
Cost

Project function	How is it interdependent on cost?
Communication
Human resources
Procurement and contracting
Project integration
Quality
Risk
Scope
Time

BSBPMG521 LEARNER GUIDE 57 | P a g e Version 3.0
Communication

Project function	How is it interdependent on communication?
Cost
Human resources
Procurement and contracting
Project integration
Quality
Risk
Scope
Time

BSBPMG521 LEARNER GUIDE 58 | P a g e Version 3.0
Human resources

Project function	How is it interdependent on human resources?
Communication
Cost
Procurement and contracting
Project integration
Quality
Risk
Scope
Time

BSBPMG521 LEARNER GUIDE 59 | P a g e Version 3.0
Procurement and contracting

Project function	How is it interdependent on procurement and contracting?
Communication
Human resources
Cost
Project integration
Quality
Risk
Scope
Time

BSBPMG521 LEARNER GUIDE 60 | P a g e Version 3.0
Project integration

Project function	How is it interdependent on project integration?
Communication
Human resources
Procurement and contracting
Cost
Quality
Risk
Scope
Time

BSBPMG521 LEARNER GUIDE 61 | P a g e Version 3.0
Quality

Project function	How is it interdependent on quality?
Communication
Human resources
Procurement and contracting
Project integration
Cost
Risk
Scope
Time

BSBPMG521 LEARNER GUIDE 62 | P a g e Version 3.0
Risk

Project function	How is it interdependent on risk?
Communication
Human resources
Procurement and contracting
Project integration
Quality
Cost
Scope
Time

BSBPMG521 LEARNER GUIDE 63 | P a g e Version 3.0
Scope

Project function	How is it interdependent on scope?
Communication
Human resources
Procurement and contracting
Project integration
Quality
Risk
Cost
Time

BSBPMG521 LEARNER GUIDE 64 | P a g e Version 3.0
Time

Project function	How is it interdependent on time?
Communication
Human resources
Procurement and contracting
Project integration
Quality
Risk
Scope
Cost

BSBPMG521 LEARNER GUIDE 65 | P a g e Version 3.0
2.4 Develop a project management plan that integrates all projectmanagement functions with associated plans and baselines
Project management plan
The project management plan sets out every conceivable schedule, policy and procedure for all
project management functions, associated plans and baselines. It should be clear and concise, and
sufficiently detailed for any member of the project team and all stakeholders to understand. It
should detail what each member of the team should be doing, when they should be doing it and the
manner in which they should be doing it.
A project management plan may be:
 A covering document that integrates the planning requirements of the nine
functions of project management
 In single or multiple document format.
The planning requirements of each of the nine functions should be carefully considered and
integrated within the overall project management plan. As you discovered in the previous chapter,
all nine functions are interdependent and this should be reflected in the project management plan.
By integrated, it means:
 Decisions that:
o determine comparative value
o evaluate competing interests
o make trade-offs
 Processes and activities that:
o combine
o coordinate
o define
o identify
o unify.
Associated plans and baselines include:
 Communications plan (stakeholders and information)
 Human resources plan
 Procurement plan
 Project budget
 Project schedule
 Quality-management plan
 Risk plan
 Scope-management plan.
Contents of a project management plan
In view of all the above, the project management plan should contain the following content.
BSBPMG521 LEARNER GUIDE 66 | P a g e Version 3.0
Introduction
The introduction provides a high level description of the project including its purpose, objectives,
deliverables, and intended outcomes and benefits. It does not need to be finely detailed as the rest
of the document will provide the necessary information.
Project management approach
This is a description of the overall management approach to the
project including key stakeholders and delegated authorities
and managers and their respective roles and responsibilities.
The constraints and limitations should be included as well as
information relating to the organisations and/or suppliers that
will provide resources for the project. Decision-making
authorities and the aspects over which they have authority and
limits of authority should also be included.
Project scope
A detailed description of the project scope that was outlined in the project charter should be
included here, clearly documenting what the project will do/include and what it will not do/include.
The more detail the better as it will clarify exactly what the project will include and will not
disappoint stakeholders at a later date. Deliverables should be clearly documented.
Milestone list
This section documents all of the milestones within the project including dates for each milestone.
Each milestone should be briefly explained with more detail used for the major milestones and these
major milestones being highlighted. It should also document procedures that should be used should
milestones or delivery dates have to be changed.
Schedule baseline and work breakdown structure
The work breakdown structure (WBS) should be clearly explained and any technical terminology
within it clearly defined in a glossary. The WBS is the core of the project as it contains all of the
deliverables and sub-deliverables that will ensure completion of the project. The WBS controls the
scope of the project; any deliverables not included in the WBS should not be produced. The WBS
determines the project schedule which is itself a timeline and schedule of project activities.
Change management plan
You will probably already have a change management procedure that is used in all of the
organisation’s projects when changes to the original plans are required. It is important to
understand that changes within any project and their impact on the project should be carefully
considered before they are approved. Delegated authorities for approving change should also be
documented as well as the way in which changes should be recorded and monitored.
Communications management plan
The communications management plan may be almost as lengthy as the overall project
management plan itself. It should define how, what and when information is disseminated to all
members of the project team and key stakeholders, who communicates it and include a
communications conduct. It should also contain meeting and reporting schedules that details which
team members are responsible for each. It is also a good idea to include a communications directory
for all project team members.
BSBPMG521 LEARNER GUIDE 67 | P a g e Version 3.0
Cost management plan
The cost management plan details how the budget will be allocated and how spending is measured,
reported and controlled. It also identifies the delegated authorities for managing budgets and their
limits of authority, and the delegated authorities for approving changes to budgets.
Procurement management plan
The procurement management plan details the criteria for supplier selection, the way in which
suppliers are selected (such as requests for quotation, information and proposal), types of supply
contract, and constraints on terms and conditions of supply. It also sets out the limits of authority
afforded to the procurement manager.
Project scope management plan
Although the scope has already been defined it is inevitable that
it will change during the life cycle of the project. Changes to the
scope must be documented and communicated to relevant
parties in order to avoid “scope creep” which results in delays,
unnecessary extra work, and failure to meet deadlines and
achieve deliverables, incurs costs and encourages potential risks and issues. The scope management
plan determines who is responsible for managing scope, how it is measured and verified and the
procedures for scope changes.
Schedule management plan
The schedule management plan details the overall framework for the project schedule, how
resources are allocated, time frames for project activities, roles and responsibilities for achievement
of deliverables and milestones and measures of project performance.
Quality management plan
This part of the document defines the expected standards of quality of the deliverables and the
processes and procedures used to produce the deliverables. It details who is responsible for quality
management and how quality is controlled, monitored and assured.
Risk management plan
This section describes the strategies to identify and manage potential risks to the success of the
project and procedures to optimise opportunities presented by risks. It will also include a risk
register.
Staff management plan
This should include an organisation chart and determine the organisational structure; whether it is a
matrix or project structure and how resources will be managed and allocated and by whom.
Resource calendar
Linked to the staff management plan, the resource calendar identifies the resources needed for
which project activities at which stages and times of the project schedule. This will help to avoid
potential conflicts in management in matrix organisational structures.
Cost baseline
This sets out a budget for each stage of the project and may even be broken down into sub sections.
The project management plan should be approved and signed off by the delegated authority which
is usually the sponsor.
BSBPMG521 LEARNER GUIDE 68 | P a g e Version 3.0
2.5 Establish designated mechanisms to monitor and control planned activity
Monitoring and controlling planned project activity
Now that you have created your project management plan you
need to establish methods to monitor and control the planned
project activities to ensure that it remains on schedule to meet
all determined deliverables, objectives and quality standards.
Due to the temporary nature and uniqueness of each project
they need constant and active monitoring and controlling to
ensure they are working according to schedule unlike an
embedded process that has been tried and tested and almost
runs itself.
The monitoring and controlling process is an ongoing analysis of project performance against project
objectives, deliverables and schedule to determine whether any changes to the project plan are
required.
Mechanisms to monitor and control planned activity include:
 Pulse meetings – these are short and frequent project management team meetings
during which the status of day to day project activities is reported including any
issues or potential risks. The frequency of these meetings varies according to the
nature of the project; they may occur three times a day in fast paced projects or
once a week in slower moving projects
 Variance reports – these reports show the difference between the actual project
activity and the planned or scheduled project activity. These are particularly
important in terms of the budget and time frame of the project. Variance reports
are usually separated into two; the current period variance (what has happened
since the last reporting cycle) and the cumulative variance (what has happened
since the project started)
 Program reviews – unlike pulse meetings, program reviews focus on the big picture
of the project and are held with project team members and sub-project leaders in
longer intervals. The focus of these meetings is to determine whether and how each
function of the project is impacting on or interfering with the others
 Technical reviews – these are formal meetings between technical experts that have
nothing to do with the project during which an in-depth analysis is completed on a
technical aspect of the project to determine whether project activities and
deliverables have been accomplished to the agreed specification and standard.
They will often generate a number of actions that must be undertaken within a
given time frame to ensure the technical aspects of the project are on track
 Project forecasting – this involved assessing the current performance of project
activities, issues that have occurred, and potential risks to estimate the impact on
the triple constraints of the project activity (duration, cost, quality)
 Problem solving – this should be included in your change and issues management
plan
BSBPMG521 LEARNER GUIDE 69 | P a g e Version 3.0
 Project Management Information System – a database that provides project
managers with techniques and tools to collect, combine and disseminate
information through electronic and manual channels during the planning, execution
and closing stages of a project. It can be as simple as a Microsoft office file to a
bespoke PMIS enterprise package. During the planning stage, a PMIS is used to set
all the frameworks for the project and defines the scope baseline. It is used to set
out the objectives and time lines of the project so that during the execution stage
all of the accomplishments of the project can be measured against the initial plan at
different stages and reports generated for stakeholders. It also enables project
managers to manage materials, keep a record of financial data, and keep a record
for auditing and reporting purposes
 Management reviews – these are formal, scheduled meetings between the key
stakeholders and the project management team that determine the overall
progress of the project against the original plan, identifying any risks or problems
that need to be resolved in order for the successful completion of the project. They
should be minuted with the documents forming part of the evaluation on the
project’s completion
 Dashboards – a dashboard is a snap shot of key performance indicators that shows
whether or not the project is on target in each of the key performance indicator
areas. It is a simple visual aid that usually employs the RAG method of
demonstrating the performance of project activity (red means not on target and
action needs taking, amber means on track, and green means the activity is
complete or ahead of schedule). Each project activity will have its own key
performance indicators but they will all usually include the triple constraints
 Change management log – this is a simple document that records the changes that
have had to be made to project activities, the reasons for the changes, the impacts
the change(s) will have or have had on other project activities and alterations to the
triple constraints as a result.
All planned activities should be monitored and controlled in one way or another and records kept of
all reviews, reports and meetings for use in the evaluation of the completed project.
BSBPMG521 LEARNER GUIDE 70 | P a g e Version 3.0
2.6 Negotiate approval of project plan with relevant stakeholders and project
authority
Finalise project plan and gain approval
Before the project can begin, the project plan needs to be approved and signed off by the sponsor
and other key stakeholders. The approval of the project plan means that the objectives and
deliverables have been reviewed and agreed to. The signing off of the project plan indicates the
completion of the planning and design stage and can be regarded as a project milestone. It also
represents a commitment from the sponsor and key stakeholders to continue with the project under
the agreed constraints.
Having consulted the sponsor and key stakeholders about their requirements for the project
objectives and deliverables during the initiation stage the project plan should reflect their
expectations and the approval should be a simple process.
Gaining approval of the project plan from project authorities may include:
 Review project plan document and ensure accuracy and completion
 Disseminate the project plan to the relevant stakeholders in an agreed format and
to an agreed time scale
 Arrange a meeting with the relevant stakeholders to review and discuss the
proposed project plan. Minute the meeting and use the minutes to amend the
project plan if and where necessary
 Amend the project plan according to the requirements of the relevant stakeholders
and re-submit the plan to an agreed time scale, arranging another meeting if
necessary to review and discuss the amendments
 Request a decision from the relevant
stakeholders as to whether or not the plan has
been approved in order for the project to
continue. If the plan has not been approved the
reasons should be documented by the relevant
stakeholder
 Obtain signatures from all relevant stakeholders on a separate project plan
approval document which should be an appendix to the project plan.
Good negotiators
Negotiating is a skill that can take a long time to perfect with the ideal outcome being a win-win
solution for both parties. It is a process that can take a long time.
Best practice for negotiations:
 Identify the factors upon which each stakeholder is insistent
 Identify areas for negotiation on all sides
 Identify with whom the balance of power lies in terms of bargaining strength
between the stakeholders and the project team – which has more evidence for
their case than others?
 Be prepared for all eventualities when you enter negotiations with stakeholders so
you are not caught off guard
BSBPMG521 LEARNER GUIDE 71 | P a g e Version 3.0
 Always use reliable facts and figures that are accurate and cannot be questioned
 Prepare an agenda prior to the meeting and ensure all members of your team are
briefed and provided with sufficient information so as not to compromise the
negotiations
 Start with a wide ranging proposal as opposed to small details to leave plenty of
room for manoeuvre
 Do not continue the meeting if communications or negotiations are breaking down
– call a recess or rearrange the meeting for another time
 Be fair and reasonable
 Ensure all negotiations are documented and recorded clearly, and wherever
possible signed by all parties, so that you have an audit trail and an accurate record
of the agreement should it be disputed when the project plan is re-submitted.
Project management plan approval
The approval document should be signed and dated by all relevant stakeholders with their name,
title and role clearly documented.
Relevant stakeholders may include:
 Project manager
 Project sponsor
 Investors
 Business steward.
The approval document will be simple and contain just a paragraph that states all the signatories
have reviewed the project plan and agree to the approaches and schedule it sets out. It may also
have a clause that states how any changes to the plan should be approved and documented.
BSBPMG521 LEARNER GUIDE 72 | P a g e Version 3.0
Section 3 Execute project in work environment
3.1 Manage the project in an established internal work environment to
ensure work is conducted effectively throughout the project
Managing the execution of the project
You have initiated and planned your project and have the approval to begin the execution. You have
set in place procedures for monitoring and controlling project activities against the project plan
which will run concurrently with the execution of the project and which you will need to oversee
whilst you manage the work taking place on the ground. You may find that human resources assist in
the management of the established internal work environment, but as project manager it is your
role to ensure that the whole of the project team work effectively throughout the life cycle of the
project according to these policies and procedures.
If you are new to project management it is worth bearing in mind that whilst you and your project
team are new to the organisation by whom you have been employed, they will almost certainly have
established their very own internal work environment that you will have to learn, understand, work
within, and potentially change or enhance to ensure that work is conducted as effectively and
efficiently as possible. The work force of an organisation are often very reluctant to change
embedded working practices and can also be resistant to new faces issuing orders and instructions.
How you manage the internal work environment can be the success of failure of a project.
Internal work environment may include:
 Organisational policy and procedures
 Organisational culture and style
 Physical working conditions
 Geographic location and/or dispersion
 Team dynamics.
Organisational policy and procedures
In a long and well established organisation the policies and procedures will be well engrained into
the fabric of the business and the day to day operational activities. Dependent on the size of the
organisation, there may be a large number of established policies and procedures, or there may be
only a basic few. Some industries will also be governed by specific legislative and regulatory policies
and procedures, and all will have to adhere to generic WHS and anti-discriminatory legislation.
Policies and procedures may include:
 WHS policies and procedures
 Equal opportunities
 Privacy, confidentiality and security
 Risk assessments
 Communications – internal and external
 Personnel:
o disciplinary
o grievance
BSBPMG521 LEARNER GUIDE 73 | P a g e Version 3.0
o appraisal/performance
o expenses
o sick leave
o annual leave
o recruitment
o induction and training
o redundancy
o retirement
o pension contributions
 Office management:
o environmental impact
o e-mail/internet use
o use of office facilities
o security
 Ethics:
o complaints
o personal development
o quality assurance
o whistleblowing
 Partnership working
 Media relations
 Financial.
Organisational culture and style
Every organisation has a particular culture that emanates from the leadership team and their style of
leadership and personalities and the mission statement of the company. The culture of the
workforce and their work ethic and practices reflect the code of ethics and the values of the
organisation. Because projects are temporary it is easy to overlook the fact that your project team
will be working within an already established organisational culture that may be completely different
to your own. The project is your only priority whereas the organisation, and more importantly, the
work force and your resources will almost probably have a number of different roles and
responsibilities outside the project that are as critical as their role within the project. As with the
leadership of an organisation, the leadership of a project takes on the culture of the project manager
and team. It is important to understand the culture of the organisation for whom you are working
and work within it wherever possible.
Alternatively, you might find that the culture of the organisation is not conducive to the demands of
the project and is resistant to change. You and your project team need to be able to engage with the
existing culture and lead any necessary changes by example.
BSBPMG521 LEARNER GUIDE 74 | P a g e Version 3.0
In order for the project to be successful and win the support and effort of the organisation’s
employees the following needs to be in place:
 Mutual trust
 Acceptance of errors and mistakes
 Positive working conditions
 Accurate reporting on the progress of the
project and any issues within the work force
as a result of the project
 Team building training sessions that allow the
project team to explain to the organisation’s
work force what the project is about, why it is necessary, their roles and
responsibilities, and the importance of their involvement and commitment.
Physical working conditions
You also need to keep in mind that the actual physical working environment is established and each
of its components will already be in use for something within the business. In projects where
temporary buildings and facilities are erected on site for the project staff to operate from the project
activities can be kept as far away from “normal” working practices as possible. However, if the
project activities coincide with existing working practices and procedures they are going to take over
existing resources; this might be in the form of office space, technology, equipment, vehicles, staff
rooms etc. This is one of the largest gripes of existing employees when their usual working materials
and resources are invaded, for want of a better word. Again, communication with the work force
about what is going on and why is essential to obtain their commitment to the project. You may find
that you have to give them something back as a trade-off; by doing this they will feel valued and
considered and are more likely to assist in your endeavour for quality and to meet the project
objectives and constraints.
Geographic location and/or dispersion
As a project manager you may find yourself travelling to many different geographical locations
across the nation or even throughout the world. Each location has its own features and dynamics
that may affect the way in which you manage the project. Processes that you normally use in project
management may not be suitable for each location. The organisation may have embedded
procedures that rely upon the geographical location of the business that cannot be changed for
physical reasons, such as a company that is located on an island may need supplies to be flown in
but the supplier you usually use does not have the facility to do so.
Team dynamics
Team dynamics can have a huge impact on the success or failure of a project, including:
 Output and productivity
 Mood of employees and whether they are
happy in their work – happy employees are
more likely to have a positive work ethic
 Staff retention rates and recruitment
 Individual and team/departmental
performance
 Reputation of the organisation/project team.
BSBPMG521 LEARNER GUIDE 75 | P a g e Version 3.0
In large organisations there are numerous different teams and some people may belong to a number
of different ones depending on their roles and responsibilities. Some teams work well together and
some do not. Personalities within the team play a large part in shaping the dynamics, and often just
one person can have seriously positive or negative effects on the dynamic.
If you inherit a work force with positive team dynamics you should harness the positivity and
motivation and work with it. However, you may encounter a lethargic team that are reluctant to
work for you. Poor team dynamics are borne from poor leadership and lack of communication or
reward.
The following points should help to improve team dynamics:
 Communication – employees like to be kept in the loop, particularly when change is
on the horizon. As soon as possible you should communicate information about the
project especially why it is necessary and how it is going to affect their roles and
daily work activities. You should also encourage feedback as employees also like to
have their opinions and feelings heard. By acting upon their feedback and
communicating what you have done as a result, you make them feel empowered
and valued
 Motivation – unmotivated employees are lazy and lack commitment. Use incentives
and rewards to encourage positive work ethics and praise a job well done. The
rewards do not necessarily have to be financial, a simple “thank you” or “well done”
or praise about your work to your line manager goes a long way
 Innovation – include the employees in problem-solving and ideas generation. They
are the people on the ground doing the job and have a lot of combined expertise
and knowledge between them. Harness their ideas and reward and promote
thinking outside the box
 Efficiency – make sure that the roles and responsibilities assigned to each member
of the team is suitable and appropriate for their level of knowledge and expertise.
Being a project manager means being all things to all people and managing the conditions you are
given. You cannot adopt a one size fits all approach to project management because all projects are
different and all organisations are different. In order to ensure work is conducted effectively
throughout the project you need to manage these existing conditions very carefully. You do not
want to alienate the existing work force by barrelling over their established procedures but equally,
you do not want to let them hinder the project by allowing them to make the rules.
BSBPMG521 LEARNER GUIDE 76 | P a g e Version 3.0
3.2 Maintain established links to align project objectives with organisational
objectives throughout the project
In chapter 1.2 you identified the relationship between the project and the broader organisational
strategies and goals. In chapter 1.3 you negotiated and documented the project objectives in
relation to the organisational objectives, and in chapter 2.5 you established ways in which to
monitor and control planned activity which should have included how you intend to keep project
objectives in alignment with organisational objectives throughout the life cycle of the project.
Project versus organisational objectives
As you read that title you should have been thinking, “Surely, the two are the same?” and you would
be have been correct. The project exists in order to make changes and/or improvements to the
organisation in alignment with its strategic objectives. In the initiation and planning stages you spent
time negotiating and determining the project objectives and plan with the relevant stakeholders and
project authorities and neither should have been approved if the project objectives, deliverables and
outcomes were different to the organisational objectives.
You have included the project objectives in relation to the organisational strategy in all of the major
documents within the project so far including the PID, the project governance structure, the project
charter, the project management plan and the designated mechanisms to monitor and control
planned activity, so there should be no excuse that you are unaware of the overall organisational
objectives.
Once the project gets underway, some project
managers have a tendency to become absorbed with
the project as a separate entity to the organisation
under the pressures of deadlines and budgets, and
managing the integration of the nine project functions.
In the past, a project was considered a success if the
deadline was met and the project was completed
within the allocated budget. This is no longer the case
and on completion of the project, there will be as in
depth evaluation as to how well the project met the
objectives it was set in the initiation stages.
As a project manager it is easy to focus on the following generic project deliverables:
 Hours worked to date
 Hours remaining to work
 Duration to date and remaining
 Deliverables complete
 Milestones completed
 Upcoming milestones
 Budget allocation
 Resources allocation.
BSBPMG521 LEARNER GUIDE 77 | P a g e Version 3.0
While these are integral to the smooth running and completion of the project, they do not focus
on the core objectives of the project. You should also be using key performance indicators to
measure project progress that are directly linked to the organisation’s strategic objectives.
These should be promoted within the project team and reported to the key stakeholders at
regular intervals. By doing so the project becomes embedded within the organisational
structure and culture. It also allows you as a project manager to maintain project activity in
alignment with organisational objectives, and to realign it if it has wandered off track or out of
scope.
Align project and organisational objectives throughout the project life cycle
In chapter 2.5 you considered methods of monitoring and controlling planned activity. As these
methods have already been established and form part of the project plan for the monitoring and
controlling stage, the most sensible thing to do would be to adopt those already in use to monitor
the project objectives. You have established key performance indicators that relate to the
organisational objectives need to be used to monitor project progress in conjunction with key
project deliverables.
These measures can form the content and reporting information for the following mechanisms to
monitor and control project activities without having to establish more reporting procedures and
channels:
 Pulse meetings – day to day KPIs can be reported along with any risks to project
objectives becoming disconnected to organisational objectives
 Variance reports – whilst these reports show the difference between planned
project activity with actual project activity they can also report the differences or
alignment of project objectives with organisational objectives in the same report in
a separate section
 Program reviews – making the comparison between project and organisational
objectives part of the program reviews that take place between project team
members and sub-project leaders enables the whole team to be responsible for the
alignment of the two, rather than it just being the project management team and
the key stakeholders. It reinforces the organisational objectives onto the project
activities to keep the alignment maintained
 Project forecasting – whilst this is primarily concerned with the performance of the
project in terms of the triple constraints, there is no reason why it cannot include
forecasting of whether or not the project objectives are in alignment with
organisational objectives, and if they are not, forecasting what it will take and how
long it will take, if at all, to realign them
 Management reviews – these meetings are an ideal opportunity for the key
stakeholders, who should have an overall view of the project as they are not usually
directly involved with daily work activities, to monitor whether or not project and
organisational objectives are in alignment
 Dashboards – these visual snap shots are a good way to promote the KPIs of the
project in relation to the project and organisational objectives throughout the
whole of the project team to reinforce the expectations that project activities
should not be veering from the project plan
 Change management log – there may be a requirement to amend project activities
and plans to realign project objectives with organisational objectives. These should
be recorded in the change management log for use in evaluation on the completion
of the project.
BSBPMG521 LEARNER GUIDE 78 | P a g e Version 3.0
By using existing reporting methods, all risks and issues can be recorded on the same documents as
the project is considered holistically as opposed to a separate entity to the organisation. It keeps the
purpose of the project and strategic objectives in the forefront of the minds of all of the project
team from the bottom to the top.
As all of these meetings and reporting methods have been planned into the project schedule at
relevant intervals it should be simple to identify if the project objectives are meandering from those
of the organisation, and if so to put in place remedial action in a timely manner to resolve the
matter.
BSBPMG521 LEARNER GUIDE 79 | P a g e Version 3.0
3.3 Within authority levels, resolve conflicts negatively affecting attainment
of project objectives
Conflict
When you established your project management plan you included within it a relationships
management or conflict resolution procedure. Whilst no conflict would be helpful to the smooth
running of a project it is simply unrealistic to expect that conflict will not be encountered in some
way during the life cycle of the project. However harmonious the nature of the project team is, there
are inevitably going to be conflicts that may arise for all manner of reasons.
Balancing a project team is no easy feat. Whilst the team should all be working together to achieve
the same goal, it is important to understand that each member is an individual and has their own
opinions on tasks and priorities, their own interests at heart, and a different personality to the next.
At the outset of the execution stage, conflict can occur for a number of reasons including:
 Negative organisational culture and style towards projects and project management
team
 Inherited poor team dynamics
 Lack of knowledge by the project manager regarding existing internal work
environment
 Resistance to change in procedures, leadership, and daily work activities.
Conflict within the execution stage of project management can occur for a number of reasons. The
following factors are common causes of conflict:
 Ambiguous roles and responsibilities – it is your responsibility as project manager
to ensure that all project team members know exactly what their roles and
responsibilities are and how these relate to the project objectives and the
organisational objectives. To assume that they understand their roles without first
checking allows them to think that they understand what is expected of them, even
if they don’t, which can result in:
o conflict between team members who
are executing the same task but in a
different way
o conflict between team leaders and
team members because one is
challenging the other over the
expectations of the task in hand
o conflict between project manager
and members of the project team
when they are challenged about the
accuracy of their work
o conflict between project manager
and stakeholders over issues and delays arising from conflicts over roles and
responsibilities
 Discrepancies in prioritising tasks – project team members often have tasks to
undertake that are not part of the project, or part of another project that is running
simultaneously. It is important that the project manager communicates the
importance of each project task to relevant team members and that this is agreed
with functional authorities. This may result in:
BSBPMG521 LEARNER GUIDE 80 | P a g e Version 3.0
o conflict between functional and project authorities over the allocation of
resources
o conflict between project team members and project authorities who are
unclear as to whom they are answerable
 Independent or lone working – in some projects certain team members work alone
and/or in different geographical locations to the rest of the team and may not be a
part of regular communications and project updates. Conflict may arise if they are
issued instructions or alterations to instructions that they do not understand
because they have not been included in the communication channels. It is
important that the project manager includes all project team members in all
relevant and appropriate channels of communication. They also need to understand
how their role fits into the project and organisational objectives
 Delay on completion of task dependencies – in most projects certain tasks cannot
be started until others have been completed. Conflict may arise if team members
are due to start work on their project task but cannot because the previous task is
incomplete. Team members need to understand the impact that their work, or lack
of work, has on other members of the project team and how this can affect project
objectives
 Lack of communication – in essence all of the sources of conflict listed above are
mainly due to lack of communication or poor communication. As we learned at the
start of the unit, effective communication is vital to the smooth running of the
project. The whole project team needs to understand what they should be doing,
when they should be doing it, why they are doing it and the impact of not doing it,
or doing it incorrectly, can have on the project objectives
 Changes to terms and conditions of supply
contracts – sometimes during a project it may
be necessary to amend the terms and
conditions of supply contracts for various
reasons. Changing the agreed terms can
cause serious conflict, usually stemming from
the vendor and can result in long delays to
project work, whilst negotiations take place
or worse, if the vendor or contractor pulls out
of the project leaving the project manager to
source a new vendor or contractor
 Issues within the community – your project activities may be having a detrimental
effect on the community around the location of the organisation.
Avoiding conflicts
A good project manager will prevent conflicts by using effective communication strategies
throughout the life of the project. The meeting schedules set out in the project plan should be
adhered to, and if more communication is needed, should be amended. Project managers should
encourage a two-way communications process between them and their project team to raise any
issues or potential sources of conflict before they arise. This is why the initiation, planning, and
BSBPMG521 LEARNER GUIDE 81 | P a g e Version 3.0
monitoring and controlling stages are so crucial to the smooth running of the project. Involving the
project team and stakeholders in relevant consultation processes such as open forums,
questionnaires, and meetings allows them to air their concerns and for you to address potential
conflicts before they arise. It also makes the project team feel valued and take ownership of the
project which results in a more cohesive and productive work force.
Constant assessment allows sources of potential conflict to be addressed and resolved before it
becomes a huge issue that may delay the project, or worse, compromise completion.
Conflict resolution
Where conflict is unavoidable it must be addressed
swiftly and thoroughly to ensure the issues are
resolved and for the project to continue. There are a
number of steps in conflict resolution models which
are generally accepted as the norm and adopted by
organisations as their own resolution of conflict
procedures. The number of steps you have to take
to resolve the disagreement will depend upon the
needs and expectations of the disgruntled party.
Some conflicts are easier to resolve than others;
submissive personalities will usually be easier to
please than dominant individuals.
Steps in a conflict resolution model include:
 Negotiation – you have already covered negotiation in a previous chapter and this
is the lowest level of conflict resolution. It is a voluntary process in which proposals
are passed back and forth from each party until an agreement is reached. Both
parties can negotiate for themselves or can involve a third party to perform the
negotiations for them, but ultimately each party makes their own decisions in the
process. Negotiations can be:
o quick and inexpensive
o informal and unstructured
o private and confidential
o resolved informally
 Mediation – if negotiations fail, mediation is the next step. Again, this is a voluntary
process that all parties agree to enter to try and resolve the dispute informally
without having to involve legal or trade union action. A third, impartial party is
invited to act as the mediator and chair the informal meeting between the parties
involved. Whilst the meeting is informal it does run to a set format; the mediator
will explain the situation at the beginning of the meeting and lay down the ground
rules to which party must abide, such as “do not talk when another party is talking”.
Each party is given the opportunity to give their version of the dispute and the
reasons for the conflict. After each party has listened to the other the idea is that
they resolve the dispute together by suggestions solutions to the problem. When
mediation works, many creative and innovative solutions are found that actually
BSBPMG521 LEARNER GUIDE 82 | P a g e Version 3.0
strengthen the relationship between the parties involved. Mediation can be
performed by a member of the project team, the project management team or if
necessary, a lawyer. All mediation meetings must be minuted, the agreed solutions
documented and signed by all parties involved. Mediation:
o promotes communication and cooperation
o allows disputes to be proactively resolved by the parties involved
o can eliminate hostility and preserve relationships
o avoids time and expense of going through legal proceedings
o may create an even more acceptable and innovative solution than that
originally proposed
o is voluntary, informal and flexible
 Arbitration – if negotiation and mediation fail to secure resolution, the matter will
require a more formal resolution. Arbitration is the process of submitting the case
to an impartial third party, the arbitrator, to hear both sides of the dispute in order
for a decision to be made. (It is an out of court method of resolving legal and trade
union disputes.) Arbitration:
o can be voluntary
o is private
o is conducted as a hearing in which all parties present evidence to the
arbitrator
o is usually quicker and less expensive than going to court
o allows the parties involved to select an arbitrator with expert knowledge of
their area of dispute
o results in a decision made by the arbitrator that is final and can be enforced
in court
 Litigation – if the dispute becomes so serious and all steps taken to resolve the
dispute have failed, you may have to go to court. A trial will be held during which
both parties and their respective lawyers will present evidence to a judge who will
then make a decision based upon applicable legislation. Litigation is:
o involuntary – all parties must present evidence
o a formal and structured process
o public – all court proceedings and records are open to the public
o based upon relevant legislation
o final and binding
o expensive and can be a lengthy process
o open to appeal.
The conflict should not usually become so serious that arbitration and litigation are necessary, as
most conflict can be resolved informally and internally with negotiation and mediation.
BSBPMG521 LEARNER GUIDE 83 | P a g e Version 3.0
Risks of not dealing with conflict properly include:
 Dealing with the person raising the issue of conflict and not the actual issues does
not resolve the source of conflict. It also may not resolve the person’s gripe. Conflict
escalates which could be detrimental to the project objectives
 Unresolved conflict may lead to personal conflict within teams and possibly
breakdowns in activity
 Many people take conflict personally and attach emotions to the source of conflict.
If they are not given the opportunity to resolve the matter in a manner appropriate
to their needs, the source of conflict may not be eliminated and may recur.
Benefits of dealing positively with conflict can include:
 Recognising and dealing with potential compromises to the project objectives
 Understanding the needs of the project team
 A more cohesive team dynamic
 A team understanding of the project objectives and a common approach to
completing assigned project activities
 Preventing future conflicts.
BSBPMG521 LEARNER GUIDE 84 | P a g e Version 3.0
Section 4 Manage project control
4.1 Ensure project records are updated against project deliverables and plans
at required intervals
Records
Your project plan and deliverables have been approved by the relevant authorities and as the project
gets underway you will need to produce and update project records at the required intervals set out
in the project schedule. With any records you should ensure systems are in place to keep the
information secure, manageable, updated, and accessible to those that require it.
Security and audit requirements may include:
 Despatching and collecting procedures
 Legal and project policies, guidelines and
requirements
 Procedures for deciding which records
should be captured and filed
 Procedures for updating records
 Security procedures.
Despatching and collecting procedures
The project will benefit from having one designated person to handle all incoming and outgoing mail
to ensure it all ends up at the right destination. In large projects separate staff members should be
employed to receive, collate, distribute and collect all project related mail.
The project should have a procedure in place that determines those responsible for overseeing the
despatching and collecting of internal and external mail and the steps that must be followed to
ensure the security of it.
There should be an electronic mail-management system that tracks all incoming and outgoing mail
to avoid losing or misplacing any. This is especially important if the project involves sensitive legal
documents and packages.
Project policies, guideline and requirements
The project should have an information security policy that details how information, both electronic
and hard copy, is managed and secured to protect from breaches in confidentiality, and contingency
plans should any of the information systems fail or be breached.
An information security policy may include:
 Backup systems
Those persons responsible for each information system must ensure appropriate
backup and recovery systems and procedures are in place and must meet the needs
of the project
 Compliance
Terms and conditions of employment and the project’s Code of Conduct will clarify
responsibilities and limits of employees’ access to and use of information systems.
Where appropriate, training will be given on legal compliance
BSBPMG521 LEARNER GUIDE 85 | P a g e Version 3.0
 Outsourcing and third party access
All third parties that have access to the project’s information systems must agree to
and follow the project’s information security policy
 Physical access to information
Areas where confidential and restricted information is held should have the
appropriate level of physical access controls and only appropriate and relevant
members of staff will have access
 IT operations
Procedures should be in place for reporting security incidents and possible
weaknesses in security systems, as well as reporting malfunctions in information
systems
 Disposal of information systems
Procedures should be in place for the safe disposal of equipment and/or systems
containing confidential information
 Access
Access to information systems for employees should be set accordingly and should
be password protected and monitored by management. Each employee should be
accountable for their own usage and must not share their password with others
 Confidential or restricted material
Confidential and restricted information should be stored centrally and accessed
according to the authorisation levels of each piece of information. Employees
should be clear on what constitutes, and the consequences of, breaching
confidentiality. Confidential and restricted material should be destroyed by
shredding or other similar means when no longer required.
Legal policies, guidelines and requirements
The Privacy Act 1988 regulates the handling of an individual’s personal information. Personal
information is defined by the Act as “information or an opinion, whether true or not, and whether
recorded in a material form or not, about an identified individual, or an individual who is
reasonably identifiable” and includes:
 Name
 Address
 Telephone number
 Signature
 Date of birth
 Medical records
 Bank account details
 Commentary and opinion.
The Privacy Act includes 13 Australian Privacy Principles (APPs) that set out guidelines for
appropriate handling, holding, accessing and correcting of personal information, including sensitive
information (see below), for example how personal information can be used and disclosed and the
right for individuals to access and correct their own personal information.
BSBPMG521 LEARNER GUIDE 86 | P a g e Version 3.0
The APPs apply to Australian and Norfolk Island government agencies and private sector
organisations whose annual turnover is more than three million dollars. There are exceptions to this.
To find out if the APPs apply to the organisation and for more information go to:
http://www.oaic.gov.au/privacy/privacy-topics/business-and-small-business/small-business
Sensitive information includes:
 An individual’s racial or ethnic origin
 Health information
 Political opinions
 Membership of a political
association, professional or
trade association or trade
union
 Religious beliefs or affiliations
 Philosophical beliefs
 Sexual orientation or practices
 Criminal record
 Genetic information
 Biometric information that is to
be used for certain purposes
 Biometric templates.
Project records
What project records will need to be updated against the project deliverables and the project plan?

Deliverables register	Project plan – records
Current status of each deliverable	Project management approach
Quality targets	Project scope
Quality standards and criteria	Milestone list
Quality assurance reviews undertaken	Schedule baseline and work breakdown structure
Quality control reviews undertaken	Change management plan
Actions required from quality assurance and control reviews	Communications management plan
Time frame in which to complete actions	Procurement management plan
Current status of quality of deliverables	Project scope management plan
Schedule management plan
Quality management plan
Risk management plan
Staff management plan
Resource calendar
Cost baseline

BSBPMG521 LEARNER GUIDE 87 | P a g e Version 3.0
Project management information software
As discussed in chapter 2.3 a project management information system:
 Is a means of recording project information including:
o scope
o timeframes
o financial costs
o quality assurance
o human resources
o communications
o risk
o procurement
o governance
o change and issues
management
o stakeholders
 Provides a systematic approach to the storage, searching and retrieval of
information relevant to the project so that information is easily accessible. A PMIS
automatically controls the following processes in relation to data:
o input
o storage
o processing
o output
o control/security
 May include:
o access authority levels
o complex computer-based systems
o data ownership considerations
o modified systems to cater for unique project requirements
o privacy considerations
o simple manual systems.
A PMIS sets a standard protocol for recording and storing information ensuring that it is gathered,
collated and recorded in a consistent manner throughout the life of the project. Procedures and
formats for documenting information will be dictated by the PMIS so that all who input information
will do so to the agreed standard. The consistency makes analysing and comparing information
throughout different stages in the project much more efficient and accurate. A PMIS will usually be
managed by a designated person or a team of designated people responsible for different areas of
the project. The information within the PMIS will be quality assurance checked by them to ensure
accuracy and relevance of information communicated to stakeholders.
BSBPMG521 LEARNER GUIDE 88 | P a g e Version 3.0
A PMIS helps to keep information relevant and up to date. When reporting during the project the
information that is communicated must be real-time and accurate at the time of reporting and in
accordance with scheduled time frames. A PMIS can generate automatic updates of specific
measures within the project. A simple manual system does not have this facility and is open to
human error.
Having access authority levels, data ownership and privacy considerations all help to preserve the
integrity of the information held on the PMIS.
The PMIS will also have the agreed standards and expectations of the project deliverables and plan
programmed into it so that each time actual current status is recorded it can be compared against
what the planned status should be and any necessary changes made to the project plan and/or
schedule.
BSBPMG521 LEARNER GUIDE 89 | P a g e Version 3.0
4.2 Analyse and submit status reports on project progress and identified
issues with stakeholders and relevant authorities
Monitoring and controlling
During the execution stage of the project you will be continually assessing and reporting on the
progress of the project to stakeholders and relevant authorities and also any identified issues that
may compromise or hinder the project. These reports will serve as a basis to either continue with
the project as planned if all is running to schedule, cost and to quality expectations or implement
changes to the schedule and/or plan if it is not.
Project reports
During the life of the project there will be a number of reports to prepare, produce and release for
different aspects of the project and for different stakeholders.
Status reports may include:
 Client progress reports
 Internal or external
 Regular consolidated reports to project authority
 Reports under contractual obligations
 Specific budget and schedule reports.
Project status reports
As explained in the name, this report details the progress of the project including:
 Project status summary – this is a snap shot of the progress of the project that
demonstrates the percentage of completion and the current status, often by a RAG
dashboard, of the key elements of the project including:
o scope
o schedule
o cost
o risks
o quality
For example:
Project status summary Percentage complete:
55%

Scope

Schedule

Cost

Risk

Quality

 Work planned last week
 Work completed last week – and any work outstanding from the work that was
planned for this week and reasons why. Also include any milestones reached and
deliverables met
 Work planned for next week – include expected deliverables and milestones to be
met and reached
BSBPMG521 LEARNER GUIDE 90 | P a g e Version 3.0
 Open issues – this details issues that have already been identified and procedures
put in place, and should include the status of the issues
 Open risks – this details risks that have been identified and have already occurred
or on the verge of occurring
 Deliverables and milestones – this should contain information about each milestone
in terms of work breakdown structure, the planned deadline, the forecasted
schedule, the current actual deadline, and the status (ahead, on or behind
schedule). The same information should be included for each deliverable
 Open change requests – any requests for changes in project plans, scope or
schedule (or any other changes to any aspect of the project plan) should be detailed
here with the date of request documented and the status of the request (in review,
approved, or denied).
 Key performance indicators.
Risk register
Again, self-explanatory, the risk register is an ongoing document that reports the following:
 Potential risks to the life or progress of the project
 The extent of the potential negative impact on the project caused by the risks
 Contingency plans to deal with the risks.
Issue log
The issue log is a document that reports and records and risks that have been realised and
unexpected events that have occurred and interrupted the project. It documents the way in which
the incident has been dealt and the impact it has had on the project. The accuracy of these reports is
important for auditing purposes.
Executive summary
This is a detailed report that provides in depth information about the status of the whole project and
the impact it is envisaged to have on the bottom line of the organisation.
Everything else report
These reports are specific to each individual project and can be about anything and everything
associated with it.
Preparing and producing reports
When preparing and producing a report there are a number of things you have to keep in mind.
Initial planning:
 Make sure you understand the topic of the report
 Purpose of the report – persuade, inform, argue, evaluate, advise
 Audience of the report
 Format required.
If you are given instructions and guidelines to follow, make sure you do.
BSBPMG521 LEARNER GUIDE 91 | P a g e Version 3.0
Planning and researching:
 Determine the key aspects of the report to understand what information is required
 Keep the topic in mind when researching and reject any information that is
irrelevant
 Keep records of sources used.
Report structure:
 Determine the format of the report – is there a specific template used by the
organisation?
 Determine the content. Does the report require any of the following:
o title page
o contents page
o terms of reference
o introduction
o main body
o supporting evidence
o summary/results
o evaluation
o conclusion
o recommendations
o glossary/references/bibliography/appendices
 Language style – is the tone of the report formal or informal?
Proofreading and checking the finished document for:
 General layout and style
 Coherence of the text
 Grammar, spelling and punctuation
 Whether it has met the brief?
Content
When producing reports it is important that the content is accurate, clear, concise and well
structured. It must contain all relevant information but must not breach any confidentiality or
security protocols.
BSBPMG521 LEARNER GUIDE 92 | P a g e Version 3.0
4.3 Analyse and submit impact analysis of change requests for approval,
where required
Impact analysis
An impact analysis is a way of forecasting the full impacts that a proposed project change may have
upon the project objectives, deliverables and outcomes in order to decide whether or not to
implement the change. It should be used as a preventative measure to identify and avoid risks
before they occur, and not a reaction to risks after they have been realised and the damage to the
project has been done. In the same way that you submitted a project proposal in the initiation stage
that documented the reasons for completing the project, the changes it would make to the
organisation, and the benefits it would bring, an impact analysis identifies risks to the performance
and progress of the project and changes that could be made to avoid realisation of the risk and thus
improvement to the project.
By identifying risks before they become problems, as a project manager you can complete an impact
analysis on a proposed change to the project to submit for approval to relevant authorities before
any disasters occur. By averting disasters and instead planning, communicating, and managing a
smooth and considered change in conjunction with the rest of the project team, you gain their trust
and respect as a measured and organised project manager who knows what they are doing and
understands the direction the project should be taking.
Impact analysis is concerned with identifying all possible negative impacts and effects that the
proposed change could have on the project. For small changes and for changes in small projects, the
impact analysis can be completed by just one person without the input of other project team
members. For large decisions in multi-functional organisations, input should be sought from all
relevant project team members and departments.
Impact analysis may include:
 Assessment against project quality
requirements
 Forecasting against triple constraints
(scope, time and cost)
 Review of project baselines against
proposed change.
Stages in conducting a thorough and effective impact analysis:
 Planning – if gathering input from the wider project team (recommended in large
decisions and when the change will affect different functions and departments)
ensure that they are clearly briefed on the features of the proposed change and the
reasons for it. Ensure that they understand the change being proposed
 Gather the negative impacts that the proposed change will have on each team
member’s function and record all suggestions. If this is done as a brainstorming
activity at a meeting with all function representatives you may want to set an
agenda so as to keep the contributions in a semblance of order. You may want to
divide the impacts into different project areas and functions such as the:
o departments within the organisation
BSBPMG521 LEARNER GUIDE 93 | P a g e Version 3.0
o nine functions of the project
o vendors
o deliverables
o project objectives
o organisational strategies and goals
o culture and values of the organisation
o team dynamics
o organisational structure in terms of
staffing
o work breakdown structure
 Ensure you identify how, if at all, each negative impact will affect other areas of the
project. You might find that the proposed change is too great to manage effectively
and within the triple constraints of the project
 Evaluate the impacts and their possible effects on the triple constraints or the
project, the project deliverables, project objectives and outcomes, and
organisational objectives. Come to a balanced and measured decision as to whether
the change will cause more negative effects than the risk you are trying to prevent
 Identify how you will manage the change if the decision is to go ahead with the
proposed change:
o what actions will you need to implement if the change goes ahead?
o how will you communicate the changes to the members of the project team
that will be affected by the change and how will you get their support as
opposed to their resistance?
o what contingency plans will you put in place should the possible negative
impacts be realised?
Changes
Changes could be made to any aspect of the project including:
 Triple constraints – scope, budget, deadline
 Quality – of deliverables, production,
supplies, raw materials etc.
 Work breakdown structure
 Organisational structure
 Delegated authorities
 Suppliers
 Deliveries
 Management plans
 Governance structure
 Project plan
 Project schedule, and so on.
BSBPMG521 LEARNER GUIDE 94 | P a g e Version 3.0
Approvals for change requests
This procedure will be different in each project team, organisation and hierarchy structure but the
procedures for managing change will be documented in your change management plan.
This document will detail the:
 General information:
o request number
o name (of person submitting request)
o project name
o date requested
 Proposed change:
o description
o reason for change
 Expected impact on project including:
o performance
o technical
o schedule
o budget
o impact on other projects
 Decision by delegated authority:
o approval/denial/approved with conditions
o name, title and role of the delegated authority
o reason for denial (if applicable)
o conditions for approval
o signature and date.
BSBPMG521 LEARNER GUIDE 95 | P a g e Version 3.0
Project change request form example

General information

Request number: Name: Project name: Date of request:

Proposed change

Description of change: Reason for change:

Expected impact of change

Performance impact: Technical impact: Schedule impact: Budget impact: Other impacts: Impact to other projects:

Decision by delegated authority

Approved Denied Approved with conditions Name/title/role: Reason for denial: Conditions of approval: Signature: Date:

BSBPMG521 LEARNER GUIDE 96 | P a g e Version 3.0
4.4 Maintain relevant project logs and registers accurately and regularly to
assist with project audit
Project logs and registers
Throughout the project you and your project team should be keeping accurate and up to date
records of all project activity that will assist with the project audit and evaluation on the completion
of the project. The more accurate and frequent the record keeping, the easier it is to complete a
transparent audit and the more precise and valuable the lessons learned report will be. Not only
does it assist on the completion of the project it also helps during the monitoring and controlling
stage because it enables an ongoing evaluation of the project, helping to identify potential risks and
conducting impact analyses.
Project logs and registers may include:
 Change log
 Daily log
 Issues log
 Quality log
 Risk register
 Task-completion log
 Version-control log.
Change log
As the name suggests the change log is a central area in which to record and monitor all of the
changes made during the life of the project. Records can include:
 Change management issues
 Amount of change required to meet project objectives
 Individual changes made within the project including:
o nature of the change requested
o impacts of the change if approved
o change approval details including conditions
o implementation methods and schedule of changes
o status of changes (requested/under review/approved/denied).
Daily log
The daily log is set up by the project manager and is their responsibility to maintain. It can take any
form that the project manager desires from a paper based diary, a ring binder to bespoke electronic
software. It acts as a daily tracker for all aspects of the project.
The daily log includes day to day information including the following:
 To do list/actions to be taken
 Reminders
 Decisions to be made
 Meetings held and resulting action points
 Potential risks
BSBPMG521 LEARNER GUIDE 97 | P a g e Version 3.0
 Persons responsible for actions
 Target dates by which actions should be complete.
Issues log
As we have already established, all projects will encounter issues and the issues log is where they
must be documented. The issues log is a rolling record that:
 Numbers the issue
 Describes the issue
 Prioritises the issue (usually high, medium or low)
 Assigns the issue to a category
 Records who reported the issue
 Assigns responsibility of the issue to a member of the project team
 Records the status of the issue (open/resolved)
 Records the data of resolution
 Records actions taken to resolve the issue and the outcomes of each action.
The issues log should be reviewed regularly and kept updated in order to ensure issues are being
dealt with promptly and appropriately by the designated member of the team, and in order to
provide accurate reports to stakeholders.

Issues log
Project name:
Issue number and date	Description	Priority	Category	Reported by	Assigned to	Status and date of resolution	Actions taken
001 06.03.20 15	Bird nesting inside warehouse	Low	Security	B. Johnson	V. Wade	Closed 09.03.15	Environmental services attended and removed nest
002 10.03.20 15	Vendor pulled out of contract	High	Resources	L. Morris	M. Darwin	Open	New vendor required

Quality log
Your quality management plan should contain a section that details the quality control
measurements you will use for quality assurance and quality control. Quality assurance testing will
have been built into the project schedule at appropriate intervals. If these quality control
measurements are not met during the testing procedures, remedial action will have to be taken. All
findings must be documented on the quality log. You may find that substandard quality poses a risk
to the project, becomes an issue, and ultimately requires a change resulting in the information
appearing on a number of different project registers.
Your project may have two separate quality logs, one for quality assurance and the other for
quality control, but they will both require the same information such as:
 Trial/test number
 Date of test
 Process measured
BSBPMG521 LEARNER GUIDE 98 | P a g e Version 3.0
 Required value
 Actual measurement
 Whether this value is acceptable
 Recommendations if it is not acceptable
 Date resolved.
Risk register
The risk register is quite a complex document that is more like a risk assessment than simply
information inputted into a document. Calculations need to be made to evaluate the level of risk
each one poses to the project and these need to be reviewed as actions are taken to prevent or
minimise risks.
A risk register may look something like this:

Risk identification	Qualitative rating	Risk response
Risk	Category	Probability	Impact	Score	Ranking	Response	Trigger	Owner

Description of each key term in the table:
 Risk – this describes the cause of the risk, the risk itself, and the effect the risk will
have on the project
 Category – this denotes which area of the project will be affected by the risk
 Probability – this is the likelihood that the risk will occur; it is on a scale of one and
10 with 10 being the most likely
 Impact – this is the impact the risk will have on the project if it is realised; again on a
scale of one to 10 with 10 being the biggest impact
 Score – this is determined by multiplying the scores from the probability and the
impact; this score is on a scale of one and 100
 Ranking – the priority of the risk in relation to other risks that is determined by the
score
 Response – this is the course of action to be taken should the risk occur
 Trigger – this is an indicator that the risk is about to occur or something that incites
its occurrence
 Owner – this is the person assigned by the project manager who is responsible for
identifying the trigger and managing the risk if it occurs.
Task completion log
The task completion log is a list of all of the tasks that must be actioned for the completion of the
project. It contains all of the project activities requiring completion, the time frames for completion
and the member(s) of the project team responsible for completing them. In a large project, this task
list can be huge. The most practical way of organising the task completion log is to break it down
into project parts and list all of the tasks required by each part. You can use the work breakdown
structure as a guide to dividing the project into parts; each deliverable will be classed as one part of
the project and then the tasks involved in producing that deliverable can be sub-divided to make it
more manageable.
BSBPMG521 LEARNER GUIDE 99 | P a g e Version 3.0
The tasks then need to be documented on a spread sheet or a GANTT chart. A Gantt chart is a visual
representation of a project schedule that shows you what has to be done within your project and
when it needs to be done by. By laying out the project tasks and events in the order they should be
completed in, the Gantt chart helps to sequence those events and tasks. It will show the project
activities displayed against time and the time is broken down into increments; days, weeks or
months. To the left of the chart is the list of activities and along the top there is a suitable time scale.
The activities are represented by bars and the position and length of that bar reflects the start date,
duration and end date of each activity. This chart uses the horizontal lines to show the amount of
work that is done in certain periods of time in relation to the amount of time that was originally
planned for those periods.
A Gantt chart allows you to easily see:
 The start and end date of the whole project
 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 Gantt chart is the most common and easiest way to create dependencies and to show
predecessor and successor relationships.

W/C 1st	W/C 8th	W/C 15th	W/C 22nd	W/C 29th	W/C 6th
Briefing
Research
Writing
Editing
Distribution

 

Week 1	Week 2	Week 3	Week 4	Week 5
Task A
Task B
Task C
Task D
Task E

 

Week 1	Week 2	Week 3	Week 4	Week 5	Week 6
Task A
Task B
Task C
Task D
Task E

BSBPMG521 LEARNER GUIDE 100 | P a g e Version 3.0

Week 1	Week 2	Week 3	Week 4	Week 5	Week 6
Prepare
Research
Write
Check
Send

You might want to add more information to the task completion log such as:
 Estimated time frame for completion
 Person responsible for each task
 Which tasks need to be started earlier than others and the reasons for this
 Important milestones and key turning points
 Date of completion
 Any other comments or notes regarding each task.
Version control log
Version control is directly related to the change management process. As we have discussed,
changes in projects are inevitable and whilst we have identified the need for a change log, we have
not considered the outcome of the changes to the products, procedures or services produced by the
project. We have considered the impacts on the project, but not the actual tangible changes to the
outputs of the project. For example, if mountain bikes are one of the outputs that have already been
sold to customers, and half way through the project there is a change to an aspect of the design such
as the break cables but it is not recorded and the old design plans are discarded rather than filed or
archived, there is nothing to refer to when a customer who has bought one of the first versions of
the mountain bike returns to have the cables repaired or replaced because they have broken. It may
be that the project team staff has not changed and that they know about the changes to the bike
and know to repair the cables with the first design, but the organisation may no longer stock the old
design because they do not use them anymore. It might also be that the project team who
implemented the changes in design to the break cables have moved on and taken the knowledge
with them.
This is why it is important to keep a version control log that documents the following information:
 All of the products ever produced by the organisation
 A version history of each product which details:
o each discrete change made to the product or procedure
o the new design/plan/process
o the version number.
Procedures for capturing and filing records
Keeping accurate records is vital to maintaining good business and for effective administration.
Records are a historical account of your project and can be used to make informed decisions on
future plans and also provide evidence of accountability. They provide a trail of communication,
decisions and actions for auditing purposes.
BSBPMG521 LEARNER GUIDE 101 | P a g e Version 3.0
To decide what records need to be captured and filed, the project needs to consider its core
business, administrative, legal and social context. It also needs to consider risks to the business if
important information is lost or compromised.
Capturing
Any record you capture is documenting the project.
Records take a variety of forms including:
 Emails
 Written reports
 Maps
 Plans
 Audio/visual recordings.
A record should be documented in a way that best supports the needs of the project.
Records must be captured to the project’s records management system to ensure they are:
 Accurate
 Genuine
 Unaltered
 Secure
 Available
 Related to other relevant records.
Describing
In order to manage your records over time and for ease of locating the right document, records need
to be described, and the way this description is called metadata.
Examples of metadata include:
 Title
 Author
 Registration/account number or any other unique feature
 Date created
 Subject matter
 Format
 History of use.
Where possible, this process should be automated.
Procedures for updating records
Records can be updated manually or automatically. Updating records manually is time consuming
and has the inherent risk of human error.
In a Database Management System (DBMS) a stored procedure is a set of Structured Query
Language (SQL) statements with a specific name that automatically updates records with one
command. It can be used by a number of programs within the DBMS.
BSBPMG521 LEARNER GUIDE 102 | P a g e Version 3.0
Using stored procedures helps to:
 Control access to data (end-users can input and change data but cannot re-write
procedures)
 Preserve data integrity (all data is entered consistently).
Security procedures
The project should have an information security policy and procedures that cover the following
areas:
 Document control
 Document location
 Revision history
 Approvals
 Distribution
 Document history
 Enquiries
 Introduction and purpose
 Scope
 Your responsibilities
 Project’s responsibilities
 Where to find more information
 Equal opportunities impact assessment.
Why is auditing important?
However large or small the project, it is important to keep accurate records for auditing purposes.
The project could be subject to external, legal auditing in which case it is even more important to
store information appropriately. Internal auditing can help to detect and prevent fraud and theft,
test internal control and monitor compliance with internal policy and external regulations. It also
aids continuous improvement as mistakes or missed opportunities can be identified and resolved to
improve future projects.
BSBPMG521 LEARNER GUIDE 103 | P a g e Version 3.0
4.5 Ensure associated plans are updated to reflect project progress against
baselines and approved changes
Project baselines
Project baselines are the agreed estimated project frameworks established in the initiation and
planning stages of the project by management and stakeholders. They set out the benchmarks for
the running, measuring and controlling of the project. As projects progress, changes may need to be
made to the baselines to be of any use as a measurement tool. Baselines are generally made up of
the triple constraints.
Project baselines are generally related to:
 Scope baseline
 Cost baseline
 Schedule baseline
 Quality baseline.
Progress should be assessed and measured against
baselines in terms of:
 Planned work
 Scheduled work
 Actual work.
Gantt charts are a particularly useful tool to measure progress against project baselines. See the
previous chapter for more information.
These assessments, along with other reports during the monitoring and controlling stage such as
risks and issues, may result in alterations to all or some of the baselines. Because the baselines
underpin the project plan and schedule the associated plans which have been based upon the
baselines may also have to be updated and/or amended.
Updating associated plans to reflect project progress against baselines and
approved changes
Associated plans that may need to be amended include:
 Communications plan (stakeholders and information) – this may be the plan that
requires the least amendment as regardless of changes to baselines, stakeholders
still need to be kept updated and information still needs to be disseminated. The
updates to the communications plan may probably be the frequency of
communications and perhaps the detail in the information disseminated,
particularly if progress is well under schedule, costs are well above budget, quality
is substandard, and scope creep is beyond control
 Human resources plan – changes to the human resources plan might include closer
performance management if progress is under baseline requirements, and
reallocation of resources
 Procurement plan – changes to the procurement plan might include changes to
terms and conditions in supply contracts if there are delays in supplies or supplies
are of a substandard quality, and reallocations of budgets
BSBPMG521 LEARNER GUIDE 104 | P a g e Version 3.0
 Project budget – changes to the budget may include further investment, reduction
in investment, and modifications to existing budgets within departments
 Project schedule – delays may require extensions to the schedule, over
performance may require project activities to be brought forward and consequently
this will have an impact upon the allocation of resources and potentially the
procurement plan as supplies may need to be delivered sooner than originally
estimated
 Quality-management plan – changes to the types and frequency of quality
assurance and control measures and tests may be required if there are issues with
quality
 Risk plan – changes to the risk management plan may include ownership of risks
and triggers to risks if current plans are not working efficiently
 Scope-management plan – further restrictions may need to be imposed on the
management of the scope if they are not being managed appropriately and
threaten the smooth running of other project baselines.
All changes to baselines and associated plans should be recorded in an appropriate register in an
appropriate format with reasons for the changes so that the information can be used in the
evaluation process and for lessons learned.
Approved change requests
In chapter 4.3 you looked at change request forms following impact analysis.
The same procedure can be followed when proposing changes or revisions to project:
 Policies
 Management plans
 Procedures
 Costs or budgets
 Project schedules
 Associated plans.
BSBPMG521 LEARNER GUIDE 105 | P a g e Version 3.0
Project change request form example

General information

Request number: Name: Project name: Date of request:

Proposed change

Description of change: Reason for change:

Expected impact of change

Performance impact: Technical impact: Schedule impact: Budget impact: Other impacts: Impact to other projects:

Decision by delegated authority

Approved Denied Approved with conditions Name/title/role: Reason for denial: Conditions of approval: Signature: Date:

BSBPMG521 LEARNER GUIDE 106 | P a g e Version 3.0
Section 5 Manage project finalisation
5.1 Identify and allocate project finalisation activities
Project finalisation activities
You are reaching the completion of your project and you now need to complete the final activities in
preparation for the handover to the client.
Project finalisation activities may include:
 Completing financial transactions
 Consolidating and storing project data
 Documenting outstanding project issues
 Obtaining or providing certifications
 Preparing final project reports
 Updating organisation knowledge
management.
Completing financial transactions
All financial transactions need to be completed and recorded appropriately and in compliance with
legal and accounting requirements and also for auditing purposes. The project cannot be handed
over to the client with any outstanding monies owed. Financial transactions may include payments
to suppliers, wages for the project team, rent for premises, utility bills and many more specific to
your project.
Consolidating and storing project data
All the documentation and data generated throughout the life of the project should be gathered,
collated in an appropriate manner and stored securely. The data will be used for the review of the
project and should not be archived until the review is complete. Sensitive data should be stored
securely unless it is of no future value and in these circumstances it should be destroyed by
shredding or other similar manner. Financial data should be kept for a minimum of seven years
according to legal requirements.
Each document should be accompanied by the following metadata:
 Title
 Author
 Registration/account number or any other unique feature
 Date created
 Subject matter
 Format
 History of use.
Where and how information is stored will depend upon the nature of the information and who
requires access to it and when. It may be filed on specific computer systems unique to the project
and may require authorisation passwords or user permissions to retrieve it. It may be paper based
and stored in a filing cabinet. It is important that secures systems are in place for the storing of all
information and that contingency plans and back-up systems are in place should there be any
BSBPMG521 LEARNER GUIDE 107 | P a g e Version 3.0
security breaches or issues. You should have designated gate keepers of stored information that are
responsible for the integrity of the information.
Documenting outstanding project issues
Hopefully all issues during the life of the project will have been resolved but you need to check the
relevant registers for any issues, risks or changes that are unresolved or in the process of being
resolved. Any outstanding project issues should be clearly documented in a report and discussed
with stakeholders and the client prior to handover. Reasons for the remaining issues should be
clearly explained with recommended solutions.
Obtaining or providing certifications
Project completion certificates may be issued, and in some industries legally required, to sign off the
completion of the project to a guaranteed industry standard, or a standard agreed by stakeholders
and the project team at the outset of the project. Certification is predominant in the construction
industry following compliance with a number of workplace health and safety checks prior to sign off.
Preparing final project reports
In order to undertake a final review, lessons learned report, and the final project report, all reports
on the nine functions of the project management need to be completed, along with final
assessments of project baselines and final forecasts.
Updating organisation knowledge management
Knowledge management is linked to information management and refers to the sharing of the
knowledge of the individuals of a project team or organisation with the rest of the organisation for
continuous improvement in future projects. Knowledge is often lost if not captured, developed,
shared, and subsequently used to improve efficiency within an organisation. The knowledge of an
organisation is generally captured on a database that should be updated in a standard and agreed
procedure during and on completion of the project.
Allocating finalisation activities
It will depend on the size of the project and the project team as to whom you allocate finalisation
activities.
In large projects the following allocations would be obvious and feasible:
 Completing financial transactions – cost manager in association with the
procurement manager
 Consolidating and storing project data – communications manager
 Documenting outstanding project issues – Risk manager in association with scope
and time manager
 Obtaining or providing certifications – quality manager
 Preparing final project reports – integration manager in consultation with all nine
project function managers
 Updating organisation knowledge management – human resources manager.
BSBPMG521 LEARNER GUIDE 108 | P a g e Version 3.0
5.2 Ensure project products and associated documentation are prepared for
handover to client in a timely manner
Project products
A project product is anything tangible that has been produced by the project either as an end item
or a component of other products. Because project products are usually continued to be used within
the organisation on the completion of the project, all of the relevant documentation such as training
manuals, operating instructions, URLs, passwords and authorities, troubleshooting information, and
guarantees, needs to be handed over to the client in order for the products to function after the
project team depart. Work must therefore be spent on preparing this documentation to handover to
the client by the agreed time frame with any training needs addressed.
The handover and acceptance of project products to the client may include:
 Products meet the specifications and
quality standards set out in the
project plan
 Products meet the satisfaction of the
client who is willing to sign off the
products
 Supporting materials and practical
assistance meets the expectations of
the client
 Products meet the triple constraints
 Risks and issues have been resolved
or are under control.
Associated documentation
When you handover the project to your client you will need to ensure the relevant documentation is
prepared and handed over to your client along with the project products.
Associated documentation may include:
 ‘As built’ design specifications
 Certificates, guarantees, licenses, indemnities and warranties
 Product or service specifications
 User, training and installation manuals
 Any other associated documentation.
Handover process
When the project team hands over the products to the client the documentation that is handed over
with them should support a seamless transfer and supply all users with the necessary information to
use the products that have been produced by the project. This documentation may require support
of training sessions and/or on the job training.
BSBPMG521 LEARNER GUIDE 109 | P a g e Version 3.0
The handover of the products and associated documentation may be supplemented with an
overall project handover to operations document that details the following:
 Document purpose – record of the transfer of all the information required to
operate and/or use the products handed over including key project documents
 Outline of changes/enhancements – details of any changes or enhancements made
to the original specification and/or design, including original plans and updated
versions, and version history
 Support – any technical or practical support implemented throughout the life of the
product or for a period of warranty
 Handover documentation – all documentation associated with the products
 Risk log – risks concerned with the products themselves, not the entire risk register
of the project
 Issues log – again, any issues that have occurred with the products, open and closed
 Lessons learned – any advice for improvements in future production of similar
products.
The practicalities of the handover of products and associated documentation should also be
considered and arranged with consideration given to:
 Whether documentation is handed over in a hard copy and/or electronic form
 Security of information as it is handed over – including the handover of authorities
and passwords and the physical handover of manual documentation
 The time frame of the handover
 Who is responsible for the handover – including the arrangements, the physical
handover, the electronic transfer etc.
 Whether documentation is held by the project team, and if so, for how long
 The owner of the property – in terms of copyright and intellectual property rights
 Training sessions scheduled/already been held.
BSBPMG521 LEARNER GUIDE 110 | P a g e Version 3.0
5.3 Finalise financial, legal and contractual obligations
As the project draws to a close there will be a number of loose ends to tie up. The financial, legal and
contractual obligations are probably the most important to finalise as failure to do so could result in
serious breach of contracts and may even lead to legal action.
Financial obligations
Dependent on the scale of your project you may have financial obligations to finalise both internally
and externally.
Internal financial obligations may include the final accounting for the overall spend of the project,
broken down into the following project areas:
 Cost-management plan – reconciliation of planned expenditure and actual
expenditure
 Work breakdown structure – how did the actual spend compare to the budgets
allocated to each component of the WBS?
 Change and risk management – how did changes to the project affect budgets?
 Procurement records and accounts need to be finalised and recorded appropriately
 Payroll needs to be finalised and records stored/handed over appropriately
 Vendors should be given their final payments and accounts update accordingly;
there should be no outstanding invoices.
External financial obligations relate to outside borrowing; funds that have been lent by sources
other than the stakeholders and investors, such as bank loans or contracts for services (utilities for
example). It is important to finalise these external financial obligations as, if the obligation is not
honoured or paid in full, it could result in court action and the seizure of assets of the project and/or
the organisation.
Legal obligations
Contracts themselves are legal documents and we will look at them shortly, but in terms of finalising
legal obligations within the project itself, you should consider, if you have one, your project
management service level agreement.
The project management service level agreement is a contract established
at the beginning of the project to determine the following:
 Project terms – this generally includes the time line and
the budget and any penalties for which the project team is
liable if the terms are not met. Any penalties should have
been avoided if you have reviewed the project baselines effectively throughout and
negotiated changes with the client and stakeholders accordingly
 Outsourcing – how contracts with vendors, contractors and sub-contractors are
managed
 Communication plan – did you meet the terms and conditions of communications
between the stakeholders and the client?
 Risk insurance – finalising the business liability insurance or extending it should
there be any anticipated issues to the successful completion of the project
BSBPMG521 LEARNER GUIDE 111 | P a g e Version 3.0
 Confidentiality agreements – ensure confidentiality has not been breached
including employee theft or breach of intellectual property.
Contractual obligations
During the life cycle of the project you and your procurement manager will have negotiated,
established, possibly changed terms and conditions of supply contracts for vendors and contractors.
In the finalisation stages you need to ensure that all terms and conditions have been adhered to,
particularly if they have been changed throughout the project.
Final checklist should include:
 Ensuring any changes to contracts and terms and conditions have been updated
following negotiations and records kept of all the changes made with contracts
being agreed, re-written and signed by both parties where appropriate and adhered
to
 The statement of work or service level agreement was clearly defined and
deliverables clear, amended if appropriate following the review of the
procurement-management plan and adhered to
 All timelines and schedules were realistic and detailed clearly with no ambiguities
and communication with vendors confirmed that they were able to meet the
requirements, and if not, actions were put in place to ensure that they could
 All supply contract schedules were consistent with one another (such as timelines)
 Cancellation policies were clear and included all requirements of both parties
 Key personnel were identified and their roles and responsibilities clearly defined
 Procedures for monitoring and controlling supplier underperformance were
included and clear with any penalties outlined. Any issues
of underperformance were highlighted by the review and
were dealt with according to the procedure, documented
and reported to the relevant authority with changes
made to suppliers if necessary
 All key terms were defined in a glossary
 Procedures for dealing with disputes were included and where necessary were
followed, documented and reported as appropriate with actions put in place to
ensure the dispute and the time taken to deal with it did not compromised the
vendor’s ability to meet their contractual obligations on time
 All approvals from higher authorities were obtained prior to signing contracts and
agreements
 All legal requirements were included and ratified by a legal professional, and where
applicable, changes to contracts and terms and conditions were also reviewed and
ratified
 The contracts were signed by all relevant parties at each relevant stage throughout
the project
 The contracts were and are stored appropriately and securely.
BSBPMG521 LEARNER GUIDE 112 | P a g e Version 3.0
5.4 Undertake project review assessments as input to future projects
Project review assessments
At the end of every project it is important to spend time reviewing, evaluating and assessing how
successful and effective each aspect of the project has been in order to identify areas of
improvement for future projects.
Project review assessments may include:
 Benefits realisation review
 Outcomes evaluation
 Post-implementation review
 Project lessons learned.
Benefits realisation review
As discussed in chapter 1.3, benefits do not just happen as soon as the project is finished. Time
should be invested in embedding the procedures and practices that will lead to full realisation of
benefits. The true benefits may not be seen for five years after completion of the project. For
example, in a landscape gardening project, you would not expect the gardener to rotate and prepare
the land, plant seeds, bulbs and saplings and then leave them to bloom alone without any after care
and cultivation. The same principle, although perhaps not as extreme, applies to all projects.
Benefits realisation includes:
 Delivering training
 Carrying out demonstrations
 Preparing training manuals
 Providing help desks and trouble shooting
 Soliciting feedback from employees and the client
 Making changes to the project after it has been completed.
Benefits realisation may not take place immediately after the completion of the project. It might not
occur until six months after the project implementation review to allow the project time to establish
itself.
The benefits realisation review may include the following:
 Purpose of the review – to determine whether the expected benefits of the project
have been realised, and whether any issues or problems have occurred
 Expected benefits that were documented in the original business case and project
initiation document
 How the benefits have been measured
 Resources used in benefit realisation – what support has been implemented since
the completion of the project?
 Resources required to complete the review
 Actual benefits realised after project handover:
o do they meet the expected benefits, if not, how far off are they?
BSBPMG521 LEARNER GUIDE 113 | P a g e Version 3.0
o are they different to the expected benefits?
o are there more benefits than expected?
o were the benefits realised faster than expected?
o are there further benefits to be made?
o do changes need to be made to the support
structure in order to realise benefits and if so, is
this cost effective?
 What non-benefits have been realised and what problems have they caused?
Outcomes evaluation
The outcomes evaluation will be very similar to the benefits realisation review as outcomes are very
similar to benefits. Outcomes and benefits are the result of your work within the project and directly
related to the project objectives.
The outcomes evaluation would ask the following questions:
 Expected and agreed project outcomes set out at the beginning of the project, short
and long-term
 Key performance indicators to measure the outcomes
 Actual outcomes and whether they meet the initial expected outcomes including:
o changes to knowledge within the organisation
o changes to actions and behaviour of the organisation itself and its employees
o changes to conditions
 Any unexpected and unwanted outcomes that are detrimental as opposed to
beneficial
 Any unexpected but welcome outcomes that have improved the organisation
 No change at all.
Post-implementation review
A post-implementation review (PIR) is the final step in the life cycle of the project. It is a critical
evaluation of the entire project that determines whether or not the project was a success and the
reasons for this. It is usually conducted by somebody impartial and usually between three and six
months after the completion of the project. This allows the project work time to settle into the
organisation and enables the benefits substantial time to be realised. It assesses each aspect of the
project to determine whether or not the project has met its objectives.
A PIR performs the following functions:
 Measures the objectives, benefits and outcomes
 Determines whether or not the project was within its scope
 Assesses the quality and accuracy of the final deliverables
 Reviews the project against the schedule
 Compares the actual expenditure against the budget
 Identifies the key achievements of the project and milestones
 Provides information and evaluation for lessons learned
BSBPMG521 LEARNER GUIDE 114 | P a g e Version 3.0
 Is a method of reporting the findings to the stakeholders
 Evaluates the final outcome of the project.
Lessons learned
A lessons learned report is a vital piece of information to help to improve project management in
future projects. Every strategy employed by the project team throughout the project should be
evaluated, reported on and fed back to project authorities or senior management within the
organisation at the end of the project.
Record essential information
In order to put all the strategies into context it is important to
record details of the project.
Essential information includes:
 Project objectives, benefits and outcomes
 Project manager and leaders
 Description of the
client/customer/sponsor/investors –
understanding their needs and expectations in
terms of governance will have a bearing on the
review
 Dates of the project
 Deliverables
Document a complete picture
If lessons are going to be learned, the mistakes need to be included as much, if not more, than the
successes in order to prevent them happening again. Include what worked, what didn’t work, and
why. It is as important to document the reasons for strategies not working because they may work
well in alternative projects, but just were not suited to this particular one. Suggest more efficient
methods of management in the scenarios you have experienced within the project and what you
would do differently in hind sight.
You should have a plethora of documents and reports that have been generated throughout the life
of the project from which to compile your lessons learned report. Capturing and recording
information as you go through the project allows you to analyse successes and failures at different
points within the project and enables a more balanced and accurate review of governance
effectiveness. If you haven’t kept records throughout the project, this in itself could be a valuable
lesson learned for the next project.
Be honest
In order to get a full picture of how effective project management was, ascertain honest and open
feedback from all involved. Feedback should be sought from all team members from the top to the
bottom in the chain of command and all information, however small, should be noted and reported
in order to make the best improvements to future processes. Seek feedback from all other internal
and external stakeholders in the same manner. Asking for the opinions of your stakeholders makes
them feel valued and more motivated.
BSBPMG521 LEARNER GUIDE 115 | P a g e Version 3.0
Embrace the negative comments and treat them with respect. These are the most critical aspects of
the report that, if used appropriately, could transform the efficiency of project management
processes. Always searching for continuous improvement keeps an organisation dynamic and at the
forefront of improving efficiency; this mentality makes an organisation attractive to work with and
keeps employees motivated and committed.
Input into future projects
All of the project review assessments should be used to compile one report that highlights areas of
project management and project activities that worked well and should be employed in future
projects. It also highlights room for improvement and serious errors that could have been avoided,
and as such what should not be employed in future projects.
Keeping accurate records, logs and registers from the initiation stage through to the completion of
the project will enable a much more accurate evaluation and review of the success of the project.
Record keeping may be a lesson learned in itself; there are numerous logs, registers and databases
to keep updated, but ultimately they are telling the story of how successful or unsuccessful your
project was. If there are gaps or inaccuracies in the records, the evaluation of your project will not
be complete. This not only has an impact on the project itself, but could tarnish the reputation of the
project management team, particularly the project manager, and that of the client and stakeholders
involved.
BSBPMG521 LEARNER GUIDE 116 | P a g e Version 3.0
Congratulations!
You have now finished the unit ‘Manage project integration’.
BSBPMG521 LEARNER GUIDE 117 | P a g e Version 3.0
References
These suggested references are for further reading and do not necessarily represent the contents
of this Learner Guide.
Websites
Alex S. Brown: http://www.alexsbrown.com/align-proj-strat.html
Bright hub project management: http://www.brighthubpm.com/methods-strategies/67087-projectmanagement-methodologies-how-do-they-compare/
Bright hub project management: http://www.brighthubpm.com/project-planning/63692-projectfeasibility-study-samples/#imgn_0
Bright hub project management: http://www.brighthubpm.com/project-planning/5161-what-is-aproject-charter/
Bright hub project management: http://www.brighthubpm.com/project-planning/65203-theproject-life-cycle/
Bright hub project management: http://www.brighthubpm.com/risk-management/63360-projectmanagement-legal-issues-are-you-at-risk/
Ezine articles: http://ezinearticles.com/?Project-Quality-Management&id=3664876
Ezine articles: http://ezinearticles.com/?Project-Scope-Management—The-BasicPrinciples&id=4687039
Inc.com: http://www.inc.com/michael-olguin/6-tips-to-managing-client-expectations.html
Matchware.com: http://www.matchware.com/en/example/wbs-template-construction-of-a-housedel.htm
Method 123: https://www.method123.com/post-implementation-review.php
Mindtools.com: http://www.mindtools.com/pages/article/newTED_96.htm
Official templates: http://www.officialtemplates.org/project-management-task-list-template.html
Planware: http://www.planware.org/strategicplan.htm
Prince2: http://www.whatisprince2.net/prince2-process-starting-up-a-project.php
Project Management Documents: http://www.projectmanagementdocs.com/project-controllingtemplates/project-status-report.html
Project Management Documents: http://www.projectmanagementdocs.com/project-planningtemplates/risk-register.html
Project Management Guru: http://projectmanagementguru.com/controlling.html
Project Smart: http://www.projectsmart.co.uk/10-golden-rules-of-project-risk-management.php
Project Smart: http://www.projectsmart.co.uk/project-cost-management.php
References for business: http://www.referenceforbusiness.com/management/Mar-No/Missionand-Vision-Statements.html
University of Manchester: http://documents.manchester.ac.uk/DocuInfo.aspx?DocID=8308
All references accessed on and correct, as of 19.03.2015, unless other otherwise stated.

Tags: assignmentexpert, assignmenthelp, assignmenthelpaustralia, assignmenthelper, assignmenthelpuk, assignmenthelpusa, OnlineAssignmentHelp, studytime