PMA Reference Book

Page 1 of 45

PPProject MMManagement AAApproach (PMA) RRREFERENCE BBBOOK Version 2014 Holcim Technology Ltd INN - Knowledge Management Holderbank, Switzerland

PMA Reference Book

Page 2 of 45

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

PMA Reference Book

Page 3 of 45

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?

PMA Reference Book

Page 4 of 45

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.

PMA Reference Book

Page 5 of 45

2 The Holcim Project Management Approach (PMA)

2.1 Vision, Mis-sion & Ben-efits

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

. . G E T T I N G P E OP L E T O W O R K S Y S T E M A T I C A L L Y . . . . . T O U S E A V A I L A B L E K N O W L E D G E R E P E A T E D L Y . . .

. . A N D T O I M P R OV E W I T H E V E R Y P R O J E C T

The MISSION 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 BENEFITS 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.

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.

Phase II

ProjectPlanning

Phase III

ProjectRealization

Phase IV

ProjectCompletion

Phase V

ProjectEvaluation & Transfer

Phase I

ProjectDefinition

Phase II

ProjectPlanning

Phase III

ProjectRealization

Phase IV

ProjectCompletion

Phase V

ProjectEvaluation & Transfer

Phase I

ProjectDefinition

PMA Reference Book

Page 6 of 45

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.

PMA Reference Book

Page 7 of 45

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.

PMA Reference Book

Page 8 of 45

2.3 Dependencies between projects

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

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 detail when using PMA

Following the principles of all PMA phases and all steps rigidly and consistently is key to get the benefits from the approach. However, since no single project is fully identical to 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 their specific project, three project categories 1 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 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.

1. Are project costs in excess of 50,000 USD?

2. Does project duration exceed 3 months?

3. Are there more than three people involved in the project team (including the project manager)?

4. Are the Client’s expectations towards the project unclear?

5. Do we have little or no experience in creating the desired product or service?

6. Would any project failure have a strong negative impact on the project team / organization?

Overall ProjectOverall Project

Phase I Phase II Phase II I Phase IV Phase VProject Definition

Project Planning

Project Realization

Project Completion

Project Evaluation & Transfer

Phase I Phase II Phase III Phase IV Phase VProject Definition

Project Planning

Project Realization

Project Completion

Project Evaluation & Transfer

SubSub--ProjectProject

Overall ProjectOverall Project

Phase I Phase II Phase III Phase IV Phase VProject Definition

Project Planning

Project Realization

Project Completion

Project Evaluation & Transfer

Phase I Phase II Phase III Phase IV Phase VProject Definition

Project Planning

Project Realization

Project Completion

Project Evaluation & Transfer

SubSub--ProjectProject

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

Learning summary

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

Project Definition

Phase II

Project Planning

Phase III

Project Realization

Phase IV

Project Completion

Phase V

Project Evaluation & Transfer

1. Assessment of initial situ-ation

2. Stakeholder analysis

3. Search for lessons learned

4. Definition of product or service (deliverables)

5. Milestone schedule

6. Outline project organiza-tion

7. Estimation of project costs & benefits

8. Risk identification & eval-uation

9. Agreement with the Client

1. Project team set-up

2. Project Schedule

3. Communication plan

4. Project Budget 5. Project kick-off

1. Activity list

2. Project review (within team)

3. Capture of knowledge

4. Project status report

5. Client/Steering Group review

1. After Action Review (AAR)

2. Learning summary 3. Knowledge transfer

1. Hand-over

2. Final report 3. Closing meeting

PMA Reference Book

3 Details of all Steps within the 5 Phases

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

Phase I Project Definition

Phase II Project Planning

Phase III Project Realization

Phase IV Project Completion

Phase V Project Evaluation & Transfer

PMA Reference Book

3.1 Steps within Project Definition

3.1.1 Assessment of Initial Situation

OBJECTIVE AND

BENEFITS

The objective of this step is to arrive at a common understanding of the Project Definition by giving a structured explanation of the Client’s initial situation. This will help in getting a clear 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.

PROCEDURE FOR USE

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-ent’s decision to initiate the project

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.

REVIEW QUESTIONS

• Has the project team discussed the root causes, business objectives and mission together with the Client?

• Are root causes based on facts resulting from previous analysis?

• 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 with the Client. Don’t make assumptions since this might set a false direction to the project. 3 Identifying the root causes of the project is a pre-requisite to start searching for solutions. Solve!, Holcim systematic problem-solving process, can be used to identify root causes of the pro-ject, and select the most effective solutions (deliverables, 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.

Cross-reference The assessment of the initial situation provides input to the definition of the product or service (3.1.4, page 15)

PMA Reference Book

3.1.2 Stakeholder analysis

OBJECTIVE AND

BENEFITS

The objectives of this step are to identify the project’s stakeholders, to understand their level of interest and influence on the project, to find out their specific interests and to agree on 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.

PROCEDURE FOR USE

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-sults, and the level of interest they have on the project execution and/or deliverables (High, 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”

REVIEW QUESTIONS

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

• Have important stakeholders been asked about their interest in the project?

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

BENEFITS

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

PROCEDURE FOR USE

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

2. Find out similar projects within and outside the company. Identify these projects, where 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

REVIEW QUESTIONS

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

• Have both internal (e.g. databases, similar projects) and external sources been used in the search for lessons learned?

• 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

AND BENEFITS

The objective of this step is to agree on the product or service to be delivered by the project team, in order to achieve the expected business objectives. Creating a “SMART” product (Spe-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

PROCEDURE FOR USE

1. Together with the Project Client and Team, recall the project mission (defined in the as-sessment of the initial situation)

2. Describe the product or service the project team needs to deliver to achieve this mission, 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

REVIEW QUESTIONS

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

• Do the defined deliverables contribute to the achievement of project objectives?

• 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 AND BENEFITS

The objective of this step is to define the milestones that need to be achieved in order to de-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.

PROCEDURE FOR USE

1. Define milestones and make sure these are SMART.

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

3. Make the due dates of the milestones visible by putting them into a milestone schedule.

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

REVIEW QUESTIONS

• Does the milestone schedule clearly reflect the sequence of major achievements throughout the project life?

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

BENEFITS

The objective of this step is to create the project organizational chart, defining the roles and re-sponsibilities of the persons involved in the project. Additionally, the document flow, and meet-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.

PROCEDURE FOR USE

1. Check project organizations of similar projects.

2. Consider skills needed to perform different responsibilities/tasks

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.

REVIEW QUESTIONS

• Have all roles of team members (including responsibilities, time dedication and authorities) been defined and agreed within the team?

• Have all roles of team members (including responsibilities, time dedication and authorities) 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 AND

BENEFITS

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

PROCEDURE FOR USE

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

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.

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

REVIEW QUESTIONS

• Have the estimated project costs been broken down according to the main cost compo-nents?

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

BENEFITS

The first objective is to consider the risks that may influence the project. Risks typically have a negative effect on a project; however there could be risks with a positive effect (opportunities). 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.

PROCEDURE FOR USE

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-storm to complete the risk identification.

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

REVIEW QUESTIONS

• Have the major risks and opportunities been identified?

• Have all project team members considered possible risks within their area of responsibility?

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

BENEFITS

The objective of this step is to get the Client’s formal approval to launch the project. This ap-proval is based on all aspects of the project definition. The sign-off by the Client ensures 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.

PROCEDURE FOR USE

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

2. Prepare the project approval form (summary of previous steps)

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

REVIEW QUESTIONS

• Have the Client and project team agreed on the outcomes of each step in phase I?

• Have all steps of phase I been completed before signing the agreement?

• 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

AND BENEFITS

The first objective of this step is to complete the project organization as outlined during the pro-ject definition (see 3.1.6, page 17), with all the names of the people involved including the 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.

PROCEDURE FOR USE

1. Define additional persons who will be part of the team: complete the roles and responsibili-ties template (following the procedure)

2. Ensure that new team members understand the project definition as well as their specific 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.

REVIEW QUESTIONS

• Have all project team members been made aware of the project definition and their role in it?

• Is responsibility assignment matrix prepared and agreed on by the team and rele-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 AND

BENEFITS

The objective of this step is to detail the agreed milestone schedule by describing the tasks needed to reach the milestones. The project schedule provides the team with a control tool that 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.

PROCEDURE FOR USE

1. Define the tasks needed to reach the agreed milestones

2. Assign a responsible person for each task.

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

REVIEW QUESTIONS

• Are all tasks in the project defined in a clear and concise manner?

• Are all the tasks needed to achieve the milestones agreed upon with person responsible to get 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 AND

BENEFITS

The objective of the communication plan is to ensure that appropriate communication with key stakeholders takes place at the right times, in order to proactively manage stakeholders’ expec-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

PROCEDURE FOR USE

1. Retrieve the stakeholder analysis from phase I and highlight those with whom the project team will communicate during the project life.

2. Define what has to be communicated to them.

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.

REVIEW QUESTIONS

• Have communication actions been defined for the key stakeholders (high or medium level of interest and/or influence)?

• Will the subject of communication (what to communicate) and the manner of communi-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 AND

BENEFITS

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

PROCEDURE FOR USE

1. Find out if budgeting procedures exist in your company. If these do not exist, use the tem-plate provided.

2. Use the project schedule to break down the tasks into the various cost components needed to execute them

3. Define when all costs will be incurred

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

REVIEW QUESTIONS

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

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

BENEFITS

The objective of the project kick-off is to conclude the planning phase and to ensure that all as-pects are in place to start the realization phase. The kick-off meeting also helps in the process 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

PROCEDURE FOR USE

1. Invite the Project team and Client (and SG members, stakeholders if appropriate) to the kick-off meeting.

2. During the meeting, get the Client to revisit key elements of the project with the team

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)

REVIEW QUESTIONS

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

• Are the project team and Client (and/or Steering group and stakeholders) present during 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 AND

BENEFITS

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

PROCEDURE FOR USE

1. Define the period to cover (weeks)

2. Break down the tasks from the project schedule into activities (including risk monitoring and communication plan).

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.

REVIEW QUESTIONS

• Have the project schedule tasks been broken down into detailed activities at the lowest useful level for the upcoming period?

• Are activities issues proactively addressed to avoid project delays?

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

BENEFITS

The objective of this step is to review all activities with the team in order to have proactive control of project progress and to identify and address issues encountered. This requires a common un-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.

PROCEDURE FOR USE

1. Make sure all team members are prepared for the project review meeting (follow up on ac-tions, identify issues, etc.)

2. During the meeting, analyze performance, on time, cost and deliverables.

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.

REVIEW QUESTIONS

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

• Are the project review meetings properly prepared, (agenda, invitation, etc.)?

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

BENEFITS

The objective of this step is to capture knowledge as it occurs. Knowledge can be captured af-ter evaluating the progress of the project regarding budget, time and quality (in regular After 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

PROCEDURE FOR USE

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.

2. In the AARs, discuss what went well and what did not go so well. Analyze reason for the 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.

REVIEW QUESTIONS

• Are project evaluations (or AARs) carried out regularly to correct deviations and capture knowledge?

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

BENEFITS

The objective of this step is to report to the Client (including the Steering Group) on the status of the project as agreed upon in the outline project organization (documents and meetings). It 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.

PROCEDURE FOR USE

1. Select the period to report on.

2. Collect information on the quality of the deliverables, costs, time schedule, key issues and 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

REVIEW QUESTIONS

• Does the project status report incorporate the outcomes of the project review meeting?

• Does the project status report provide the right information for the Client and Steering 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 AND

BENEFITS

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

PROCEDURE FOR USE

1. Prepare the agenda and contents of the meeting (include review of risks and communica-tion plan)

2. Send (if any) the change request forms to be discussed during the meeting

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

REVIEW QUESTIONS

• Are the meeting agenda and latest status report sent out in advance to the Client /all SG members?

• Are all relevant issues discussed during the Client/SG meeting and corresponding actions & 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 AND

BENEFITS

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

PROCEDURE FOR USE

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

2. Together with the Client, agree on all actions resulting from the test to ensure that the product or service is compliant with the agreed project definition

3. Also agree on further actions to be taken to ensure proper project completion

REVIEW QUESTIONS

• Is the project hand-over conducted with the Client and relevant Steering Group members?

• Are objectives and deliverables from the project definition compared to the actual project 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 AND

BENEFITS

The objective of the final report is to summarize the delivered results, their quality, costs and time spent and compare, these with the agreement made at the definition phase of the project. 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.

PROCEDURE FOR USE

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.

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

REVIEW QUESTIONS

• Is the structure of the final report agreed on by the Client and the project team?

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

BENEFITS

The objective of the closing meeting is to formally complete the project and to officially release the project team from any further responsibility to deliver. This is also the last meeting with the 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.

PROCEDURE FOR USE

1. Prepare the agenda and contents of the meeting and send them to the attendees.

2. Calculate the overall project success (OPS)

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)

REVIEW QUESTIONS

• Has the meeting agenda been sent out to all participants in advance?

• Have the hand-over actions been completed before the meeting date?

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

BENEFITS

The objective of the After Action Review in this phase of the project is to systematically capture the experiences, focusing on performance of the team and enabling participants to discover for 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.

PROCEDURE FOR USE

1. Select participants for the After Action Review

2. Check the need to for an external or independent facilitator to support the After Action Re-view (formal AAR)

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

REVIEW QUESTIONS

• Are all relevant participants (including the Client) attending the AAR of the project?

• Is the facilitator of the AAR acting in a neutral manner (balancing positive and improve-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 AND

BENEFITS

The objective of the learning summary is to distill the learning captured during the project. It takes into account both the outcomes of the After Action Review and the knowledge captured 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.

PROCEDURE FOR USE

1. Review lessons learned captured during phase III as well as the outcome of the After Ac-tion Review

2. Decide on the most important lessons learned which can benefit future projects.

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.

REVIEW QUESTIONS

• Are lessons learned (captured during phase III and phase V) evaluated to filter out the most important learning of the project?

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

BENEFITS

The objectives of this step are to determine who will receive the lessons learned (as agreed upon in the learning summary), and to define practical actions regarding how the lessons 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.

PROCEDURE FOR USE

1. Upon completion of the learning summary, define who can benefit from the lessons learned.

2. Decide on the most effective mechanism to transfer lessons learned within your depart-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

REVIEW QUESTIONS

• Has the team clearly defined the knowledge to be transferred, to whom, how and by whom?

• 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 Elements of work needed to achieve a task. Each task is broken down into activities. An activity nor-mally has a responsible, an expected duration, and an expected start and finish date. Activity list Step of the project realization phase where the tasks are broken down into activities. After Action Review (AAR) An After Action Review is an end-of-action evalua-tion (review) for teams and/or persons responsible and involved in the action to be evaluated. It is used during phase V; however it can also be used during other phases. Agreement with the Client Summary of the project definition that has to be explicitly approved by the Client and the project manager, in order to proceed with the project. Assessment of initial situation The first step of the definition phase. In this step, the root cause for starting the project, the objectives related to the project and the mission of the project are defined. Assumptions Factor considered true, certain or real for plan-ning purposes. They need to be checked or validated before approving the project, since they could pose risks to the project. Business Objective A business result or target to be achieved through the project. It should be aligned with the long-term corporate goals as described in the Strategic and Business Plan and the Operational Road Map (ORM). Capture of knowledge Step of the project realization phase to explicitly identify and store lessons learned for future use in Phase V or to enable immediate transfer if required. Changes Agreed adaptations to the project content (definition and planning). Changes to documents as part of the project planning can be made by the project team. Changes to documents as part of the project defini-tion have to be made by the Client/Steering Group.

Client Representative of the end users with the authority to take decisions on behalf of his/her organization during project phases. Closing meeting Step of the project completion phase to formally release the project team from the responsibility to deliver the defined product or service. Communication plan Step of the project planning phase to describe what is to be done to provide important stakeholders with the right information and involve them at the right time. Contingency reserve A reserve (e.g. time or money) that allows for an alternative strategy to be used to ensure project success if specified risk events occur. Control The process of comparing actual performance with planned performance, analyzing variances, evaluat-ing possible alternatives and taking appropriate action and/or decisions as needed. Cost See project cost. Critical path The sequence of tasks which determines the earli-est date of project completion. The critical path will usually change as tasks might be completed ahead of or behind schedule. Although normally calculated for the entire project, the critical path can also be determined per milestone. Definition of product or service Step of the project definition phase to clearly de-scribe what will be delivered (product / service) to the Client as a result of the realization phase. End users The organization that will make use of the product / service delivered by the project team. Estimation of project costs An approximation of project costs and benefits. This approximation should always include some indica-tion of accuracy. The level of accuracy improves as

GLOSSARY Holcim PMA Reference Book

the project concept is developed (preliminary, con-ceptual, feasibility, order of magnitude or definitive) Final report Step of the project completion phase to summarize the comparison between the project definition agreed upon and the actual product or service, ac-tual costs and degree of schedule compliance. It also includes hand-over summary, learning sum-mary and further recommendations related to sus-tainability of the product or service. Hand-over Step of the project completion phase used to de-scribe the activities that ensure that the product or service is accepted by the Client. It is also in this step that outstanding actions are explicitly agreed upon between the project team and the Client. Issue A point or matter in question, which the project team has to manage to completion by assigning actions or making decisions. Knowledge transfer Step of the project evaluation and transfer phase to define the mechanism and actions to ensure that transfer of the lessons learned to the appropriate recipients takes place. Learning summary Step of the project evaluation and transfer phase to distil the key lessons learned derived from the After Action Review and the capture of knowledge. Lessons learned New knowledge acquired during the project. It should describe what to do or avoid to ensure com-pletion of a specific aspect of the project Milestone A significant achievement that summarizes the completion of an important set of tasks or the com-pletion of an important event in a project. It is the means by which the Client and Steering Group will monitor progress against plan. Milestone schedule A schedule which shows the milestones of the pro-ject. Mission A statement of what the project team aims to do to reach the defined objective. Also called scope statement or team assignment.

Outline project organization Step of the project definition phase. First definition of the hierarchical set-up of the project including roles, responsibilities and authorities of the Steering Group, Client, project manager and identified team members. It also outlines document flow and meet-ing schedule. Performance indicators Measurable values to visualize the status of the progress in realizing the product or service. Phase A collection of logical steps to achieve properly con-trolled project progress. Often but not necessarily, each phase is active at any time. Problem A deviation from the expected performance. It is detected when there is a gap between what is hap-pening (actuals) and what should be happening (plans). Product or service The items that the project team will deliver to the Client. They are the means by which the business objectives will be achieved. Project A one-time, multi-task job that has clearly defined starting and ending dates, a specific scope of work to be performed and a budget to achieve the de-fined business objectives. Project budget Step of the project planning phase to describe the project costs in detail to allow cost control during the realization phase Project charter A document created before the project definition phase, that describe the initial understanding of the client and project manager of the new product or service to be delivered, including: root causes to start the project, business objectives, project mis-sion, deliverables, high-level milestone schedule, high-level cost, high-level risks and required project team members Project completion (phase IV) The fourth phase of the Project Management Ap-proach (PMA) which ensures that the ownership of the product or service is properly transferred to and accepted by the end users, so that the project team can be released from their responsibility to deliver.

GLOSSARY Holcim PMA Reference Book

Project costs The actual costs incurred by the project team to realize the product or service and to manage the project. Project definition (phase I) The first phase of the Project Management Ap-proach (PMA), used to build a relationship with the Client and to gather sufficient information to ensure an agreement can be reached with the Client. Project evaluation and transfer (phase V) The fifth phase of the Project Management Ap-proach (PMA) used to evaluate the way of working with the Client and the project team and to ensure that distilled lessons learned are being transferred to enable future improvements in projects. Project Failure Projects that are terminated with or without mutual consent between the Client and the project team. Projects that fail do not deliver the expected busi-ness objectives and consequently they waste re-sources. Project kick off Step at the end of the project planning phase which ensures that the project team is fully aligned to commence the realization phase. Project life cycle The collection of the 5 phases defined by the Pro-ject Management Approach Project Management Approach (PMA) The Holcim Project Management Approach which defines the principles under which projects within the responsibility of Holcim management will be conducted. Project manager The person accountable for delivering the agreed product or service, and responsible for the day-to-day management of the project. Project organization The reporting structure and organizational chart that details "Roles and Responsibilities". Project planning (phase II) The second phase of the Project Management Ap-proach (PMA) to detail the project as outlined dur-ing the project definition phase in terms of the tasks that are to be planned for, the costs involved, as well as to form the project team and to describe the way of working during the rest of the project.

Project realization (phase III) The third phase of the Project Management Ap-proach (PMA) to ensure that delivery takes place in accordance with the agreement made during the project definition phase; includes project reviews within the team and with the Client to properly con-trol and report on progress. Project review (within the team) Step of the project realization phase to assess the status of the project with the project team and to assign actions and make decisions to address iden-tified issues. Project schedule Step of the project planning phase to describe tasks within the project, together with the associated time scale in which they are planned to be undertaken. Project status report Step of the project realization phase to summarize and communicate the status of the project perfor-mance indicators (cost, time and quality), achieve-ments, plan for the next period issues and correc-tive actions taken, and support required from the Steering Group. Project team Individuals involved in the execution and the man-agement of the project work Project team set-up Step of the project planning phase where the pro-ject organization is further outlined and the team building process is started. Risk A risk is an uncertain event or condition that, if it occurs, could have a: • Negative effect: e.g. partial or complete failure

to achieve the business objectives, overrun of budgeted cost and time limits, etc

• Positive effect: e.g. exceeding targets/business objectives, lower cost or shorten realization time, etc

Risk identification and countermeasures Step of the project definition phase to create a prior-itized list of negative (and positive) risks and define actions to avoid (or exploit), transfer (or share), or mitigate (or enhance) their potential impact. Risk owner Individuals accountable for the management of in-dividual risks (See "Standardized Approach to Risk Management"). Risk profile The risk profile comprises the total of all risks with their significance and likelihood.

GLOSSARY Holcim PMA Reference Book

A risk profile can be graphically represented by a risk map (individual risks placed in a diagram with the two axes "Significance" and "Likelihood"). Risk management Risk management is the sum of all actions taken with the aim to identify and cope with risks. Every member of the project organization assigned to perform a certain task is accountable for manag-ing the risks related to this task. Root cause The deepest underlying cause(s) triggering the oc-currence of a specific effect. Schedule See project schedule. Search for lessons learned Step of the project definition phase to incorporate previous experience into the definition phase. Standardized approach to risk management The standardized approach to risk management comprises the systematic identification of and cop-ing with risks. Its core element is a process consist-ing of the following steps 1) risk identification, 2) analysis of risk sources/drivers/influences, 3) measurement of significance and likelihood, 4) evaluation of actual and definition of target risk pro-file (including definition of respective actions), 5) assurance that risks are managed in order to achieve target risk profile, and 6) continuous moni-toring of development of risk profile and monitoring of implementation of action plans.

Standardized risk management is the responsibility of the Steering Group. Individual members of the Steering Group or of the Project Team are ac-countable for management and monitoring of indi-vidual risks (Risk Owners). Stakeholders Internal or externa individuals and / or organizations (or parts of organizations) who have an interest in or can be affected by the project. Influential stake-holders provide input for project deliverables.

Stakeholder analysis Step of the project definition phase to identify all stakeholders and interact with them to determine their interest in the project and to define measures to be taken in order to incorporate those interests in the project (mainly in deliverables). Steering Group Individuals representing the end users; they provide the financial resources and must approve and agree on project definition, budget, plans and changes to the project definition. Client/Steering Group review Step of the project realization phase to assess the status of the project with the Client and/or Steering Group, assign actions and make decisions to ad-dress identified issues and risks. Step A component of a phase. All steps have to be fin-ished to complete the phase of a project. Task A task is a cohesive unit of work in a project (one that is not too big nor too small to be tracked). A milestone is broken down into tasks. Normally, a task will be broken down into a series of activities to enable proper monitoring of progress. Team norms Guidelines that the team agrees to follow as it con-ducts its work. Most newly-organized teams find it effective to start out with an initial set of norms with the understanding that these will need to be re-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-rience. Workflow (meetings and documents) Set of interrelated meetings and documents to en-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

project kick off meeting

project definition meeting internal

milestone schedule outline project organization

estimation of project costs and benefits

project approval meeting

hand-over

after action review

learning summary

closing meeting

search for lessons learned

agreement with the client

activity list

project review meeting

action and decision log

project status report

capture of knowledge

Client/ steering group review meeting

action and decision log

hand-over list

project schedule

project budget communication

plan knowledge

transfer

project definition meeting

with client

Phase I Phase II Phase III Phase IV Phase V

Involvement

Cl ient

Final report

project team set-up

2

4

1 3

3

high

low

involvement project team

high

low

Document related to a meeting

Input indicator Document Meeting

Explanation of figures Executed if the steps of the project planning show that the “agreement with the client “ is incorrect / incomplete

1

Executed if the steering group (incl.. the client) decides that the “agreement with the client” needs to be updated / changed

2

Executed if the project team decides that one of the steps in the project planning needs to be updated / changed

3

Executed if the project team decides that the “activity list” needs to be updated / changed

4

Change / update indicator

Explanation of change / update indicators

stakeholder analysis assessment of initial

situation

risk identification and countermeasures

definition of product or service

new projects

Explanation of who is involved

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 to Project Risk

Management

The standardized approach to project risk management consists of a 6-step process:

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

Every member of the project organization who has been assigned a certain task is accountable for 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-countable for management and monitoring of indi-vidual risks (Risk Owners).

Application of Standardized Approach to Risk Management in Individual Projects

Project Management Phase I - Project Definition

- Performance of Risk Management Process Steps 1 to 5 by Steering Group, in a form ade-quate to the project (participants to the pro-cess, level of detail, degree of formalization)

- Determination of standardized risk manage-ment activities in the other Project Manage-ment Phases (II to V)

- Starting with the standardized approach to risk management in parallel with the project allows 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.

Project Management Phases II to V:

- Performance of Risk Management Process Step 6 (responsibility of the Steering Group)

- Standardized procedures as defined by the Steering Group in Phase I (e.g. formal reviews of Risk Management Process Steps 1 to 5, formal reporting requirements etc.)

- Additional activities as defined by Project Man-ager (e.g. application of Process Steps 1 to 6 on sub-projects)

1. Identify

risks

2.Sourceof risks

3.Measure

risks

4.Evaluate

risks

5.Manage

risks

6.Control

risks

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