Sei sulla pagina 1di 45

PMA Reference Book

P roject M anagement A pproach


(PMA)

R EFERENCE B OOK
Version 2014
Holcim Technology Ltd
INN - Knowledge Management
Holderbank, Switzerland

Page 1 of 45
PMA Reference Book

TABLE OF CONTENTS

1 Introduction 3

2 The Holcim Project Management Approach (PMA) 5


2.1 Vision, Mission & Benefits 5
2.2 The 5 PMA Phases 5
2.2.1 Phase I 6
2.2.2 Phase II 6
2.2.3 Phase III 7
2.2.4 Phase IV 7
2.2.5 Phase V 7
2.3 Dependencies between projects 8
2.4 Level of detail when using PMA 8
2.5 Overview all steps of the Five Phases 10

3 Details of all Steps within the 5 Phases 11


3.1 Steps within Project Definition 12
3.1.1 Assessment of Initial Situation 12
3.1.2 Stakeholder analysis 13
3.1.3 Search for Lessons Learned 14
3.1.4 Definition of product or service (deliverables) 15
3.1.5 Milestone schedule 16
3.1.6 Outline Project Organization 17
3.1.7 Estimation of Project Costs & Benefits 18
3.1.8 Risk Identification & Countermeasures 19
3.1.9 Agreement with the Client 20
3.2 Steps within Project Planning 21
3.2.1 Project Team Set-up 21
3.2.2 Project Schedule 22
3.2.3 Communication Plan 23
3.2.4 Project Budget 24
3.2.5 Project Kick-off 25
3.3 Steps within Project Realization 26
3.3.1 Activity List 26
3.3.2 Project Review (within Team) 27
3.3.3 Capture of Knowledge 28
3.3.4 Project Status Report 29
3.3.5 Client / Steering Group Review 30
3.4 Steps within Project Completion 31
3.4.1 Hand-over 31
3.4.2 Final Report 32
3.4.3 Closing Meeting 33
3.5 Steps within Project Evaluation and Transfer 34
3.5.1 After Action Review (AAR) 34
3.5.2 Learning Summary 35
3.5.3 Knowledge Transfer 36

4 Glossary 37

5 Appendix A:
How the 5 Phases and the corresponding steps are interrelated 41

6 Appendix B: Project Risk Management 42

7 Bibliography 45

Page 2 of 45
PMA Reference Book

1 Introduction

Purpose
This Book provides a detailed insight of the Holcim Project Management Approach (PMA).
It serves as a reference in the application of PMA.

Target Audience
This Reference Book has been written to support Holcim employees regularly involved in pro-
jects (especially project managers) who have been introduced to the Holcim PMA through at
least one training session.

Applicability
The PMA defines the generic methodology to be applied in all projects managed by Holcim
employees. The PMA is defined by 5 phases with 25 underlying steps. Whatever size and
contents a project may have, it will always go through the 5 phases. Only the level of detail
when using the PMA differs as the complexity of projects varies (see paragraph 2.4)

Structure
This Reference Book:
• explains the 5 phases defined within the PMA (see chapter 2)
• provides a detailed explanation of all 25 steps within the 5 phases (see chapter 3)
• explains the objective and benefits of each step
• helps with the application through practical procedures, review questions and tips for use
• includes a glossary to explain terms used within the PMA (see chapter 4)

What is a Project?
A project is a temporary endeavor undertaken to produce a unique product, service or result:
• With defined start and end dates
• Is always different from other projects even if some common elements are repeated
• Is unique, there are always uncertainties about products, costs, time, etc.
• Since a project is typically new to a team, it needs more planning than routine work
• Typically involves several people across different businesses and levels

How are projects started?


Projects are triggered by a business need or issue detected by the Project Client, e.g. in-
crease production, improve profit margins, improve employee morale, etc. Usually there are a
number of alternatives to tackle the business need. In order identify and select the best alter-
native to tackle the business issue, Project clients and Project Managers could apply Solve!
Holcim systematic problem solving tool, to quantify the issue, identify the root causes and
select the best solution/alternative to implement, in order to achieve the expected business
objectives.

How are projects linked to the business cycle?

Page 3 of 45
PMA Reference Book

Projects are the key mechanism to improve a business. When companies need to achieve
specific goals, they typically start projects. All business plans of Holcim Group Companies
display the key projects to be implemented to achieve the expected business goals. After be-
ing identified, a project is developed and implemented so that at its end, the delivered product
or service allows the client achieve the business goals.

Who is usually involved in a project?


Projects always have a number of people involved including:
• Project Client: the person who requests the project to be executed, approves what is to
be implemented, provides resources (funds in particular) to execute the project, receives
the project upon completion and uses it to achieve the expected business goal of the pro-
ject
• Project Steering Group: the group of people who supports the client to guide the project
throughout its life.
• Project Manager: the person who organizes the work needed to deliver the expected out-
come of the project. The project manager’s responsibilities include leading the team, en-
gaging stakeholders and managing risks to ensure successful completion of the project.
• Project team members: people who work to deliver the expected outcome of the project.
Team members need to manage their own operational work as well as the project work,
interacting with other team members to ensure successful completion of the project.
• Stakeholders: people not regularly involved in the project, whose interests may be affect-
ed (positively or negatively) by the project.

What is project portfolio management?


Project portfolio is a collection of projects that are grouped together to facilitate effective man-
agement of work to meet strategic business goals. Projects within a portfolio may or may not
be interdependent of each other.

Project portfolio management is the process of identifying, prioritizing, authorizing, managing


and controlling projects to achieve specific strategic business objectives. Resources and cash
flows are allocated among projects within a portfolio.

The Link between the PMA and other Holcim Guidelines


Within the Group, various guidelines have been established to deal with specific projects with-
in a given environment. Since the Holcim Project Management Approach provides a generic
basis for all types of projects, other guidelines can be mapped onto this approach.

Over the last few years Holcim Group Support Ltd. has developed specific extensions to PMA
for Capex projects. In the cement business, the approach is called ProMap. More details can
be found in the Holcim Portal under “Business Tools – CAPEX / ProMap”. In the Aggregates
and Construction Materials business, the approach is called ACMPro, and it is divided into
AggPro (for Aggregates projects), RMXPro (for RMX projects) and AspPro (for Asphalt pro-
jects). These can be found in the Portal under “Group – Functional Areas – Aggregates and
Construction Materials – Investment Support / ACMPro”.

The Link between the PMA and other Project Management


standards
There are several associations for Project Management in the world, such as the Project
Management Institute (PMI), Association for Project Management (APM), IPMA, etc. All those
bodies collect and publish best practices in Project Management. The Holcim PMA is fully
aligned and consistent with those worldwide best practices.

Page 4 of 45
PMA Reference Book

2 The Holcim Project Management Approach (PMA)

The Holcim Project Management Approach holds a VISION aiming at . . .

. . GETTING PEOPLE TO WORK SYSTEMATICALLY . . .


2.1 Vision, Mis- . . TO USE AVAILABLE KNOWLEDGE REPEATEDLY . . .
sion & Ben- . . AND TO IMPROVE WITH EVERY PROJECT
efits

The M I SSI O N of this Reference Book is to support Holcim employees in the under-
standing and constant application of the PMA. The objective of the PMA lies within the
creation of a common language that provides the Group with a logical and practical ap-
proach in the area of project management. Explicit integration of the search for
knowledge already available at the start of a project and the transfer of gained
knowledge at the end contribute to the objectives of becoming a faster learning organiza-
tion.

Consistent use of the PMA results in a number of substantial BENE FI TS for the
current project as well as for future ones, e.g.:
• All relevant stakeholders are explicitly involved
• Project deliverables are precisely defined and accepted by the Client
• Relevant risks/opportunities and countermeasures are considered
• Project progress is reviewed regularly to ensure that schedule, budget and delivera-
bles meet the objectives
• The approach focuses on teamwork and cross-functional communication
• Project communication becomes easier throughout the Holcim Group
• Transfer of lessons learned from one project to other projects

2.2 The 5 PMA


Phases
The 5 phases as described below are the basis of the approach.

Phase I Phase II Phase III Phase IV Phase V


Project Project Project Project Project
Definition Planning Realization Completion Evaluation &
Transfer

Within each individual phase, a number of steps are defined. These steps serve as a
systematic easy-to-use checklist to guide the project team through the project life cycle.

Page 5 of 45
PMA Reference Book

2.2.1 Phase I Project Definition

Objective

The objective of this phase is to build a relationship with the Client and to really under-
stand his objectives. Another objective is to gather sufficient information to ensure that
the project is properly defined and that it is realizable and acceptable for the project
team.
Steps
• Assessment of initial situation for details see page 12
• Stakeholder analysis for details see page 12
• Search for lessons learned for details see page 14
• Definition of product or service (deliverables) for details see page 15
• Milestone schedule for details see page 16
• Outline project organization for details see page 17
• Estimation of project costs & benefits for details see page 18
• Risk identification & countermeasures for details see page 19
• Agreement with the Client for details see page 20

During this phase it is important to be explicitly clear to the Client and the project team
not only on what will be within the definition of the project, but also on what will not be
realized in this project. In order to offer the best possible proposition one will have to
address the assumptions made by the Client and by the project team.

There can be several meetings on the project definition (depending on the project size) in
order to agree and share a common understanding on all the necessary details. The first
meeting is between the Client and project manager (preferably with a PMA trainer) to
have an initial discussion about the initial situation, project deliverables, team composi-
tion and time constraints. The project manager initiates this meeting.

2.2.2 Phase II Project Planning


Objective

The objective of project planning is to detail the project as outlined during the definition
phase in terms of the tasks that are to be planned and costs that are involved. Further-
more, a communication plan has to be established. The purpose of all these steps is to
give as complete a description as possible on the way of working during the other phas-
es of the project.

Steps
• Project team set-up for details see page 21
• Project Schedule for details see page 22
• Communication plan for details see page 23
• Project Budget for details see page 24
• Project kick-off for details see page 25

Since the project team must be able to start delivering the defined product or service at
the end of this phase, everybody has to fully understand and be committed to the project.
One has to fully understand how communication and reviews will be handled, where
documents will be stored, what tasks are to be fulfilled to reach the milestones, and how
the various tasks interact. If required, the project team will have to be trained before en-
gaging on the project.

Page 6 of 45
PMA Reference Book

2.2.3 Phase III Project Realization


e Objective
The purpose of Phase III is to ensure delivery of the defined product or service in accord-
ance with the project definition. Therefore, a certain number of project team reviews and
reviews with the Client are needed to properly control costs, results and time.

Steps
• Activity list for details see page 26
• Project review (within team) for details see page 27
• Capture of knowledge for details see page 28
• Project Status Report for details see page 29
• Client/Steering Group review for details see page 30

To deliver the product or service, issues need to be discussed openly within the team and
the Client/Steering Group during review meetings. Changes to the project definition or
project planning have to be made in accordance with the mechanism for handling chang-
es which is part of the project definition. In addition, it is important to capture knowledge
during the realization of the project to generate the necessary input for phase V.

2.2.4 Phase IV Project Completion


Objective
The objective of this phase is to ensure that the Client accepts the product or service and
that the ownership is properly transferred to the Client so that the project team can be
discharged of its responsibility to deliver.
Steps
• Hand-over for details see page 31
• Final report for details see page 32
• Closing meeting for details see page 33

This phase focuses on handing over the product or service that has been defined during
Phase I (Project Definition). It must be absolutely clear that after the project completion
phase, the Client (and his/her organization) is fully responsible for sustaining and main-
taining the product or service that has been delivered by the project team. Any outstand-
ing actions aside from the activities within Phase V will have to be explicitly documented
and agreed upon during handover (Step 1).

2.2.5 Phase V Evaluation and Transfer


Objective
The objective of the last phase is to evaluate the way of working with the Client and the
project team during the project. It has to be ensured that all lessons learned are summa-
rized. Finally, actions to transfer lessons learned will have to be defined.
Steps
• After Action Review (AAR) for details see page 34
• Learning summary for details see page 35
• Knowledge transfer for details see page 36

Learning can be derived from various aspects such as the contents of the project (e.g.
technical aspects) or the process one has gone through (way of working). Both the output
of knowledge gained during the realization as well as the output of “After Action Review”
will be integrated in the learning summary.

Page 7 of 45
PMA Reference Book

2.3 Dependenci Frequently - especially in larger projects - specific complex tasks are handled as sub-
es projects. Such a sub-project will follow its own 5-phase approach, having its own Client,
between project team, etc. Therefore, a situation may arise where several related projects apply the
projects PMA in parallel.

Overall
OverallProject
Project
Phase I Phase II Phase III Phase IV Phase V
Phase I Phase II Phase III Phase IV Phase V
Project Project Project Project Project
Project Project Pr oject Project Project
Evaluation
Definition Planning Realization Completion
Definition Planning Realization Completion & Evaluation
Transfer
& Transfer

Phase I Phase II Phase III Phase IV Phase V


Phase I Phas e II Phase III Phase IV Phas e V
Project Project Project Project Project
Pr ojec t
Definition Proje ct
Planning Pr ojec t
Realization Proje ct
Completion Proje ct
Evaluation
De finition Pla nning Re alization Comple tion Evaluation
& Transfer
& Tr ansfe r

Sub-
Sub-Project
Sub-Project

The project manager and the team responsible for the sub-project will apply the PMA in
their sub-project. The responsibility to apply the PMA to the overall project will remain with
the project manager responsible for the overall project.

It is important that sub-projects are aligned with the overall project in order to achieve the
overall objectives.
2.4 Level of Following the principles of all PMA phases and all steps rigidly and consistently is key to
detail when get the benefits from the approach. However, since no single project is fully identical to
using PMA another, project managers have to check to what level of detail the steps of the 5 phases
need to be applied. Therefore the expression “rigid principles, flexible application” is creat-
ed. This expression means that while it is mandatory to follow all the phases and steps for
each project, compliance e.g. to the documentation and frequency of review meetings may
vary from one project to another. The more complex a project is, the more detail should be
used in the application of the PMA.

To help project managers in determining the level of detail in the application of the PMA to
1
their specific project, three project categories are outlined:
A. Project of high complexity: the answer to 4 to 6 questions can be “yes”
B. Project of medium complexity: the answer to 2 to 3 questions can be “yes”
C. Project of low complexity: the answer to 0 to 2 questions can be “yes”

1. Are project costs in excess of 50,000 USD? 5. Do we have little or no experience in creating
2. Does project duration exceed 3 months? the desired product or service?

3. Are there more than three people involved in the 6. Would any project failure have a strong negative
project team (including the project manager)? impact on the project team /
organization?
4. Are the Client’s expectations towards the project
unclear?

1
It is not possible to make the categorization of the level of detail in a fully precise way hence the suggestions
should be combined use, according to the rules of common sense.
Page 8 of 45
PMA Reference Book

For each category, the level of detail when applying the PMA is indicated in the table on the next page. The
table contains all 25 steps and an indication of the level of detail suggested for the three project categories.

Phase Step A B C
Phase I: Assessment of Initial Situation.   

Project Definition Stakeholder analysis   

Search for lessons learned   

Definition of product or service (deliverables)   

Milestone schedule   

Outline project organization   

Estimation of project costs   

Risk identification & countermeasures   

Agreement with the Client   


Phase II: Project team set-up   

Project Planning Project Schedule   

Communication plan   

Project Budget   

Project kick-off   
Phase III: Activity list   

Project Realization Project review (within the team)   

Capture of knowledge   

Project Status Report   


(exception report only)
Client/Steering Group review   
(exception report only)
Phase IV: Hand-over   

Project Completion Final report   

Closing meeting   
Phase V: After Action Review (AAR)   

Project Evaluation Learning summary   


& Transfer Knowledge transfer   

 Full compliance Project documentation must be available to demonstrate that all aspects of
the steps are taken into consideration
 Partial compliance Project documentation must be available to demonstrate that relevant as-
pects of the step are taken into consideration
 Limited compliance No project documentation is required; one only needs to be aware of the
step
PMA Reference Book

2.5 Overview all steps of the Five Phases

The graph below gives an overview of all steps. In the appendix a graph is included showing how all steps are connected with one another.

Phase I Phase II Phase III Phase IV Phase V


Project Project Project Project Project
Definition Planning Realization Completion Evaluation
& Transfer

1. Assessment of initial situ- 1. Project team set-up 1. Activity list 1. Hand-over 1. After Action Review
ation 2. Project Schedule 2. Project review 2. Final report (AAR)
2. Stakeholder analysis 3. Communication plan (within team) 3. Closing meeting 2. Learning summary
3. Search for lessons 4. Project Budget 3. Capture of knowledge 3. Knowledge transfer
learned 4. Project status report
5. Project kick-off
4. Definition of product or 5. Client/Steering Group
service (deliverables) review
5. Milestone schedule
6. Outline project organiza-
tion
7. Estimation of project
costs & benefits
8. Risk identification & eval-
uation
9. Agreement with the Client
PMA Reference Book

3 Details of all Steps within the 5 Phases

Phase I Phase II Phase III Phase IV Phase V


Project Project Project Project Project
Definition Planning Realization Completion Evaluation &
Transfer

In this chapter, the project management approach as


presented in the previous chapter will be covered in
more detail, the steps from each phase will be described
using the following structure:
• Objective and benefits
• Procedure for use
• Review questions
• Tips for use
• Cross reference to other steps of the PMA
PMA Reference Book

3.1 Steps within Project Definition

3.1.1 Assessment of Initial Situation

OBJECTIVE The objective of this step is to arrive at a common understanding of the Project Definition by
AND giving a structured explanation of the Client’s initial situation. This will help in getting a clear
BENEFITS picture of the Client’s reasons for starting the project. The assessment of the initial situation
ensures that the Client’s real motives for initiating the project are made fully transparent and
understood by the project team in order to proceed with the project definition.

1. Organize a meeting or workshop with the Client to start project definition

2. Find out the root causes (current or past issues, business risks or opportunities) of the Cli-
PROCEDURE ent’s decision to initiate the project
FOR USE
3. Together with the Client, define SMART business objectives that are to be achieved through
the project (link the objectives clearly to the overall business objectives)

4. Agree on the mission assigned to the project team to meet the business objectives (bounda-
ry/scope of the project). A mission is a statement of what the project team is going to do to
achieve the defined objectives.

5. Capture, review and agree on the outcome with the Client and document in the templates.

• Has the project team discussed the root causes, business objectives and mission together
with the Client?
REVIEW
• Are root causes based on facts resulting from previous analysis?
QUESTIONS
• Do the Client and project team have a clear and common understanding of the overall busi-
ness objectives of the project?
• Do the business objectives of the project contribute to reach the overall company objec-
tives?
• Does the mission (scope statement) clearly describe the assignment the project team will
carry out throughout the project life cycle?

TIPS FOR USE


1 Before meeting the team to start the project, the Client and Project Manager should get togeth-
er to prepare the basic element of the project definition (see project charter template, available in
the PMA section of the Holcim Portal)
2 The assessment of initial situation will only bring the full benefits if it has been defined together
Cross-reference
The assessment of the
with the Client. Don’t make assumptions since this might set a false direction to the project.
initial situation provides 3 Identifying the root causes of the project is a pre-requisite to start searching for solutions.
input to the definition of Solve!, Holcim systematic problem-solving process, can be used to identify root causes of the pro-
the product or service ject, and select the most effective solutions (deliverables, 3.1.4, page 15)
(3.1.4, page 15)
4 Business risks are possible root causes since, if not addressed, they could materialize and im-
pact the business
5 Projects can originate because of market demand, organizational need, customer requests,
technological advance, legal requirements, ecological requirements, social needs, etc.
6 Making objectives SMART (Specific, Measurable, Attainable, Relevant, situated in Time) will
help the Project team and Client to determine whether those have been achieved or not.
7 Involve experienced personnel in the assessment to address all assumptions made by the Cli-
ent and the project team
8 The business objectives of the project must be derived from the functional plan/business plan
of a Group Company. They should be linked to the functional or company’s KPI’s.
PMA Reference Book

3.1.2 Stakeholder analysis

OBJECTIVE The objectives of this step are to identify the project’s stakeholders, to understand their level of
AND interest and influence on the project, to find out their specific interests and to agree on
BENEFITS measures to be taken in order to incorporate those to the project. Stakeholder analysis helps
gain buy-in by directly involving the stakeholders in the project. It forces thinking around issues
that might impact the project (positively or negatively) and make these explicit with the Client. It
ensures the project manager; team members and the Client have a common view on the pro-
ject environment.

1. Identify the relevant stakeholders with the Client (also include third parties, e.g. environmen-
tal organizations, the government, etc.)

2. Categorize stakeholders depending on the level of influence they have on the project’s re-
PROCEDURE sults, and the level of interest they have on the project execution and/or deliverables (High,
FOR USE Medium, Low)

3. Contact important stakeholders to find out their interests (needs, requirements and expecta-
tions) in the project

4. Analyze information as a result of interviews workshops, surveys, prototypes, etc. with


stakeholders.
5. Review and agree with the Client on the implications of the stakeholder analysis to the pro-
ject. Define actions to be taken in order to address stakeholder interest and gain “buy-in”

• Have all stakeholders who have an interest in our project been identified?

REVIEW • Have important stakeholders been asked about their interest in the project?
QUESTIONS
• Have corresponding measures been taken to incorporate stakeholders' interests in the pro-
ject?

TIPS FOR USE


1 Do not make assumptions about stakeholder interests; make sure these come from them
2 Do not talk to stakeholders without the Client’s consent ,ensure confidentiality of information if
required
3 Ignoring stakeholders’ interests may lead to unsuccessful completion of a project (additional
costs, delays, partial achievement of objectives, etc
4 Create the document in such a way that both the Client as well as the project team will get an
understanding of various stakeholder interests.
5 Ensure that the interest of stakeholders with high or medium level of influence and interest are
addressed (e.g. incorporate the stakeholder’s requirements on the product & specifications, etc.)

Cross-reference
The stakeholder analysis provides input for:
- Definition of the product or service (3.1.4 page 15)
- Project schedule (3.2.2 page 22)
- Communication plan (3.2.3 page 23)
- Risk identification and countermeasures (3.1.8 page 19)
PMA Reference Book

3.1.3 Search for Lessons Learned

OBJECTIVE The objective of this step is to ensure that lessons learned from previous projects are taken into
AND account. Using these lessons learned to make decisions about the project content or the man-
BENEFITS agement of the project will help you improve your project in terms of time, cost and/or quality.

1. Identify the relevant stakeholders with the Client (also include third parties, e.g. environ-
mental organizations, the government, etc.)
PROCEDURE 2. Find out similar projects within and outside the company. Identify these projects, where
FOR USE these were carried out, and the names of project managers and/or Clients
3. Find out lessons learned from similar or any other projects applicable to this project

4. List all source of potential information (experienced people, literature, the Holcim Portal,
etc)., to search for similar experiences and/or lessons learned

5. Review and analyze the benefits of the lessons learned

6. Determine which experiences/lessons learned will be integrated into the project (and
how/where), as well as which ones you are not going to integrate into your project
7. Review the lessons learned throughout the project life cycle in order to use them at the ap-
propriate moment

• Have all stakeholders who have an interest in our project been identified?

REVIEW • Have both internal (e.g. databases, similar projects) and external sources been used in the
search for lessons learned?
QUESTIONS
• Have the owners (sources) of lessons learned been interviewed to gather more infor-
mation?
• Have decisions been made based on the lessons learned?

TIPS FOR USE


1 Search for useful experiences (good and bad), search for potential pitfalls in the project
2 Search for subject-related l (content of the project) and project management-related (sched-
ule, organization, etc) lessons learned.
3 The lessons learned should describe what needs to be done/ not done, and the reason why it
should be done or not done.
4 Use easy tools like the Internet and Holcim Portal for quick search
5 Keep the work practical and straightforward; in most cases there will not be enough time for a
very detailed study
6 If the team members don’t remember the content of lessons learned from previous projects,
use the pending list to create an action and a responsible to search for lessons learned.
7 Contact subject matter experts (SMEs) within Group Companies and HGRS to identify similar
projects.

Cross-reference
The search for lessons learned provides input
to all other aspects of the project definition, as
well as the other phases of the project. It is not
a one-time event; it should be a continuous
activity throughout the project life cycle
PMA Reference Book

3.1.4 Definition of product or service (deliverables)

OBJECTIVE The objective of this step is to agree on the product or service to be delivered by the project
AND team, in order to achieve the expected business objectives. Creating a “SMART” product (Spe-
BENEFITS cific, Measurable, Attainable, Relevant, situated in Time) makes the project easier to control at
a later stage. Finally, the criteria to measure the overall project success should be defined. A
detailed, complete list of deliverables and specifications is crucial for successful project com-
pletion

1. Together with the Project Client and Team, recall the project mission (defined in the as-
sessment of the initial situation)
PROCEDURE 2. Describe the product or service the project team needs to deliver to achieve this mission,
FOR USE making the defined product or service SMART
3. Describe “quality” specifications, time and / or cost constraints as these will have an impact
on the team’s capability to deliver the product or service
4. Identify, document and validate all assumptions made during the definition and planning
phases of the project as well as the special conditions required by the team
5. Present the definition of the product or service to important stakeholders (if Client agrees)
and incorporate their requirements
6. Agree on the final version of the definition of the product or services with the Client

7. Define and agree on the overall project success KPI

• Do the Client and project team have a clear and common understanding on the delivera-
bles of the project?
• Are the products or services defined in a SMART manner?
REVIEW • Do the defined deliverables contribute to the achievement of project objectives?
QUESTIONS • Have all assumptions and/or special conditions been understood and accepted by the Cli-
ent and project team?
• Do the Client and the project team agree on the criteria to measure project success (OPS)?

TIPS FOR USE


1 Solve!, Holcim systematic problem solving process, can help the team identify the most effective
products/services to address the project root causes.
2 The Work Breakdown Structure (WBS) technique can be used to decompose the project deliv-
erables into smaller, more manageable components.
3 It is very important to agree on what is part of the deliverables, and what is NOT part of the de-
liverables or what is excluded (in and out of scope)
4 Involve experienced personnel to verify all assumptions made by the Client and the team
5 Have a good understanding about how results will be measured. Overall Project Success (OPS)
is about project management success (completing the project within the expected cost, time and
quality) as well as project success (achieving business objectives).
6 Some Capex Projects in Holcim use an Investment Scorecard, which describes the business
objectives (KPIs or project drivers) of the project. This can be used or referred to in the OPS
7 When defining the product or service, include elements that will ensure sustainability of the
product/service after the project end date.
Cross-reference
The definition of the product or service provides input for:
- Outline of the project organization (3.1.6 page 17)
- Definition of the milestone schedule (3. 1.5 page 16)
- Estimation of the projects costs (3.1.7 page 18)
- Agreement with the Client (3.1.9 page 20)
- Hand-over of the project (3.4.1 page 31)
- Final report (3.4.2 page 32)
PMA Reference Book

3.1.5 Milestone schedule

OBJECTIVE The objective of this step is to define the milestones that need to be achieved in order to de-
AND BENEFITS liver the agreed product or service. Once the product or service is defined, the milestone
schedule shows how it will be accomplished. Identifying intermediate results helps in moni-
toring the project’s progress. SMART milestones (specific, measurable, attainable, relevant,
situated on time) make the project easier to control at any stage. The definition of the mile-
stones allows a first estimation of resources needed for the project. Defining the milestones
makes it possible to set up a more detailed project schedule and activity list in the succeed-
ing phases of the project.

1. Define milestones and make sure these are SMART.

2. Discuss and agree on the milestones with the Client.

PROCEDURE 3. Make the due dates of the milestones visible by putting them into a milestone schedule.
FOR USE 4. Discuss and agree on the time frames needed with the project team.

5. Evaluate the resources estimated and the resources available.

6. Discuss and agree the milestone schedule with the Client

• Does the milestone schedule clearly reflect the sequence of major achievements
throughout the project life?
REVIEW
QUESTIONS • Do the defined milestones enable the Client to monitor progress against time?
• Are the milestones fully understood and agreed on by the Client and project team?
• Are the milestones described as the start or the end of a number of tasks?

TIPS FOR USE


1 Make sure the milestones are built up logically to ensure delivery of the defined product or
service
2 Some projects have to be planned based on a given completion date (backward planning).
Fix the project completion date, and then plan milestones and due dates from the end to the
beginning of the project.
3 The duration between milestones can vary from days to months. The level of detail depends
on the span of control needed from the perspective of the Steering Group (including the Client)
and the project team.
4 Only outline the milestone schedule. Do not go into details at this stage, as this will lead to
detailed discussions at a stage where general understanding between the Client and the pro-
ject team is the prime objective.
5 Check if there are deliverables to be handed over after the completion of each milestone.
6 Depending on the nature of the project, sometimes the tasks (Phase II, step 2) need to be
defined before the milestones become apparent.

Cross-reference
The milestones & the milestone schedule are input for the:
- Agreement with the Client (3.1.9, page 20)
- Project schedule (3.2,2 page 22)
PMA Reference Book

3.1.6 Outline Project Organization

OBJECTIVE The objective of this step is to create the project organizational chart, defining the roles and re-
AND sponsibilities of the persons involved in the project. Additionally, the document flow, and meet-
BENEFITS ing schedule should be agreed on, to facilitate coordination among team members and Cli-
ent/Steering Group. A clear definition of responsibilities and authority reduces conflicts and
helps collaboration among people involved in the project.

1. Check project organizations of similar projects.


PROCEDURE 2. Consider skills needed to perform different responsibilities/tasks
FOR USE 3. Prepare an initial organizational chart including (suggested) names (names of project man-
ager and Steering Group must be known)
4. Agree on roles of each individual and describe their responsibilities & authorities

5. State the time dedication of each team member; consider other commitments, planned hol-
idays, training, etc.
6. Obtain the agreement of superiors on each team member’s time dedication in the project.

7. Discuss the organizational chart with the Client and the project team

8. Outline, discuss and agree on the document flow and meeting schedule. Clarify how inter-
actions with the Steering Group (including Client) will take place.

• Have all roles of team members (including responsibilities, time dedication and authorities)
been defined and agreed within the team?
REVIEW • Have all roles of team members (including responsibilities, time dedication and authorities)
QUESTIONS been agreed with all functional managers?
• Are all project meetings and documents defined and agreed within the team and the Cli-
ent?

TIPS FOR USE


1 At this stage not all of the project team members may be identified, but the skills needed for the
project have to be known and understood.
2 Organization charts, tables with roles and responsibilities and RACI charts are complementary
tools to enable the Project Manager that enable the project manager to agree on the project organ-
ization
3 Take the time to explain to the Client and Steering Group members their responsibilities to the
project.
4 The role of a person in a project may be very different from his/her role in his/her organization.
Therefore it’s important to agree on this with the Client.
5 Ensure that all team members are aware of the level of commitment required in the project.
6 Fix the dates for the Steering Group meetings in advance (use various means of communica-
tion to ensure that the Steering Group will come together to act on their responsibilities)
7 Full understanding on the document and meeting schedule prevents future misunderstandings

Cross-reference
The outline of the project organization provides input for the:
- Definition of the milestone schedule (3.1.5 page 16)
- Estimation of projects costs & benefits (3.1.7 page 18)
- Agreement with the Client (3.1.9 page 20)
- Project team set-up (3.2.1 page 21)
PMA Reference Book

3.1.7 Estimation of Project Costs & Benefits

OBJECTIVE The objective of this step is to estimate project costs in order to compare this with the Client’s
AND cost constraint (step 1.4). It gives a first insight into the feasibility of the project taking costs and
BENEFITS benefits into consideration. Calculating project returns helps the Project Client and Manager
get approval to proceed with the project.

1. Agree on the resources required to complete the project.

PROCEDURE 2. Make an estimate of all costs like material (varies from building materials to communication
materials, etc.), expenses (travelling, etc.), third party assistance (subcontractors), etc.
FOR USE
3. Estimate the level of accuracy of each estimate, and establish a contingency shall there be
risks in the estimate.
4. Discuss and agree on the costs within the project team

5. Identify and quantify the benefits of the project to calculate payback time, NPV, etc.

6. Identify non-monetary benefits of the project

• Have the estimated project costs been broken down according to the main cost compo-
REVIEW nents?
QUESTIONS • Have the estimated benefits and payback time been considered?
• Have non-monetary benefits been discussed and identified?

TIPS FOR USE


1 All costs should be clearly related to the definition of the product or service. When estimating
costs of the project, the benefits should also be taken into account
2 The more details available, the higher the accuracy of the project cost estimates
3 Pay attention to specific tools for calculating project costs to be used within different types of
projects (e.g. CAPEX Valuation Tool – CVT, Investment Cost Presentation – ICP, etc.)
4 The costs associated with the initial phase (Project definition) of a project can be lost if the pro-
ject is not approved (and will have to be expensed). Therefore it is advisable to explicitly state the
costs required to reach project approval.
5 Document and make sure the Client is aware of all assumptions made when estimating costs
to avoid surprises
6 Cost estimates can be based on different techniques (analogous estimating, parametric esti-
mating, bottom-up estimating, etc).
7 The accuracy of cost items reflects the level of confidence on the estimates. Contingency costs
should be based on the accuracy of the cost items as well as the risk in each estimate.
8 Make sure that the Client agrees on the costs at this stage, to avoid discussions that may inter-
fere with the project delivery at a later date.
9 A further cost evaluation shall be made in the planning phase (Phase II, step 4, Project budg-
et).

Cross-reference
Project costs are input for:
- Agreement with the Client (3.1.9 page 20)
- Project budget (3.2.4 page 24)
PMA Reference Book

3.1.8 Risk Identification & Evaluation (Countermeasures)

OBJECTIVE The first objective is to consider the risks that may influence the project. Risks typically have a
AND negative effect on a project; however there could be risks with a positive effect (opportunities).
BENEFITS At this early stage of the project, there is still a degree of freedom to modify project parameters
in order to minimize the risks. The second objective is to establish the framework for systematic
risk management throughout the project. This allows an integration of the Holcim standardized
approach to business risk management in order to align views on risk profile and mitigating ac-
tions.

1. Review the product, specifications, assumptions, stakeholders, milestones, costs and organ-
ization to identify possible risks that may lead to unsuccessful completion of the project, Also
look at risks that occurred in past projects (lessons learned). Finally, consider doing a brain-
PROCEDURE storm to complete the risk identification.
FOR USE 2. Quantify the risks according to their impact on the project and their likelihood of occurrence
(probability that the risk will happen). Prepare a risk map if useful.
3. Focus on the high severity risks; these are the ones with a high significance and a high like-
lihood. The risk threshold should be defined by the project team and Client.
4. For each of the identified risks with a high severity, come up with a proposed countermeasure.

5. Assign persons responsible and due dates to tackle the proposed countermeasures

• Have the major risks and opportunities been identified?

• Have all project team members considered possible risks within their area of responsibility?
REVIEW
QUESTIONS • Have countermeasures been agreed to treat high severity risks or to realize the opportuni-
ties?
• Has a responsible been assigned for each proposed countermeasure?
• Has a responsible been assigned for each proposed countermeasure?
• Has the Client been involved in the risk analysis?

TIPS FOR USE


1 See appendix for details on Risk Management.
2 For major projects (like a large CAPEX-project) also consult Business Risk Management (BRM)
in order to fulfill specific risk management requirements
3 Organize a workshop (with the Client if feasible) on risk identification and evaluation
4 If major risks are identified, be sure that these are communicated to the Client
5 Learn from past projects: the failures of the past are the best source of risk control information.
6 Possible risk countermeasures are: for high severity risk: avoid (eliminate) or transfer (e.g. to a
supplier); for medium severity: mitigate (reduce likelihood or impact); for low severity risks: accept,
including a contingency (in terms of cost, time, resources, etc). – See PMBoK
7 For justifying certain Capex projects, there is an evaluation of the risk level of NOT doing the
project (ProMap risk matrices).
Cross-reference
Risk identification and evaluation provide input for:
- Search for lessons learned (3.1.3 page 13)
- Project schedule (3.2.2, page Error! Bookmark not
defined.)
- Activity list (3.3.1 page 26)
- Project review (3.3.2 page 27)
- Client/Steering Group review (3.3.5 page 30)
PMA Reference Book

3.1.9 Agreement with the Client

OBJECTIVE The objective of this step is to get the Client’s formal approval to launch the project. This ap-
AND proval is based on all aspects of the project definition. The sign-off by the Client ensures
BENEFITS his/her full commitment to the definition made. This agreement prevents misunderstandings
(between the project team and the Client) on the project contents. The agreement also demon-
strates shared vision among the team, the Client and senior/top management.

1. Be sure that all pending items in phase 1 are listed down.


PROCEDURE 2. Prepare the project approval form (summary of previous steps)
FOR USE
3. Present the project approval form to the Steering Group

4. Ensure that a formal sign-off is given by the Client

5. If no sign-off is given redo the necessary parts of the Project Definition

• Have the Client and project team agreed on the outcomes of each step in phase I?
REVIEW
• Have all steps of phase I been completed before signing the agreement?
QUESTIONS
• Has the agreement been signed by both the project manager and the Client?

TIPS FOR USE


1 Talking to the Client, always be clear about the contents and possible pitfalls in the agreement
in order to prevent unnecessary discussions at a later stage
2 This agreement is not a legal document. However, in some projects there can also be a formal
agreement in terms of legal contract.
3 Be aware that you need the Client’s agreement to finalize the planning phase of the project.
You may start planning before agreement is obtained knowing that some changes may be needed
on the plan.
4 It is possible to have more than one project definition meeting with the Client before an agree-
ment is reached.

Cross-reference
The agreement with the Client enables further work
in the next phase - Project planning (3.2, page 21).
PMA Reference Book

3.2 Steps within Project Planning

3.2.1 Project Team Set-up

OBJECTIVE The first objective of this step is to complete the project organization as outlined during the pro-
AND ject definition (see 3.1.6, page 17), with all the names of the people involved including the
BENEFITS roles, responsibilities and authorities. The second objective is to start the team building pro-
cess; an important part of this is to create awareness on each team member’s tendency to con-
tribute to the team as well as how to relate with other team members.

1. Define additional persons who will be part of the team: complete the roles and responsibili-
ties template (following the procedure)
PROCEDURE 2. Ensure that new team members understand the project definition as well as their specific
FOR USE roles in the team.
3. Explain the importance of having an efficient team, and of starting the team building pro-
cess
4. Use available in the company personality tests (eg., team roles of Belbin, conflictology,
etc). Ask your local human resources functions to support you in assessments and result
interpretation.
5. Prepare responsibility assignment matrix (RACI-based). It is a grid to show which project
resources as well as stakeholders are assigned to what project activity and in what role.
6. Agree on team norms to speed up team building process.

• Have all project team members been made aware of the project definition and their role in
it?
REVIEW
• Is responsibility assignment matrix prepared and agreed on by the team and rele-
QUESTIONS vant stakeholders?
• Is the entire project aware of the roles and authorities individually and as a team?
• Have team norms been discussed and agreed within the team?

TIPS FOR USE


1 Ensure that all team members have a clear understanding of individual preferences and areas of
support required.
2 Identify strengths of the project team.
3 Effective team work is key to project success. Teams go through phases known as forming, storm-
ing, norming, performing, adjourning; achieving the performing phase quick is important
4 Team building exercises help team members get to know each other, learn how to work together,
and set up team rules and norms much faster and with far less conflicts. They are recommended when
team members have limited or no experience working together.
5 Project Management (PMA) training ensures consistency of the approach among all team members
(especially for larger projects).
6 If appropriate, invite other employees during certain tasks in the project, to balance the team.
7 For further information about available personality tests, please, consult your HR.

Cross-reference
The project team set-up provides input for:
- Outline project organization (3.1.6 page 17)
- Risk identification and evaluation (3.1.8 page 20)
- Project kick-off (3.2.5 page 25)
PMA Reference Book

3.2.2 Project Schedule

OBJECTIVE The objective of this step is to detail the agreed milestone schedule by describing the tasks
AND needed to reach the milestones. The project schedule provides the team with a control tool that
BENEFITS shows all the tasks to be done including their interdependencies. Understanding which tasks
are in the “critical path” (= sequence of tasks that determines the earliest possible finish date of
the project) enables a more focused project control during the realization phase.

1. Define the tasks needed to reach the agreed milestones


PROCEDURE 2. Assign a responsible person for each task.
FOR USE 3. Estimate the duration of each task

4. Define links between tasks

5. Determine the end date of each task and draw a bar (or Gantt) chart

6. Determine the critical path to check whether additional measures are needed to finish the
project on time

NOTE: You may include major risk countermeasures and communication actions in the project
schedule

• Are all tasks in the project defined in a clear and concise manner?
REVIEW • Are all the tasks needed to achieve the milestones agreed upon with person responsible to get
QUESTIONS them done?
• Have all interdependencies, durations and due dates been agreed by the project team?
• Has the schedule been discussed with external parties (if any) to incorporate delivery times
and external constraints?
• Have all pending actions in phase I (search for lessons learned, risks, etc.) been in-
cluded in the project schedule?
• Are all team members aware of the critical path of the project?
• Have all steps from phases IV and V been included in the project schedule?

TIPS FOR USE


1 Ensure that there is sufficient detail in the schedule to control the overall project and the interde-
pendencies of tasks. It is to be noted that going into too much detail may lead to a loss of overall con-
trol. Detailed control is covered through the use of activity lists (phase III)
2 Ensure that all team members are fully aware of, and have agreed to, the tasks they must perform
3 Check the work load of each team member to prevent overloading; if possible, assign non-critical
tasks during periods of low work load level.
4 Consider other constraints e.g. plant shutdowns, equipment delivery times, etc when doing the
schedule.
5 Use of available scheduling tools (Microsoft Project, Primavera and SAP-PS/PPM Projects) is en-
couraged, but make sure your team members and stakeholders can view your schedule.

Cross-reference
The project schedule provides input for:
- Project budget (3.2.4, page 24)
- Risk identification and evaluation (3.1.8 page 19)
- Project kick-off (3.2.5, page 25)
- Activity lists (3.3.1, page 26)
PMA Reference Book

3.2.3 Communication Plan

OBJECTIVE The objective of the communication plan is to ensure that appropriate communication with key
AND stakeholders takes place at the right times, in order to proactively manage stakeholders’ expec-
BENEFITS tations. This will secure their involvement and continuous buy-in towards the project and avoid
unpleasant surprises in the future due to a lack of communication. Another objective is to de-
fine a contact list to be shared by all team members in order to facilitate communication within
team and with stakeholders

1. Retrieve the stakeholder analysis from phase I and highlight those with whom the project
team will communicate during the project life.
PROCEDURE
2. Define what has to be communicated to them.
FOR USE
3. Define how to communicate with those stakeholders taking into consideration the different
tools/media available.
4. Assign a person responsible for communication action and plan the frequency (or dates)
when communication will be carried out.
5. Establish a contact list by filling in the contact list template.

• Have communication actions been defined for the key stakeholders (high or medium level
of interest and/or influence)?
REVIEW • Will the subject of communication (what to communicate) and the manner of communi-
QUESTIONS cating (how to communicate) effectively engage the stakeholders?
• Does the contact list include information on all team members and stakeholders of the pro-
ject?

TIPS FOR USE


1 Although “face to face” communication is the most effective medium, the use of other technologies
(video and phone conference) will ensure exchange of information and knowledge transfer
2 Consider using creative tools/media for communication (presentations, special newsletters, etc.)
when planning communication to stakeholders to increase the span of attention.
3 Explain to the team the importance of communicating any changes in contact information to keep
the list updated. The updated contact list must be accessible to all team members
4 Look into communication skills of the team: The Human Resources department can be contacted
to provide tips on communication skills.

Cross-reference
The communication plan provides input for:
- Project schedule (3.2.2, page 22)
- Project kick-off (3.2.5, page 25)
- Activity list (3.3.1, page 26)
- Project review (3.3.2, page 27)
- Steering Group review (inc. Client) (3.3.5, page 30)
PMA Reference Book

3.2.4 Project Budget

OBJECTIVE The objective of this step is to plan in detail the costs to be incurred during the project and when
AND these costs will occur. It is an aggregation of the estimated cost of the individual activities and
BENEFITS work The project budget enables the project team to compare actual costs versus the planned
costs (cost baseline) and take action if needed

1. Find out if budgeting procedures exist in your company. If these do not exist, use the tem-
plate provided.
PROCEDURE
2. Use the project schedule to break down the tasks into the various cost components needed
FOR USE to execute them

3. Define when all costs will be incurred

4. Use this project budget as a control tool during project realization

• Is the project budget aligned with the cost estimation in phase I?


REVIEW
QUESTIONS • Does the project budget show in detail all costs to be incurred during the project life cycle?
• Is the budget set up in a way that allows a timely control of costs?
• Are costs for contingency added into the budget?
• Does the project budget use all information from the product definition and project schedule?

TIPS FOR USE


1 Use the company budget tools or the standard PMA template
2 Ensure that the budget is set up in such a way that regular control during the project realization is
possible
3 Discuss the budget with the project team: since this increases cost awareness and supports better
cost management within the whole team
4 If you have sub-projects within a large project, consider having a budget for each sub-project
5 Cost requires expert input. Ask people who will be doing the work about their charges for time and
materials
6 In case you define contingency actions, budget for the costs of these actions.
7 Preparing a cash flow projection will help you determine the funding requirements for your project.

Cross-reference
The project budget provides input for:
- Project kick-off (3.2.5 page 25)
PMA Reference Book

3.2.5 Project Kick-off

OBJECTIVE The objective of the project kick-off is to conclude the planning phase and to ensure that all as-
AND pects are in place to start the realization phase. The kick-off meeting also helps in the process
BENEFITS of team building and maximizes the momentum to start the realization by creating common
commitment. Being one team with a shared understanding and commitment is especially im-
portant when the project faces problems during the realization phase

1. Invite the Project team and Client (and SG members, stakeholders if appropriate) to the
kick-off meeting.
PROCEDURE
2. During the meeting, get the Client to revisit key elements of the project with the team
FOR USE
3. Review and agree on the planning documents (project team setup, project schedule,
communication plan, project budget)
4. Review the team norms/ground rules

5. If needed, fine tune the project schedule, communication plan and risks identification and
countermeasures

6. Update and distribute the documents with the agreed changes (if any)

• Have all steps in phases I and II been completed before the kick off meeting?

REVIEW • Are the project team and Client (and/or Steering group and stakeholders) present during
QUESTIONS the kick off meeting?
• Are the participants committed to the project and agree to their roles and responsibilities in
the project?

TIPS FOR USE


1 Maximum involvement will ensure that all aspects of the planning will receive full commitment from
the project team
2 Client and/or Steering Group attendance will support the realization of the project (active leadership
from Top Management);
3 Send the documentation in advance to all participants to increase the effectiveness of the meeting
4 Reviewing the ground rules/norms of the team helps to intensify teamwork during the realization
phase
5 In some cases, the approval of the project (agreement with the client, Phase I step 9) happens only
after this phase is also concluded.

Comment: The kick off meeting should create the right momentum to start realizing the product or service.
PMA Reference Book

3.3 Steps within Project Realization

3.3.1 Activity List

OBJECTIVE The objective of this step is to establish the sequence of activities required to complete the
AND tasks set in the project schedule. .A detailed definition of activities and a clear assignment to
BENEFITS responsible persons will ensure proper coordination and control. The activity list is a time man-
agement tool for the project.

1. Define the period to cover (weeks)

PROCEDURE 2. Break down the tasks from the project schedule into activities (including risk monitoring
and communication plan).
FOR USE
3. Agree on a responsible person, effective time needed to complete the activity and planned
due date.
4. Review and adjust the activity lists during the project review meeting

5. After completion of activities, record actual time spent, actual due date and comments if
needed.
6. Analyze deviations between the plan and actual durations and due dates, and agree on
actions.

• Have the project schedule tasks been broken down into detailed activities at the lowest
useful level for the upcoming period?
REVIEW
• Are activities issues proactively addressed to avoid project delays?
QUESTIONS
• Have actual hours spent and actual due dates been recorded to allow for review and
reporting?
• Does the project manager support the team members actively when issues arise during
the planning or execution of activities?

TIPS FOR USE


1 The period covered by an activity list depends on the span of control needed in the project
2 Short interval control through activity lists helps to identify possible problems at an early stage
3 Remember the saying “the devil is in the detail”. Don’t go into more detail than is really needed.
4 The activity list as described above is for the project activities. Nevertheless, it can also be used
for personal/other activities.

Cross-reference
The activity list provides input for project review (3.3.1 page 26)
PMA Reference Book

3.3.2 Project Review (within Team)

OBJECTIVE The objective of this step is to review all activities with the team in order to have proactive control
AND of project progress and to identify and address issues encountered. This requires a common un-
BENEFITS derstanding of the achievements in terms of costs, time spent and the quality of deliverables. Is-
sues need to be resolved by making a decision and/or defining an action. Project review is the
main control system for the project manager and the team.

1. Make sure all team members are prepared for the project review meeting (follow up on ac-
tions, identify issues, etc.)
PROCEDURE
2. During the meeting, analyze performance, on time, cost and deliverables.
FOR USE
3. Review and update the plan for the coming period (schedule of the succeeding few weeks)

4. Review risks and countermeasures and include new ones as needed.

5. Review communication plan and add/modify as needed.

6. Use the change request form to address changes.

7. Review team dynamics (norms, leadership)

8. Resolve issues, review and update the action and decision log.

9. Distribute the action and decision log to the agreed recipients within one day of the meeting.

10. Capture knowledge as it occurs (see next step) as part of the review meeting.

• Are regular project review meetings carried out as agreed in the outline project organization?

REVIEW • Are the project review meetings properly prepared, (agenda, invitation, etc.)?
QUESTIONS
• Is the project status reviewed and all review meeting documentation (schedule, budget, ap-
proved changes, action & decision log, etc.) updated to reflect current status?
• Is the project team making decisions proactively in to avoid any cost/time/quality deviations?
• Are communication actions as well as risk analysis and countermeasures regularly reviewed
during project review meetings?
• Are requested changes analyzed and agreed on formally with the client?

TIPS FOR USE


1 Ensure that all team members regard the review as a means to support attainment of project mission
2 Developing interpersonal skills (inc. conflict management) help to increase productivity
3 Ensure that the project schedule and budget are updated; agree on any corrective actions needed
to keep the project within the agreed cost, time and quality specifications.
4 If persons are not present during the meeting, ensure that actions assigned are communicated to them.
5 Ensure that the action and decision log is updated each time an action or decision is agreed upon
6 Monitor the key project risks as part of the project review (revise the risks defined in phase I)
7 Ensure that the change request forms are used and approved by appropriate people
8 Change request include corrective and preventive actions, defects repair and updates

Cross-reference
• The project review meeting (within the team) provides input for:
- Capture of knowledge (3.3.3 page 28)
- Project status report (3.3.4 page 29)
PMA Reference Book

3.3.3 Capture of Knowledge

OBJECTIVE The objective of this step is to capture knowledge as it occurs. Knowledge can be captured af-
AND ter evaluating the progress of the project regarding budget, time and quality (in regular After
BENEFITS Action Reviews). Capturing knowledge immediately after the learning takes place ensures that
all important elements of the knowledge are understood. Furthermore, it makes Phase V of the
project (evaluation & transfer) much easier to conduct. This leads to a more efficient transfer of
knowledge

1. Hold regular After Action Reviews (AAR) of the project. This can be done as part of or in-
dependently of the project review meeting.
PROCEDURE 2. In the AARs, discuss what went well and what did not go so well. Analyze reason for the
FOR USE deviations/success and agree on the lessons learned: what should be done next time so
that success can be repeated and deviations can be avoided
3. Capture any lessons learned as soon as they occur.

4. Using the template, record the lessons learned from the last period

5. Decide, depending on the importance and impact of the lesson learned, whether
knowledge should be transferred immediately (through assigning an action for it during the
review meeting) or logged for review in phase V of the project.

• Are project evaluations (or AARs) carried out regularly to correct deviations and capture
REVIEW knowledge?
QUESTIONS • Are all lessons learned clearly defined and captured in order to be reviewed in phase V?
• If appropriate, are the key lessons learned transferred before the end of the project?

Tips for use

1 Doing regular After Action Review (AAR) after completing some of the larger and more important
tasks/milestones will help you not only to identify lessons learned but also to set the project on the
right track. For information on the AAR please refer to paragraph (3.5.1, page 56)
2 Openness regarding mistakes is a prerequisite for improvement and for the capture and transfer of
lessons learned
3 Knowing how quickly the lessons learned have to be distributed depends on certain criteria, e.g.
safety, impact on costs etc.

Cross-reference
Capture of knowledge provides input for the learning summary
(3.5.2 page 35)
PMA Reference Book

3.3.4 Project Status Report

OBJECTIVE The objective of this step is to report to the Client (including the Steering Group) on the status
AND of the project as agreed upon in the outline project organization (documents and meetings). It
BENEFITS provides the Client with the information to actively work on his/her role. The project status re-
port ensures proper control for the project team, Client and Steering Group.

1. Select the period to report on.


PROCEDURE 2. Collect information on the quality of the deliverables, costs, time schedule, key issues and
FOR USE actions to resolve, and areas where support from the Steering Group is needed, etc.
3. Prioritize and summarize the project key information in the project status report.

4. Use a traffic light colour system to indicate the status of the projects

5. Send the status report to agreed recipients

• Does the project status report incorporate the outcomes of the project review meeting?
REVIEW • Does the project status report provide the right information for the Client and Steering
QUESTIONS Group to steer the project (review progress and provide support)?
• Are the project status reports regularly distributed among team members/Steering Group?

TIPS FOR USE


1 The contents of the status report will be derived from the project review meeting. Ensure that the
Client gets the latest information on the status of the project.
2 A status report should be limited to 1 page. In case you have a lot of information to report on, priori-
tize it to fit in a one-page report. Additional information can be provided in appendices.
3 Making status reports available to the project team helps in sharing a common understanding about
the project
4 Hand in the status report at the agreed times defined in phase I, step 6, outline project organization.

Cross-reference
The project status report provides input for the Steering Group review
(including Client) (3.3.5 page 30)
PMA Reference Book

3.3.5 Client / Steering Group Review

OBJECTIVE The objective of this step is to formally review project progress together with the Client/Steering
AND Group as agreed in the outline project organization (documents and meetings). Regular re-
BENEFITS views with the Steering Group ensure that proper attention is given to the project environment
and its business context.

1. Prepare the agenda and contents of the meeting (include review of risks and communica-
tion plan)
PROCEDURE
2. Send (if any) the change request forms to be discussed during the meeting
FOR USE
3. If needed, pre-present to the individual Steering Group members and adapt contents on
the basis of feedback
4. During the meeting, review the status of the project, risks and countermeasures and com-
munication plan.
5. Log and summarize all actions and decisions agreed upon during the meeting

6. Distribute the action and decision log within a day of the meeting

• Are the meeting agenda and latest status report sent out in advance to the Client /all SG
members?
REVIEW • Are all relevant issues discussed during the Client/SG meeting and corresponding actions
QUESTIONS & decisions recorded?
• Are the project communication plan and risk analysis reviewed and updated with the Cli-
ent/SG members?
• Are change requests being discussed and agreed with the Client?

TIPS FOR USE

1 Early planning and communication of Client/Steering Group meetings to the Client and all SG
members ensures that these meetings are efficient and effective
2 Topics outside the scope of the meeting should be set aside and addressed in a separate meet-
ing.
3 Do not be over-optimistic with regard to the number of topics that can be handled and the time al-
located for each topic.
4 Since it might be difficult to arrange a meeting with the Client and all Steering Group members
physically present, arrange meetings in advance and make use of other communication media, e.g.
telephone conferences, if needed
5 Including a review of the risk evaluation and the communication plan in the agenda ensures that
these aspects are being managed actively at the level of the Client/SG

Comment: The review of progress with the Steering Group is used to identify whether changes are needed in project
definition. At the end of the realization phase, the Client / Steering Group will decide whether the hand-over can
commence
PMA Reference Book

3.4 Steps within Project Completion

3.4.1 Hand-over

OBJECTIVE The objective of the hand-over step is to ensure that explicit acceptance of the product or ser-
AND vice is made by the Client. Further actions to complete the project are agreed between the Cli-
BENEFITS ent and the project team. The hand-over process clearly signals that the responsibility is
changing from the project team to the Client.

1. Depending on the project, organize an acceptance test (e.g. performance test, user ac-
ceptance test, etc.) or review of the product or service delivered to the Client
PROCEDURE 2. Together with the Client, agree on all actions resulting from the test to ensure that the
FOR USE product or service is compliant with the agreed project definition
3. Also agree on further actions to be taken to ensure proper project completion

• Is the project hand-over conducted with the Client and relevant Steering Group members?
REVIEW • Are objectives and deliverables from the project definition compared to the actual project
QUESTIONS results and delivered products?
• Have all pending hand-over actions been agreed to ensure full satisfaction of the Client?
• Have the dates for the closing meeting and/or phase V workshop been agreed with all par-
ticipants?

TIPS FOR USE

1 Don’t allow the hand-over to be regarded as a “clean up” process (to quickly end the project and
leave the Client with lots of open issues). In case of delay, the delivery date has to be re-negotiated
with the Client/Steering Group as soon as possible
2 Make the hand-over a structured transition to achieve future responsibility for use and maintenance
of the product or service delivered
3 Make all completion dates for hand-over actions realistic and make sure that the actions are being
reviewed by the Client and end–users
4 In Capex projects, this is the so-called Commissioning phase, and it could consist of a series of
tests (start up, cold commissioning, hot commissioning and provisional take over, etc.).

Cross-reference
The hand-over provides input for the:
- Final report (3.4.2 page 32)
- Closing meeting (3.4.3 page 33)
PMA Reference Book

3.4.2 Final Report

OBJECTIVE The objective of the final report is to summarize the delivered results, their quality, costs and
AND time spent and compare, these with the agreement made at the definition phase of the project.
BENEFITS The report serves two purposes: first, it provides the Client and the Steering Group with a
summary of the project at its end state; secondly, it serves as a quick reference for other pro-
jects.

1. Define the basic structure of the report including: objectives, definition of product or ser-
vice, the project schedule, and the cost as agreed with the Client.
PROCEDURE
FOR USE 2. Describe and compare the actual outcome in terms of the above mentioned aspects
3. Give a short explanation of any deviations

4. Review and agree on the report with the Steering Group (including Client)

5. Include the learning summary (phase V) as part of the Final Report

• Is the structure of the final report agreed on by the Client and the project team?
REVIEW
QUESTIONS • Does the final report reflect the complete summary of the overall project?
• Is the final report sent to all relevant persons for their review?

TIPS FOR USE

1 Ensure that any deviations have been reviewed with the Client and appropriate stakeholders (if
needed) before inclusion in the final report
2 If amendments have to be made after the presentation of the final report, these must be documented
and dated
3 For Capex projects, make sure you review the original agreement made in the Capex request form
and/or the Investment scorecard, to analyze whether the project has been successful or not.
4 Including the learning summary into the final report will allow this document to be a complete refer-
ence for future projects.

Cross-reference
The final report provides input for the closing meeting (3.4.3 page 33)
PMA Reference Book

3.4.3 Closing Meeting

OBJECTIVE The objective of the closing meeting is to formally complete the project and to officially release
AND the project team from any further responsibility to deliver. This is also the last meeting with the
BENEFITS Steering Group. In this meeting the Client gives the final approval of the project. The meeting
normally has an informal character to celebrate the successful completion of the project.

1. Prepare the agenda and contents of the meeting and send them to the attendees.
PROCEDURE 2. Calculate the overall project success (OPS)
FOR USE
3. During the meeting, review completion of hand-over actions and get the approval (by
means of signature) of the project from your Client
4. Decide on further communication and marketing of the results

5. Ensure that the project is formally ended and that the project team is released from further
responsibilities to deliver
6. Communicate the responsibility of the project team and the Client to complete the project
evaluation and transfer (phase V)

• Has the meeting agenda been sent out to all participants in advance?
REVIEW
• Have the hand-over actions been completed before the meeting date?
QUESTIONS
• Did the Client and the project manager sign-off the project approval?
• Has the Client taken full ownership of the product and formally released the project team
members from further responsibility to deliver?

TIPS FOR USE

1 Review the contents of the meeting, agenda, etc. with the Client prior to the meeting in order to re-
vise contents if needed.
2 Consider including the element of “social event” as part of the closing meeting to recognize and cel-
ebrate success.
3 Depending on the magnitude of the project, invite important guests to witness the project results.
4 Ensure the continuity of persons if a follow-up project needs to be defined

Cross-reference
The closing meeting marks the formal completion of the project and
gives way to the After Action Review (3.5.1 page 34)
PMA Reference Book

3.5 Steps within Project Evaluation and Transfer

3.5.1 After Action Review (AAR)

OBJECTIVE The objective of the After Action Review in this phase of the project is to systematically capture
AND the experiences, focusing on performance of the team and enabling participants to discover for
BENEFITS themselves what happened, why it happened and how to sustain strengths and improve on
weaknesses. Capturing these experiences helps to improve future projects by improving not
only collective performance (better project results) but also individual performance. AARs may
also be conducted after critical project phases or milestones to enable continuous fine tuning
and improvement.

1. Select participants for the After Action Review

PROCEDURE 2. Check the need to for an external or independent facilitator to support the After Action Re-
view (formal AAR)
FOR USE
3. Conduct a structured AAR following the terms of reference (template) and the Guideline on
After Action Review to capture the lessons learned
4. Inform people how information from the AAR will be will be handled

• Are all relevant participants (including the Client) attending the AAR of the project?
REVIEW • Is the facilitator of the AAR acting in a neutral manner (balancing positive and improve-
QUESTIONS ment points)?
• Are key topics pre-selected and evaluated during the AAR?
• Have the key lessons learned been identified for the benefit of future project teams?
• Have the outcomes of the AAR been recorded?

TIPS FOR USE


1 Distinguish between “must act on this aspect” and “nice-to-know aspects”
2 Organize the After Action Review immediately after the completion of the project.
3 Ensure that everybody participates by asking open-ended questions.
4 Create a “safe“ climate for people to feel free to make contributions
5 Use of questionnaires may help prepare for the meeting to gather information
6 Focus on learning points, problems and solutions

Cross-reference
The After Action Review provides input for the learning summary (3.5.2 page 35)
PMA Reference Book

3.5.2 Learning Summary

OBJECTIVE The objective of the learning summary is to distill the learning captured during the project. It
AND takes into account both the outcomes of the After Action Review and the knowledge captured
BENEFITS during the realization phase. It provides a quick insight for future projects that might have to
deal with similar situations. The learning summary can contain both technical and project man-
agement aspects. It helps to enable better execution of future projects.

1. Review lessons learned captured during phase III as well as the outcome of the After Ac-
tion Review
PROCEDURE
2. Decide on the most important lessons learned which can benefit future projects.
FOR USE
3. Copy and paste the lessons learned and ensure that they are clearly linked to the cause of
the learning
4. Include the learning summary in the Final Report of the project in order to give context to
the learning.

• Are lessons learned (captured during phase III and phase V) evaluated to filter out the
REVIEW most important learning of the project?
QUESTIONS
• Can lessons learned be traced back to the source for more in-depth understanding?

TIPS FOR USE

1 The learning summary should include key recommendations for future project teams who will be
undertaking similar projects.
2 Putting the learning summary in the Final Report helps other project teams understand the con-
tent and context of the knowledge gained.

Cross-reference
The learning summary provides input for
- Knowledge transfer (3.5.3 page 36)
- Final report (3.4.2 page 32)
PMA Reference Book

3.5.3 Knowledge Transfer

OBJECTIVE The objectives of this step are to determine who will receive the lessons learned (as agreed
AND upon in the learning summary), and to define practical actions regarding how the lessons
BENEFITS learned can be transferred. Knowledge transfer is the last step in the process of the project. It
ensures that knowledge is not just available but that it has been transferred in the most prag-
matic way.

1. Upon completion of the learning summary, define who can benefit from the lessons
learned.
PROCEDURE 2. Decide on the most effective mechanism to transfer lessons learned within your depart-
FOR USE ment/Company/Group
3. Agree on actions to make the transfer happen, using the Action & Decision Log

4. Ensure that the Project Manager transfers knowledge

• Has the team clearly defined the knowledge to be transferred, to whom, how and by
REVIEW whom?
QUESTIONS
• Have the lessons been transferred?

TIPS FOR USE

1 Follow the KISS (Keep It Simple and Straightforward) principle


2 Make use of the corporate resources/events to transfer lessons learned worldwide
3 Consider making the final report available (containing the learning summary) as a future reference
for other projects, using the Holcim Portal or any other Holcim wide knowledge-sharing platform.

Comment
The knowledge transfer marks the end of the Project Management Approach (PMA)
GLOSSARY Holcim PMA Reference Book

4 Glossary

Activity Client
Elements of work needed to achieve a task. Each Representative of the end users with the authority
task is broken down into activities. An activity nor- to take decisions on behalf of his/her organization
mally has a responsible, an expected duration, and during project phases.
an expected start and finish date.

Activity list Closing meeting


Step of the project realization phase where the Step of the project completion phase to formally
tasks are broken down into activities. release the project team from the responsibility to
deliver the defined product or service.
After Action Review (AAR)
An After Action Review is an end-of-action evalua- Communication plan
tion (review) for teams and/or persons responsible Step of the project planning phase to describe what
and involved in the action to be evaluated. It is used is to be done to provide important stakeholders with
during phase V; however it can also be used during the right information and involve them at the right
other phases. time.

Agreement with the Client Contingency reserve


Summary of the project definition that has to be A reserve (e.g. time or money) that allows for an
explicitly approved by the Client and the project alternative strategy to be used to ensure project
manager, in order to proceed with the project. success if specified risk events occur.

Assessment of initial situation Control


The first step of the definition phase. In this step, The process of comparing actual performance with
the root cause for starting the project, the objectives planned performance, analyzing variances, evaluat-
related to the project and the mission of the project ing possible alternatives and taking appropriate
are defined. action and/or decisions as needed.

Assumptions Cost
Factor considered true, certain or real for plan- See project cost.
ning purposes. They need to be checked or
validated before approving the project, since Critical path
they could pose risks to the project. The sequence of tasks which determines the earli-
est date of project completion. The critical path will
Business Objective usually change as tasks might be completed ahead
A business result or target to be achieved through of or behind schedule. Although normally calculated
the project. It should be aligned with the long-term for the entire project, the critical path can also be
corporate goals as described in the Strategic and determined per milestone.
Business Plan and the Operational Road Map
(ORM). Definition of product or service
Step of the project definition phase to clearly de-
Capture of knowledge scribe what will be delivered (product / service) to
Step of the project realization phase to explicitly the Client as a result of the realization phase.
identify and store lessons learned for future use in
Phase V or to enable immediate transfer if required. End users
The organization that will make use of the product /
Changes service delivered by the project team.
Agreed adaptations to the project content (definition
and planning). Changes to documents as part of the Estimation of project costs
project planning can be made by the project team. An approximation of project costs and benefits. This
Changes to documents as part of the project defini- approximation should always include some indica-
tion have to be made by the Client/Steering Group. tion of accuracy. The level of accuracy improves as
GLOSSARY Holcim PMA Reference Book

the project concept is developed (preliminary, con- Outline project organization


ceptual, feasibility, order of magnitude or definitive) Step of the project definition phase. First definition
of the hierarchical set-up of the project including
Final report roles, responsibilities and authorities of the Steering
Step of the project completion phase to summarize Group, Client, project manager and identified team
the comparison between the project definition members. It also outlines document flow and meet-
agreed upon and the actual product or service, ac- ing schedule.
tual costs and degree of schedule compliance. It
also includes hand-over summary, learning sum- Performance indicators
mary and further recommendations related to sus- Measurable values to visualize the status of the
tainability of the product or service. progress in realizing the product or service.

Hand-over Phase
Step of the project completion phase used to de- A collection of logical steps to achieve properly con-
scribe the activities that ensure that the product or trolled project progress. Often but not necessarily,
service is accepted by the Client. It is also in this each phase is active at any time.
step that outstanding actions are explicitly agreed
upon between the project team and the Client. Problem
A deviation from the expected performance. It is
Issue detected when there is a gap between what is hap-
A point or matter in question, which the project pening (actuals) and what should be happening
team has to manage to completion by assigning (plans).
actions or making decisions.
Product or service
Knowledge transfer The items that the project team will deliver to the
Step of the project evaluation and transfer phase to Client. They are the means by which the business
define the mechanism and actions to ensure that objectives will be achieved.
transfer of the lessons learned to the appropriate
recipients takes place. Project
A one-time, multi-task job that has clearly defined
Learning summary starting and ending dates, a specific scope of work
Step of the project evaluation and transfer phase to to be performed and a budget to achieve the de-
distil the key lessons learned derived from the After fined business objectives.
Action Review and the capture of knowledge.
Project budget
Lessons learned Step of the project planning phase to describe the
New knowledge acquired during the project. It project costs in detail to allow cost control during
should describe what to do or avoid to ensure com- the realization phase
pletion of a specific aspect of the project
Project charter
Milestone A document created before the project definition
A significant achievement that summarizes the phase, that describe the initial understanding of the
completion of an important set of tasks or the com- client and project manager of the new product or
pletion of an important event in a project. It is the service to be delivered, including: root causes to
means by which the Client and Steering Group will start the project, business objectives, project mis-
monitor progress against plan. sion, deliverables, high-level milestone schedule,
high-level cost, high-level risks and required project
Milestone schedule team members
A schedule which shows the milestones of the pro-
ject. Project completion (phase IV)
The fourth phase of the Project Management Ap-
Mission proach (PMA) which ensures that the ownership of
A statement of what the project team aims to do to the product or service is properly transferred to and
reach the defined objective. Also called scope accepted by the end users, so that the project team
statement or team assignment. can be released from their responsibility to deliver.
GLOSSARY Holcim PMA Reference Book

Project costs Project realization (phase III)


The actual costs incurred by the project team to The third phase of the Project Management Ap-
realize the product or service and to manage the proach (PMA) to ensure that delivery takes place in
project. accordance with the agreement made during the
project definition phase; includes project reviews
Project definition (phase I) within the team and with the Client to properly con-
The first phase of the Project Management Ap- trol and report on progress.
proach (PMA), used to build a relationship with the
Client and to gather sufficient information to ensure Project review (within the team)
an agreement can be reached with the Client. Step of the project realization phase to assess the
status of the project with the project team and to
Project evaluation and transfer (phase V) assign actions and make decisions to address iden-
The fifth phase of the Project Management Ap- tified issues.
proach (PMA) used to evaluate the way of working
with the Client and the project team and to ensure Project schedule
that distilled lessons learned are being transferred Step of the project planning phase to describe tasks
to enable future improvements in projects. within the project, together with the associated time
scale in which they are planned to be undertaken.
Project Failure Project status report
Projects that are terminated with or without mutual Step of the project realization phase to summarize
consent between the Client and the project team. and communicate the status of the project perfor-
Projects that fail do not deliver the expected busi- mance indicators (cost, time and quality), achieve-
ness objectives and consequently they waste re- ments, plan for the next period issues and correc-
sources. tive actions taken, and support required from the
Steering Group.
Project kick off
Step at the end of the project planning phase which Project team
ensures that the project team is fully aligned to Individuals involved in the execution and the man-
commence the realization phase. agement of the project work

Project life cycle Project team set-up


The collection of the 5 phases defined by the Pro- Step of the project planning phase where the pro-
ject Management Approach ject organization is further outlined and the team
building process is started.
Project Management Approach (PMA)
The Holcim Project Management Approach which Risk
defines the principles under which projects within A risk is an uncertain event or condition that, if it
occurs, could have a:
the responsibility of Holcim management will be
• Negative effect: e.g. partial or complete failure
conducted. to achieve the business objectives, overrun of
budgeted cost and time limits, etc
Project manager • Positive effect: e.g. exceeding targets/business
The person accountable for delivering the agreed objectives, lower cost or shorten realization
product or service, and responsible for the day-to- time, etc
day management of the project.
Risk identification and countermeasures
Step of the project definition phase to create a prior-
Project organization itized list of negative (and positive) risks and define
The reporting structure and organizational chart that actions to avoid (or exploit), transfer (or share), or
details "Roles and Responsibilities". mitigate (or enhance) their potential impact.

Project planning (phase II) Risk owner


The second phase of the Project Management Ap- Individuals accountable for the management of in-
dividual risks (See "Standardized Approach to Risk
proach (PMA) to detail the project as outlined dur- Management").
ing the project definition phase in terms of the tasks
that are to be planned for, the costs involved, as Risk profile
well as to form the project team and to describe the The risk profile comprises the total of all risks with
way of working during the rest of the project. their significance and likelihood.
GLOSSARY Holcim PMA Reference Book

A risk profile can be graphically represented by a Stakeholder analysis


risk map (individual risks placed in a diagram with Step of the project definition phase to identify all
the two axes "Significance" and "Likelihood").
stakeholders and interact with them to determine
Risk management their interest in the project and to define measures
Risk management is the sum of all actions taken to be taken in order to incorporate those interests in
with the aim to identify and cope with risks. the project (mainly in deliverables).
Every member of the project organization assigned
to perform a certain task is accountable for manag- Steering Group
ing the risks related to this task.
Individuals representing the end users; they provide
Root cause the financial resources and must approve and
The deepest underlying cause(s) triggering the oc- agree on project definition, budget, plans and
currence of a specific effect. changes to the project definition.

Schedule Client/Steering Group review


See project schedule. Step of the project realization phase to assess the
status of the project with the Client and/or Steering
Search for lessons learned Group, assign actions and make decisions to ad-
Step of the project definition phase to incorporate dress identified issues and risks.
previous experience into the definition phase.

Standardized approach to risk management Step


The standardized approach to risk management A component of a phase. All steps have to be fin-
comprises the systematic identification of and cop- ished to complete the phase of a project.
ing with risks. Its core element is a process consist-
ing of the following steps 1) risk identification, 2) Task
analysis of risk sources/drivers/influences, 3)
A task is a cohesive unit of work in a project (one
measurement of significance and likelihood, 4)
evaluation of actual and definition of target risk pro- that is not too big nor too small to be tracked). A
file (including definition of respective actions), 5) milestone is broken down into tasks. Normally, a
assurance that risks are managed in order to task will be broken down into a series of activities to
achieve target risk profile, and 6) continuous moni- enable proper monitoring of progress.
toring of development of risk profile and monitoring
of implementation of action plans. Team norms
Standardized risk management is the responsibility Guidelines that the team agrees to follow as it con-
of the Steering Group. Individual members of the ducts its work. Most newly-organized teams find it
Steering Group or of the Project Team are ac- effective to start out with an initial set of norms with
countable for management and monitoring of indi- the understanding that these will need to be re-
vidual risks (Risk Owners). viewed and modified frequently. The creation and
adherence to team norms foster not just a success-
ful project outcome, but also a satisfying work expe-
Stakeholders rience.
Internal or externa individuals and / or organizations
(or parts of organizations) who have an interest in Workflow (meetings and documents)
or can be affected by the project. Influential stake- Set of interrelated meetings and documents to en-
holders provide input for project deliverables. sure that planning, controlling and reporting during
the project is being dealt with in a structured man-
ner and that any required changes are made to
ensure delivery of the product or service to the Cli-
ent.
Appendix A PMA Reference Book

5 Appendix A: How the 5 Phases and the corresponding steps are interrelated

Explanation of Phase I Phase II Phase III Phase IV Phase V


who is involved
assessment of initial
high low situation hand-over
project definition stakeholder analysis
meeting hand-over
I with client list
n i definition of product
v n or service

o v risk identification and


countermeasures action and
l o decision log
Final report
2
v l Client/ closing
e v steering group meeting
review meeting
m e
project approval
e m meeting 3

n e agreement with
n the client
t search for lessons project status
t learned report after action
review
C 1
l p
i r 3

e o
n j
4
t e project team set-up
learning
c outline project
project schedule
activity summary
t organization list

project definition communication


milestone schedule
meeting plan action and
t internal decision log
estimation of project project budget knowledge
e costs and benefits project transfer
a review meeting
project kick off
m meeting capture of
knowledge
new projects

low high

Explanation of figures Explanation of change / update indicators


1
Executed if the steps of the project planning show that the
Meeting “agreement with the client “ is incorrect / incomplete
Input indicator
2
Executed if the steering group (incl.. the client) decides that the
Document “agreement with the client” needs to be updated / changed
Change / update indicator
3
Executed if the project team decides that one of the steps in
Document related the project planning needs to be updated / changed
to a meeting
4
Executed if the project team decides that the “activity list”
needs to be updated / changed
Appendix B PMA Reference Book

6 Appendix B: Project Risk Management

General Projects are exposed to risks which typically may lead to the following:
• partial or complete failure to attain the objective, i.e. non-
achievement of project objectives (qualitative and/or quantitative), or
partial achievement of the defined product or service but not within
budgeted cost and time limits (downside or negative risks), or
• missing additional benefits or missing possibilities to lower cost or
shorten realization time (opportunity risks).
Risks may occur in various areas:
• Company external project context, e.g. industry/market, external
stakeholders, laws/regulations, environment etc. (basic business
assumptions)
• Company internal project context and project concept, e.g. strategic
planning, technology, human resources etc.
• Project management and project implementation, e.g. project or-
ganization, performance of project management function, contrac-
tors etc.
To a great extent, project management inherently comprises project risk
management: a lot of tasks are performed and most of the decisions are
taken to minimize threats and to profit from opportunities. Nevertheless,
partial or complete project failures occur and are due to:
• Lack of risk awareness
• Project scope and objectives unclear or unrealistic, i.e. overly opti-
mistic
• Inadequate project organization
• Insufficient allocation of resources, work overload of persons in-
volved in the project
• Project organizations/teams not familiar with (standard) project pro-
cedures, etc.
Performing a standardized approach to project risk management im-
proves this situation and supports project management much like a
safety net. With its standard approach (see below) and its forms and
checklists which have been developed for specific types of projects (e.g.
for CAPEX Projects) it has following objectives:
• Improvement of risk awareness throughout the project organization
from inception to project completion
• Anticipation of problems of all kinds, detection of non-addressed
opportunities
• Alignment of views in Project Steering Group and Project Team on
risk profile and actions to be taken to manage risks
• Comprehensive and systematic coping with project risks.
Appendix B PMA Reference Book

Standardized Approach The standardized approach to project risk management consists of a 6-step
to Project Risk process:
Management
Step 1: "Identify"
Purpose: Create risk awareness.
Tasks:
- Identification of risks (categorizing by brain storming); results of brainstorm-
ing require clear structuring and categorization prior to further processing
- First prioritization of risks with regard to their significance and their likeli-
hood of occurrence.
Step 2: "Source"
Purpose: Understand the logic and origin of individual risks.
Tasks:
- Analysis of sources/drivers of risks, identification of links and interdepend-
encies.
- Nomination of Risk Owners (individuals accountable for the management
of individual risks).
Step 3: "Measure"
Purpose: Review first prioritization; define key risks.
Tasks:
- Quantification of risks with regard to significance and likelihood
- Quantification with facts and figures wherever possible, qualitative ranking
where not possible
Remarks:
1) Net risks shall be quantified, i.e. considering risk mitigating measures
(e.g. insurance) actually in place.
2) Focus shall be on realistic scenarios and not on unlikely worst cases.

Step 4: "Evaluate"
Purpose: Check acceptability of risk profile (risk profile: risk situation as de-
fined by outcomes of Steps 1 to 3) and draw conclusions.
Tasks:
- Analysis of risk levels of individual risks as well as of aggregated risk situa-
tion
- Definition of target risk profile (-> risk tolerances) including
measures/actions to reach this profile; depending on the project and its
status, this can mean anything between isolated measures to cope with
isolated risks and complete redefinition or even canceling of the project.
Step 5: "Manage"
Purpose: Ensure adequate management of risks.
Tasks:
- Ensure implementation of risk mitigating measures/action plans (-> mile-
stones, allocation of resources, and definition of responsibilities)
Step 6: "Monitor"
Purpose: Avoid surprises.
Tasks:
- Continuous monitoring of identified risks and keeping the radar open for
new risks
- Giving notice of favorable as well as unfavorable developments and mak-
ing sure that adequate actions are taken in time
- Reporting on implementation of action plans (progress reporting) as well as
on changes in the risk profile
Appendix B PMA Reference Book

Responsibility for Risk Management

6. 1. Every member of the project organization who has


Control Identify been assigned a certain task is accountable for
risks risks managing the risks related to this task.
Standardized risk management is the responsibility
of the Steering Group. Individual members of the
Steering Group or of the Project Team are ac-
5. 2. countable for management and monitoring of indi-
Manage Source
vidual risks (Risk Owners).
risks of risks

4. 3.
Evaluate Measure
risks risks

Application of Standardized Approach to Risk Management in Individual Projects


Project Management Phase I - Project Definition Project Management Phases II to V:

- Performance of Risk Management Process - Performance of Risk Management Process


Steps 1 to 5 by Steering Group, in a form ade- Step 6 (responsibility of the Steering Group)
quate to the project (participants to the pro-
cess, level of detail, degree of formalization) - Standardized procedures as defined by the
Steering Group in Phase I (e.g. formal reviews
- Determination of standardized risk manage- of Risk Management Process Steps 1 to 5,
ment activities in the other Project Manage- formal reporting requirements etc.)
ment Phases (II to V)
- Additional activities as defined by Project Man-
- Starting with the standardized approach to risk ager (e.g. application of Process Steps 1 to 6
management in parallel with the project allows on sub-projects)
to already defining the project bearing risk con-
siderations in mind. This proactive approach
should prevail throughout the project: risk con-
siderations should be a standard element in all
decision making processes, thus reducing the
necessity for emergency actions due to sur-
prises or foreseeable negative developments.
Bibliography PMA Reference Book

7 Bibliography

GRAY, Clifford F., LARSON, Erik W., Project Management, The management process, Irwin
McGraw-Hill, 2000, 479 pages.

BAKER, Kim & Sunny, The complete idiot’s guide to Project Management (second edition), Alpha
books, 2000, 404 pages.

LEWIS, James P., The Project Manager’s desk reference (second edition), Mc Graw Hill, 1999, 546
pages.

WEISS, Joseph W., WYSOCKI, Robert K., 5-Phase Project Management , A practical planning and
implementation guide, Perseus Books Publishing, L.C.L., 1992, 121 pages.

WYSOCKI, Robert K, Effective Project Management, WILEY, Sixth, 2012, 774 pages.

GOLDRATT, Eliyahu M., Critical Chain A business novel, The North River Press, 1997, 246 pages.

MARTIN & TATE, Project Management, “Memory Jogger”, GOAL/QPC

Project Management Institute, “A guide to Project Management Body of Knowledge, Fifth edition”,
2013, 590 pages

Justice, Thomas. Jamieson, David W., The Facilitators´s Fieldbook, Anacom, 1999, 460 pages

Potrebbero piacerti anche