PFQ2023
PFQ2023
PFQ2023
Fundamentals Qualification
APMBOK 7 Edition
robinjkay@aol.com
All rights reserved. No part of this publication may be reproduced, stored in a retrieval
system, transmitted or utilised in any form or by any means, electronic, mechanical,
photocopying, recording or otherwise without written permission from the author.
ISBN: 978-0-244-91205-5
1
Preface
The information contained within this book is based upon sound and generally accepted project management
principals. It is intended to cover those areas of the APM Body of Knowledge (7th edition, 2020) that are
included in the PFQ syllabus.
To study for this certificate requires no prior knowledge or experience in project management. It is designed
for anyone starting out on the first steps of a career in project management or those simply working in or
around a project environment and who need to know a little more about project management.
There are two ways you can register to sit the PFQ examination: by registering for a training course and exam
with an accredited training provider, or by self-study and sitting the exam on one of APM’s open events or
online.
2
Contents
1 Project Management and the Operating Environment .................................................................. 7
1.1 What is a project? ................................................................................................................ 8
1.2 The Key Purpose of Project Management ............................................................................. 8
1.3 The Project Manager ............................................................................................................. 9
1.3.1 The 4 Key Project Management Roles ............................................................................ 9
1..3.2 The 6 Major Project Management Activities ................................................................. 9
1.4 The Project Management Triangle .......................................................................................10
1.5 Projects v Business-as-Usual ...............................................................................................10
1.6 Programme Management .....................................................................................................11
1.6.1 Programme v Project .....................................................................................................12
1.6.2 Programme Manager Roles & Responsibilities .............................................................13
1.7 Portfolio Management .........................................................................................................13
1.7.1 Benefits of managing groups of projects as a portfolio .................................................14
1.7.2 Differences Between Programmes and Portfolios ........................................................15
1.8 PESTLE Analysis ................................................................................................................15
2 Project Life Cycles and Reviews .................................................................................................17
2.1 A Linear Project Lifecycle ...................................................................................................18
2.1.1 Concept phase (or Initiation/Feasibility) ........................................................................18
2.1.2 Definition (or Planning) phase .......................................................................................18
2.1.3 Implementation (or Execution) phase ............................................................................18
2.1.4 Handover .......................................................................................................................18
2.1.5 Closeout .........................................................................................................................19
2.2 Iterative life cycle ................................................................................................................19
2.3 Time Boxes ..........................................................................................................................20
2.4 Hybrid Life Cycles...............................................................................................................20
2.5 The Extended Project Life Cycle ........................................................................................20
2.6 Phase/Gate Reviews .............................................................................................................21
2.7 Post Project Review/Lessons Learned review ......................................................................21
3 Roles and responsibilities ............................................................................................................23
3.1 Project Organisation Structure .............................................................................................24
3.2 The Project Board ................................................................................................................24
3.3 The Project Sponsor.............................................................................................................24
3.3.1 Sponsor responsibilities .................................................................................................25
3.3.2 Sponsor activities ...........................................................................................................25
3.4 The Project Team & Team Leaders .....................................................................................25
3.5 The End Users .....................................................................................................................25
3.6 Quality Assurance ................................................................................................................25
3.7 The Project Office................................................................................................................26
3.7.1 Project Support Office-PSO ...........................................................................................26
3.7.2 Project Management Office-PMO .................................................................................26
3.7.3 Central Programme Management Office-CPMO ...........................................................27
3.7.4 Benefits of a Project Office............................................................................................27
3
3.8 Project Governance ..............................................................................................................27
4 Project Management Planning.....................................................................................................29
4.1 Building the Business Case ..................................................................................................30
4.1.1 Business Case Objective & Purpose ..............................................................................30
4.1.2 Contents of a Business Case ..........................................................................................30
4.1.3 Constructing a Business Case ........................................................................................30
4.1.4 Contents of a Business Case ..........................................................................................31
4.2 Success and Benefits Management ......................................................................................31
4.2.1 Project Success Criteria .................................................................................................31
4.2.2 Project Success Factors ..................................................................................................32
4.2.3 Key Performance Indicators ..........................................................................................32
4.3 Stakeholder Management ....................................................................................................32
4.3.1 Typical Stakeholders .....................................................................................................33
4.3.2 The Stakeholder Management Process ..........................................................................33
4.3.3 Benefits of Stakeholder Management ............................................................................34
4.4 The Project Management Plan .............................................................................................34
4.4.1 Project Plan Content ......................................................................................................35
4.4.2 Project Plan Attributes ...................................................................................................35
4.4.3 Deployment Baselines ...................................................................................................36
4.5 Benefits Management ..........................................................................................................36
4.5.1 Responsibility ................................................................................................................36
4.5.2 Benefits review ..............................................................................................................36
4.6 Estimating Methods .............................................................................................................36
4.6.1 Analytical (Bottom Up) Estimating ...............................................................................37
4.6.2 Analogous Estimating ....................................................................................................37
4.6.3 Parametric Estimating ....................................................................................................37
4.6.4 The Estimating Funnel ...................................................................................................37
4.7 Project Reporting .................................................................................................................38
4.8 Report Structure ...................................................................................................................38
5 Scope Management .....................................................................................................................39
5.1 Definition of Scope Management ........................................................................................40
5.2 Work Breakdown Structure .................................................................................................40
5.2.1 Benefits of the WBS ......................................................................................................41
5.3 The Product Breakdown Structure .......................................................................................41
5.4 Relationship between WBS and PBS ...................................................................................42
5.5 Cost Breakdown Structure ...................................................................................................42
5.6 Organisational Breakdown Structure (OBS) ........................................................................43
5.7 Change Control ....................................................................................................................43
5.7.1 Definition of a Change ...................................................................................................43
5.7.2 Why Change Control is Important .................................................................................44
5.7.3 The Change Control Process ..........................................................................................44
5.7.4 The Change Request Form.............................................................................................45
5.7.5 Impact Analysis .............................................................................................................45
5.7.6 The Change Control Log ...............................................................................................46
4
5.8 Configuration Management .................................................................................................46
5.8.1 Configuration Management Activities ...........................................................................46
5.8.2 Components of the Configuration Management System ................................................47
5.8.3 Link to change control ...................................................................................................47
6 Scheduling & Resource Management .........................................................................................49
6.1 The Precedence Diagramming Method ................................................................................50
6.1.1 Other Link Types ...........................................................................................................50
6.1.2 Leads and Lags ..............................................................................................................51
6.1.3 Critical Path Analysis (CPA) .........................................................................................51
6.1.4 Node Convention ...........................................................................................................52
6.1.5 Worked Example ...........................................................................................................52
6.1.6 The Critical Path ............................................................................................................54
6.1.7 Total Float and Free Float ..............................................................................................55
6.1.8 Gantt Charts ...................................................................................................................55
6.1.9 Gantt Chart Features ......................................................................................................56
6.1.10 Gantt v Network ..........................................................................................................56
6.1.11 Milestone Planning ......................................................................................................57
6.2 Resource Management.........................................................................................................57
6.3 Resource Smoothing ............................................................................................................58
6.4 Resource Levelling ..............................................................................................................59
6.5 Procurement .........................................................................................................................60
6.5.1 Definitions .....................................................................................................................60
6.5.2 The Procurement Process ...............................................................................................60
6.5.3 Procurement Strategy .....................................................................................................61
6.5.4 Make or Buy ..................................................................................................................61
7 Project Risk & Issue Management ..............................................................................................63
7.1 Definitions of Risk...............................................................................................................64
7.2 The Risk Management Plan .................................................................................................64
7.3 Risk Management Process ...................................................................................................64
7.3.1 Initiation ........................................................................................................................65
7.3.2 Risk Identification .........................................................................................................65
7.3.3 Risk Assessment ............................................................................................................66
7.3.4 Risk Response Planning.................................................................................................67
7.3.5 Implement Responses ....................................................................................................68
7.3.6 The Benefits of Managing Risk .....................................................................................69
7.3.7 Drawbacks of Managing Risk ........................................................................................69
7.4 Issue Management ...............................................................................................................69
7.4.1 Issue Log .......................................................................................................................70
8 Project Quality Management .......................................................................................................71
8.1 Definition of Quality............................................................................................................72
8.1.1 Quality V Grade.............................................................................................................72
8.1.2 Elements of Quality Management ..................................................................................72
8.1.3 Quality Planning ............................................................................................................72
8.1.4 Quality Assurance ..........................................................................................................73
5
8.1.5 Quality Control ..............................................................................................................73
8.1.6 Quality Control v Quality Assurance .............................................................................73
8.1.7 Continuous Improvement.............................................................................................73
8.1.8 Project Management Responsibilities ............................................................................74
9 Communication ...........................................................................................................................75
9.1 Communications Management ............................................................................................76
9.2 Channels of Communication................................................................................................76
9.3 Barriers to Communication ..................................................................................................77
9.3.1 Physical .........................................................................................................................77
9.3.2 Interpersonal ..................................................................................................................77
9.3.3 Organisational ................................................................................................................77
9.3.4 Culture and Language ....................................................................................................77
9.3.5 Jargon ............................................................................................................................78
9.4 Effective Communications...................................................................................................78
9.5 Importance of effective communications planning ..............................................................78
9.6 The Communications Management Plan .............................................................................79
10 Teamwork and Leadership .................................................................................................81
10.1 The Project Manager as Leader .........................................................................................82
10.1.1 Attributes of Good Leaders .....................................................................................82
10.1.2 Leadership Activities ..............................................................................................82
10.1.3 Leadership Styles (Hersey & Blanchard) .....................................................................83
10.2 The Project Team ...............................................................................................................84
10.2.1 A Team Definition .......................................................................................................84
10.2.2 Characteristics of Effective Teams ..............................................................................84
10.3 Team models......................................................................................................................84
10.3.1 Belbin Roles ................................................................................................................84
10.3.2 Advantages & disadvantages .......................................................................................86
10.4 Team Building ...................................................................................................................86
10.5 Stages in Team Development.............................................................................................87
10.6 Influencing Team Performance ..........................................................................................88
6
1 Project Management and the
Operating Environment
Learning Objectives
• Explain “PESTLE”
7
1.1 What is a project?
Here are three different definitions
“An endeavour in which human, material and financial resources are organised in a novel
way to deliver a unique scope of work of given specification, often within constraints of
cost and time, and to achieve beneficial change defined by quantitative
and qualitative objectives.”
The Association for Project Management
A unique set of coordinated activities, with definite starting and finishing points,
undertaken by an individual or organisation to meet specific objectives within defined
schedule, cost and performance parameters”
All of these are valid definitions from which we can determine the following key
characteristics that together differentiate projects from “business as usual”.
• Projects are Unique. When doing a project, we create something that did not
previously exist. Some projects are totally different whist others may contain some
elements similar to previous projects.
• It is the unique elements of projects that causes them to involve Risk & Uncertainty.
• Projects are Finite and Temporary. They have a start point and an end point.
• Projects generally require Teams and teams need Organising and Leading
Planning, monitoring and controlling are the mechanical aspects of project management. The
most difficult aspect of project management is the leading and motivation of the project team,
8
especially when things are not going well. Being good at the mechanical tasks is not sufficient
to make a good project manager. Leadership skills are paramount. See later.
• Integrator:
o Project Integration involves all those activities needed to ensure that people, procedures and
work of the project is carried out in a coordinated fashion. The project manager is the only
person aware of all the project activities and how they relate to each other.
• Communicator:
o The project manager must ensure that efficient communication channels are set up within
the project organisation. A project manager who fails to disseminate information on time
can become the major bottleneck in a project.
• Leader:
o Leadership is not the same as management. The project manager must be able to solve
problems, guide people from different areas, co-ordinate the project, lead by example and
motivate the team
• Decision Maker:
o The project manager must have the self-confidence to make key decisions even if some risk
is involved. A key aspect of project management is knowing when to make a decision and
when to consult the sponsor.
• Planning:
o Making sure robust plans are in place to meet the project objectives.
• Organising/Integrating:
o Co-ordination of the mixture of human, financial and physical assets
• Monitoring
o Monitoring progress in relation to time, cost & quality and customer satisfaction
• Controlling
o Taking corrective action when actual performance deviates from the plan
• Leading/Motivating
o Leading and motivating the team and seeing to the needs of individuals
• Reporting/Communicating
o Keeping stakeholders informed of progress and issues
9
1.4 The Project Management Triangle
The interaction of Time, Cost and Quality/Performance is usually represented by the Project
Management Triangle, sometimes referred to as the triple constraint. In the centre of the
triangle lie Health & Safety and Customer Satisfaction. These should be paramount on any
project.
The Project
Management
Triangle.
It is rare that a project goes exactly to plan. There will be changes, both planned and
unplanned and the whole project is subject to risk and uncertainty. When deviations occur one
or more of the triple constraints has to give. For example if a project is behind schedule more
resources may be needed to catch up. This will increase cost. If the budget is fixed then it may
be necessary to reduce quality or functionality. The responsibility for making such decisions
lies with the Sponsor and his Board. The job of the project manager is to advise on the
possible options and their implications.
Projects take place in a cloud of uncertainty. The Project Manager is constantly maintaining a
balance between time, cost and quality with due regard to health and safety and with the
constant goal of achieving customer satisfaction.
.
1.5 Projects v Business-as-Usual
Business as Usual is the term used to describe the normal business processes and operations
conducted by the company or organisation as it undergoes its day to day business. Much of it
consists of repeatable and routine management processes. It provides the services and products
for business customers on a daily and continuous basis. It is focused on such things as:-
Projects are Unique. When doing a project, we create Business-as-Usual usually involves the
something that did not previously exist. Some projects are ongoing provision of specified products or
totally different whist others may contain some elements services on a Repetitive basis.
similar to previous projects
Projects are Temporary endeavours that are Finite or Busines-as-Usual is an ongoing process
Timebound. They have a start point and an end point. that continues indefinitely.
When the objectives are met, the project terminates. (Some
projects are terminated before the objectives are met. This
will be discussed later)
Projects usually involve creating a team which only exists For stability and efficiency Business-as-
for the life of the project. Usual requires a Permanent Workforce
with minimal turnover.
Projects are normally Revolutionary in that their outcome Business-as-Usual on the other hand is
is normally a step change in the way something operates. Evolutionary in the sense that
organisations strive for continuous
improvement in small non-disruptive
steps
Because of their uniqueness Projects usually involve Risk Business-as-Usual is based on cumulative
and Uncertainty. Managing risk is a key aspect of project Experience that minimises or eliminates
management. risk.
Projects take place in an environment that is Dynamic and Business-as-Usual relies on a Stable and
Changing Predictive environment.
Projects have specific plans that are implemented and are Business as usual follow internal
generally bespoke and created to meet the deliverables of procedures and process that maintain the
the project business.
Projects are constrained and measured by the requirements Business-as-usual strives at all times to
of time, cost and quality. decrease costs and improve quality and
productivity.
11
• Programme Management provides a strategic tool for managing business projects and
keeps the focus on the business change objectives
• Projects within a Programme still have individual project managers who report to the
programme manager who in turn reports either to a senior sponsor who could be a
board member or to the board itself.
• Programmes will ensure project objectives are in line with corporate objectives
• There will be more efficient use of resources because they will be allocated with
regard to overall programme requirements rather than individual projects
12
1.6.2 Programme Manager Roles & Responsibilities
The principal responsibility of the programme manager is to ensure that the objectives of the
programme are met. In order to do this the programme manager: -
• Must ensure that all project managers share a vision across the whole of the
programme so that all project plans are fully aligned with the programme objectives.
• Will act as the link between individual projects and project boards and the
programme board and must ensure that all information flow both between projects
and upwards to the programme board is timely and accurate.
• Must ensure that all projects are progressing in line with the requirements of the
programme
• Makes sure that scarce resources are prioritised across projects for maximum
programme benefit
Unless asked for assistance the programme manager does not normally get involved with the
detail of individual projects but is responsible for managing the interfaces between them and
resolving conflicts between them.
1. Project selection.
Projects for potential inclusion within the portfolio should be carefully selected
and a business case prepared. Projects should align with corporate strategy and
contribute to overall corporate goals. Projects within the portfolio should exhibit
an appropriate balance between risk and return.
2. Resource allocation.
This is concerned with the management of resources across competing projects
and programmes within the portfolio. Resource issues will occur between
projects particularly with to regard to scarce or limited resources and capacity
13
bottlenecks. The portfolio manager must decide on the optimum allocation of
resources.
4. Portfolio Reviews
The portfolio management process must constantly review the balance within the
portfolio of cost and benefit, and risk and reward. The portfolio manager must be
prepared to prematurely close projects or programmes where they are no longer
viable or involve unacceptable risk.
5. Managing Interdependencies.
A Portfolio Manager must be aware of all the possible interactions and
interdependencies between all the different elements of the portfolio.
• There is a strategic link between programmes, projects and BAU operations to ensure
that all the activities of the organisation are supporting business objectives.
• Political
• Economic
• Sociological
• Technological
• Legal / Regulatory
• Ethical/Environmental
• Social Will the project impact on people’s health or living standards? Is it subject to
trends or fashion or demographic changes?
• Environmental Does the project have an environmental impact? How can this
impact be minimised? Will there be opposition?
15
16
2 Project Life Cycles and Reviews
Learning Objectives
17
2.1 A Linear Project Lifecycle
A linear project life cycle consists of a sequence of distinct phases or stages. A phase can only commence
when the previous phase has completed. Phases cannot overlap. There are many varieties of life cycles which
vary across different industries and organisations. Shown below is a generic lifecycle which can be applied to
many different kinds of project.
2.1.4 Handover
Handover consists of all those activities involved with the formal transfer of ownership from the project team
to the client/sponsor and end users. It could be a simple handover of product and documentation or a lengthier
process involving testing and training. The process must demonstrate that the deliverables conform to the
specified performance requirements. The handover process must be planned and documented in the project
plan. Key tasks:-
18
• Prepare the Handover Plan.
• Testing of deliverables by the project team prior to formal handover.
• Carry out acceptance tests with the Client and end users.
• Transfer responsibility and formal ownership from the project team to the Client.
• Agree and document any outstanding issues regarding bug fixes/snagging lists.
2.1.5 Closeout
Closeout is concerned with closing the project down in a consistent and organised manner. Key tasks:-
Note that there are no universally accepted names for project phases. Concept often includes Feasibility and
vice versa and the first phase is sometimes called Initiation. The Definition phase is often referred to as the
Planning phase. It is often broken down into Design & Development stages which are sometimes treated as
two separate phases. The Implementation phase is often called the Execution phase. This is where the final
project deliverables are constructed. Handover and Closeout is often referred to as the Exit phase
A major drawback of the iterative method compared to the linear model is that because the total requirements
are not identified up front the ultimate cost and duration is impossible to accurately forecast.
19
Figure 2.2 An iterative life cycle
2.3 Time Boxes
Linear projects usually work to a fixed scope. If some deliverables are delayed, then you need either more
time or more resource, both of which will mean more expense.
Iterative projects often employ the technique of time boxes. With timeboxing, duration is fixed, and usually
resource as well, meaning that some requirements will have to be deferred. This means requirements have to
be prioritised.
20
Although projects are deemed complete when they are formally handed over, the Sponsor
remains involved until the planned benefits have been realised. Benefits realisation takes
place during the initial stage of the Operations phase. This is called the Extended Project Life
Cycle. The inclusion of Operational and Termination phases of the project make up the
Product Life Cycle.
• The post project review occurs after handover of the project deliverables i.e. all work
completed and signed off.
• It is the management review at the end of the project and does not consider the
technical issues
• The PM is responsible for ensuring it takes place but should not lead it. This should
be done by an independent facilitator
• It should be a non-confrontational meeting. Its purpose is not to allocate individual
blame.
21
22
3 Roles and responsibilities
Learning Objectives
• Product Owner
• End Users.
23
3.1 Project Organisation Structure
The figure below shows a typical project structure
25
3.7 The Project Office
All organisations that take project management seriously will have a project office that exists
to support the organisation’s project needs. Major projects and/or programmes may have their
own dedicated support office. Where a project office does not exist the services must be
provided from within the project.
At its simplest level the project office may just provide administrative support to project
personnel. At the other extreme can become the “Centre of Excellence” for project
management and the body to which project managers report. It will be the overseeing body for
all project activity and be responsible for linking corporate strategy to project execution.
The presence of a project office allows an organisation to draw together its project
management expertise and makes possible the development of that expertise into a centre of
excellence. A project management office fits particularly well with a strong matrix
organisation as project managers and project office staff can be brought under common
management. However, for functional and weak/balanced structures some sort of project
office is vital in order to facilitate a common approach to managing projects.
The Project Office can have various names depending on the organisation and the extent of its
role e.g.
26
• Development and management of PM job descriptions and training programmes and
professional development.
• Organisation of mentoring and skills development
• Organise and facilitate Gateway Reviews and Post Project Reviews
• Line management of project managers
Ultimately the project office takes on a strategic role within the organisation and becomes the
ECMO. It reports directly to a Board member and can take on the following responsibilities.
• Organisational policies
o e.g. Health & Safety, Environmental, Human Resource etc.
27
• Regulations
o Legal obligations which provide a mandatory framework on which policies are built
• Functions, Processes and Procedures
o Derived from the project methodology
• Defined roles, responsibilities and authority levels
o Also derived from the project methodology
The latter two items illustrate that project governance is highly dependent upon the presence of a properly
implemented project methodology. Proper project governance is virtually impossible without it. Project
Governance is a subset of Corporate Governance which is a Board responsibility. It therefore follows that it
is a board responsibility to ensure that a project methodology is implemented in the organisation and its use
made mandatory.
28
4 Project Management Planning
Learning Objectives
• Explain the purpose and content of a Business Case
29
4.1 Building the Business Case
4.1.1 Business Case Objective & Purpose
The objective in developing a Business Case is to provide a justification for carrying out the
project. It must show the expected costs and benefits of the project and how it fits in with the
company strategy and contributes to the corporate goals of the organisation. Not all costs and
benefits are tangible, i.e. they cannot easily be expressed in purely monetary terms.
In any organisation there are usually many proposed projects that are competing for limited
funds. Therefore the purpose of the Business Case is not just to demonstrate why a project is
viable in its own right but also why it should be favoured over others.
The Business Case is prepared very early in the project life cycle. As normally no detailed
planning has taken place it is often difficult to decide the level of detail in the Business Plan.
The answer is that it should contain enough information to enable a decision to be made as to
whether to carry on with the project. The decision can always be modified in the light of more
detailed planning.
Every project must in some way contribute to the corporate goals of the organisation.
In order to construct a business case, it is necessary to estimate the costs and expected benefits
of the project and produce a budget and schedule. This is effectively the first attempt at a
project plan, and it is carried out by performing the steps shown in fig 4.1 opposite. It is an
iterative process which will become more accurate as the project progresses, experience is
gained, and more knowledge is obtained
30
The Business Case will make clear the balance between the expected costs and benefits of the
project and the level of risk involved. As the project develops and the true costs and risks
emerge it should be continuously reviewed to check that the project continues to meet the
business objectives. If not there may be a case for termination or scope change.
. BUSINESS CASE
PROJECT OBJECTIVES & SCOPE
RESOURCES
PROJECT BUDGET
Figure 4.1 Business Plan Construction
From the point of view of the Project Manager success may be defined as delivering to time,
cost and specification. However other stakeholders may be more concerned with business
benefits. These will not be known at time of handover. It is perfectly possible for a project to
be deemed a delivery success but fail to produce its business benefits. On the other hand many
projects delivered late and over budget have nevertheless delivered considerable business
benefits.
Examples are: -
• Clear project mission
• Top management support
• Client consultation
• Committed project personnel
• Monitoring and feedback mechanisms
• Clear communications
• Adequate resources
Key Performance Indicators are continuously measured over the life of the project. They
directly measure the project performance against Project Success Criteria. Although success
criteria can be qualitative or quantitative ideally, they should be SMART. i.e. Specific
Measurable Achievable Realistic Timely
32
4.3.1 Typical Stakeholders
End users are important stakeholders and their requirements must be captured early on when
considering project requirements. It is also particularly important to recognise and manage
negative stakeholders as if left unmanaged they can have a detrimental effect on the project.
The above list is not exhaustive. Each project will have its own particular set of stakeholders.
Step1 Identification
The most usual method of identification is by Brainstorming. This
would be typically be led by the project manager and would include the Sponsor, team
members, end user representatives and anyone else who can add value. Relationships between
stakeholders can be represented by a Stakeholder Map such as the example shown below
which relates to an IT project in a manufacturing environment.
Step 2 Analysis
In the analysis stage, it is necessary to try and discover the position of stakeholders with respect to the
project. Consideration might be given to questions such as the following:
33
• Will they benefit from the success of the project?
• Will they be openly supportive of the project?
• Do they have reasons for wanting the project to fail?
• If their views are negative or ambivalent can they be persuaded to change?
• What is their level of power and influence?
Step 3 Planning
Planning consists of examining each stakeholder, trying to understand what is their likely
attitude to the project, what motivates them what power they exert, and then formulating an
action strategy to manage and influence them. A brief example based on the project of figure
4.3 is shown below.
Figure 4.4
Stakeholder
Action Plan
Step 4 Managing
Stakeholders must be actively managed, especially as their views and motivation may change
over the life of the project. The analysis must be repeated throughout the project lifecycle as
new stakeholders appear and attitudes change. “Champions” can be used to managing or
influencing “Blockers” or to organise “Supporters”.
The Project Management Plan is a live, configuration controlled document which builds upon
the information contained in the Business Plan. It provides a contract between the Sponsor and
the Project Manager. It is a reference point for reviews, audits and control. It also assists
effective handover in the event of a change in project management or sponsorship.
Not every section is required by every project. On smaller projects the overhead of all these activities may
not be practical thus some may be omitted or level of detail reduced. Such exceptions need to be justified.
Thus each section or subsidiary plan is detailed to the extent required by the specific project.
The Project Management Plan is unlikely to exist as a single hardcopy document. In order to be effectively
maintained and be accessible to team members and appropriate stakeholders it is better to have an electronic
document that is made available on the organisation’s intranet.
• The Project Management Plan is a live, configuration controlled document that builds upon the
information contained in the Business Plan.
• It provides a contract between the Sponsor and the Project Manager.
• It is a reference point for reviews, audits and control.
• It also assists effective handover in the event of a change in project management or sponsorship.
• It is the primary tool for Stakeholder communication
35
4.4.3 Deployment Baselines
It is important to understand that the Project Management Plan is not simply a record of the project planning
outcomes. The original project plan as agreed between the Sponsor and the Project Manager serves as a
baseline of what will be deployed by the project and against which all future outcomes are compared. The
agreed project plan is essentially a contract between the Sponsor and the Project Manager. Outcomes, in terms
of schedule, budget and quality are monitored to capture deviations from the baseline plan so appropriate
actions can be taken. Formal changes to project scope will generate incremental changes to the deployment
baseline but the original baseline and all subsequent changes must be recorded to ensure an audit trail.
What has been said above is fully applicable to traditional linear life cycles but not entirely applicable to an
iterative life cycle. In the linear approach we attempt to define all the requirements up front before carrying
out a detailed design and manufacture. Thus we are able to plan the whole project from start to finish.
With an iterative approach we do not attempt to produce upfront a total set of detailed requirements. Instead
we a list of desired outcomes. We can then select a subset of those desired outcomes, convert those outcomes
into deliverable requirements and plan accordingly. Thus at the start there can only be a detailed plan and
deployment baseline for the first iteration, making forecasting of budget and schedule for the whole project
problematical. The subset of the desired items chosen i.e the scope of the iteration, will be limited by the size
of the time box
36
There are three main estimating methods
1. Bottom Up Estimating
2. Comparative Estimating
3. Parametric Estimating
37
4.7 Project Reporting
It is the responsibility of the PM to ensure that all relevant project information is
communicated to the Sponsor and appropriate stakeholders in a timely and effective manner.
The benefit of such a process is that by keeping relevant stakeholders informed as to project
progress it will avoid misunderstandings and manage expectations. It is a vital part of
stakeholder management.
There will be ongoing informal communication at all times, but project status should be
formally reported, usually on a monthly basis and at key points such as phase ends. To do this
the PM will require formal reports from appropriate team members which must then be
collated and simplified for passage upwards.
It should be stressed that formal reporting is not a substitute for ongoing project
communication. Information must be presented in a timely fashion and it may not be
appropriate to wait until the next monthly report. Avoid overloading Stakeholders with too
much information and use Exception Reporting when appropriate.
Note that a study of Earned Value Management is not included in the syllabus. In simple terms
Earned Value is a technique for measuring project performance and progress. EVM has the
ability to combine measurements of scope, schedule, and cost in a single integrated system. It
measures not just cost of work done but relates this cost to the amount of useful work done
with regard to the planned budget and schedule. For a full treatment see “The PMQ Primer”
by Robin Kay. ISBN 978-1-32698355-0
38
5 Scope Management
Learning Objectives
39
5.1 Definition of Scope Management
Scope Management is concerned with all the tools and processes that ensure that enough work,
but no more, is carried out to produce the project deliverables. It is concerned with controlling
the boundaries of the project and ensuring that all work done is related to project objectives
and that any new work is subject to a formal change control process. It is also important to
clearly establish what is excluded from the project scope.
The Business Plan will define the breadth of the project scope. As the project progresses and
plans become more detailed, the depth of the scope will increase. Scope creep and
uncontrolled change are common causes of project failure so if changes are made to the scope
breadth then this must be done through a formal change control process. The primary tools for
defining and controlling project scope are the Work Breakdown Structure (WBS) and the
Product Breakdown Structure (PBS).
The WBS is the framework on which the project is built. It is not possible to build a realistic
project plan without first developing a WBS that details all the project tasks that must be
accomplished. The process of creating the WBS causes the project manager and all involved
with the planning process to carefully consider all aspects of the project.
The WBS shows how each work package contributes to the overall project objectives and so
provides a firm basis for both planning and controlling the project. Each work package or task
represents the level at which the project manager exerts control. Each WP/task is a self-
contained piece of work that can be given to a single person or a small team. Each will have a
list of defines attributes:-
40
• Specification
• Acceptance criteria
• Responsibility
• Budget
• Duration
• Resource requirements
• Dependencies
The size of these Work Packages is very important because they must be small enough to
allow realistic estimates to be made, but also not so small that the sheer number of tasks
overwhelms the planning and control process.
41
Production of the PBS has 3 main objectives: -
The topmost product is the “final” product or project outcome. The PBS includes as lower
level items, products supplied by external sources. Each higher level product is completely
defined by the levels below. The PBS will generally include “intermediate” or “enabling”
products or “sub-assemblies”
42
Figure 5.4 Cost Breakdown Structure
Change Control is the process by which all changes are identified and evaluated and then a
decision made on whether they are approved, rejected or deferred.
Changes can arise from 3 main areas: -
1. From errors, omissions in the original planning.
2. From evolution of project requirements or new techniques
3. Legal/mandatory changes
43
5.7.2 Why Change Control is Important
“Scope Creep”, where project scope keeps increasing over time; and uncontrolled change are
major causes of project failure. Changes to the project baseline must be evaluated and planned
with the same thoroughness as the original plan.
However, we cannot prohibit project change, because change is usually beneficial, and in fact
many projects would fail if no changes were allowed. In certain circumstances a change freeze
may be appropriate but when changes are allowed, they MUST be controlled.
Excessive change requests are usually a symptom of poor planning and requirements
definition. Proper planning and consultation with all appropriate stakeholders will help
minimise change requests.
1. The request is entered into the change control system. Change requests must be made
in writing in the appropriate standard form or screen.
2. An Owner is assigned to manage the change control process. (Not the change itself)
3. A brief preliminary evaluation is carried to see if it is worth further investigation and
to prioritise it.
Submit request
4. If the answer to the above is yes, then an impact analysis is
carried out.
5. CCB* Approve, reject or postpone the change request Assign Owner
6. If approved, plans, documentation, timescale and budgets
are updated.
7. The Change Log is updated Prelim. Investigation
8. All who are impacted are advised of the changes.
Impact Analysis
Figure 5.6 Change
Control Process
No . Accept?
Defer .
Yes
.
Inform Update Plans & Log
Requestor
44
All changes must be authorised so if unauthorised changes are discovered they must
be retrospectively be put through the change control process. This may mean undoing some
changes
Impact assessment must be carried out by people who are competent to fully understand the
implications of the change on the current baseline plan. They must determine: -
Note: That for proposed major changes, the effort involved in analysing the impact can itself
have a significant impact on the project and therefore the analysis may need to be formally
approved.
45
5.7.6 The Change Control Log
The Change Control Log consists of the original Change Request form plus a statement of the
current status and the ultimate outcome in terms of effect on schedule and budget and any
other knock on effects.
The Change Control Log is an important part of the project audit trail. The Baseline Project
Plan plus the Change Control Log represent the current state of the project.
Changes to the project will often result in changes to the project configuration so change
control is intrinsically linked to configuration management.
A product, whether it is a physical thing such as a motor car or something ethereal such as software, is made
up of many inter-related components. These include documents such as specifications, designs and plans as
well as deliverable components. The totality of items is known as the Configuration. Configuration
Management encompasses all the activities concerned with the creation, maintenance and change control of
the configuration.
As a product is developed it will undergo additions and changes. Changes to one configuration
item may impact others. We therefore need to control and manage these knock on effects.
Controlling the configuration during the project will ensure the traceability and integrity of the
delivered product or products.
The Configuration Management System must be totally aligned with the Change Control
System. Its ability to identify possible knock on effects will facilitate change assessment and
will also protect different versions of the deliverable.
Configuration Management is not just a project tool but is a key tool in the subsequent
operation and maintenance of the project deliverables.
46
5. Configuration Audit
Carried out to demonstrate that the products produced conform to the current
specification and all procedures have been followed
47
48
6 Scheduling & Resource Management
Learning Objectives
49
6.1 The Precedence Diagramming Method
In the Precedence Diagramming Method tasks are represented by boxes with dependencies shown as logical
connections between the boxes. A simple example is shown below.
Upon completion of Task A we can start Tasks B and C. Once both these are completed, we can start task
D. Thus, B and C are preceded by A and D is preceded by B and C.
The tasks are derived from the WBS. Each box represents a lowest level task or work package.
50
6.1.2 Leads and Lags
We can also introduce delays between activities known as lags and allow for overlapping by
using leads.
Lags occur when there is a delay between one activity and the following activity. Lags are
designated by a value placed on the arrow. Lags can be used on all 4 relationships.
Lead can only take place with Finish to Start activities. It occurs when there is an overlap. In
other words the dependant activity can start before the preceding activity has finished. The
examples below illustrate 3 units lag and lead.
This pass calculates the earliest possible start and finish times for each task.
This pass calculates the latest possible start and finish dates which will complete the schedule
on time.
Total Float = Late Finish – Early Finish or Late Start – Early Start
Total Float is defined as the amount of time an activity can be delayed or extended without
affecting the total project duration (end date)
51
6.1.4 Node Convention
Figure 6.2
52
Step 2- Carry out the forward pass
Figure 6.3
Thus for
activity A, 0 + 10 = 10. This 10 is carried forward to all the successor activities and so on.
Where there are multiple arrows we take the latest (the largest) as before. Thus for activity F
we take the largest of 25 (from B), 15(from C) and 20(from E).
Figure 6.4
Thus for activity F, 35(the finish time) – 10 (duration) = 25 (the start time) This 25 becomes the latest
finish date for B, C and E. Where there are multiple backward arrows e.g. into activity A then we take the
smallest which in this case is the 10 from B.
53
Step 4 Calculate Total Float by subtracting the early dates from the late dates.
Figure 6.5
The Critical path is the sequence of activities through a project network from start to finish,
the sum of whose durations determines the overall project duration. On this path the late
completion of activities will have an impact on the project end date.
54
6.1.7 Total Float and Free Float
Total Float is defined as the amount of time a task can be delayed without delaying the end
date. Free Float is defined as the amount of time an activity can be delayed or extended
without delaying the start of the next activity. The presence or absence of free float can be
determined by inspection as the following example shows.
The significance of Free Float is that the project manager knows that he can utilise free float to
for instance ease temporary resource problems, knowing that there are no knock on effects. If
there is total float but no free float then there will be knock on effects to consider. Also note
that where a sequence of tasks in a line such as B,C above exhibit a value for total float then
that float is effectively shared. If we utilise some or all of the total float in B then it will be
removed from C. .
55
Figure 6.7 Software generated Gantt chart
56
6.1.11 Milestone Planning
Although it is usually necessary to plan in detail, in the early stages of a project such detail is
not usually available, and planning takes place at a less detailed level. We generally start by
establishing the key milestones. Milestones are key occurrences in the project which mark the
achievement of key objectives such as the completion of a phase. Milestones are used by
management for project control. They are often not concerned with project detail but only in
the progress against key milestones. Milestones are often linked to payment schedules.
Completion of a milestone can trigger the issuing of an invoice.
Resource Management is concerned with making resources available when required and
avoiding waste. In the case of people it is better to have a smooth profile rather than
continuous hire and fire. There are two methods for achieving this.
57
1. Time Limited Scheduling (Smoothing)
This is usually the default option. Scheduling of resources will take place ignoring resource
constraints. In other words infinite resource is assumed. This is usually the default option when
doing the initial planning.
No time limit is placed on the schedule. Tasks will take place at the earliest times resources
become available.
Applying Resource Smoothing and utilising the float on activity B and D we arrive at the
position following. This is a Time constrained schedule. Here the network schedule is
allowed to change but the end date is retained.
58
Figure 6.10 Resource Smoothing.-Finishing Point
Resource Constrained
Schedule
Levelling eliminates
resource problems by
ignoring time constraint s.
It is Resource constrained
59
6.5 Procurement
6.5.1 Definitions
Procurement
The securing (or acquisition) of goods or services for use in your project.
Contract
An agreement between two parties which is legally binding’
Contractor
A person, company or firm who holds a contract for carrying out the
works and/or the supply of goods in connection with the Project
Supplier
Any organisation, including contractors and consultants, which supplies
goods or services to customers.
6.5.2 The Procurement Process
The overall procurement process is illustrated in the flowchart below.
60
6.5.3 Procurement Strategy
The answers to these questions will go a long way towards determining the
most appropriate contract type.
2. The indirect costs – i.e. the cost of managing and monitoring the purchasing
process
3. The overall effect of the decision on the organisation e.g. would a decision to
Make have a knock on effect on other projects which may require the same
resources. Would a decision to outsource put in-house facilities at risk?
61
62
7 Project Risk & Issue Management
Learning Objectives
63
7.1 Definitions of Risk
APM definition:
The above is more a statement of how risk is measured. A better definition is:-
A project risk is something that might occur, and if it does, will impact on the project’s
objectives of time, cost and performance/quality. Risk is uncertainty in an outcome. Risks can
be both threats (downside) and opportunities (upside).
The way in which risk is to be managed in a project is detailed in the “Risk Management
Plan.” The Risk Management Plan defines how all the risk processes will be carried out. It
does not consider individual risks.
64
7.3.1 Initiation
This is the activity of setting up the process, making decisions on such things as risk categories
and tools and techniques to be used. Basically, it is about organising the team to carry out risk
management.
• Brainstorming
o Using the project team and appropriate stakeholders
• SWOT Analysis
o Strengths and Opportunities generate upside risks o Weaknesses
and Threats identify downside risks
• Assumptions Analysis
o Looking at the assumptions made in the planning to see if any of
them constitute a risk
• Constraints analysis
o Similarly, for project constraints
• Using the WBS
o Identifying risks to individual work packets
• Interviews
o Interviewing people with knowledge or insight
There may also be sources of information that can help the identification process e.g.
• Prompt/Check Lists
o Using existing prompt sheets and check lists
• Post Project Reviews (Lessons learned)
o From previous projects with some commonality
• Risk Registers of other projects
o Again, using projects with some commonality
65
7.3.3 Risk Assessment
The purpose of Risk Assessment is to prioritise the identified risks. In particular it needs to
establish the key risks that require management focus.
Assessment is based on determining Probability and Impact and this is most conveniently
carried out with the aid of a Probability and Impact Grid.
66
A pseudo quantitative method often used is to simply
apply a scale of 1 to 5 to the impact and probability.
Multiplying these scales gives the Exposure for each
square that can be used to prioritise the risks.
Figure 7.3
1. Avoid
Avoid the risk and eliminate uncertainty by not doing something or doing it in a
different way
2. Transfer
Transfer liability or ownership of a risk to someone else such as the client or
subcontractor or 3rd party. e.g. insurance or back to back contracts
3. Reduce/Mitigate
If the risk cannot be avoided and is too large to accept then we must take steps to
reduce probability and/or impact
4. Accept
Take it on board and accept the consequences. The severity/probability of the
risk does not justify great effort in managing it.
5. Contingency Plan
Have an alternative plan at hand to implement if the risk occurs
When the severity of a risk determines that it must be actively managed then the following
process should be followed:-
1. Re-examine the risk to determine its current status and validate the previous
evaluation
2. Demonstrate the viability of the mitigation plan by evaluating the cost of mitigation
and comparing with the reduction in exposure.
3. Decide if the mitigation results in an acceptable level of risk.
4. If so decide on who will own and manage the risk and be empowered to do so.
Opportunities
Similarly there are strategies for developing opportunities.
67
• Exploit-
o Try and exploit the opportunity by eliminating the uncertainties surrounding
the opportunity
• Share-
o If you do not have the resources to exploit the opportunity yourself then try
to find a partner to share it.
• Enhance-
o Work to increase the probability and impact of the opportunity
• Accept –
o Wait and see what happens
Each risk that has a planned response must be proactively managed by the person responsible.
In addition the risk plan needs to be formally reviewed on a regular basis.
The primary tool for managing risk is the Risk Register an example of which is shown in
figure 7.4
The Risk Register must be routinely reviewed on a regular basis and when risk events happen.
The overall risk status of the project and the progress of “active” risks will be reported as part
of the standard project reporting procedures as defined in the Risk Management Plan and the
Communications Plan.
68
7.3.6 The Benefits of Managing Risk
On many projects risks are not actively managed for the reasons stated later on. However as
well as being a requirement of good Governance, the proper management of risk confers
significant benefits.
• Increased understanding by the project leads to more realistic plans and greater
probability of delivering to them. Increased understanding of the risks leads to their
minimisation and allocation to the person best placed to manage them. The
understanding of risk helps determine the most appropriate contract type. A team
view of the risks can lead to more objective decision making
The Cost
Risk Management is an overhead requiring a significant input of effort and cost. Although this is no different
from the input of effort and cost into all Planning processes, such as Scope Management and Change Control,
there is one key difference - Risk Management is about things that may never happen and even if they might,
"it won't happen to me".
Visibility
Once we have put lots of effort and money into Risk Management the likely result is that it tells us what we
did not want to know. We will either have to invest in reducing the risks or accept that the project might take
a lot longer or cost a lot more than we had hoped or even that we should not do the project at all. Many
people may have a vested interest in the project and do not wish to hear anything that might endanger it.
Some issues arise out of risks events that had been previously identified. Others will come as a
complete surprise.
Some Issues may necessitate formal changes that require the Change Control Process to be
invoked. For example, a Client suddenly announces a major budget cut which necessitates
reduction to project scope.
Some Issues will not cause a formal change but must be managed. For example a key resource
resigns from the project or a vital piece of equipment breaks down.
69
It is important to have a formal process to manage issues. If they are caught earlier they should
be easier to resolve before causing damage. The process is similar to Risk management
• Identification
o By their very nature Issues tend to identify themselves
• Escalation
o At what level in the project/organisation must this issue
be addressed for a solution? Who owns the issue?
• Monitoring
o The Owner monitors the issue and reports on progress. An
Issue log is maintained.
o
• Resolution
o The issue is closed when fully resolved to the satisfaction of all
parties.
Once an Issue has been formally escalated it is entered onto the Issue Log which is very
similar to the Risk register. In fact Issues can be thought of as Risks that were not previously
identified or were accepted but have turned out more severe than expected or had a very low
probability of occurrence.
Many organisations group risks and issues together and maintain a single Risks & Issues
Register
70
8 Project Quality Management
Learning Objectives
71
8.1 Definition of Quality
Quality can be defined as the totality of characteristics of an entity that bear on its ability to
satisfy stated or implied needs. A quality product must conform to the defined
requirements/specifications but most importantly must be “fit for purpose”.
Customer requirements are the basis for managing Quality. A “Quality” product is one that
meets the specification and satisfies the customer.
“Over delivering” often called “Gold Plating” can be regarded as poor quality.
Quality must not be confused with Grade. Grade is to do with relative functionality and
features. A high grade product may be rich in functionality and possibly luxury fittings but if it
does not conform to requirements and meet customer expectations it is not a quality product.
Conversely a product with basic, minimal functionality and lack of “frills” can be a quality
product.
Quality Management is a management discipline concerned with making sure that activities
happen according to a prescribed plan. It is all about preventing problems. Quality
management involves carrying out a project through all its phases with zero deviations from
the project specifications and adhering to defined processes.
• Quality Planning
• Quality Assurance
• Quality Control
Quality planning is defined as “identifying which quality standards are relevant to the project
and determining how to apply and satisfy them”. In other words, setting standards and how to
achieve them. The primary output of the quality planning process is the Project Quality
Management Plan. It describes how the project team intends to implement its Quality Policy.
This reinforces the basis of modern thinking about project quality management; that is quality
is a planned activity and not something that is applied afterwards by inspection and correction.
Inspection still has a part to play in quality management; however increased inspection is not
generally considered the best path to improved quality.
72
8.1.4 Quality Assurance
Formal Audits
• Project Audit
• Quality Audit
• Financial Audit
• Technical Audit
Audits examine if processes, policies and procedures are being adhered to. Audits can be
internal to the project, within the organisation but outside the projects or from external bodies.
e.g. checking for ISO 9000 compliance.
Reviews
Reviews can be more informal than audits. Thy concentrate more on what the project is
producing and the project status and environment rather than the processes. Reviews should be
constructive not destructive or people will be reluctant to participate.
The basic difference between the two processes is that Quality Control is about doing the
physical things to ensure quality in your product whilst Quality Assurance is concerned with
checking that all the processes and procedures specified in the Quality Plan have been
properly carried out. Quality Assurance is fundamentally an audit process. Whilst Quality
Control is a project team activity Quality Assurance is carried out by external auditors as well
as self-auditing within the project team
• Make sure that all project personnel are aware of the need for quality and the required
quality standards and that they have received the necessary training and are capable of
carrying out the work to the appropriate standard
• Make sure that there is an approved quality plan detailing all the required quality
assurance and control procedures and standards and that all the project team and
relevant stakeholders are familiar with the requirements of the plan.
• Make sure everyone is aware, by means of appropriate training and communication,
of their roles & responsibilities for carrying out quality management actions. If
necessary appoint a Quality Manager.
• Carry out monitoring and controlling actions to make sure that the product quality is
being adhered to as per the quality plan, and that the outcomes of quality audits are
noted and acted upon.
• Ensure there is an effective change control process in place and communicate
regularly throughout the project with client and stakeholders to ensure that the project
deliverables continue to be aligned with client requirements.
Remember that the modern attitude to quality is that it is built into the product and the people
and processes that build it. Quality is not something that is achieved by inspection and
correction. Quality is planned in. The motto is “Get it right 1st time”
74
9 Communication
Learning Objectives
75
9.1 Communications Management
Communications Management is concerned all the ways in which information is exchanged
and interpreted. This is achieved in 3 main ways, written, verbal and by body language.
Written
Written communication is permanent. It is memory independent but can still be ambiguous
and open to interpretation
E-mail, although written, has some of the elements of speech because it is immediate and it is
easy to send something you may have cause to regret. However unlike speech or ordinary
written communications it can literally be published to the world in minutes
Verbal
The majority of our communication is done this way. The advantage is that it is fast, easy and
natural. However spoken words are transient and are easily misunderstood and may be
recalled in different ways
Body Language
Body language can give away our feelings even when they contradict our words and can
convey a message without using words.
Examples
The most effective form of communication is face to face but when this is not possible we can use
Virtual Communication. This means any technology people use to communicate with each other when they
cannot be face to face. We can also use Physical Communication. This involves symbols, signs and gestures
and can occur with both face and virtual communication. Everyone possesses some form of physical
76
communication skills. These include our body posture when speaking, eye contact, facial expressions, touch
and gesticulations. Often such behaviours can contradict what is actually being said.
1) Physical
2) Interpersonal
3) Organisational
4) Culture and language
5) Jargon
9.3.1 Physical
These are barriers that arise from the environment in which the communication is taking place.
An example of this type of environment is open plan offices where private conversations are
difficult meaning people may feel inhibited in what they can say or where noise levels can
make conversation difficult. It also includes things such as too high or low temperature, poor
acoustics and being uncomfortable e.g. poor seating.
9.3.2 Interpersonal
Barriers can occur due to the lack of interpersonal skills of the persons involved. An example
of this is where someone’s style of communication may appear aggressive to others, especially
to people beneath them. This may make them unapproachable.
Another example is where people have an inbuilt bias which leads them to stop listening
when something is said they disagree with. Also people may inadvertently give out body
language signals than can contradict what they are saying or be misinterpreted.
9.3.3 Organisational
Problems can occur because of a lack of understanding of how an organisation works. For
example, some organisations have an environment of openness and trust whilst others may
operate on strict hierarchical and “need to know” lines.
Barriers may also arise due to poor definition of roles and responsibilities. working
relationships and defined lines of communication. The project organisational structure may
also cause barriers especially if it is cross functional.
Barriers commonly occur between people of different nationalities. This is often simply down
to one or both of the parties having to speak in a foreign language. However, there may be
deeper cultural barriers. For instance, in some cultures people have difficulty in admitting they
have not understood whatever it is you have asked them to do or have difficulty admitting that
they cannot do it.
77
Even within single countries individual organisations can have very different cultures. For
instance in new High-Tec companies the dress code and the manner in which people speak to
each other can be very informal with people addressing their seniors by their first name, whilst
in older established organisations there may be strict dress codes and rules of etiquette.
9.3.5 Jargon
People commonly use acronyms and abbreviations and technical terms and assume that
everyone else understands them. Coupled with this is an unwillingness by some people to
admit lack of understanding because of fear of appearing stupid.
Such barriers can be addressed by minimising the use of jargon, being aware that other people
may need explanations, and fostering a climate where people are not afraid to ask questions.
• Team leader and the PM must know what the project staff are doing otherwise they
cannot monitor project progress.
• You must keep your client/sponsor aware of project status and manage their
expectation otherwise you may not be doing what they want you to do
• You must maintain channels of communication with project staff and stakeholders so
that everyone knows what is going on and the work of the project can carry on in a
fully integrated and co-ordinated manner
78
• An effective plan will ensure that everyone will receive the same, accurate, timely
information. This will help avoid mistakes and delays
• If good communication are not in place then people will make incorrect assumptions
79
80
10 Teamwork and Leadership
Learning Objectives
81
10.1 The Project Manager as Leader
Project managers are expected to plan, manage and organise but the most important skill is
Leadership. Leadership is mainly based on example and good communication skills
Good leaders lead by example. Team members are greatly influenced by the behaviour of the
leader. They will take their lead from the project manager and will tend to pick up both good
and bad behaviour.
Recognise Achievement
People expect hard work and achievement to be recognised. They also require a record of that
recognition so do it in writing.
Reward Success
Recognition is essential but people also expect to be rewarded. Public recognition is a form of
reward but eventually rewards must be tangible.
Encourage, Support and Motivate A good leader will spend time coaching and
encouraging people to become more effective and will always support his team members.
82
Be Available
Finally a good leader will make sure he is available to his team and maximises face to face
contact. This can be difficult to achieve on geographically dispersed projects.
1. Directing
2. Coaching
3. Supporting
4. Delegating
These four styles can be expressed in terms of Supporting Behaviour (concern for the person and Directive
Behaviour (concern for the task)
“.. two or more people who interact, dynamically, interdependently, and adaptively
toward a common and valued goal/objective/ mission, who have each been assigned
specific roles or functions to perform”
Salas, Dickenson, Converse and Tannenbaum
Project teams are normally transient and will be disbanded upon completion of the project.
84
manager. However with experience and knowledge of the role types it is possible to accurately
determine role types without the test.
Belbin later added a ninth role, that of specialist brought in purely for their expert knowledge in a
particular area.
The roles are briefly described in the table following along with their weaknesses
Shaper Challenging, full of drive dynamic Provokes others, hurts feelings No apologies, no humour
Monitor Evaluator Sober, strategic, sees options Lacks drive, overly critical Cynicism without logic
Team worker Cooperative, mild, diplomatic Indecisive, easily influenced Avoiding pressure situations
Resource Develop contacts, enthusiastic Overoptimistic, loses interest Letting clients down
investigator
Specialist Single minded, rare knowledge Overlooks big picture Ignoring important info.
85
10.3.2 Advantages & disadvantages
Both models work by testing people to find out which team roles they are best suited to. This
enables people to be placed in roles they are most likely to enjoy. When people are matched to
a role suitable for them they are likely to be happier in their job and perform better. It avoids
the square peg in a round hole syndrome. So the principal advantage of using such models is
having a motivated, happier and higher performing team. People forced into unsuitable roles
will exhibit stress and performance and team morale will suffer.
The downside is that the process can be expensive and time consuming. It is also subject to
manipulation if people being tested are aware of the method.
• Frustration
• Unhealthy conflict
• Unproductive meetings
• Members are willing to work hard for the good of the team
• They are willing to sacrifice personal interests for the team good
86
10.5 Stages in Team Development
The most widely used model of team development is the “Forming, Storming, Norming, Performing model”.
This model is illustrated opposite.
Figure 10.3
This is a well-recognised process that all teams go through. The job of the PM is to get the team
performing and keep them there. The PM must also realise that going through the stages from Norming to
Performing is natural and must be expected, Events such as team changes, change in objectives,
uncontrolled changes or setbacks can cause a team to stop performing and revert to storming.
The way in which the model relates to project activities and what must take place to progress from one stage
to
the next is illustrated below.
87
10.6 Influencing Team Performance
There are things that a leader can do to make sure that he/she has maximum beneficial influence on team
performance. e.g. :-.
• Make sure everyone contributes to and “buys in” to the project plan
88
Practice Exam Questions
1. Which of the following statements is the most important responsibility of the project sponsor?
3. Which of the following statements about a project life cycle is not true?
5. Which of the following would you not expect to find in a business case.
89
7. Which of the following best describes a project’s business case?
A. Success Criteria
B. Individual team member performance
C. Success Factors
D. Project progress
10. Which of the following is the best definition of the critical path?
A. Ensuring that the final product meets the needs of the business.
B. Minimising the impact of changes on the scope of the project.
C. Making sure that all changes are beneficial.
D. Ensuring the traceability and integrity of the delivered product or products
A. All the activities concerned with negotiating with potential suppliers of goods and services.
B. The placing of a contract with a supplier.
C. Arranging for the supply and delivery of purchased goods to a project site.
D. The securing (or acquisition) of goods or services.
90
14. Project context can be defined as:
17. Using the Work Breakdown Structure (WBS) to assist estimating is known as:
A. Comparative estimating.
B. Bottom-up estimating.
C. Definitive estimating.
D. Parametric estimating.
A. Bystanders
B. Key players
C. Stakeholders
D. Supporters
A. Quality planning
B. Quality control
C. Quality measurement
D. Quality assurance.
91
21. The document that represents the prime means of communicating the project manager’s
intentions to the stakeholders is the:
24. According to APM which of the following best describes a project issue?
26. Responsibility for producing the project management plan lies with:
92
27. Which of the following is true with regard to project quality?
A. Having a quality system will ensure that all products are of the approved standard.
B. Project quality is primarily the responsibility of people actually doing the work.
C. Quality cannot be achieved just by quality control inspections.
D. Quality will follow if everyone follows the quality system.
28. Which process determines if the quality system is being adhered to?
A. Design reviews
B. Project reviews
C. Quality audits
D. Product testing
A. PETAL
B. PASTEL
C. PISTOL
D. PESTLE
A. The totality of all the projects, programmes and associated operations within an organisation
B. All projects and programmes within an organisation
C. A set of independent projects under the control of one manager
D. A +C
33. When deciding on the relative importance of Time, Cost & Quality which of the following is
true?
A. Cost is always paramount
B. It is better to slip the schedule than increase the cost
C. Time, Cost and Quality are equally important
D. It is a negotiation between Time, Cost and Quality in relation to the overall project objectives.
93
34. What are the five activities in a configuration management process?
94
41. Which of the following best describes a project’s business case?
A. A statement of why the project is needed and what costs and benefits will accrue
B. A statement of what the project will deliver in terms of products/deliverables
C. A document which describes how the project will be managed
D. A statement as to how the project fits into the long-term strategy of the client
43. What term is used to define things within the project whose presence will
increase the likelihood of project success?
A. Acceptance criteria
B. Success criteria
C. Key performance indicators
D. Success factors
95
48. Which of the following statements is false?
A. Comparative estimating
B. Bottom-up estimating
C. Strategic estimating
D. Parametric estimating
96
55. If Total Float for an activity is negative, which of the following is true?
A. Demonstrate that the deliverables have been produced to the agreed time, cost and quality
B. Demonstrate that the deliverables are fit for purpose
C. Confirm that deliverables pass the agreed acceptance tests
D. Ensure that the deliverables generate the benefits defined in the business case
58. Which of the following is most likely to appear in a Project’s Business Case?
60. Which of the following would be provided by the Work Breakdown Structure?
97
62. Which of the following defines the term ‘deployment baseline’?
63. A project life cycle which combines approaches from the linear and iterative life cycles is known as
a ???? project life cycle.
A. a hybrid.
B. an extended.
C. a reduced.
D. a combined.
64. Which of the following statements refers to how scope is managed in a linear project but not an
iterative project?
1) exchanging information
2) managing stakeholders
3) confirming there is a shared understanding
4) building relationships within your team
A. 2 and 3 only
B. 1 and 4 only
C. 1 and 3 only
D. 2 and 4 only
67. A project manager requires a team member to focus on the team’s objectives and draw out other
team members. Which of the Belbin’s team roles is most appropriate?
A. Shaper.
B. Monitor evaluator.
C. Specialist.
D. Coordinator
98
68. Which of the following is a difference between deployment baselines in linear life cycles and
iterative life cycles?
A. Linear project life cycles set the deployment baseline for the whole project.
B. In an iterative project life cycle the scope and quality are fixed in the deployment baseline.
C. Only deployment baselines in iterative life cycles have an integrated baseline review.
D. Only deployment baselines in linear life cycles have an integrated baseline review.
70. Which of the following are challenges for a project manager developing and leading a project
team?
A. 1, 2 & 3
B. 1, 2 & 4
C. 1, 3 & 4
D. 2, 3 & 4
99
Practice Questions Answers
1. Which of the following statements is the most important responsibility of the project sponsor?
3. Which of the following statements about a project life cycle is not true?
5. Which of the following would you not expect to find in a business case.
A. Success Criteria
B. Individual team member performance
C. Success Factors
D. Project progress
10. Which of the following is the best definition of the critical path?
A. Ensuring that the final product meets the needs of the business.
B. Minimising the impact of changes on the scope of the project.
C. Making sure that all changes are beneficial.
D. Ensuring the traceability and integrity of the delivered product or products
A. All the activities concerned with negotiating with potential suppliers of goods and services.
B. The placing of a contract with a supplier.
C. Arranging for the supply and delivery of purchased goods to a project site.
D. The securing (or acquisition) of goods or services.
101
15. A principal purpose of a project handover is:
17. Using the Work Breakdown Structure (WBS) to assist estimating is known as:
A. Comparative estimating.
B. Bottom-up estimating.
C. Definitive estimating.
D. Parametric estimating.
A. Bystanders
B. Key players
C. Stakeholders
D. Supporters
A. Quality planning
B. Quality control
C. Quality measurement
D. Quality assurance.
E.
21. The document that represents the prime means of communicating the project manager’s
intentions to the stakeholders is the:
102
22. Which of the following would not be classified as a project risk?
24. According to APM which of the following best describes a project issue?
26. Responsibility for producing the project management plan lies with:
A. Having a quality system will ensure that all products are of the approved standard.
B. Project quality is primarily the responsibility of people actually doing the work.
C. Quality cannot be achieved just by quality control inspections.
D. Quality will follow if everyone follows the quality system.
28. Which process determines if the quality system is being adhered to?
A. Design reviews
B. Project reviews
C. Quality audits
D. Product testing
103
29. A common acronym for an analysis of project context is:
A. PETAL
B. PASTEL
C. PISTOL
D. PESTLE
A. The totality of all the projects, programmes and associated operations within an organisation
B. All projects and programmes within an organisation
C. A set of independent projects under the control of one manager
D. A +C
33. When deciding on the relative importance of Time, Cost & Quality which of the following is
true?
104
36. The relative importance of Schedule, Cost and Performance is:
A. A statement of why the project is needed and what costs and benefits will accrue
B. A statement of what the project will deliver in terms of products/deliverables
C. A document which describes how the project will be managed
D. A statement as to how the project fits into the long-term strategy of the client
105
43. What term is used to define things within the project whose presence will increase
the likelihood of project success?
A. Acceptance criteria
B. Success criteria
C. Key performance indicators
D. Success factors
106
49. Identifying and implementing project success factors will:
A. Comparative estimating
B. Bottom-up estimating
C. Strategic estimating
D. Parametric estimating
107
55. If Total Float for an activity is negative, which of the following is true?
A. Demonstrate that the deliverables have been produced to the agreed time, cost and quality
B. Demonstrate that the deliverables are fit for purpose
C. Confirm that deliverables pass the agreed acceptance tests
D. Ensure that the deliverables generate the benefits defined in the business case
58. Which of the following is most likely to appear in a Project’s Business Case?
60. Which of the following would be provided by the Work Breakdown Structure?
108
62. Which of the following defines the term ‘deployment baseline’?
63. A project life cycle which combines approaches from the linear and iterative life cycles is known as
a ???? project life cycle.
A. a hybrid.
B. an extended.
C. a reduced.
D. a combined.
64. Which of the following statements refers to how scope is managed in a linear project but not an
iterative project?
1) exchanging information
2) managing stakeholders
3) confirming there is a shared understanding
4) building relationships within your team
A. 2 and 3 only
B. 1 and 4 only
C. 1 and 3 only
D. 2 and 4 only
67. A project manager requires a team member to focus on the team’s objectives and draw out other
team members. Which of the Belbin’s team roles is most appropriate?
A. Shaper.
B. Monitor evaluator.
C. Specialist.
D. Co-ordinator
109
68. Which of the following is a difference between deployment baselines in linear life cycles and
iterative life cycles?
A. Linear project life cycles set the deployment baseline for the whole project.
B. In an iterative project life cycle the scope and quality are fixed in the deployment baseline.
C. Only deployment baselines in iterative life cycles have an integrated baseline review.
D. Only deployment baselines in linear life cycles have an integrated baseline review.
A. 1 and 2 only
B. 1 and 4 only
C. 3 and 4 only
D. 2 and 4 only
70. Which of the following are challenges for a project manager developing and leading a project
team?
E. 1, 2 & 3
F. 1, 2 & 4
G. 1, 3 & 4
H. 2, 3 & 4
110
111
112