learner guide: bsbpmg521 manage project integration...work closely with others to integrate all...

Learner Guide: BSBPMG521

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



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.


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


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


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


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


4. Manage project

control


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


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.


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


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.


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


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.


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

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

http://www.brighthubpm.com/methods-strategies/67087-project-management-methodologies-how-do-they-compare/



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


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.


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.


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


other representatives, and its mission statement and strategic goals, in non-

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


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, action-

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


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.


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


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


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.


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


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


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


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.

https://wiki.duraspace.org/display/VIVO/Project+Governance


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


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

https://www.accc.gov.au/regulated-infrastructure


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.


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.

http://pharmacy.ksu.edu.sa/en/pages/departments/quality/?page_id=16


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.


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


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


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.


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


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

deliverables 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



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

deliverables 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 sub-

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


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


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


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.


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


Planning stage


Agreed outcome

Review and revision of scope


Organisational breakdown structure

Resource allocation



Agreed outcome

Project schedule

Budget allocation

Governance plan



Agreed outcome

Risk assessment

Finalising the plan and obtaining approval

Other

Other


Execution stage


Agreed outcome

Time management

Cost management

Quality management

Change and issues management

Relationships management


Monitoring and controlling stage


Agreed outcome

Monitoring and reviewing all processes in execution stage

Identifying and preventing risks

Minimising changes to project


Closing stage


Agreed outcome

Producing closing report

Redistribution of resources

Administrative work

Next steps for future projects


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


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.


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.


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


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


Week 1 Week 2 Week 3 Week 4 Week 5 Week 6

Task A

Task B

Task C

Task D

Task E


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


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

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

http://www.bestoutcome.com/project-governance-gateways.html

http://www.bestoutcome.com/project-governance-gateways.html


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, non-

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


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


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.


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


Project integration

Quality

Risk

Scope

Time


Communication

Project function How is it interdependent on communication?

Cost

Human resources


Project integration

Quality

Risk

Scope

Time


Human resources

Project function How is it interdependent on human resources?

Communication

Cost


Project integration

Quality

Risk

Scope

Time



Project function How is it interdependent on procurement and contracting?

Communication

Human resources

Cost

Project integration

Quality

Risk

Scope

Time


Project integration

Project function How is it interdependent on project integration?

Communication

Human resources


Cost

Quality

Risk

Scope

Time


Quality

Project function How is it interdependent on quality?

Communication

Human resources


Project integration

Cost

Risk

Scope

Time


Risk

Project function How is it interdependent on risk?

Communication

Human resources


Project integration

Quality

Cost

Scope

Time


Scope

Project function How is it interdependent on scope?

Communication

Human resources


Project integration

Quality

Risk

Cost

Time


Time

Project function How is it interdependent on time?

Communication

Human resources


Project integration

Quality

Risk

Scope

Cost


2.4 Develop a project management plan that integrates all project-management 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.


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.


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.


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


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.


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


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.


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


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.


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.


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.


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.


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.


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.



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:


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


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


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.


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.


Section 4 Manage project control


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


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.


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

http://www.oaic.gov.au/privacy/privacy-topics/business-and-small-business/small-business


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.


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.


4.2 Analyse and submit status reports on project progress and identified issues with stakeholders and relevant authorities


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


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.


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.


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


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.


Organisational structure

Delegated authorities

Suppliers

Deliveries

Management plans

Governance structure

Project plan

Project schedule, and so on.


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.


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:


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


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

Bird nesting inside warehouse

Low Security B. Johnson V. Wade Closed 09.03.15

Environmental services attended and removed nest

002 10.03.2015

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


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.


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


Task A

Task B

Task C

Task D

Task E



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.


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.


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.


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


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.


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:


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


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.


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.


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.


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


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.


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?


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


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.


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.


Congratulations!

You have now finished the unit 'Manage project integration'.


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

management-methodologies-how-do-they-compare/

Bright hub project management: http://www.brighthubpm.com/project-planning/63692-project-

feasibility-study-samples/#imgn_0

Bright hub project management: http://www.brighthubpm.com/project-planning/5161-what-is-a-

project-charter/

Bright hub project management: http://www.brighthubpm.com/project-planning/65203-the-

project-life-cycle/

Bright hub project management: http://www.brighthubpm.com/risk-management/63360-project-

management-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-Basic-

Principles&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-house-

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

templates/project-status-report.html

Project Management Documents: http://www.projectmanagementdocs.com/project-planning-

templates/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/Mission-

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

http://www.alexsbrown.com/align-proj-strat.html



http://www.brighthubpm.com/project-planning/63692-project-feasibility-study-samples/%23imgn_0

http://www.brighthubpm.com/project-planning/63692-project-feasibility-study-samples/%23imgn_0

http://www.brighthubpm.com/project-planning/5161-what-is-a-project-charter/

http://www.brighthubpm.com/project-planning/5161-what-is-a-project-charter/

http://www.brighthubpm.com/project-planning/65203-the-project-life-cycle/

http://www.brighthubpm.com/project-planning/65203-the-project-life-cycle/

http://www.brighthubpm.com/risk-management/63360-project-management-legal-issues-are-you-at-risk/

http://www.brighthubpm.com/risk-management/63360-project-management-legal-issues-are-you-at-risk/

http://ezinearticles.com/?Project-Quality-Management&id=3664876

http://ezinearticles.com/?Project-Scope-Management---The-Basic-Principles&id=4687039

http://ezinearticles.com/?Project-Scope-Management---The-Basic-Principles&id=4687039

http://www.inc.com/michael-olguin/6-tips-to-managing-client-expectations.html



https://www.method123.com/post-implementation-review.php

http://www.mindtools.com/pages/article/newTED_96.htm

http://www.officialtemplates.org/project-management-task-list-template.html

http://www.planware.org/strategicplan.htm

http://www.whatisprince2.net/prince2-process-starting-up-a-project.php

http://www.projectmanagementdocs.com/project-controlling-templates/project-status-report.html

http://www.projectmanagementdocs.com/project-controlling-templates/project-status-report.html

http://www.projectmanagementdocs.com/project-planning-templates/risk-register.html

http://www.projectmanagementdocs.com/project-planning-templates/risk-register.html

http://projectmanagementguru.com/controlling.html

http://www.projectsmart.co.uk/10-golden-rules-of-project-risk-management.php

http://www.projectsmart.co.uk/project-cost-management.php

http://www.referenceforbusiness.com/management/Mar-No/Mission-and-Vision-Statements.html

http://www.referenceforbusiness.com/management/Mar-No/Mission-and-Vision-Statements.html

http://documents.manchester.ac.uk/DocuInfo.aspx?DocID=8308