qa apmp pre-course handbook v2.0

8/9/2019 QA APMP Pre-course Handbook v2.0

1/129

APMP Pre-course Student Handbook v0.1

APMP Certificate inProject Management

Student Pre-courseHandbook


2/129

Electronic APMP Pre-course Handbook V2.0

Page 1

ContentsIntroduction .................................................................................................... 3

1 Project Management in Context .............................................................. 4

1.1 Project Management APM Body of Knowledge (BoK) Topic 1.1 ..... 4

1.2 Programme Management - BoK Topic 1.2 ......... .......... ......... ......... ... 7

1.3 Portfolio Management - BoK Topic 1.3 ......... .......... ......... ......... ......... 9

1.4 Project Context - BoK Topic 1.4 ...................................................... 10

1.5 Project Sponsorship - BoK Topic 1.5 ......... .......... ......... ......... ......... . 11

1.6 Project Office - BoK Topic 1.6 ......................................................... 12

2 Planning the Strategy ............................................................................ 15

2.1 Project Success and Benefits Management - BoK Topic 2.1 ......... .. 15

2.2 Stakeholder Management - BoK Topic 2.2 ......... .......... ......... ......... . 18

2.4 Project Management Plan - BoK Topic 2.4 ......... .......... ......... ......... . 19

2.5 Project Risk Management - BoK Topic 2.5 ......... .......... ......... ......... . 21

2.6 Project Quality Management - BoK Topic 2.6 ......... ......... ......... ....... 24

2.7 Health, Safety and Environmental Management - BoK Topic 2.7 .... 27

3 Executing the Strategy .......................................................................... 31

3.1 Scope Management - BoK Topic 3.1 ......... .......... ......... ......... ......... . 31

3.2 Scheduling - BoK Topic 3.2 ............................................................. 36

3.3 Resource Management - BoK Topic 3.3 ......... ......... .......... ........ ...... 42

3.4 Budgeting and Cost Management - BoK Topic 3.4 ........ .......... ........ 45

3.5 Change Control - BoK Topic 3.5...................................................... 47

3.6 Earned Value Management - BoK Topic 3.6 .......... ......... ......... ....... 51

3.7 Information Management and Reporting - BoK Topic 3.7 ......... ....... 57

3.8 Issue Management - BoK Topic 3.8 ................................................ 59

4 Techniques ........................................................................................... 62

4.1 Requirements Management - BoK Topic 4.1 .......... ......... ......... ....... 62

4.3 Estimating - BoK Topic 4.3 .............................................................. 63

4.7 Configuration Management - BoK Topic 4.7 ......... ......... .......... ........ 64

5 Business and Commercial ..................................................................... 68

5.1 Business Case - BoK Topic 5.1 ......... .......... ......... ......... .......... ........ 68

5.4 Procurement - BoK Topic 5.4 .......................................................... 73

6 Organisation and Governance............................................................... 80

6.1 Project Life Cycles - BoK Topic 6.1 .......... ......... ......... ......... .......... .. 80

6.5 Handover and Closeout - BoK Topic 6.5 .......... ......... ......... ......... .... 82


3/129


Page 2

6.6 Project Reviews - BoK Topic 6.6 ..................................................... 84

6.7 Organisation Structure - BoK Topic 6.7 ........ .......... ......... ......... ....... 86

6.8 Organisational Roles - BoK Topic 6.8.............................................. 90

6.9 Methods and Procedures - BoK Topic 6.9 ......... ......... .......... ......... .. 91

6.10 Governance of a Project - BoK Topic 6.10 .......... ......... ......... ....... 93

7 People and the Profession .................................................................... 97

7.1 Communication - BoK Topic 7.1 ........ .......... ......... ......... .......... ........ 97

7.2 Teamwork - BoK Topic 7.2 .............................................................. 99

7.3 Leadership - BoK Topic 7.3 ........................................................... 106

7.4 Conflict Management - BoK Topic 7.4 ......... ......... .......... ........ ....... 114

7.5 Negotiation - BoK Topic 7.5 .......................................................... 121

Practise QuizzesSection One Quiz 13

Section Two Quiz 29

Section Three Quiz 60

Section Four Quiz 66

Section Five Quiz 78

Section Six Quiz 95

Section Seven Quiz 122

Section Quiz Answers 126


4/129


Page 3

Introduction

The purpose of this workbook is to assist you in preparing for your APMP course. Askanyone who has attended an APMP course and they will tell you how intense the course is.

These pre-reads have been produced by QA to assist in your preparation for the course andthus enhance your learning and understanding and improve your chances of a good result.

They are sufficiently detailed to give you an overview of (and in some areas additionalinformation over and above) the 37 APMP Syllabus areas and to use in your pre-coursepreparation, during the course and as part of your evening revision along with the coursematerials (if you are reading this electronically you may wish to print off a hard copy for thecourse).

At the end of each of the seven Sections there are a number of multiple choice questions foryou to tackle to test your understanding of those topic areas. You will find an Answer Grid atthe end of the reading material.

Whilst there is no particular recommendation on how long you spend reading, or on theorder in which the material must be read, it is suggested you read the material in thefortnight prior to your course attendance, and that you allow AT LEAST 2 hours reading foreach Section.

Please note that the APM Body of Knowledge, upon which the course and this pre-reading are based, is not a structured methodology. Rather it is a collation ofprinciples and processes that support effective project management. Any number oftechniques and tools could be used to apply these principles and therefore the pre-read and the course materials should not be seen as the only way to do things! Thepre-read may offer a different viewpoint to that offered by the course trainer, this is

deliberate, the aim of this being to offer you alternative approaches to consider.


5/129


Page 4

1 Project Management in Context

1.1 Project Management APM Body of Knowledge (BoK) Topic 1.1

1.1.1 DefinitionUnique process, consisting of a set of coordinated and controlled activities with start and

finish dates, undertaken to achieve an objective conforming to specific requirements,including the constraints of time, cost and resources.

(BS6079)

1.1.2 BoK Definition of Project ManagementProject management is the process by which projects are defined, planned, monitored,controlled and delivered such that the agreed benefits are realised. Projects are unique,transient endeavours undertaken to achieve a desired outcome. Projects bring about changeand project management is recognised as the most efficient way of managing such change.

1.1.3 Project Management ProcessThe BoK describes the Project Management Process as shown below in Figure 1.1.1.

This comprises:

An Input

The element that triggers a project this could be a problem, a new business opportunity, alegislative change or some other driver for change.

An Output

This describes the outputs or deliverables that the project will produce, often known as aproduct or products. These products could be new business services or some other form oforganisational change. In any event all projects produce some sort of change within anorganisation.

The input is managed by Project Management to produce the output and is affected by:

Constraints

These are the things within which the project team must operate, e.g. time, cost, quality,technical and other performance parameters, legal environment etc.

Mechanisms

To assist the delivery of the outputs within the constraints there are a number ofmechanisms that the Project Manager has at her/his disposal to manage the project. These

include the people, techniques and tools, equipment and organisation that comprise theProject Team and its supporting environment.


6/129


Page 5

Figure 1.1.1 - The Overall Project Management Process

Project Management can be described in terms of 4 generic processes that are applied tothe project as a whole and to each phase of the project life cycle (see Topic 6.1):

Starting or initiation This process ensures that the project or phase has a sound basis upon which toproceed. For the project, the business case will be established at this time and thereasons for undertaking the project need to be clearly understood by all. There will bean initial analysis of stakeholders and risk and then a small team can be formed to takethe project forward

Defining and planning In this process, for the project, the Project Management Plan (PMP) will be developed(see Topic 2.4). The project team will prepare the plans for the project or phase,developing the work undertaken during Starting . Once this is completed the project orphase will be fully understood and the funds released so the work can be undertaken.

Monitoring and control This is where the project team will spend most of its time. It covers three main areas giving out work and receiving advice of its completion, sending and receiving progressreports (monitoring) and taking appropriate action based on the content (control) andfinally monitoring and controlling change to the project. This tends to be an iterativeprocess as the project moves from stage to stage or phase to phase.

Learning and closing process The project comes to a close when the deliverables will be handed over and the projectbrought to an end. A key activity to be undertaken at this time is to evaluate how theproject was managed, what went well, what didn t go so well and what could be donedifferently in the future. Whilst these are typically end of project activities they should beundertaken at each major review point to ensure that there is a process of continuousimprovement being undertaken throughout the project s life -cycle.

1.1.4 Supporting ElementsThere are a number of elements which support the general Project Management processes.Briefly these are:

ConstraintsTime, cost, quality,

technical and other performance parameters,legal, environment, etc.

ConstraintsTime, cost, quality,technical and other performance parameters,legal, environment, etc.

MechanismsPeople, techniques andtools, equipment,organisation

MechanismsPeople, techniques andtools, equipment,

organisation

OutputProject deliverables,and/or services,change


InputBusiness need, problemor opportunity


Management of theProject


ConstraintsTime, cost, quality,

technical and other performance parameters,legal, environment, etc.

ConstraintsTime, cost, quality,technical and other performance parameters,legal, environment, etc.

MechanismsPeople, techniques andtools, equipment,organisation

MechanismsPeople, techniques andtools, equipment,

organisation








7/129


Page 6

Quality Assurance The process that ensures the Quality Plan developed for the project is being implemented.Basically, QA is checking the checkers.

Configuration Management The discipline whereby all the products/deliverables of the project are recorded and keptunder version control. This also includes Change Control.Risk Management

An essential ingredient for project success is the detailed identification, assessment,evaluation, mitigation and management of risk.

Procurement Procurement is an integral part of Project Management and requires particular skills,especially within the areas of contract and law.

Financial Control Cost control within the project is crucial. At a minimum the Project Manager will be requiredto report actual spend against planned spend and be able to forecast spend within the next

phase and for the remainder of the project.People Skills This will involve establishing the team, communications to staff at all organisational levels

and negotiation skills to name but a few.

1.1.5 Project Management vs Business as UsualProject Management techniques and processes enable the Project Manager to managetime, cost, scope, quality, performance and risk in order to implement change within thebusiness. This differs from managing the normal operational activities (business as usual) ofthe organisation.

Typically, techniques for managing projects are focussed on:

responding to change

dynamic multi discipline teams

delivering products to time, cost and quality in order to produce benefit

flexible approach to working methods

taking some risks.

On the other hand business as usual is focussed on:

optimising repetitive process

functional team containing related disciplines maintaining/improving quality

reducing costs

reducing risk

using the products of the project to generate benefits.


8/129


Page 7

1.2 Programme Management - BoK Topic 1.2

1.2.1 BoK Definition of Programme ManagementProgramme management is the co-ordinated management of related projects, which mayinclude related business-as-usual activities that together achieve a beneficial change of astrategic nature for an organisation. What constitutes a programme will vary acrossindustries and business sectors but there are core programme management processes.

1.2.2 Programme Management ProcessesWithin Programmes each project is inter-dependent upon another and each will contribute tothe overall benefit that justifies the programme. Some projects may be infrastructureprojects. These are projects that don t make a direct contribution to the benefit, but withoutthem the programme would fail. An example of this would be a project to install acommunications network within an organisation. In its own right this generates no directbenefit. However, until it is implemented the company will not be able to run the newapplications that do deliver benefits.

When managing a programme, changes and risk at project level must be considered forescalation to the programme.

There are few, if any, strict definitions of a programme. What differentiates a sub -projectfrom a project or a project from a programme is rather vague. For example a programmeconcerned with building a hospital, or a new international airport terminal may be viewed asa programme or as a super -project. The underlying definition of programmemanagement usually contains reference to some element of strategic change as a result ofundertaking the work. This is not usually the case for projects. Timescales also play a part

many projects last for less than 2 years whist most programmes continue for 3 5 years,sometimes longer. Irrespective of the definitions you use there are a number of keyprocesses used in programme management.

It is normal for the Project Managers to report to the Programme Manager. The ProjectManagers will normally have a degree of autonomy, but will inevitably be subject to commonrestraints imposed to support the overall objectives of the programme.

The Programme Manager will be responsible for the allocation of resources to the ProjectManagers and the link between the project portfolio and the parent organisation s objectives.

Programme management brings with it a risk that more than one level of business changemanagement may lead to confusion. The manager of the programme will have to take thisinto account and be prepared to address any conflicting project objectives and disputes overshared resources. The management, direction and objectives of the programme willinevitably influence each of its constituent projects.

Programme management processes concentrate on benefits management and stakeholderinvolvement. The production of deliverables or outputs is left to the project managers.

Example process flow:

A project will deliver an output (product) to the programme

The programme takes the output and implements it in the business (the transitionprocess)

The business experiences some change in process or staff behaviour, which is known asthe outcome.

As a result of the outcome the business is now able to generate benefits.


9/129


Page 8

This is a key difference between programme and projects.

Projects produce outputs, programme produce outcomes and generate benefits. Benefitswill be realised during the programme life-cycle and continue to managed once theprogramme has closed.

1.2.3 Advantages of Programme ManagementProgrammes are focussed on delivering strategic change and realisation of benefits.

Programme management offers its projects many of the benefits associated with sharingscarce resources and economies of scale.

Some of the functions performed by support staff within projects may be undertaken atprogramme level for all projects within the programme, e.g. IT systems support andConfiguration Management etc.

A single member of staff may be made responsible for collating all the informationassociated with a particular project management task such as risk management. As aresult, the effort required to maintain risk logs across projects will be reduced. This specific

example has the additional benefit of maintaining an alertness to risks associated withproject dependencies and risks which may be common across a number of projects.

There will be a reduction in the number of subject matter experts required across theprogramme. This will have the effect of reducing costs. However, it will also have what isperhaps a more important benefit, in that it will allow the sharing of individuals with scarceskills across several related projects within the programme.

Centralised support services ensure consistency in the tools, procedures and methods beingused.

1.2.4 Disadvantages of Programme ManagementWhere projects are geographically dispersed, the benefits of the centralised support servicesetc. associated with managing a programme will be significantly reduced. Theireffectiveness is also likely to suffer.

Support staff have to be alert to the duality of their role, their obligations to the programmeand their project.

If a number of projects require the same specialist expertise, resource conflicts may arise.


10/129


Page 9

1.3 Portfolio Management - BoK Topic 1.3

1.3.1 BoK Definition of Portfolio ManagementPortfolio management is the selection and management of all of an organisation s projects,programmes and related business-as-usual activities taking into account resourceconstraints. A portfolio is a group of projects and programmes carried out under thesponsorship of an organisation. Portfolios can be managed at an organisational, programmeor functional level.

1.3.2 Portfolio ManagementFigure 1.3.1 - Inter-relationships between portfolios, programme and projects

In its simplest form an organisation would have a single portfolio containing one or moreprogrammes supporting its strategic vision. Each programme is then broken down intoprojects which will be undertaken in addition to the normal operations of the organisation.Management of the relationships between the programmes, projects and BAU is normallythe responsibility of a senior management team within the organisation concerned.

Key tasks will be to monitor resource requirements across the 3 strands, ensure that theprogrammes continue to support the strategy and to ensure that benefits are realised. In

particular the portfolio management team will be concerned with the interdependenciesbetween programmes and projects in terms of scarce resources, balance within the portfolioof risk and return, timing of outputs and managing capacity bottlenecks where more than oneproject requires the same resource(s) at the same time.

It is probable in many large organisations that whilst there might be an overarching strategyeach function may have its own portfolio. For example the Sales and Marketing Departmentmay have a number of programmes running which support their strategic sales vision, eachspawning a number of projects whilst they continue to manage the BAU.

At the same time the Operations Dept may have a similar portfolio to manage.

Strategic objectives

and targets

Strategic Benefits

Programme 1Programme 1 Programme 2Programme 2

Project A Project B Project C Project D Project E

Sub-Project

A1

Sub-Project

A2

Business as Usual

Programmemanagement

Projectmanagement

Portfoliomanagement

Strategic objectives

and targets

Strategic Benefits

Programme 1Programme 1 Programme 2Programme 2

Project A Project B Project C Project D Project E

Sub-Project

A1

Sub-Project

A2

Business as Usual

Programmemanagement

Projectmanagement

Portfoliomanagement


11/129


Page 10

1.4 Project Context - BoK Topic 1.4

1.4.1 BoK Definition of Project ContextProject context refers to the environment within which a project is undertaken. Projects donot exist in a vacuum and an appreciation of the context within which the project is being

performed will assist those involved in project management to deliver a project.

1.4.2 Project ContextProjects are about the implementation of change, usually in step form, within anorganisational/business environment. As such all projects need to be established withintheir own particular context both internally and externally.

The changes essentially fall into two categories:

Technical Involves change to the technology, physical environment of the organisation as a result ofengineering work, IT work, hardware, software, networks etc.

Cultural Involves change to the organisation, such as skills, attitudes, values, managementprocesses, structure etc.

The vast majority of projects are a combination of both types. It is often more difficult tocope with cultural change than technical change, e.g. the second runway at Manchester

Airport, on the face of it a purely technical project, but one which aroused intense feelingabout the environment e.g. cultural issues.

To assist with the assessment of the project s strategic setting it is often usef ul to conduct aPESTLE analysis.

Political

The current/potential impact of global, national, local or organisational political pressure.EconomicalThe current/potential impact of global, national, local or organisational economic factors.

SociologicalThe current/ potential impact of society s composition, culture, behaviou r attitudes, abilitiesand expectations.

TechnicalThe current /potential impact of advances in technology.

LegalThe current/potential impact of global, national or local legislation.

EnvironmentalThe current/potential impact of the project and the changed organisation on the environment.

A PESTLE analysis can be used to identify potential threats and opportunities and will assistwith the successful management of the project.


12/129


Page 11

1.5 Project Sponsorship - BoK Topic 1.5

1.5.1 BoK Definition of Project SponsorshipProject sponsorship is an active senior management role, responsible for identifying thebusiness need, problem or opportunity. The sponsor ensures the project remains a viable

proposition and that benefits are realised, resolving any issues outside the control of theproject manager.

1.5.2 The Project SponsorThis is perhaps the most important role in any project. S/he is responsible for the project, itsbusiness case, budget and the resulting achievement of benefits. The sponsor is theprimary risk taker and will chair the steering group.

Accordingly, a sponsor is normally a senior manager within an organisation and must beempowered to make decisions by the corporate management. It is important that whoevertakes the role must have the capability and the time available to commit to the project. Thesponsor should ideally stay with the project throughout its life-cycle.

Many large projects cross organisational boundaries and as such internal politics canbecome an issue for the project. Therefore, the sponsor must have sufficient authority tocross these boundaries and engage the stakeholders to ensure that they all support the aimsof the project.

The project manager is accountable to the sponsor and regular communication betweenthem is vital to success. This should not be confined to formal reporting but should includeinformal contact throughout.

Figure 1.5.1 details the role of the sponsor throughout the life-cycle.

Figure 1.5.1 Sponsor s role across the life -cycle

Establish context Agree team Provide resource State benefits Contribute to and

sign off theBusiness case

Provide guidance Contribute to the

PMP Sign off the PMP

Receive reports Make decisions Chair steering

group Chair reviews Monitor change Prepare for

benefits realisation

Acceptdeliverables

Agree outstandingwork

Sign off reports Ensure plans for

benefits realisationare in place

Concept Definition Implementation Handover andcloseout

Establish context Agree team Provide resource State benefits Contribute to and

sign off theBusiness case

Provide guidance Contribute to the

PMP Sign off the PMP

Receive reports Make decisions Chair steering

group Chair reviews Monitor change Prepare for

benefits realisation

Acceptdeliverables

Agree outstandingwork

Sign off reports Ensure plans for

benefits realisationare in place

Concept Definition Implementation Handover andcloseout


13/129


Page 12

1.6 Project Office - BoK Topic 1.6

1.6.1 BoK Definition of Project Office A project office serves the organisation s project management needs. A project office canrange from simple support functions for the project manager to being responsible for linkingcorporate strategy to project execution.

1.6.2 Role of the Project OfficeIn all but the smallest of projects there will be a significant amount of administration to beundertaken. Without any support this falls to the Project Manager to complete and caneasily result in one of two outcomes; the administration is left whilst the PM concentrates onday to day management, or the PM gets the admin done at the expense of the day to daymanagement. Alternatively, the PM works lots of overtime!

This is where the role of the basic project office comes in. It can be some administrativesupport, maybe 2 or 3 days a week and the person taking the role assists the PM withadministration, completion of minutes of meetings, maintaining the schedule, receiving andanalysing reports and so forth. Because this is a part time function at this level it is oftendifficult to justify in terms of headcount and resources available. It is for this reason thatmany organisations have established a formal Project Support Office (PSO) function.

A PSO is a group of perhaps 5 or 6 staff that supports several projects between them. Asthe peak demand for administration varies the staff are able to cross project boundaries andassist where required.

Typical responsibilities of a PSO include:

Operate a filing system for several projects

Operate a configuration management system

Be a centre of expertise for:o Estimating techniques

o Planning and control software

o Risk analysis methods and software

Preparation of plans

Project reporting

Assurance of the process

Maintain logs for risks, issues and changes.

In some organisations the PSO is combined with a Programme Support Office and becomesa Programme and Project Support Office (PPSO). At the programme level the role is oftenexpanded to cover the governance of the project, and staff in these units often act asdeputy managers.

Whatever arrangements are made in the project it important that the project documentationis not overlooked as it forms an important audit trail throughout the project life-cycle.


14/129


Page 13

Section One Project Management in Context

1, Which of the following is a typical characteristic of a project?

a) Repetitive

b) Stable, unchanging team

c) Goal driven

d) Constant, unchanging environment

2. Which of the following is best suited to be line managed?

a) Building a bridge

b) Developing a tin-opener

c) Buying a car

d) Manufacturing car batteries

3. Which of the following best describes the overall aim of project management?

a) To eliminate risk

b) Adhere precisely to the original specification

c) Ensure the original budget is met

d) Achieve the success factors described in the Business Case

4. Which of the following constitute a programme?

a) A group of otherwise unrelated projects sharing resources

b) A large and complex project

c) A group of projects sharing a common business purpose

d) Maintaining Business operations

5. What are considered by a PESTLE analysis?

a) Political, Economic, Sociological, Technical, Legal, Environmental

b) Personnel, Economic, Safety, Technical, Legal, Estimating

c) Political, Ecological, Safety, Technical, Lifecycle, Environmental

d) Personnel, Ecological, Sociological, Training, Lifecycle, Estimating


15/129


16/129


Page 15

2 Planning the Strategy

2.1 Project Success and Benefits Management - BoK Topic 2.1

2.1.1 BoK Definition of Project Success and Benefits ManagementProject success is the satisfaction of stakeholder needs and is measured by the successcriteria as identified and agreed at the start of the project. Benefits management is theidentification of the benefits at an organisational level and the monitoring and realisation ofthose benefits.

2.1.2 GeneralThe succes of a project will be judged by many people, including:

The client/sponsor

The project manager and project team

The users

The customer

There are many examples of projects which appear to hav e failed, especially in the publicsector as these often reach the headlines. However, just because a project has exceededits original budget does not mean it has failed. It may appear so but if the additional spendhas been authorised and benefits can still be realised, can it really be judged a failure?

To judge success it is necessary that there be some objective criteria. Once these criteria,and the associated Key Performance Indicators, have been set then the project managerwill aim ensure that they can be achieved.

2.1.3 Project Success CriteriaSpecifically these revolve around time, cost, quality/performance and the customer srequirements. Budgets and timescales are often set in advance - the requirements andassociated acceptance criteria can be difficult to pin down. What makes the deliverableacceptable to the customer?

2.1.4 Project Success FactorsResearch has indicated that there are five key factors which can be established againstwhich success can be measured:

Project Objectives

clearly identified within the project plans and kept to throughout the work

Project Personnel

the project manager and the project team must be competent

Support from Above

the project must be supported by top management

Resources

time, money, material and people must be sufficient to do the job

Communication and Control


17/129


Page 16

communications channels up, down and across the project are established with clearmechanisms for feedback on performance.

Other factors conducive to project success would include:

A plan - good and managed, replan when required

Time to plan - very important, often difficult to find

The right sized work packages suited to the team and measurable

2.1.5 Key Performance IndicatorsThe BoK defines Key Performance Indicators (KPIs) as measures of success criteria andgoes on to say that Tracking KPIs ensures that the project is progressing towardsachievement of success criteria, enabling corrective action to be taken. The KPI must becarefully chosen to be suitable measures of the project s su ccess and they must be clearand unambiguous.

2.1.6 Benefits ManagementThe benefits are those things, tangible or intangible, that justify the time, money andresources that are spent on delivering a project. If there are no benefits then, ideally, thereshould be no project. If the benefits disappear, for whatever reason then the project shouldbe stopped. The benefits should be monitored and maintained throughout the life-cycle ofthe project and efforts made to realise them once the project products have been delivered.

However, in many projects, this is overlooked and the projects continue when no benefitscan be identified.

2.1.7 Benefits ProcessProject Phase Relationship to benefits

Concept Business benefits are identified by the sponsor andencapsulated within the business case

Definition The benefits are further refined and the business case updated.The PMP is produced which describes how the project willdeliver the products that will enable the benefits to be realised.

Implementation The benefits are benchmarked. Figures are collected that relateto each benefit so that a similar exercise can be undertakenduring realisation which will enable a comparison to be made.

As more becomes known about the project and its outputsfurther benefits are identified if possible and the existing benefits

are monitored to ensure that the claims are still valid.Handover andClose Out

The sponsor accepts the products and makes sure that plansare in place for the benefits to be realised.

Operations The sponsor ensures that the operational or BAU staffundertake the necessary activities to realise the benefits, e.g. ifthe new product was to allow a reduction in staff numbers thenthe appropriate numbers of staff should be re-deployed. If theproduct was to enable increased sales then the sales figuresshould be monitored to check that the benefits have beenrealised. If not then action should be taken.


18/129


Page 17

2.1.8 Defining BenefitsBenefits should be measurable. Benefits can be categorised as shown below in figure 2.1.1.

Figure 2.1.1 Benefit Categories

There are many types of benefits and ideally the benefits should fall into the tangiblecategory and therefore be easier to justify. However, benefits that fall into the intangiblecategory are also useful and may well indicate areas where cultural change may be requiredwithin the organisation. This could represent considerable challenges to realise thesebenefits.

Each benefit identified must be carefully and precisely stated and it is useful to test thebenefits agai nst the DOAM criteria:

DESCRIPTION o What precisely is this benefit?

OBSERVATION

o What differences should be noticeable between pre- and post-project?

ATTRIBUTION

o Where will this benefit arise?

MEASUREMENTo How will the achievement of the benefit be measured?

e.g. better image staff morale customer service i.e.

improved market perception

e.g. greater accuracy increased employee efficiency customer service

increased speed of response

e.g. staff reductions increased revenue accommodation costs

Indirect

Direct (non-financial)

Direct (financial)

Intangible

Tangible

Relate toNon-financialobjectives

Relate toFinancialobjectives

e.g. better image staff morale customer service i.e.

improved market perception

e.g. greater accuracy increased employee efficiency customer service

increased speed of response

e.g. staff reductions increased revenue accommodation costs

Indirect

Direct (non-financial)

Direct (financial)Direct (financial)

IntangibleIntangible

TangibleTangible






19/129


Page 18

2.2 Stakeholder Management - BoK Topic 2.2

2.2.1 BoK Definition of Stakeholder ManagementStakeholder management is the systematic identification, analysis and planning of actions tocommunicate with, negotiate with and influence stakeholders. Stakeholders are all thosewho have an interest or role in the project or are impacted by the project.

2.2.2 Stakeholder ManagementKey stakeholders should be identified early within the project life cycle, mapped andanalysed.

This will involve a number of steps:

1. Identify the stakeholders, perhaps through a workshop or other brainstorming activity.

2. For each stakeholder identified, establish their main interest in the project e.g. time,cost, scope, benefit or quality. Not only will this help to identify how stakeholders arelikely to react in the future but will show what the stakeholders see as the main driverof the project. For example if the analysis shows a majority of ticks against qualityand none against cost it would show that the main driver is quality and cost is not akey issue.

3. For each stakeholder identified establish their power and interest rating. It shouldalso be established whether s/he has a positive or negative attitude towards theproject.

4. The results of the power/interest analysis can be plotted on a grid as shown infigure 2.2.1 below.

Figure 2.2.1 Stakeholder mapping

The information relating to main interest area that was gathered earlier can now be used asa basis of the communications plan, as it will show the type of information each stakeholder(group) requires. The analysis could also be used to identify the role the stakeholder shouldtake, if any, on the project team. It may also assist with identification of key risks associatedwith stakeholders.


20/129


Page 19

2.4 Project Management Plan - BoK Topic 2.4

2.4.1 BoK definition of Project Management PlanThe project management plan brings together all the plans for a project. The purpose of theproject management plan (PMP) is to document the outcomes of the planning process andto provide the reference document for managing the project. The project management planis owned by the project manager.

2.4.2 Project Management PlanThe Project Management Plan (PMP) is the key document which contains all the keyinformation for the project. It is sometimes known as the Project Initiation Documentation(PID) in Prince 2, the Project Strategy Plan or the Project Execution Plan (PEP).

Basically, the PMP documents the what, why, when, how, where, who, how muchand what if of the project.

The PMP is owned by the Project Manager and it must be approved by the project team and

the project sponsor. It must have the commitment of all concerned.The purpose of the PMP is to provide a basis upon which the project can be managed andits success judged.

It has two primary purposes:

it ensures that the project has a sound basis upon which to proceed before asking thesponsor and other stakeholders to make major commitment to the project

it provides a base document against which the project management team can assessprogress, change management issues and the ongoing viability of the project.

BS 6079-1: 2002 states that a basic project management plan should contain the followingsections:

a) Introduction and summary

This part of the PMP should include the following information:

Project name, reference number, issue number and date

PMP Contents

Name of sponsor

Summary of objectives and the approach proposed to achieve them

Summary of completion (acceptance) criteria List of amendments and short summary of each

References to mandates, governance standards etc

Guidance for performing the work, for example, procurement strategy, riskmanagement strategy, contract management, organisation structure etc

Document circulation and contacts list

List of associate contracts

Reference to the business case upon which the project was authorised.


21/129


Page 20

b) Commitment acceptance (for task owner commitments and project manager sacceptance of them)

This includes the task owners commitments and the PM s acceptance of thesecommitments. This should be achieved by signing the appropriate WBS reference.This would include any caveats made by the task owners.

c) Project Work Breakdown Structure (WBS)

The WBS is a hierarchical description of the tasks that will form the project schedule. At project level the WBS should indicate the areas of work for the task owners so thatthey can develop the WBS into a task level breakdown. This graphicalrepresentation reduces the risk of overlooking something and helps to define theamount of work involved. (It is discussed further in Section 3 Executing theStrategy).

The WBS dictionary is a list of all the tasks along with a short description of each. Itwill also include a glossary of task definitions and will enable users to locate tasksquickly.

d) Schedule

The schedule is a Gantt (or bar) chart, perhaps supported by a critical path network.It provides a view of the tasks against a calendar (and the network shows thedependencies between them).

e) Statement of Work (SOW)

The SOW includes a description of the work, the person accountable for the work, alist of key deliverables, timescales, schedule of dependencies, cost schedule, riskassessment, performance measures, description of the work content and reportingrequirements.

At the level of the PMP this may relate to the project but each subsidiary work areaand further sub-division into the individual tasks will all require a SOW at theappropriate level.

In summary, the PMP is not a trivial document; neither will it be completed quickly. It is,however, the basis for a successful project and must be baselined, placed underconfiguration management and updated throughout the project.


22/129


Page 21

2.5 Project Risk Management - BoK Topic 2.5

2.5.1 BoK Definition of Project Risk ManagementProject risk management is a structured process that allows individual risk events andoverall project risk to be understood and managed proactively, optimising project success byminimising threats and maximising opportunities.

2.5.2 More Definitions(From the Project Risk Analysis and Management Guide 2 nd edition)

o Risk event ..is an uncertain event or set of circumstances that, should it occur,will have an effect on achievement of one or more of the project s objectives

o Project risk..is the exposure of stakeholders to the consequences of varia tions inoutcome.

Additionally, a differentiation should be made between threats and opportunities:

o Threat is a risk event that has a negative impact o Opportunity is a risk event that has a positive impact.

2.5.3 Risk Management ProcessThe risk management process identified is shown below in figure 2.5.1.

Figure 2.5.1 - Risk Management Process

Each element of the cycle is defined within the slides.

Initiate

Identify

Assess

Plan responses

Implement responses

Manageprocesses

Initiate

Identify

Assess

Plan responses

Implement responses

Manageprocesses

Initiate

Identify

Assess

Plan responses

Implement responses

Manageprocesses


23/129


Page 22

2.5.4 Qualitative Risk Identification & Assessment TechniquesThere are several qualitative risk management techniques including:

Assumptions analysis

Constraints analysis

Check lists

Prompt lists

Workshops/Brainstorming/SWOT analysis

Probability-Impact (P-I) tables

Interviews.

2.5.5 Risk Planning StrategiesOnce risks have been identified, their individual importance assessed and their combinedeffect on achievement of project objectives analysed, it is necessary to decide how torespond appropriately. Risk control techniques fall into four groups, aiming to avoiduncertainty, transfer ownership, reduce exposure or absorb individual risk. These areoutlined below.

Risk Avoidance

Measures designed to avoid uncertainty include:

Clarifying requirements and objectives.

Improving channels of communications.

Obtaining information from external sources.

Acquiring expertise.

Changing the direction or strategy for project implementation.

Reducing the scope of the project.

Adopting a familiar approach for implementation.

Using proven methods, tools and techniques.

Risk Transfer

It may be appropriate to transfer ownership and liability for a risk to another party outside theproject. It should be recognised that it may not be possible to transfer all aspects of a risk.For example, financial liability may be transferred to a supplier via cost penalties, but the

project will retain the performance impact if supplied equipment is late or non-compliant.Methods for risk transfer include:

Financial instruments such as insurance, performance bonds, warranties orguarantees.

Renegotiation of contract conditions to pass the risk back to the customer.

Subcontracting risks to suppliers.

Entering into risk-sharing joint ventures or client-contractor teaming arrangements

Considering other contractual forms such as target-cost incentivisation.


24/129


Page 23

Risk Reduction

There are many strategies for reducing risk exposure, and the bulk of risk control activity isfocused on this objective. Risk reduction techniques aim to:

Reduce the probability of occurrence by targeting trigger conditions

Reduce the potential severity of impact by targeting impact drivers Tackle the common causes of risk by identifying generic responses

Include targeted contingency or risk budgets, applied to high-risk areas, and withidentification of specific release conditions when the contingency amount may beused.

Risk Acceptance

It is not usually possible to remove all risk from a project, and strategies must be adopted tocontrol risks that cannot be avoided, transferred or cost-effectively reduced. These mayinclude:

Routine risk monitoring and reporting Regular risk reviews and updates

Feedback of risk information into project planning and strategy

Efficient infrastructure support for the risk process

Continued commitment to proactive risk management


25/129


Page 24

2.6 Project Quality Management - BoK Topic 2.6

2.6.1 BoK Definition of Project Quality ManagementProject quality management is the discipline that is applied to ensure that both the outputs ofthe project and the processes by which the outputs are delivered meet the required needs ofstakeholders. Quality is broadly defined as fitness for purpose or more narrowly as thedegree of conformance of the outputs and process.

2.6.2 Principles of Quality ManagementQuality management is the process of ensuring that the quality expected by the customer isachieved. It encompasses all the project management activities that determine andimplement the Project s Quality Plan.

2.6.3 Quality Management SystemsQMS: A Quality Management System with an organisational structure, procedures andprocesses to implement quality management. Both the Customer and the Supplier may havequality systems. The project may have to use one of these quality systems or an agreedmixture of both.

QP: Quality Planning establishes the objectives and requirements for quality and lays outthe activities for the application of the quality system. The quality approach for the wholeproject is defined in the Project Quality Plan (itself a part of the PMP). It is important that theCustomer s quality expectations are understood and documented prior to projectcommencement. This is done in Mobilisation. The Quality Plan specifies in detail therequired quality activities and resources, with the associated detailed quality criteria.

QA: Quality Assurance sets up the quality system and is the means of assuring that thequality system operates to achieve an end product which meets quality and customerrequirements. It creates and maintains the quality system, audits and evaluates it. A qualityassurance function may be set up separately from, and independent of, the organisation sproject and operational activities. Its purpose is to monitor the use of the quality systemacross all projects within the corporate body. If such an independent body does not exist, theproject assurance function within the project will assume the quality assurance role.

QC: Quality Control is the means of ensuring that products meet the quality criteria specifiedfor them. Quality control is about examining deliverables/products to determine that theymeet requirements.

We should examine the principles behind a quality check to provide:

A structured approach to the examination of subjective and objective quality criteria

Early identification of defects - a platform for improvement with attendant reduction in thecosts of the final product

A test of completion - once they have successfully passed Quality Review, an objectivemeasurement for management progress control is provided; progress is measured byproduct delivery

A means for all vested interests to work together to improve product quality

For personnel to commit to that product, as ownership of the product is shared betweenQuality Review participants

A means to check for defects in standards and methods chosen for the project -leadingtowards standards improvements.


26/129


Page 25

2.6.4 Quality Management ToolsBearing in mind that project management is systemic (the separate parts inter-relate) it is notsurprising that we have already examined some quality tools in Risk Management.

Audits : a review of the project, its management, standards and procedures. An internalbody, such as project support office, or an external auditor, can undertake the auditdepending on the situation. The aim of the audit is to assist the team to undertake theproject in a controlled manner that will aid the project to deliver right first time. The audit orwill prepare a report documenting the results of the audit and if non-conformances are notedwill normally give a date by which they should be rectified. This will often include a date for are-assessment.

Ishakawa Diagrams (Cause and Effect Analysis): These are also known as fishbonediagrams where there is an effect, and a range of possible causes sorted into categorieswith factors on each bone emanating from the central backbone. In a quality situation thequality problem would be the head a nd factors that contribute to the problem would becategorised and added to the bones. It may be useful to use another technique known asthe Five Whys when identifying causes. This simple technique is very like the inquisitivechild that continually asks why? Research has shown that if you ask why something hasoccurred and then when given an answer, you ask why again you will, after 5 iterations havegot to the root cause.

As an example take checkout queues in supermarkets being too long.

Why? Be cause the operator can t check the goods through fast enough

Why? Because the operator doesn t understand the systems

Why? Because training has not been given

In this example 3 whys were enough to get to root cause of the problem staff training.In some cases two or three more iterations may be required.

Once this has been completed a further analysis will be required to see which bone orgroup of bones would have the most effect if fixed. This could be achieved using aPareto analysis.

Pareto Analysis : Vilfredo Pareto was an Italian economist who, in 1906, observed thattwenty percent of the Italian population owned eighty percent of the country's total wealth.Ever since then, Pareto's observation has been used in a variety of ways, and is oftenreferred to as the 80-20 Rule, the "Vital Few and Trivial Many Rule.", or simply Pareto'sPrinciple.

It is of particular interest to us here in that it is a reminder that just a few causes account formost of the effect in a Cause and Effect Diagram. When you have carried out a Cause and

Effect analysis your next step should be to identify and work on the vital few causes.

Thus it is possible to identify those problems (the 20%) that if fixed will have the most effect(the 80%).

Sampling: This is a quality control technique and is used to check that products meet thequality criteria specified. For example, in a manufacturing environment the products will bechecked every 100 runs.

100% testing : This quality control technique does exactly what it says everything is tested.For example an installation of telephone sockets in a large building may mean that 10,000outlets are installed. The client may want all to be tested. However, as this number includes


27/129


Page 26

a number of spares and allows for growth it may be that sampling may be a more costeffective and adequate approach.

Inspection : Similar to audit but requires the physical inspection of the products to see thatthey conform to the criteria specified. It may well be supported by data from other activitiessuch as sampling or 100% testing.

Control Charts : These are used to record historical quality control data, perhaps fromsampling and, in common with many monitoring activities, will enable the user to identifytrends, either good or bad. If a negative trend has been identified, one of the othertechniques can be used to identify its cause and then corrective action taken.

2.6.5 Cost of QualityThere is a balance between providing high standards which are expensive to maintain butproduce low error rates, and low standards which cost nothing but have a high cost inrectification and rework.

This is shown graphically below and the minimum cost is the balance. However, in most

projects the aim would not be to achieve the minimum cost but somewhere to the left of thepoint shown as we would expect to have slighter higher standards and be prepared to payextra for them.

Figure 2.6.1 The Cost of Quality

LowHigh

HighLow

Number of MistakesStandards

C o s

t

Cost of Control

Cost of Failures

Total CostMinimum Cost

LowHigh

HighLow

Number of MistakesStandards

C o s

t

Cost of ControlCost of Control

Cost of FailuresCost of Failures

Total CostMinimum Cost


28/129


Page 27

2.7 Health, Safety and Environmental Management - BoK Topic 2.7

2.7.1 BoK Definition of Health, Safety and Environmental ManagementHealth, safety and environmental management is the process of determining and applyingappropriate standards and methods to minimise the likelihood of accidents, injuries or

environmental impact both during the project and during the operation of its deliverables.

2.7.2 Health & Safety Legislation All employers have a general Duty of Care under common law to take whatever steps arenecessary to ensure the health, safety and welfare of their employees and in particular toprovide:

A safe place of work

Safe means of access to that place of work

Safe system of work

Adequate materials Competent fellow employees

Protection from unnecessary risk of injury.

2.7.3 [Extracts from ] The Health & Safety at Work etc. Act General DutiesGeneral duties of employers to their employees.

2. (1) It shall be the duty of every employer to ensure, so far as is reasonably practicable, thehealth, safety and welfare at work of all his employees.

(2) Without prejudice to the generality of an employer's duty under the preceding subsection,the matters to which that duty extends include in particular

(A) the provision and maintenance of plant and systems of work that are, so far as isreasonably practicable, safe and without risks to health;

(B) arrangements for ensuring, so far as is reasonably practicable, safety and absence ofrisks to health in connection with the use, handling, storage and transport of articles andsubstances;

(C) the provision of such information, instruction, training and supervision as is necessary toensure, so far as is reasonably practicable, the health and safety at work of his employees;

(D) so far as is reasonably practicable as regards any place of work under the employer'scontrol, the maintenance of it in a condition that is safe and without risks to health and theprovision and maintenance of means of access to and egress from it that are safe andwithout such risks;

(E) the provision and maintenance of a working environment for his employees that is, so faras is reasonably practicable, safe, without risks to health, and adequate as regards facilitiesand arrangements for their welfare at work.

General duty of persons in control of certain premises in relation to harmfulemissions into atmosphere.

5. (1) It shall be the duty of the person having control of any premises of a class prescribedfor the purposes of section 1(1)(D) to us the best practicable means for preventing theemission into the atmosphere from the premises of noxious or offensive substances and forrendering harmless and inoffensive such substances as may be so emitted.


29/129


Page 28

General duties of employees at work.

7. It shall be the duty of every employee while at work

(A) to take reasonable care for the health and safety of himself and of other persons whomay be affected by his acts or omissions at work; and

(B) as regards any duty or requirement imposed on his employer or any other person by orunder any of the relevant statutory provisions, to co-operate with him so far as is necessaryto enable that duty or requirement to be performed or complied with.

2.7.4 Other Important Health & Safety LegislationThe most significant piece of health and safety legislation which has originated in Brussels(to date), is the Management of Health & Safety at Work Regulations (MHSWR). MHSWR(together with the Approved Code of Practice), requires all employers and self-employedpersons to carry out risk assessments and implement adequate arrangements for thefollowing health and safety related issues:

Planning (i.e. adopting a systematic approach for the identification of priorities and theobjectives)

Organising (i.e. putting an effective structure in place to ensure that there is progressiveimprovement)

Controlling (i.e. making sure decisions are implemented quickly and effectively)

Monitoring and reviewing.

MHSWR and the five associated Regulations are often referred to as the European SixPack :

Management of Health & Safety at Work Regulations

The Workplace (Health, Safety & Welfare) Regulations

Use of Work Equipment Regulations

Personal Protective Equipment at Work Regulations

Manual Handling Regulations

Health & Safety (Display Screen Equipment) Regulations

Health & Safety (First Aid) Regulations.

RIDDOR

The Reporting of Injuries, Diseases and Dangerous Occurrences Regulations , referred to asRIDDOR , requires employers to report specific injuries to people at work. It simplifies theneed to report accidents to members of the public in any workplace and lists reportablediseases and dangerous occurrences.


30/129


Page 29

Section Two Planning the Strategy

1. Success criteria should be developed as part of:

a) Detailed planning b) The Work Breakdown Structure

c) The Business Case

d) Risk Management

2. A Project Management Plan:

a) Is not owned by the project team

b) Excludes procurement

c) Includes the What , Why , How , When , How Much , and Who of the project d) Is developed by the Sponsor

3. Which of the following is a strategy for mitigating risk?

a) Reduction

b) Smoothing

c) Assessment

d) Identification

4. Which of the following is a correct and complete definition of project risk?

a) An event which causes uncertainty

b) An uncertainty which if it occurs would affect project objectives

c) A threat to human health and safety

d) The impact of changes in requirement

5. What does Project Quality Management consist of?

a) Quality Planning, Project Assurance, Quality Control, Continuous Improvement b) Quality Assurance, Quality Audit, Quality Control, Continuous Improvement

c) Quality Planning, Quality Assurance, Quality Control, Continuous Improvement

d) Quality Assurance, Quality Planning, Quality Audit, Continuous Improvement


31/129


Page 30

6. Which 3 things do Project Success Criteria normally revolve around?

a)

b)

c)

7 Who owns the Project Management Plan?

a)

8. What are the elements of the Risk Management Process?

a)

b)

c)

d)

e)

f)

9. What is a broad definition of Quality in a project?

a)

10. In which Phase of the project is the Project Management Plan created?

a)


32/129


Page 31

3 Executing the Strategy

3.1 Scope Management - BoK Topic 3.1

3.1.1 BoK Definition of Scope ManagementScope management is the process by which the deliverables and work to produce them areidentified and defined. Identification and definition of the scope must describe what theproject will include and what it will not include, i.e. what is in and out of scope.

3.1.2 ProcessWhen a project is started there is always a significant amount of planning work to becompleted. This will involve establishing what is required, the deliverables, the phases ofwork, what activities and tasks are required, how much will it cost and who is going to do it.The use of breakdown structures will assist the project manger to bring order to this.

We will consider 4 breakdown structures and the resulting responsibility assignment matrix.

With all breakdown structures there is no absolute way of constructing them, for exampleyou may have a product specification of requirements which is split into sub prod ucts foreach eleme nt, e.g. module 1, module 2. Alternatively, each module may have a subproduct specification of requirements.

3.1.3 Product Breakdown StructureThe Product Breakdown Structure consists of a hierarchy of Products (also known asdeliverables or outputs). The PBS is used to break the ultimate product of the project intosmaller and smaller components, usually about three levels, after which one often starts tointroduce verbs into the description and has therefore left products and moved into activities.

For example consider a project to produce a landscaped garden. The PBS may look like:

Figure 3.1.1 Product Breakdown Structure

Note each of the products is systematically referenced with a unique alpha-numericreference e.g. Shed would be referenced B.1.1. The numbering system will remain constantthroughout the project and should be used constantly across all the tools, e.g. networks,Gantt charts, schedule.

The key benefits of using Product Breakdown Structures are:

Landscaped Garden

Specification(A1)

SiteDescription

(A2)

Design(A3)

Shed(B1.1)

Patio(B1.2)

BBQ(B1.3)

ClearedSite

(B2.1)

MarkedOut

Layout(B2.2)

Lawn(C1.1)

Flower Beds

(C1.2)

PowerTools(C2.1)

HandTools(C2.2)

DocumentsGroup (A)

BuildingsGroup (B)

GardenGroup (C)

GardenGroup (B1)

SiteGroup (B2)

HorticultureGroup (C1)

ToolsGroup (C2)

Vegetable Area(C1.3)

Pond(B1.4)

Landscaped Garden

Specification(A1)

SiteDescription

(A2)

Design(A3)

Shed(B1.1)

Patio(B1.2)

BBQ(B1.3)

ClearedSite

(B2.1)

MarkedOut

Layout(B2.2)

Lawn(C1.1)

Flower Beds

(C1.2)

PowerTools(C2.1)

HandTools(C2.2)

DocumentsGroup (A)

BuildingsGroup (B)

GardenGroup (C)

GardenGroup (B1)

SiteGroup (B2)

HorticultureGroup (C1)

ToolsGroup (C2)

Vegetable Area(C1.3)

Pond(B1.4)


33/129


Page 32

Defines the scope of the project

Focuses the team on what is going to be produced

Forces the team to think of the product content, e.g. if it is a database, what type, howmany records, what is the record format etc.

What quality criteria will be applied to the product, how will it be reviewed and what skillsare required to undertake the review. This is the key, and most important element of thePBS.

Having produced a PBS it is possible to produce a Product Flow Diagram (PFD) that showsthe order in which the products are created.

To build the products will require the team members to undertake a number of activities andtasks. This results in a Work Breakdown Structure.

3.1.4 Work Breakdown StructureConstructed in exactly the same manner as the PBS the WBS will almost exclusively use

verbs in its descriptions. As an example take the landscaped garden and break oneelement down further, in this case the site description:

Figure 3.1.2 Work Breakdown Structure

Whilst the top level remains as a product the subsidiary levels are now activities anddescribe what needs to be done to produce, for example the site description got to site,measure the site, draw a plan, write a visit report and write the site description.

Each element of the WBS can be numbered and this numbering will remain constantthroughout the project.

The key benefits of the WBS are:

Again helps to define the scope of the project

Forces the team to think through the production process

Forms the basis for precedence networks and estimating

Defines the work content

The WBS is fundamental to the production of a suitable schedule

Forms the basis of Earned Value calculations by defining the base data for effort,materials and other resources.

Once a WBS has been completed it will become necessary to assign the work to the teamsor personnel responsible for undertaking the work. The first step is to produce anorganisation breakdown structure.

SiteDescription

(A2)

Go to site(A2.1)

Measure site(A2.2)

Draw SitePlan (A2.3)

Write Sitevisit report

(A2.4)

Write SiteDescription

(A2.5)

SiteDescription

(A2)

Go to site(A2.1)

Measure site(A2.2)

Draw SitePlan (A2.3)

Write Sitevisit report

(A2.4)

Write SiteDescription

(A2.5)


34/129


Page 33

3.1.5 Organisation Breakdown Structure A typical organisation breakdown structure is shown below. It will be different for eachproject.

Figure 3.1.3 Organisation Breakdown Structure

3.1.6 Cost Breakdown StructureCost breakdown is a very straightforward process which can become extremely complex inoperation. The amount of detail required within a CBS will depend on the nature of theproject and the accounting processes within your organisation. For example, do you recordtime? If so, are costs transferred between departments? Will the work be completed by acontractor? If so what sort of contract and payment method is being used, e.g. time andmaterials, fixed price, bill of quantities, monthly payment?

Basically however, the process is:

Allocate costs to each activity (from WBS/PBS) taking into account;

Labour

Materials, Plant and equipment

Subcontract

Management

Overhead and administration

Fees and taxation

Inflation

Other contingency

Allocate to a Cost Centre

The resulting Cost Breakdown Structure output is often recorded in a sophisticatedaccounting system such as SAP, which will produce cost reports for management action.

Having produced these structures it is necessary to relate one to the other, in particular theWBS (or PBS) to the OBS to produce a:

ProjectManager

Team Manager Design

Team Manager Procurement

Team Manager Testing

Team Manager Implementation

SeniorDesigner

TraineeDesigner

ChiefTester

AssistantTester

SupportEngineer 1

SupportEngineer 2

Buyer 1

Buyer 2

ContractsManager

WarehouseManager

ProjectManager

Team Manager Design

Team Manager Procurement

Team Manager Testing

Team Manager Implementation

SeniorDesigner

TraineeDesigner

ChiefTester

AssistantTester

SupportEngineer 1

SupportEngineer 2

Buyer 1

Buyer 2

ContractsManager

WarehouseManager


35/129


Page 34

3.1.7 Responsibility Assignment MatrixThis is a cross reference between tasks on the WBS (or products on the PBS) and the staffon the OBS. There are two acronyms that may be used to document varying degrees ofinvolvement and responsibility; RACI or PARIS, or a combination of both to suit your needs:

RACI

Responsibility - This person, or group, will be doing the work

Accountability - This person (and only one) will be accountable for the work being done; i.e.the buck stops here!

Consultation (communication) - A person or group of people who communicate or consultwith the doers, e.g. the testers may contribute towards the work of the researchers

Information - A person or group who needs to be kept informed of progress throughout thetask.

PARIS

Performs - This person, or group will be doing the workApproves - This person or group, approves the final product

Reviews (or is notified) - The group or person reviewing the product as it is produced

Inputs (contributes to) - A person or group of people who communicate or consult with thedoers, e.g. the testers may contribute towards the work of the researchers

Supports - The person or group of people who provide help and assistance to theperformers or support the process.

An example matrix is shown below:

Figure 3.1.4 - Example of Responsibility Assignment Matrix using PARIS

3.1.8 Breakdown Structure RelationshipsBreakdown structures are related to each other. It can be argued that to produce a PBS orWBS will first need some form of team to be developed therefore some form of OBS isrequired to get the planning process started.

The next step is to produce a PBS and this in itself may well identify products that requirespecialise expertise incorporating into the team hence the OBS will be updated.

Once the PBS is completed a WBS will be produced to identify the tasks required to buildthe products. Again the OBS may well be enhanced as the full skills requirement of theproject is identified. As the WBS is produced the CBS can be started and then finalised

when the RAM is produced and the staff types and charges known.

Code Activity DescriptionTeam MgrDesign

SeniorDesigner

TraineeDesigner

Team MgrProcurement Buyer 1 Buyer 2

ContractsManager

A1.1 Design Module 1 R P I A1.2 Design Module 2 R P I A1.3 Design Integration Routine R P IB1.1 Select Suppliers I/R P SB1.2 Prepare Contract Documents P R AB1.3 Issue Tender PB1.5 Review Tender R P P S


36/129


Page 35

The refined OBS and the WBS are related to produce a RAM, which then enables a full CBSto be produced.

Figure 3.1.5 Relationship between Breakdown Structures

3.1.9 Work Package A work package is a generic term given to the information passed to a team member in orderthat s/he may complete a piece of work. This may be a simple instruction to complete asimple task and therefore be informal or at the other extreme may cover the issuing of acomplex contract for a large piece of work, in which case it will be formal and extensive.

It will contain a SOW, reporting requirements, time, cost and quality information and anyother information necessary for the completion of the work.

3.1.10 Scope Baseline

It is essential that the scope of the project is baselined. A baseline is a snapshot, position orsituation that is recorded. Once baselined an item cannot be changed unless formal changecontrol is established. In this case future changes must pass through change control, theeffect of change must be analysed and, if the change is authorised, then the newly agreedscope will be baselined at the next version number. The original baseline remainsunchanged. This provides an audit trail throughout the project showing how and why thescope has altered since the project was initially planned..

PBS

OBS

CBS

RAM

WBS

PBS

OBS

CBS

RAM

WBS

PBS

OBS

CBS

RAM

WBS

PBS

OBS

CBS

RAM

WBS


37/129


Page 36

3.2 Scheduling - BoK Topic 3.2

3.2.1 BoK Definition of SchedulingScheduling is the process used to determine the overall project duration and when activitiesand events are planned to happen. This includes identification of activities and their logicaldependencies, and estimation of activity durations, taking into account requirements andavailability of resources.

3.2.2 The Scheduling processUnderpinning the process is the establishment of the product requirements in the PBS,followed by the activities and tasks established with a WBS. The identification ofdependencies between the activities leads to a network diagram.

The effort involved in the activities and their forecast duration need to be estimated.Included within estimating is risk analysis, although this could, and should, be started assoon as possible in the process.

Applying the duration estimates to the network diagram leads to a critical path, which whenresourced will result in a project schedule.

However, this is not a simple stairca se but rather a keep fit exercise as to produce anacceptable schedule it is often necessary to run up and down the stairway several times!New products and tasks are often identified further up the stairway as the project isunderstood in more detail and this necessitates going back down to add them into theappropriate structure. Risk management activities can also affect the number of productsand tasks.

3.2.3 Networks: Activity on NodeIt is best practice to understand the project environment, content and scope through the

WBS. The relationships between activities is normally represented by networks. We willuse Activity on Node (AoN) as this is most commonly used.

The Node shown below describes attributes in the positions shown as defined by the BritishStandards. (Software Tools allow us to modify the positions and add and/or subtract otherattributes if we wish).

Figure 3.2.2 Node Definition

The table below shows seven activities with durations and dependencies after the Project

Management Team have analysed the project.

Earliest StartTime

DurationEarliest

Finish Time

Latest StartTime

Total FloatLatest Finish

Time

Actiity Number, Activity Description,Resources Required


38/129


Page 37

Activity Duration Dependency A 1 -B 2 AC 4 AD 3 B,C

E 8 AF 9 EG 7 D,F

Basic Rules:

FORWARD PASS (Top Row)

Add Duration to Earliest Start to determine Earliest Finish

If more than one predecessor: FORWARD PASS HIGH .

BACKWARD PASS (Bottom Row)

Take the Earliest Finish Time to be the Project End Date and drop it into the Latest FinishTime of the Node.

Subtract Duration from Latest Finish to determine Latest Start

If more than one successor: BACKWARD PASS LOW .

Figure 3.2.3 Example Network

Float (or Slack) represents how much flexibility the Project Manager has in executingnetwork tasks. Float ALWAYS pertains to an Activity.

TOTAL FLOAT is the amount of delay an activity can absorb before it delays the END OFTHE PROJECT . Normal practice, used in this course, places the Total Float in the centrebox along the bottom row of a node.

FREE FLOAT is the amount of delay an activity can absorb before it delays the START ofthe NEXT ACTIVITY . Free Float has no standard position in the node BUT, as it representsa factor between adjacent nodes we will place it there. Again in the example above ActivityB shows that it can be delayed by up to 2 units of time before it affects its successor activity.Similarly, Activity D can be delayed by 10 units of time before it affects Activity G. (NB in thiscase Free Float and Total Float for Activity D are the same).

1 2 3B

13 12 15

1 4 5 5 3 8C D

11 10 15 15 10 18

0 1 1 1 8 9 9 9 18 18 7 25A E F G

0 0 1 1 0 9 9 0 18 18 0 25

FF 10

FF 2


39/129


Page 38

The CRITICAL PATH is the path joining nodes of ZERO TOTAL FLOAT . In the exampleabove it is A-E-F-G.

3.2.4 Gantt Charts: SchedulingIf we ignore potential resource conflicts then we can move swiftly from the Network to the

Schedule. Clearly the CRITICAL PATH is immovable. We may choose to force non-criticalactivities always to default to the earliest dates in the plans.

Figure 3.2.7 Gantt Chart

3.2.5 Software ToolsThere are many project management software tools. They allow data to be input againstprojects by tasks. Assuming that sufficient information is available the user can see distinct(and tailorable) views, including:

Gantt View

Network

Calendar

Resource (Person by Person usage, database of personnel, rates, groupings etc.)

Usage (Total resource commitment by day).

3.2.6 Advantages and Disadvantages of Software Tools Advantages

Allow for consistent input techniques and p rovide tailorable standard outputs

Can accommodate large-scale projects and multiple (linked) projects

Facilitate what if? scenarios

Allow filtering for multiple viewpoints and purposes (reports)

Allow maintenance of an agreed baseline

Provide simple configuration management of plans

Can separate plan from actual

Can accommodate

input tables

Gantt charts

resource tables

networks.

Day 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Activity ABCDEFG


40/129


Page 39

Disadvantages

There is no single panacea. Some are designed to help with simple and single projects.Others with multiple complex projects. The former often have a friendly interface whilstthe latter are specialist tools for the experienced user only

We can be seduced by technology GIGO or garbage in: garbage out.

Appropriateness. Simple projects do not NEED complex tools.

Customer and supplier may have differing toolsets

The PMP must address communications between interested parties

We must ensure common agreement on data definitions.

3.2.7 Milestone Planning A milestone is merely an event (normally of management significance) which tells the Project

Management Team that there should be significant and measurable progress. Milestonesare often associated with decision points. Figure 3.2.8 shows a milestone chart.

Figure 3.2.8 Milestone Chart

A milestone chart is formed by plotting plan time across the top of the chart and real timedown the side as monitoring periods. In the example above the monitoring periods occurevery 4 weeks. By plotting the monitoring period against plan time the completion line iscreated. This represents time in the project. The milestones are scheduled at the top of thechart and each monitoring period the date for the milestone is plotted. The points in thefuture are shown with a different symbol. The resulting charts are extremely useful for senior

management as they provide, at a glance, a view of how well the project is progressing.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

00 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80

18

19

20

Completion Line

MonitoringPeriod

Forecast/Actual W eeks

Forecast Datefor MilestoneCompletion

Date MilestoneForecasted thisperiod/ActualDate

Key

OriginalMilestoneForecast Date


41/129


Page 40

The charts have four basic shapes as shown and discussed below.

Figure 3.2.9 Milestone Chart Interpretation 1

In this project something clearly happened between monitoring periods 3 and 4 to cause a 6 -week delay in the project perhaps a change was authorised? In any event the situationcame under control again and no further slippage occurred.


This chart has been prepared at monitoring period 5 (note the different shapes of theforecast dates). The chart shows significant slippage on the middle two milestones and yetthe end date remains unchanged. As all milestones ultimately link to the final milestone thisshould be challenged as it would seem unlikely that any project could contain that amount ofdelay and yet still complete on time.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

00 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80

18

19

20

Completion Line

MonitoringPeriod

Forecast/Actual Weeks

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

00 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80

18

19

20

Completion Line

MonitoringPeriod

Forecast/Actual Weeks


42/129


Page 41


This is a classic case of just too late. The milestone has been forecasted as on time until just before it completes when it slips a month. This is often due to poor reporting from thetea ms where the team has reported what the PM wants to hear rather than the actual stateof progress. Action should be taken to encourage the teams to report accurately andhonestly throughout the project.


This project is out of control!

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

0

0 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80

18

19

20

Completion Line

MonitoringPeriod

Forecast /Act ual Weeks

1

2

3

4

5

6