JEREMIE AVEROUS

Practical
Project Control
Manager
Handbook

From Back-Office Manager

To Trusted Project Strategist
© Jeremie Averous & Project Value Delivery Pte Ltd
First Edition - 2016
Published by Fourth Revolution Publishing, Singapore
A trademark of Fourth Revolution Pte Ltd
23D Charlton Lane, Singapore 539690, www.FourthRevolutionPublishing.com
All rights reserved.

Except for short excerpts used for illustration or educational purposes, which then shall reference the
original book, no part of this publication may be reproduced, stored in a retrieval system or
transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or
otherwise, without the prior permission of the Publisher, Fourth Revolution Publishing –
[email protected]
While the publisher and the author have used their best efforts in preparing this book, they make no
representation or warranties with respect to the contents of this book and specifically disclaim any
implied warranties of merchantability or fitness for a particular purpose. No warranty may be created
or extended by sales representatives or written sales material. The advice and strategies contained
herein may not be suitable for your situation. You should consult with a professional where
appropriate. Neither the publisher nor the author shall in any event be liable for any loss of profit or
any other commercial damages, including but not limited to special, incidental, consequential, or
other damages.
URLs have been checked at the time of writing of this book and the publisher has no responsibility
for the persistence and/or accuracy of these links.
In this book, the alternating of gender in grammar is utilized. Any masculine reference shall also
apply to females and any feminine reference shall also apply to males.
This book has been sponsored by Project Value Delivery, a leading
consulting company in the field of Project Management for Large, Complex
Projects.
www.ProjectValueDelivery.com - [email protected]

This book is available both in paperback format and Kindle e-format, through all e-bookstores
including Amazon, Barnes & Noble, etc.
Contact us for bulk orders or customized editions!
ISBN: 978-981-09-5985-2
ISBN e-book: 978-981-09-5986-9
First print – Print-On-Demand, February 2016 / worldwide availability on all e-bookshops through
LightningSource.
 We can Customize this
Handbook for your
Organization
We have observed that organizations find great value to have their own
internal handbooks to cover Project Control issues. These full-color,
custom-branded handbooks can be spread to a wide population.
Thanks to our publishing partnership, our generic handbooks have been
successfully customized and printed in many hundreds of copies for some
major global Project-driven businesses.
Conducted after a careful review of the organization’s particularities, and
tailored to respond to your needs, such a customization includes:
Specific systems and processes,
Specifics of the industry and construction context.
Contact us for a customization Project.

Get Advanced Training delivered

The best practice concepts of this handbook are best spread in your
organization through training programs. We develop and deliver trainings
globally based on the contents of this handbook, and customized to your
particular needs. We are recognized as Registered Education Provider by
the PMI®.
Contact us for a training Project to bring your organization to the next level
in terms of Project Control.
Contact
Contact @ ProjectValueDelivery.com
 In the Same Series

1. The Pocket Guide for those Daring Enough to Take Responsibility

for Large, Complex Projects
by Jean-Pierre Capron
2. Project Soft Power, Learn the Secrets of the Great Project Leaders
by Jeremie Averous
3. Practical Cost Control Handbook for Project Managers, a Practical
Guide to Enable Consistent and Predictable Project Forecasting
by Jeremie Averous
4. Practical Project Risk Handbook for Project Managers, a Guide to
Enhance Opportunities and Manage Risks on Projects
by Jeremie Averous
5. Advanced Scheduling Handbook for Project Managers, a Practical
Navigation Guide on Large, Complex Projects
by Jeremie Averous with Thierry Linares
6. Practical Project Control Manager Handbook, from Back-Office
Manager to Trusted Project Strategist
by Jeremie Averous

And more to come…

Discover the latest publications and more on:
www.ProjectValueDelivery.com
 Contents
FOREWORD BY JONATHAN CRONE
PREFACE
INTRODUCTION TO PROJECT CONTROL
Why Project Control?
A practical handbook
The handbook’s structure
Who is this handbook for?
CHAPTER 1: PROJECT CONTROL IN LARGE PROJECTS:
COVERAGE AND REACH
Introduction
Project Control Coverage
Project Control in the Project Organization
Project Control Manager Profile and Career Path
Summary of Project Control Roles
Conclusion
CHAPTER 2: PROJECT CONTROL GOLDEN RULES
CHAPTER 3: PROJECT START-UP ESSENTIALS
Introduction
Objectives of Proper Project Start-Up
Overall Project Start-up
The Importance of Clear and Detailed Project Objectives
Additional Optional Project Start-Up activities for International or Consortium Projects
Conclusion
CHAPTER 4: THE BUILDER ROLE: PROJECT CONTROL
SETUP ACTIVITIES
Introduction
Objectives of Project Control Setup
Establishing a Comprehensive Project Baseline
Project Control-Specific Setup Activities
The Educational Role of Project Control at Project Start-Up
Additional Project Control Setup in the Case of a Consortium
Conclusion
CHAPTER 5: THE DATA ASSURANCE ROLE
Introduction
Project Control Processes –Measurement of Actuals
Other Key Measurement Areas Managed by Other Functions
Data Assurance for Advanced Indicators
The Reporting Cycles
Dealing with Management Pressure
Conclusion
CHAPTER 6: THE COMMUNICATION ASSURANCE ROLE
Introduction
Establishing Internal Interfaces between Project Control and other Functions
Essential Internal Interface Meetings
Project Control within a Consortium
Project Control and EPC contractors management
Conclusion
CHAPTER 7: THREE ESSENTIAL TRANSVERSE PROCESSES
Introduction
Management of Change
External Interface Management
Procurement / Contracting Post-Award Package Management
Conclusion
CHAPTER 8: THE CONSISTENCY ASSURANCE ROLE
Introduction
Key Consistency Points between Project Controls Processes
Root Causes of Discrepancies
Consistency Management Best Practice
Assessing Consequential Impacts
Identifying and Assessing Weak Signals
Re-baselining
Conclusion
CHAPTER 9: INDEPENDENT DATA CHECKS AND PROJECT
REVIEWS
Introduction
Challenging data with reality: Independent Data Checks
Independent Communication Checks
Independent Project Health Checks and Peer Reviews
Conclusion
CHAPTER 10: DEVISING CUSTOM INDICATORS, USING
VISUAL DASHBOARDS AND WAR-ROOMS
Introduction
Devising Indicators
Project Data-Mining
Producing and Using Visual Dashboards
War-Rooms
Conclusion
CHAPTER 11: THE STRATEGIST ROLE
Why Are Only the Project Manager and the Project Control Manager Focusing on the
Medium / Long Term Perspective?
How to Fulfil the Project Strategist Role
Developing and Implementing a Contractual Strategy
The Project Strategist Analytical Toolkit
Conclusion
CHAPTER 12: PROJECT CONTROL SOFT POWER
Introduction
Taking into Account Cultural Differences
Initiating Workshops
Checking the Project Team Health
Conclusion: Always Remember a Project is a Human Adventure
CHAPTER 13: THE PROJECT CLOSE-OUT PROCESS
Introduction: Why Project Close-Out is a Process
The Project Close-Out Process Starts from the Project Start-up Onwards
Close-Out Phase Execution
Handover of the Remaining Project Liabilities
Proper Closure of the Project as a Human Adventure
Conclusion: Project Close-Out, an essential success factor
CHAPTER 14: PROJECT CONTROL FORENSICS
Introduction
Level 1 checks – Data Assurance
Level 2 checks – Support to decision-making
Level 3 checks – Strategic Support
Conclusion
CONCLUSION: THE PROJECT CONTROL MANAGER, A
TRUSTED ADVISOR TO THE PROJECT MANAGER
APPENDIX 1: PROJECT PROPOSAL AND HANDOVER
CHECKLIST
APPENDIX 2: PROJECT CONTROL SETUP CHECKLIST
APPENDIX 3: MONTHLY PROJECT CONTROL CHECKLIST
APPENDIX 4: PROJECT CONTROL CLOSE-OUT CHECKLIST
ABBREVIATIONS AND GLOSSARY
ACKNOWLEDGMENTS
TABLE OF FIGURES
INDEX
 Foreword
by Jonathan Crone
Integrated Project Controls is my passion! When I first started my
career as a Quantity Surveyor I found myself in an industry that focused
more on fixing the problems that had occurred than addressing the potential
problems that may arise. Fortunately I worked for a company that believed
there was a better way of delivering projects and was introduced to the
principle of Integrated Project Controls.
Since that time I have worked in several project environments, across
different sectors, in different countries and within different commercial
arrangements. Whilst not all of my projects have been delivered using the
Project Controls approach, I think it is safe to say that it is no coincidence
that the most successful ones all applied these techniques.
On reflection, I believe that success was at least partly due to the rigour
that Project Controls brings in setting up the project, developing an
integrated structure and providing transparency in giving a ‘Candid
reflection of Reality’ as to the health of the project. I have no doubt that
whilst the end product may be very different in different sectors, the actual
process of Project Management hardly varies and the Project Controls
approach has a place in the delivery of any project.
I was first attracted to Project Controls by the trend curves, enabling
the reader to quickly see the course of history and extrapolate potential
outcomes. However, in starting to practice Project Controls I soon learnt
that there was a lot more depth to it. In fact, my first real test of
implementing Project Controls on a major project proved so difficult that at
first I wondered if it was worth the extra effort! However, once all of the
processes and tools were established I soon saw the benefit of managing a
Project rigorously using the principles of Project Controls. To this day I still
hold that project as my benchmark for success.
 Implementing successful Project Controls is as much a cultural
challenge as it is a technical one. In this book, you are taken through a
pragmatic practitioner’s journey of how to establish and run Project
Controls to give reliable management information enabling timely
management intervention. As well as giving practical guide to the technical
issues that need to be addressed in establishing Project Controls, such as
data structures, systems and the need for ‘Accurate not Precise’
information, it also gives invaluable guidance to the ‘softer’ cultural and
leadership issues that a Project Controls Manager may face, including some
key ‘watch-outs’ in the relationships that need to be built with the Project
Team.
The Project Control Manager Handbook is both informative and easy
to read. It would sit comfortably in any Project Delivery professional’s
bookcase.

Jonathan Crone MBA, BScHons, RICS, FAPM

January 2016
Director of the Programme Management Office, High
Speed 2 Ltd
Formerly Global Head of Project Controls, Subsea7
 Preface
This book complements our Project Control trilogy, which covered
Cost Control, Project Risk and Schedule Management. It pulls all these
disciplines together with Contract Management and describes the tasks of
the Project Control Manager on sizeable Projects.
We believe this is the first book published that specifically addresses
the tasks of the Project Control Manager during the Project execution
lifecycle. Initially conceived as a short summary, it has grown to a full-
blown reference handbook under the influence of many comments received
on the draft versions.
Project Control Managers are a somewhat rare occurrence in the
Project world. While the full-time position is only justified on sufficiently
large or complex Projects, it is then essential in terms of support to the
Project Manager in particular if the incumbent is able to fill the strategist
role.
Unfortunately, I am still encountering too many Project Control
Managers focused on data crunching and reporting, with no time for real
analysis and forward thinking. Project Control Managers’ duties have to
include setting up the processes and systems to minimize the time spent on
these mechanical tasks during Project execution. This allows more time on
analysis, forecasting, scenario planning and strategy development and
implementation.
This handbook gives practical advice on how to achieve this ambition,
in particular with a clear roadmap for Project start-up which is the essential
moment when the future capabilities of Project Control will be determined.
Invest at Project start-up, and you will reap the fruits during the entire
Project; if you don’t, you will spend the rest of the Project miserably trying
to play catch-up as some parts of the Project will spin progressively out of
control.
A proper Project setup might involve, from time to time, investing in
Project-specific tools and software if they are not provided by the wider
organization; this minor investment (relative to the size of large Projects)
will be more than offset by the gain in terms of control, visibility and
forecasting ability for the Project Manager.
Moreover, the most successful Project Control Managers have a
substantial Soft Power capability. Because their role is essential in assuring
proper communication within the Project and with key stakeholders they
need to be able to communicate and listen effectively. They also need to be
able to feel the pulse of the team and raise issues related to possible
dysfunctions. This softer side is often neglected or downplayed, yet it is
what will ultimately make the Project Control Manager an effective
strategist and irreplaceable support for the Project Manager.
I hope that this book will inspire more Project Control Managers to
apprehend their role as strategists and become the trusted advisors to the
Project Managers. This will in turn certainly improve the success ratio of
their Projects.

Jeremie Averous
Singapore, January 2016
 Introduction
to Project Control
Why Project Control?
A Project is like an intercontinental sailing
navigation. When executing a Project, one needs to
define the goal and a plan to reach it; then, fit out a
vessel with the appropriate quantities of fuel and
supplies to last for the long voyage, and finally,
recruit the right crew.
When the vessel has finally left the shore to
begin the uncertain voyage towards a new
continent, left to the forces of the sea, the currents and the winds, there are
three fundamental navigation questions that require an accurate response,
on a regular basis:
What is our current situation compared to the baseline?
Where are we heading to (if we continue according to the
present trend)?
What adjustments do we need to do to come back on course
(baseline) if we find we deviate?
The outcome of these three questions leads to a decision that needs to
be taken consciously - in the present circumstances, whether or not to
amend the current course of the vessel, or the sails’ configuration.
In our previous handbooks on Cost, Schedule and Risk we have
examined how to answer to the three fundamental navigation questions in
those respective areas:
Where are we? What is the level of the resources? What is
the actual progress?
Where are we heading to with the current trend? Will we
reach before we exhaust our resources? Do we have
 enough contingency reserves remaining for uncertainties?
What adjustments do we need to do to reach our goal in a
reasonable time and not starve before we arrive? Can we
recover to the baseline or do we need to figure out a new
plan?
In this handbook we explore how to bring all these aspects consistently
together to inform the decision of the Captain.
Project Control as a discipline is about bringing together in a consistent
manner the actual and forecast information from Cost, Schedule, Risk and
Contract Management so as to inform the decisions of the Project Manager.
On Large, Complex Projects this warrants a full time senior position on the
Project Management Team.
This role is quite similar to the particular position of the onshore
routing team in modern high seas racing, which serves to advise the Skipper
on the best trajectory, taking into account available weather and sea-state
information.
Project Control should not just be seen as an under-deck or onshore
back-office position. It needs to be in the midst of the action, and become
the strategist of the team. In reality the Project Control Manager might be
the only member of the Project’s senior management outside the Project
Manager that is able to Project himself in six months to one year time while
most of the others concentrate on the immediate tasks at hand.
The ambition of this handbook is thus to formalize the role of Project
Control in Projects, as no other specific book dedicated to that topic seems
to exist. It intends also to highlight the need for Project Control Managers
to grow into their strategy and long-term guidance role to become an
effective trusted advisor to the Project Manager on these long distance
expeditions.
A practical handbook
This handbook has been specifically written in the particular context of
Large and Complex construction Projects.
Contrary to the previous handbooks on Cost, Schedule and Risk, this
handbook intends in a way to be a ‘starters’ guide to Project Control, due to
the lack of existing literature on the subject. At the same time it tackles also
relatively advanced topics, consistently with the experience level of Project
Control Managers.
We will not repeat here the specifics of Cost, Schedule and Risk
Management and refer to our other handbooks as necessary for the specifics
in those fields. This explains why this book is less thick than might have
been expected, as it only focuses on the added value of the Project Control
Manager.
Because we recognize that readers might want to refer directly to
specific Chapters depending on the issues they are facing, the Chapters
have been written in a self-contained manner with reference to other
relevant Chapters and our other specialized Handbooks for the details. This
creates some concept repeat and cross-referencing which are done on
purpose.
Our expectation is that well worn-out copies of this handbook will be
found on every Project Control Manager’s, Project Manager’s and Project
Sponsor’s desk.
The handbook’s structure
Chapter 1 introduces and defines Project Control, describes its scope
and its fundamental principles. Keeping with the structure of our other
handbooks, Chapter 2 then exposes overall key Golden Rules for Project
Control which will be detailed in further Chapters.
Chapters 3 and 4 cover the essential moment of Project start-up.
Chapter 3 discusses the general challenges and describes the Project start-
up process in general. The specific role of Project Control, what we call the
‘builder’ role is described in Chapter 4: setting up the required processes
and structures to properly keep the Project under control during its
execution. It is absolutely essential to build tension in that area from the
first day of the Project.
Chapter 5 to 8 cover the ‘conventional’ roles of Project Control during
Project execution. Chapter 5 covers data collection and processing, where
the Project Control Manager plays the role of data assurance manager.
Chapter 6 deals with assuring proper internal communication during Project
execution. Chapter 7 covers essential transverse processes for Project
success, in particular Management of Change, external Interface
Management and post-award supplier and contractor control. Finally,
Chapter 8 elaborates on the need and the means to maintain consistency
between Cost, Schedule, Risk and Contract Management at all times.
Chapter 9 describes how independent Project reviews and data checks
should be used to the benefit of the Project, as an independent line of
defence.
Chapter 10 tackles a recent advance in team coordination, sometimes
called ‘visual management’. Providing the team with relevant, real-time,
visually expressive dashboards that can be shared is a very effective manner
to contribute to proper decision-making and team alignment.
Chapter 11 then exposes the strategist role of the Project Control
Manager and how this role should develop in the Project. This is where the
Project Control Manager really becomes the trusted advisor to the Project
Manager.
Keeping with our Project Soft Power approach to Project leadership,
Chapter 12 delves into the softer aspects of Project Control. It is not
possible to properly control a Project while ignoring these aspects which
greatly influence Project team effectiveness and ultimately, Project success.
Finally, a short Chapter 13 explains the few steps that need to be taken
from the onset of the Project for a successful Project close-out: contrary to
common understanding, Project close-out is a process, not just a moment in
the Project.
As in our other handbooks, Chapter 14 summarizes how to assess
effectively the quality of the Project Control process. The Chapter contains
a number of easy-to-use reference checklists for Project reviews. They are
complemented by useful checklists for Project tender/feasibility study, start-
up, close-out and monthly Project Control reviews in the appendices.
Who is this handbook for?
This handbook is explicitly for Senior Executives of Project-driven
organizations, Project Sponsors and Directors of Projects, Project
Managers, Project Control personnel and all those that aspire to become
Project Managers or Project Control Managers.
 Chapter 1:
Project Control
in Large Projects:
Coverage and Reach
Introduction
Project Control as a stand-alone discipline is often only formalized on
large Projects. On smaller Projects, it is generally the Project Manager
himself that effectively performs its duties, which are much lighter because
those Projects remain simple.
However depending on the nature of the Project and its contractual
setup, it might be useful to appoint a Project Control Manager for smaller
Projects in particular if:
the Project is executed on a reimbursable or detailed rates
basis, which require a lot of precise administration,
When it can be expected that the Project Manager will have to
deal with specific complexity e.g. difficult stakeholder
management, number of and distance between different
Project offices.
In general, except on the smallest Projects it is a good investment to
appoint a Project Control position to free up the Project Manager’s time,
even if it is a shared position at the portfolio level.
Project Control can have a very different scope depending on the
organization’s history. We will first describe what we consider should be
covered or not, then we explain how the position of Project Control
Manager fits in the Project organization, and finally what should be the
profile of Project Control Managers.
Project Control Coverage
Based on our experience, Project Control should cover the
following disciplines Coverage:
Cost Control,
Schedule Management,
Project Risk Management,
Main Contract Management (for Contractors),
Document Management.
Contract management is sometimes considered to be a separate
discipline that warrants a senior direct report to the Project Manager.
However we believe that Project Control can only deliver its best value
when the three dimensions of the famous Project triangle (Cost, Schedule
and Scope management) are covered. Main Contract management actually
deals with Scope, hence we believe that it should be included in the remit of
Project Control. Contract management also includes accountability for
proper flow-down from the Main Contract to Purchase Orders and
Subcontracts, and review of deviations to these requirements during the
procurement process; this has an essential link to Project Schedule and Risk
Management.
Document Control as a process typically responds both to Project
Control needs (physical progress measurement and scope control) as well as
Quality Management needs and depending on the local preferences can be
assigned to either function. However, because of the potential consequential
effects of lack of performance control during engineering phase, it is
recommended that Document Control be in the remit of Project Control to
foster proper oversight. This practice has shown to deliver substantial value
in EPC Projects.
Project Administration can sometimes be added for convenience to the
Project Control scope.
Functions recommended not to be included in Project Control
Procurement is sometimes merged together with Project Control, and
the sum is then often called Project Services. This generally happens in
organizations that consider procurement to be only a contracting exercise.
Experience in Large, Complex Projects Management (or ‘EPC’ Projects)
shows however that there are many additional competencies and processes
that are necessary in the field of Procurement (also called Supply Chain
Management). They range from strategic sourcing to supplier qualification
and post-award management. Therefore we believe that Procurement should
be promoted to a function reporting directly to the Project Manager at the
same level as Engineering and Construction, and should not be included
within the remit of Project Control. Including Procurement activities will
also distract the manager in charge from his strategist role, because of the
numerous operational constraints associated with the day-to-day
management of suppliers and contractors.
Because of the confusion between Accounting and Cost Control as
functions (refer to our Cost Control Handbook), some organizations tend to
merge the Finance/ Accounting functions within Project Control. This is not
a good idea because:
Accounting should serve as an independent line of defence
from Cost Control, looking at the Project from another
perspective,
The Project Control Manager would be distracted by
numerous financial reporting requirements, bank
administrative requests and invoice payment issues,
Accounting is run more effectively at the legal entity level
than on the Project level.
We thus recommend keeping Accounting as a separate corporate
function. While there needs to be a strong link with Project Control, it still
needs to remain separate.
Project Control Terminology
Project Control is also often called Project Controls or Project Services.
We have chosen to use ‘Project Control’ in the singular rather than
‘Project Controls’ because we want to highlight the fact that control
overall needs to be exercised on Project execution, and not just the
implementation of a series of juxtaposed controls. Control needs to be
comprehensive.
‘Project Services’ is often used when Procurement is part of the scope. It
is also sometimes used when just Contract Management is added to Cost,
Schedule and Risk. To avoid misunderstandings with organizations that
use ‘Project Services’ in a very broad sense, we have preferred to use
‘Project Control’ in this handbook.
Project Control in the Project
Organization
Project Control Managers are generally not nominated at the feasibility
study stage except when it might constitute a Project of its own due to its
size and complexity. For Contractors, Project Control Managers’
involvement in tenders is often limited to contributions on some aspects of
the future Project administration – although deeper involvement could be
helpful to prevent future issues during Project execution such as:
Payment milestones poorly defined or not precise enough (e.g.
reference to a large set of deliverables instead of a single
deliverable), leading to substantial delays in payment and cash
flow consequences,
Administration clauses too onerous without real added value
in particular on reimbursable / re-measurable / rate-based
scopes,
Contract schedule build-up not aligned with the contractual
strategy and with low resilience,
Underestimation of Project Management and Engineering
costs – or unrealistic slashing of those costs during the course
of negotiations,
Inadequate requirements to long lead items suppliers in terms
of reporting (as those awards tend to be prepared during the
feasibility stage itself).
Appendix 1 details some key control points not to be missed at
tender/feasibility study stage.
The Project Control Manager role is thus generally focused on actual
Project execution from Project Start-Up to Close-Out. Actually, Project
Control Managers are often the ones ‘shutting off the lights’ as they are
amongst the last ones to be demobilized from Projects after their final
closure.
The Project Control Manager should report directly to the Project
Manager, as shown in the following typical organization for Large Projects.
In this chart we use the terminology ‘Package Managers’ to designate those
‘Scope Owners’ in charge of significant sections of the Project scope.
Sometimes these are called ‘Project Managers’ while the overall Project
Manager is called ‘Project Director’.

Figure 1: A Typical Large Project Organization

In very large Projects there is a tendency from the managers in charge of
separate packages to request for dedicated personnel to cover Cost and
Schedule. This is not recommended when there is a single Main Contract or
investment:
Cost and Schedule have a number of components common to
the Project that cannot be split by packages, so that an
overview is needed,
Cost Contingencies, Schedule Buffers, revenue can only be
managed practically at the Project level,
It is more efficient to specialize Project Control personnel by
type of cost or activity (i.e. by function such as Engineering,
Procurement, Construction) than have them cover vertically all
activities within a Package,
Provided a proper breakdown structure is implemented from
the beginning of the Project across these disciplines, it is
entirely possible to report cost per package and to filter out
schedule by package as well, while maintaining the required
overall Cost model and Integrated Project Schedule for the
entire Project.
The recommended organization is thus to have the Project Control
team brought together directly under the Project Control Manager, and not
spread in each package.
Even when Project Control personnel (generally Cost or Schedule) is
assigned to a fabrication or construction site or to any other site outside the
Project office, it is also recommended that they still report functionally to
the Project Control Manager even if they may be placed operationally under
the Construction Manager, to make sure that reporting is immediate and
candid and that relevant control requirements are effectively implemented.
Finally, decisions might be required for the general interest of the
Project that might penalize one package and benefit another. An overall
shared Project Control Function is thus essential to perform a neutral
analysis and support decision making at a Project level by the Project
Manager.
Project Control Manager Profile and
Career Path
Project Control Manager Career Path
Project Control Managers have widely different origins and career
paths. This is due to the fact that this specialty is not formalized in most
organizations outside Project execution itself. There is also no ‘junior’
Project Control position as this position does generally not exist explicitly
for small Projects. Hence Project Control Manager is a position that does
not have a straightforward career path to develop into.
Project Control Managers have often the following origins:
An experienced Project Control personnel from either the
Cost, Contract or Schedule function that develops to take the
overall Project Control role,
A Project Manager with experience in smaller Projects that
takes such position as part of her growth and development to
later take Project Management responsibility on larger
Projects,
A Tendering Manager with experience in bidding and closing-
out Project contracts commercially.
This list is not limitative and we have observed very successful Project
Control Managers with widely different career paths, as long as they fulfil
the necessary profile and experience.
Irrespective of their origin, it is important that Project Control
managers evolve into the role and avoid staying too much into their
specialty of origin. This can sometimes be a drawback when Project
Control Managers stem from a specific Project Control function.
Project Control Manager Competency Profile
A Project Control Manager should have the following technical
competencies and experience:
Actual Project experience, so as to be able to appreciate the
issues faced during the execution of Projects,
 Sufficient industry experience to understand what in general
the drivers of Projects in this particular industry are (this point
is extremely important and warrants site visits and high level
technical training),
Sufficient knowledge of the disciplines of Cost, Schedule,
Risk and Contract management and how they are interlinked
to be able to direct the work of his team. This does not require
that he is an expert in all those disciplines, but requires that he
understands the main issues and can challenge the specialists
as to where the effort should be focused,
Sufficient understanding of commercial aspects through
substantial previous Client exposure, including an
understanding of how to account for the Client’s mid- to long-
term drivers,
Sufficient understanding of corporate financial reporting
aspects and constraints for an effective interface with the
Accounting and Finance function,
Some understanding of business IT systems setup and
implementation so as to be able to direct the development and
implementation of those systems where they would be
missing.
If the candidate does not have all the necessary experience, which often
happens for newly promoted Project Control Managers, these technical
competencies can be enhanced by training, mentoring and coaching at the
start of a Project.
If training is required at the start of the Project, it is essential that the
Project Control team is supported by an experienced Project Control
Manager or Project Control function to ensure an early set up of the Project
Control suite of systems, functions and processes which are essential for
robust and efficient control during execution. In addition, site visits are
highly recommended to understand the practicalities of Project execution in
the particular industry and context, and understand the particular issues
arising from future vendors’ manufacturing facilities, worksites and
countries.
Complementing technical competencies, softer competencies are also
required. They are actually essential for an effective Project Control
Manager – technical competency alone will not suffice, because a large part
of the role involves creating a communication network to be aware of
everything that happens on the Project and detect Weak Signals. He also
needs to influence the other functions into contributing to Project Control.
The soft competencies that are needed include:
Good presentation skills so as to be able to:
convey a clear image of the Project status and
effectively support the Project Manager in reporting
and stakeholder management,
define and execute visual management strategies
regarding dashboards presented to the team,
Good listening and interpersonal skills to exchange
continuously information with the Project team members,
Good negotiation skills so as to support the Project Manager in
contractual negotiations including Change Order and Claims,
Facilitation skills so as to ensure that the necessary workshops
and conversations required to make Project Control successful
happen in the most effective manner,
Sufficient management skills to effectively coordinate the
work of his team,
Experience of exposure to senior management and key
external stakeholders, so as to be able to prepare and deliver
effective messages.
These competencies, if not present at the onset of a Project, can also be
developed using training and coaching.
Project Control in the Organization
The home of Project Control Managers in the organization varies. This
population is generally very small and of significant seniority. In addition,
except in rare cases, the role of Project Control Manager is only a stepping
stone in a career, so that there can be expected to be a substantial turn-over
in the population.
The recommended functional reporting line in the organization is to the
Director of Projects, either directly or through a functional Director of
Project Control depending on the size of the population. This will ensure
that the focus of Project Control is on Project execution. It is also consistent
with the general career path of Project Control Managers growing into
Project Managers. Other functional reporting lines e.g. to Finance,
Commercial etc. have drawbacks in that they will tend to put emphasis on a
single component of Project Control whereas to be fully effective, Project
Control needs to be encompassing in a comprehensive manner all its
functions for the benefit of Project’s execution.
Summary of Project Control Roles
The Project Control Manager can be seen as the keeper of the Cost –
Schedule – Scope triangle. Hence most of his activities will revolve about
maintaining control and consistency across these three dimensions, both in
terms of Baseline, Actual and Forecast.
In a Project, the main responsibilities of Project Control are the
following (they will be developed in the subsequent Chapters):
Maintaining consistent Project Cost Model and Integrated
Project Schedule that reflect accurate actual data and proper
forecasts and reflect the latest Project scope as per Contract
management activities,
Determining the minimum contingency reserve amount as per
the organization’s approved calculation method,
Maintaining the required conversations about Opportunity and
Risk and making sure they are reflected in the updated Project
Risk register and associated action plans,
Producing timely relevant contractual information, notification
and correspondence; and in general, managing Contract
administration activities and coordinating Change Orders
issues,
Ensuring that internal Management of Change and internal/
external Interface Management activities interface properly
with all the relevant Project Control disciplines,
Coordinating all Project periodic reporting activities (internal
to the organization and external to Client and other
stakeholders), including both Actual and Forecast in all
dimensions,
Establishing visual dashboards and making sure they are
posted and updated continuously in the Project office and/or
the Project war-room,
Organising and managing the Document Control process in
conjunction with the Quality function in particular when it
comes to the development of as-built data,
Developing appropriate scenario analysis when relevant to
establish the best course of action when the Project is faced
 with alternatives,
Developing and proposing a contractual strategy and relevant
updates to the Project execution strategy to the Project
Manager.
In addition, depending on the Project’s organization and relevant other
organizational parameters, the Project Control Manager can also assume the
following additional roles:
Managing directly all internal Management of Change and
internal/ external Interface Management processes,
Organizing and managing the Project’s administrative support
(Project assistants team, travel arrangements, office
arrangements etc.),
Organizing the receipt, review and dispatch of the official
Project correspondence, including assignment and tracking of
actions,
Setting-up and managing relevant Project-specific information
management systems with a focus on Project Control
(excluding specialized software for Engineering or
Procurement).
Conclusion
Project Control is an indispensable function in Large Projects.
Reporting directly to the Project Manager, it covers a number of control
processes that taken together, aim to give an accurate view of the Project’s
current and forecast situation.
We recommend that Project Control covers Cost Control, Project Risk,
Scheduling, Contract and Document Management.
Project Control Manager is a senior position that is often a step in a
career: Project Control Managers rarely remain in that position for a large
number of Projects. Because of the breadth of competencies required, as
they take the role, they often need training or coaching in some areas to be
fully effective. This is often underestimated in the midst of the scramble to
get a Project started, leading to significant losses in effectiveness that could
have easily been prevented. Thus a thorough review of the technical and
soft competencies of a newly appointed Project Control Manager is a must,
together with supervision and mentoring by more senior personnel that have
performed the role in previous Projects.
 Chapter 2:
Project Control
Golden Rules
The main objective of Project Control is to enable the Project
Manager and the Project Sponsor to take decisions derived
from an accurate current knowledge and understanding of
reality, with the aim to reach a successful Project outcome.
From this broad objective, a number of Golden Rules describe the basic
requirements of Project Control Management.
In all instances, 14 Golden Rules need to be followed when it comes to
Project Control.
1. Accountability: Covering the entire Project scope, designated
‘Scope Owners’ take ownership for their Schedule, Cost and
Risk (including update, forecast and action-taking). The
Project Manager is ultimately accountable for the entire
Project. Project Control supports and challenges ‘Scope
Owners’ and raises issues of consistency and consequential
impacts of events.
2. Alignment with clear Project Objectives: establishing clear
detailed Project Objectives is an essential pre-requisite as it
will inform the build-up of the Project baseline, monitoring
system, and strategies.
3. Urgency of building Control at Project Start-Up: Very
significant effort has to be devoted at Project start-up to
establish a full baseline including breakdown structure,
together with efficient data generation, flow, exchange
protocols and compilation with the aim to minimize later data
crunching efforts and leave sufficient time to analysis.
4. Maintenance of a consistent and comprehensive Project
Model: Project Control Manager is responsible for the
maintenance of a consistent Project Model describing
accurately the Actual situation together with a full Forecast
reflecting the latest knowledge of the Project Team.
5. Candid Reflection of Reality: The Project Model must
reflect candidly the reality of the Project progress status and
associated re-forecast, however difficult or annoying this
reality could be.
6. Immediacy principle: It is essential to reflect in the Project
Model significant new variances as soon as their occurrence is
known (e.g. internal or Client’s instruction to proceed), at least
in terms of order of magnitude, even if their exact final value
has not been fully assessed.
7. Keep space for Forecasting activities: successful Project
Control minimizes actual data gathering and crunching, and
leaves sufficient time to forecasting activities.
8. Weak Signals and Consequential impacts identification: as
part of its consistency assurance role, the Project Control
Manager’s key role is to keep abreast of Weak Signals and to
detect possible consequential impacts of changes or variances
and needs to ensure that they are understood and
communicated.
9. Maintain effective Management of Change and External
Interface Management: those two transverse processes are
essential in maintaining control of the Project and the Project
Control Manager must ensure that they work effectively, with
the appropriate interfaces with the rest of the Project.
10. Monitor Project team effectiveness and health: effective
teamwork is a prerequisite for Project success. Making sure
the Project team demonstrates at all times proper alignment
and effectiveness is essential. When needed, the Project
Control Manager should foster focused workshops to ensure
alignment and commitment.
11. Challenge data with respect to Reality and implement
independent data-check and Project reviews: always
challenge reported data by ensuring an independent check
 program including visits to sites and independent audits and
measures. This should also include external reviews and peer
reviews.
12. Develop relevant Key Indicators and visual dashboards:
constantly develop, update and renew a limited set of both
long term and short term indicators to measure performance
and inform Project decisions. One of the best ways to foster
team alignment is to produce and update visual dashboards
posted on the workplace that include relevant key indicators.
13. Develop and implement a Main Contract strategy: from a
few months into the Project, the Project team should be able
to verbalize a clear Main Contract execution strategy, taking
into account cultural aspects, and demonstrate that it is
subsequently consistently implemented.
14. Develop and implement a Project Close-Out process from
Project start-up onwards: to ensure effective close-out, a
specific process needs to be implemented throughout the
Project, from the start-up onwards.
 Chapter 3:
Project Start-Up Essentials
Introduction
A proper Project start-up is essential to the success of a Project. It is an
investment which will redeem itself many times over the course of Project
execution. However it is always a hurried phase which too often leads
Project Managers to not spending enough time on key set-up areas, or even
by-passing them.
This may be due to particular operational constraints or specific
priorities set by stakeholders. These forgotten areas are also sometimes
those where Project Managers feel less comfortable, as under stress we all
tend to retreat to those activities which are the most familiar.
The role of the Project Control Manager is essential in supporting a
comprehensive set-up of the Project, and making sure the minimum
requirements are achieved to keep the Project under control in the future.
In this Chapter we cover the general process of Project start-up. In the
next Chapter we will address in particular the actions required from the
Project Control Manager in this process.
Objectives of Proper Project Start-Up
The objectives of Project start-up should, in general, be the following
(in that order):
1. Recovering all relevant data and knowledge from the
feasibility study / tender phase – this includes a
comprehensive set of data together with softer knowledge
about the Project and Client context,
2. Formalizing the Project Objectives and related KPIs,
3. Establishing an effective Project core team, which includes:
Mobilizing relevant personnel,
Defining organization, roles and responsibilities,
Organizing a proper working space (Project Office) in
a format that enhances collaboration,
Establishing adequate processes for information
management and decision-making,
Ensuring that the team reaches an effective team
performance level as quickly as possible,
4. Detailing and confirming the Project execution plan and
strategy, and establish the relevant baseline (Scope, Cost,
Schedule, Master Document Register, Procurement Plan,
manpower plan). The baseline also includes a consistent
breakdown structure used throughout the Project for all data
gathering and processing,
5. Establishing clear accountabilities in terms of cost and
schedule according to the Project breakdown structure,
6. Establishing adequate communication and information
protocols within the Project and with the key Project
stakeholders (which will include Senior Management, Project
sponsor, Discipline Managers in the organization as well as
Client/Owner and main vendors and contractors). This
involves in particular the implementation of:
A consistent data structure across all functions to
allow for proper data exchange and comparison
consistent with the baseline setup,
Relevant periodic reporting protocols and forms, as
well as the development of a relevant stakeholder
management strategy.
Overall Project Start-up
The following figure summarizes our recommended overall Project
start-up process.

Figure 2: Project Value Delivery's Project Start-up Process

Key to the success of the process is that it needs to be shaped by the

Project Management Team itself (hence be performed when the Project
Manager’s direct reports will have been designated). The best format is a
series of short and effective workshops. The reasons the workshop method
is better and more effective than doing it in small committee or by having
someone going around the team one-by-one are the following:
Confirming/ designing Project Objectives and execution
approaches as a team fosters teambuilding, which is key to
reaching quicker an effective teamwork,
Workshops will allow to leverage on the knowledge and
expertise of all members of the Project Management Team,
thus increasing significantly the usable depth of knowledge,
Workshops bringing together all the functions will allow to
identify and develop a shared understanding of priorities, an
alignment on ways of working and clear responsibilities and
therefore smoothen execution and interfaces,
Workshops with diverse members of the Project Management
team will foster creativity and it is not rare that significantly
better approaches are developed at that occasion for Project
execution.
The Project Manager needs to coordinate the series of workshops and
be present and active. He generally delegates the preparation, facilitation
and recording of the workshops to the Project Control Manager. The
reasons are the following:
During Project start-up the Project Manager will generally be
extremely busy in stakeholder management and ensuring
proper team mobilization, hence needs to rely on the Project
Control Manager for the proper organization of these start-up
activities,
Most of the workshop outcomes will take shape in one of the
main tools used by Project Control.
This will require the Project Control Manager to demonstrate his soft
skills and manage workshops properly. A more detailed description of how
to organize effective workshops is included in Chapter 12.
The Importance of Clear and Detailed
Project Objectives
Detailed Project Objectives are essential for Project success. Our
experience is that Project Managers are rarely entirely clear about their
Project Objectives, beyond the boilerplate expectation to deliver ‘on time,
schedule, budget and with the expected quality’.
Project Objectives are a set of statements that describe in a nutshell,
what the purpose of the Project is and what are the priority areas that will be
considered when evaluating the performance of the Project execution at
close-out. They differ from the concept of Project strategy in that strategy
describes the manner Project resources are intended to be used to reach the
Objectives.
Some aspects are always required in any Project Objectives, such as the
objectives in terms of Health, Safety, Environment Protection and Quality.
Objectives in terms of social impact, local content etc. can also be required.
In the rest of this section we will concentrate on those objectives related to
Project execution success.
Staying only on the topic of Cost, the following questions must be
clarified: How do all the following expectations fit together? Are they
consistent? Which ones are the most important, priority ones, and which
ones can take a back seat?
Overall Project Forecast and final financial expectation,
Expectations in terms of cash flow during the Project and
possible financing requirements,
Acceptance of risk / temporary bottom line degradation for
possible additional revenue,
Changes in the spending profile over time,
Relative importance of financial performance at reporting
period end compared to Project’s closure.
Similarly in the context of Schedule:
Overall Project Delivery Date,
Expectations in terms of possible intermediate constraints,
 Possibility of acceleration, and change of resource type and
level,
Real or artificial constraints on resources,
Optimization of key resources’ utilization (e.g. at portfolio
level) versus minimization for the single Project.
In the context of Project Risk:
Level of management reserve/ contingency and expected
release policy,
Project risk profile expectation (Low, Medium and High risks),
Portfolio risk contribution (in particular for shared resources),
Any residual process/ R&D / qualification risks.
In the context of Contract (scope)
Level of acceptance of changes from the Owner,
Level of acceptance of internal changes,
Potential of Changes to the Owner’s schedule and/or site
access conditions,
Policy as to acceptance of additional work prior to formal
signature of a Change Order/ acceptance of approvals in
principle.
In the context of Client satisfaction:
Objectives as to Client relationship (Contract Holder, sponsor,
Client’s top management)
General level of relationship to be sought with the Client
taking into account reputation, possible repeat business
expectations etc. (this might even include accepting lower
profit on the present contract for the sake of additional
business opportunities, or might influence the Change Order
strategy).
Finally how do all the requirements fit into the ‘Cost, Schedule, Scope’
triangle?
Expectations regarding Liquidated Damages and other cost
opportunities or penalties linked to schedule,
Expectations in terms of changes and Project growth or
possible termination and transfer of part of the scope to
another contractor.
 The Project Manager, at the onset of the Project, should have a clear
roadmap of what are the main objectives of the Project, and what are less
important aims. This roadmap should be explained in 10-15 statements that
define what exactly is being expected from the Project.
It is not because the Project executes a very detailed Contract, which is
supposed to reflect the expectations of the Client, that Project Objectives
are not important: there are many other stakeholders, and even the
Contractor and Client expectations often need to be expressed more
precisely.
Indeed, most Project Objectives need to be shared together with the
main stakeholders of the Project at its onset. This worthwhile exercise will
allow the Project Manager to uncover potentially hidden issues and
motivations and to get support for objectives of common interest (such as
safety, quality and stakeholder management).
The role of the Project Sponsor is here absolutely essential in terms of
expressing his own objectives, and helping identify the objectives of other
key stakeholders.
Unfortunately a proper Project Objective setting process is often
skipped at the start of Project execution because of the pressure of
operational issues. It is essential that Project Managers take the time to
formalize these Projects objectives in detail, in particular because those will
inform how to respond to inevitable changes and unexpected events during
Project execution.
Should a proper objective setting process not happen due to the
pressure of events, the Project Control Manager must insist that such a
process be implemented as it is an absolutely essential prerequisite to the
proper subsequent Project setup.
Additional Optional Project Start-Up
activities for International or Consortium
Projects
As part of the Project start-up phase, the following actions may have to
be taken either by the Project itself or by the wider organization, in
particular in the case of a Project executed as part of a Consortium:
Setting-up Project-specific legal entities if not already done at
proposal / feasibility stage, in particular in-country entities for
local content or local payment reasons, or for incorporated
Joint-Ventures,
Setting-up dedicated Project bank accounts, guarantee
facilities (Bank Guarantees, Letters of Credit) and cash loan
lines guaranteed by the contract,
Establish relevant Power of Attorneys and delegations of
signature.
Conclusion
This Chapter describes the essential steps that need to be followed for
Project start-up in general. They are all meaningless without a proper
definition of robust Project Objectives that meet the expectations of the
Project Sponsor and of the other essential stakeholders of the Project.
Establishing clear Objectives sometimes requires asking tough questions to
obtain clarity.
The contribution of the Project Control Manager to a structured and
comprehensive Project start-up process is absolutely essential, in particular
because the Project Manager will often be overwhelmed by other demands.
 Chapter 4:
The Builder Role:
Project Control Setup Activities
Introduction
This Chapter concentrates on the specific activities of Project Control
setup during the overall Project start-up.
It is essential that this setup is performed comprehensively. Proper
setup means that the odds of keeping control of the Project and anticipating
issues are much higher. As such, it is an investment in Project success. This
phase should thus correspond to a phase of high intensity for the Project
Control team.
A Project Control start-up checklist is provided in Appendix 2.
Objectives of Project Control Setup
A first objective of the Project Control Setup is to produce a
comprehensive and consistent baseline against which all Project
contributors will work. Importantly this baseline includes proper data
structuring for all relevant data on the Project. The baseline will serve to
identify deviations. Should they happen, the objective will primarily be a
recovery back to the baseline.
The second objective is a successful set-up that will ensure quick,
accurate and effective data gathering, transmittal and treatment during the
course of Project execution. This will ensure minimum retreatment (prone
to delays and errors), quick evaluation of deviations to the baseline and
more time for analysis and forecasting. These objectives include:
Continuously recover and manage all information required for
the Project according to a data structure and communication
protocols that covers operational needs as well as data
consistency needs (ref. Chapter 5 and 6),
Ensure that a consistent data structure is always implemented
– and updated consistently if needed - throughout all functions
and processes (Cost, Schedule, Engineering, Procurement,
Construction, Finance) as needed for the Project (ref. Chapter
7 on consistency).
Effectively produce relevant and up-to-date dashboards so as
to inform the Project Team decision-making (ref Chapter 10),
The ultimate objective is that the Project Management Team (with the
strong support of the Project Control Manager) can then have time to focus
time and effort on value-added activities such as:
Re-forecasting very regularly the Project outcome based on the
data and information available,
Effectively implementing scenario analysis, and more
generally, refining, updating or modifying the Project
execution strategy (ref Chapter 11),
Dealing quickly with changes, unexpected events and other
surprises that occur inevitably during Project execution.
 This setup process must be seen as putting on significant effort at the
beginning to have a smoother Project execution. In reality it is all about
creating space through an early investment for doing the most important
work later in the Project.
Because the Project Control Manager is the only member of the Project
Management Team that has the full transverse view on the Project he is best
placed to organize this setup work. For individual functions this means
often gathering and updating data that might not be immediately useful for
their own process, but that are needed in the interest of the entire Project.
The Project Control Manager must thus build the relevant overall data
architecture and be able to impose certain data gathering and updating
activities to various Functions. This often requires a lot of explanation,
facilitation and leadership. The Project Manager must support this process
actively.
When the Project is not setup properly, the Project Control team will
spend its time chasing information and trying to get a picture of doubtful
accuracy of the actual situation through various reconciliation processes,
with no time left for re-forecasting or for any strategic thinking. It then
becomes a boring clerical work with low value added. At the same time
tension and stress with increase as it will be impossible to respond to the
needs of the Project Manager. Thus this situation is often accompanied by
low morale and high turn-over in the Project Control team. Unfortunately it
is quite impossible to recover from this situation in the middle of a Project
due to the lack of a consistent data structure. The only way is to do a full re-
baseline of the Project using a dedicated task-force working with high focus
and intensity; still it is always difficult to recover the historical information
while the Project progresses at full speed. It thus can only be performed in
stages of relatively low Project activity and might even require the Project
activities to be suspended for a while.
From the Project Control Perspective the Project start-up phase may be
the time in the entire Project where the most work intensity is required. It
thus needs to start without delay and with full availability and commitment
from the Project Control team. This investment is essential, will repay itself
multiple times and cannot be neglected.
In certain circumstances, Project-driven organizations have setup
dedicated “Project Start-up Teams” that fly-in to support that phase during 2
to 3 months and then move away to another Project setup. This ensures
consistency of practice across the organization and gives assurance on the
quality of the setup itself. It is a best practice that we consider could be
usefully spread to more Project-driven organizations.
Establishing a Comprehensive Project
Baseline
Establishing a proper baseline that is fully self-consistent is a central
activity of Project start-up. It is a very substantial activity due to its reach as
it requires the collaboration of all Project functions under the supervision of
Project Control.
A baseline is not just a schedule or just a set of data. It addresses the
entire Project configuration and in particular,
The most important component of a Project baseline is the
underlying data structure.
The baseline needs to include the following elements that need to be
made fully consistent – this set is often called the Project configuration:
Contract and included relevant specifications,
Project execution plan and strategy,
Contractual constraints (e.g. specified dates and windows),
Breakdown structures (CBS, WBS, CTR for engineering etc.),
Scope, including all deliverables:
document registers (with planned dates),
procurement plan (with planned dates),
Schedule, including the fully linked and weighted Integrated
Project Schedule, plus detailed schedules where relevant e.g.
for process engineering, construction,
Physical progress measurement rules,
Project-specific procedures and processes (e.g. document
management, procurement procedure including Client
involvement, invoicing, handover etc.),
A full Project Cost Model, including manpower plans,
A full set of Project Risk deliverables (Risk Register,
quantitative analysis).
Realism and Resilience of the Baseline
The baseline needs to represent a realistic view of Project execution,
because variances to the baseline will be the first warning sign of slippages
and other Project execution issues. This is not always possible when there
are commercial issues at stake, in particular in terms of schedule. However
Projects that are executed with a baseline that is not realistic will inevitably
face difficult issues, and this is not recommended beyond some easily
manageable tweaks.
The baseline also needs to be as resilient as possible to foreseeable
internal and external events. This is provided through:
Providing ample float on non-critical activities (reinforced
through the convergence planning process – refer to our
Schedule Handbook), and stress-testing the schedule using
Schedule Risk Analysis,
Providing for sufficient cost contingency commensurate with
the level of execution risk (refer to our Risk Handbook).
In any case, it is the responsibility of the Project Control Manager to
ensure that at any one time there is a single, consistent reference baseline
applicable on the Project, throughout all functions and activities. This can
sometimes be a challenge in terms of discipline, because when faced with
deviations, people may be tempted to amend the reference on their own for
their particular scope.
Producing the Baseline
Because Project execution is now contemplated from an actual
execution perspective by a wider team there will generally be changes or
adjustments compared to the plans initially contemplated at proposal stage.
In addition, key components of the baseline will also need to be reviewed
and approved by the Project Sponsor and the Client.
The baselining exercise thus needs to be done carefully and is always a
massive work that is coordinated by the Project Control Manager. It will
take time to finalize a fully consistent Project configuration. For Large
Projects it is generally achieved 2 to 3 months after Project kick-off, and
can sometimes take longer, due to the fact that many key elements generally
need to be approved by the Client.
Re-baselining if needed during Project execution due to a significant
change of circumstances that makes reference to the initial baseline
inadequate will require as much effort and create temporary control
challenges. This is covered further in Chapter 8.
Project Control-Specific Setup Activities
The main objectives of the setup phase for Project Control include:
1. Recover all relevant data from the tender/ proposal stage and
check it against the actual Contract to provide a proper
reference to the Project,
2. Establish a proper Project execution baseline consistent with
the Project execution strategy, associated with a relevant level
of resilience as assessed by statistical analysis. This includes
the design of suitable data breakdown structures,
3. Establish appropriate baseline change control processes,
4. Assign accountability for cost and schedule throughout the
team in a comprehensive manner (to ‘Scope Owners’) through
a formal endorsement process,
5. Establish contractual consistency and necessary requirements
for suppliers / vendors and contractors.
6. Establish relevant processes for updating and reporting on the
actual situation (Actual Costs, physical progress etc.) and
forecasts from external stakeholders with the aim to obtain
accuracy while minimizing cumbersome information
gathering work, so as to leave more space for analysis,
7. Implement collaboration systems to enhance communication
and collaboration within the team, as well as the gathering of
important progress and status information,
8. Implement the breakdown structure and data gathering
requirements in all relevant systems throughout all Functions,
9. Establish / enhance / adapt the relevant Information
Technology systems to ensure that key processes will remain
under control.
The Project Control specific start-up activities are detailed in the figure
on the next page. The following sub-sections detail these processes (due to
its importance the baseline production has been addressed above).
Project Control kick-off meeting
A detailed Project Control setup plan must be defined by the Project
Control Manager. Links with other Project start-up activities and workshops
need to be taken into account in the development of the Project Control
setup plan.
Consistently with the nature of the Project setup phase, it is important
to establish a shared understanding of the setup work to be performed
amongst the Project Management Team. The Project Control kick-off
meeting needs to emphasize the objectives of this phase and the detailed
plan that is envisaged for its performance, including the contribution that is
expected from each function. Visible support of the Project Manager is
recommended. It is preferably held early in the Project, as soon as the
Project Management Team is gathered and in a position to discuss Project
Objectives.
 Figure 3: Project Value Delivery's Project Control Setup Process

Project Reference – Data Recovery and Check

The Project Reference includes the initial budget, schedule (high level
schedule or key dates) and risk profile.
Recovery of the detailed data from the tender/ feasibility stage is
mandatory. The level of detail will vary from case to case depending on the
time that was spent on this phase.
To recover this data in detail it is essential to have a hand-over meeting
with the tender/ feasibility team. Access and recovery of all the existing
working files and archives is important, because the tender/feasibility team
will be disbanded and access might not be warranted when the data is
needed in a few months’ time. Best practice is to copy that data within the
Project’s databanks, except if the organization’s setup guarantees it will
remain accessible by the Project in a well-defined location where the data
integrity is maintained.
Before the start of a Project there are often last minute adjustments
from the various decision-making meetings involving high-level managers
– either from last minute Contract negotiations, or from remarks from the
Final Investment Decision meetings. These adjustments can be very diverse
and include changes to estimated budgets (including margins and
contingencies), changes as to responsibilities and risk allocation, scope
transfers, payment terms, key dates etc. For the Project execution phase it is
important to have a Project Reference that is consistent with the latest scope
and decision from these instances. A reconciliation work needs to be done,
in parallel to a full Contract Review to check that no substantial area was
forgotten in the Project Reference.
In case a substantial discrepancy is discovered between the
tender/feasibility budget and schedule and what the Project needs to deliver,
a proper approval process must be implemented to get the difference agreed
and included in the Project Reference. In some instances the discrepancy
cannot be included in the Project Reference due to stakeholder management
issues, but it must then be formally acknowledged internally as to the basis
on which the Project performance will be measured.
Management of Change and External Interface Management
The key transverse processes of Management of Change and External
Interface Management are generally very closely interlinked (a Change
often creates an Interface issue and an Interface issue often generates a
Change). Changes (internal or external) should only be implemented after
they have been approved. An assessment of their consequences in all
aspects of Project execution is a prerequisite. These processes are detailed
in Chapter 7.
Assignment of Accountability and Endorsement of Budget and
Schedule
 This process is particularly important (but often overlooked) because it
will identify responsibilities for forecasting across the entire Project scope,
in a comprehensive manner. It involves:
Assigning accountability for all sections of the scope in terms
of Cost, Schedule and Risk to ‘Scope Owners’, after having
consolidated the scope breakdown (WBS/CBS); practically
this happens through the systematic assignment of each Work
Package in the WBS/CBS to a single accountable person
within the Project organization,
Getting endorsement of individual budgets and schedules at
the Work Package level by the ‘Scope Owner’,
Developing and implementing a thorough Contract awareness
program, including for each Project position, a mandatory
knowledge level of certain sections of the Contract.
Establishment of Requirements for Suppliers and Contractors
The requirements for suppliers and contractors need to be prepared
early in the Project, before critical purchase orders or contracts for services
are proposed for bid. Their preparation needs to be coordinated by Project
Control in close relation with Procurement.
The following describes in general what those requirements should
cover. It is important however to scale those requirements to the size and
criticality of the supply or service and taking into account the type of
contract (lump-sum or reimbursable). In particular, the full requirements
will generally only be needed for a limited number of key suppliers and
contractors. The full set of requirements is unfortunately too often used
across the board which is very onerous, in addition to creating many non-
conformances that need to be managed.
Finally, some of those requirements might be negotiated by the
suppliers or contractors. In that case, it is necessary for Project Control to
be involved in the review of the deviations requested, in particular on the
following two aspects:
Assess the deviation from the Project risk profile standpoint,
Assess whether the deviation jeopardizes the overall control of
the Project.
 The requirements to suppliers and contractors should include (in
addition to the standard contractual clauses of the organization):
Relevant Contract flow-down from the main contract, or
general requirements applicable to all suppliers and
contractors. Key areas directly related to Project execution
often include:
Cash flow considerations as to payment terms (back-
to-back with Main Contract to avoid any squeeze
situations),
Management of Changes (and associated risk
apportionment),
Liabilities,
Penalties for delays,
Free access to the worksite,
Warranty terms and duration,
Mutual indemnity for consequential losses.
Clarity on the relevant technical specifications and documents
that are applicable for each contract or purchase order, and
how any update will be transmitted,
Relevant progress measurement standards to be used
consistently by all suppliers and contractors. These include
often:
Standards for progress measurement e.g. for
document production stages, manufacturing stages,
etc.
For contractors,
Definition of a WBS/CBS subset to be
imposed on their schedule for integration /
interface into the overall Project schedule,
Specification of specific physical progress
indicators and weighting system to be applied
to a networked schedule.
Contractual administration requirements regarding:
correspondence,
transmittals,
technical document review and management of
comments,
 management of Technical Queries and similar
exchanges,
reporting mechanism,
management of Change Orders and Claims under the
contract,
final acceptance criteria and management of any
outstanding work (punch lists),
Relevant interface management system between suppliers,
contractors and the Project (when the Client’s system does not
apply), that includes as a minimum:
Relevant interface issue identification form and
database,
Proper communication on interface issue for all
parties, and associated response workflow,
An escalation mechanism in case interface issues
cannot be resolved.
Clear as-built documentation requirements (format and
timing). Associate the final payment to the as-built
documentation delivery.
These requirements are generally brought together in a document
called “special terms & conditions” that complement the “standard terms &
conditions” of the organization.
Protocols for external communication, updating and reporting
All the actions below should be conducted with the aim to minimize
administrative information collection tasks and focus on value-added
analysis and action designing.
Establish communication and sharing protocols for all
applicable specification documents and Project basic data,
including proper transmittal of any update,
Establish communication protocols with the Client (document
review, reporting, Change Order process, technical queries,
etc.),
Establish communication protocol requirements for suppliers
and contractors (document review, reporting, progress
measurement, changes, technical queries etc.). This needs to
include the review of some of those documents by the Client
 as well in addition of the Project. This aspect often requires
significant work to ensure smooth operation,
Establish the reporting routines for the organization, Client etc.
Collaboration systems implementation
Most organizations will offer basic collaboration tools (e.g. email,
shared drive within an office). New technologies are now available that can
enhance significantly the effectiveness of the Project team’s collaboration,
in particular when it is spread between remote offices.
Those include, from basic to advanced:
A Project-specific intranet where news and specific key
indicators / visual dashboards can be posted, that opens
whenever a team member opens its web browser,
Shared drives / file locations,
An instant messaging and video conferencing tool,
Action tracking systems that rely on actions generation from
the document management system, correspondence
management system, and various other processes (e.g. risk
management), and send automatic reminders to contributors/
action owners,
Possibility to collaborate online for document generation, up
to the availability of document generation software
concatenating contributions from various origins,
Shared databases receiving contributions from various origins
that can serve as a basis for the reporting data, and that can be
accessed remotely from the field, including possibly via
mobile devices,
Wikis and other similar collaborative knowledge gathering
tools,
Social networks where individual news, pictures and
observations can be shared between team members.
Collaboration tools can significantly enhance the team alignment and
efficiency, in particular when remote contributors are included. This area is
too often left unattended whereas modern technology allows cheap and
quick implementation of tools that can very significantly enhance the
team’s productivity. An implementation plan needs to be developed that
also takes into account the organization’s policy regarding confidentiality of
information. For example, cloud-based tools can be used for information
with limited strategic significance, while the aggregated Project cost data
would typically be kept locally on a server with limited outside access.
A good check for the adequacy of the collaboration tools that are
available to the team is to explore whether some groups have taken the
initiative by themselves to use external non-approved tools (e.g. instant
messenger, social network, unofficial databases or document exchange
platforms etc.). If that is observed, action must be taken to provide the
Project team with the relevant solutions. This will ensure both security and
accessibility of the data.
Project Control should thus make sure that a minimum of collaboration
tools are available and operating, and propose improvements as needed.
Systems implementation for Project Control
Systems required for Project Control complement and sometimes
overlap collaborative systems, however they need to be reassessed from the
control perspective.
Configure as required the associated processes and systems
that serve as input / output into Project Control such as:
CBS in accounting systems for invoiced amounts,
payments and accruals,
Progress measurement systems for engineering
(document control system), including CBS input and
reporting,
Commitment systems for procurement, including CBS
and cost types input,
Commitment systems for logistics and construction
including CBS and cost types input.
Make remote approvals available even for team members
travelling, so as to ensure timely approvals, including for
urgent operational issues. This covers approvals for
documents, correspondence, commitments etc.
Develop and implement any missing software system. This
depends on the maturity of the organization and the
organizational set-up of the Project (even in mature
 organizations, some Projects are conducted in Joint-Ventures
or consortium which requires to implement specific systems),
in particular as a minimum:
An electronic document and correspondence
exchange platform that avoids manual import and
exchange of such documents,
An electronic document control system including
review and comment workflow, time-phasing
(planned, forecast and actual), transmittal and
physical progress reporting capabilities, and allowing
proper exchange and workflow of documents for
Supplier and Contractor documents including double
review by Project and Client,
A correspondence management system including a
module for action assignment and tracking,
A procurement system including proper recording of
all types of commitments, proper change control on
commitments (including commitments generated
outside the office on site), etc.
An accounting system that incorporates the necessary
Project information (CBS) and report accordingly,
A time - recording system to allow detailed cost
tracking and internal resource utilization analysis,
A database-based cost control system (for large
Projects only),
A scheduling system, including capabilities for
versioning and archiving of all previous updates,
Risk management software (cost and schedule
statistical analysis),
Reporting systems for construction sites that allow
transverse analysis across the duration of the work,
Additional applications and tools designed to
minimize administrative work where required e.g.
travel commitment tool, logistics commitments etc.
We observe that even in the most mature organizations, a thorough
review of the entire Project scope will often warrant the development of ad-
hoc processes or systems to fill some gaps. If the organization is mature,
those gaps will be minimal; in some instances, the full systems setup needs
to be redeveloped. Sometimes, manual processes can suffice, however on
large Projects, simple databases are often needed to ensure data
comprehensiveness and consistency.
The Educational Role of Project Control
at Project Start-Up
The Project Control Manager must ensure that relevant data is properly
and timely recorded, and that individual functions do not implement
changes in their systems that might jeopardize the overall data streams. In a
large measure he needs to educate the entire team about their fundamental
contribution to Project Control. This generally happens at two levels:
to the entire Project Team,
and to the Project Management Team.
Education of the Project Team
The Project Control Manager must intervene regularly in town-hall
meetings, and in particular during the first overall kick-off meeting with the
entire Project team, to emphasize the importance of timely data recording.
Full, visible Project Manager backing is essential to reinforce the
message and to position the Project Control function at the appropriate level
in the eyes of the team.
It is important to underline at that occasion that systems have been
designed with the overall Project in mind, which will require data to be
recorded that might not be directly useful for the user, but that is needed for
the full Project. Compliance with the Project processes is thus a must.
The Project induction pack for newcomers must also include relevant
instructions and communication on the importance of data recording and
adherence to the Project’s specific processes.
Additional communication in the form of posters and other available
communication vectors (newsletter, intranet home page) can also support
the message.
Education of the Functional Heads (Project Management Team)
In addition to general communication it is useful to remind function
heads in the Project Management Team that should they intend to review
and amend their processes, they should liaise with Project Control to check
that they don’t jeopardize the overall data recording and management
architecture. It often happens that when individual functions try to optimize
their processes they discard activities that do not add value to themselves
but are extremely valuable for the entire Project.
Additional Project Control Setup in the
Case of a Consortium
When the Project is executed in a consortium or an unincorporated
Joint-Venture, an additional complexity layer is added. Its extent will
depend on the contractual agreement in terms of consortium or joint-
venture agreement, and how profit and risk is allocated to the various
partners.
The Consortium must adopt a set of processes and systems that is
applicable to all partners. They are either custom-made processes/ systems,
or rely on the processes/ systems of a lead partner. In any case this will
require substantial awareness and re-training of a large part of the Project
team, and this should not be underestimated at Project setup stage.
Ideally the main Project Control team should be integrated in a single
location so as not to duplicate the Project Control role or any other key
Project roles. The main Project office should also be unique with the Project
Management Team regrouped notwithstanding their origin.
Architecture choices must be made as to the Project configuration, in
particular whether certain registers will be common or must be split, such as
e.g. the document register, the procurement register or part of it, etc. The
outcome will depend on the particular circumstances of the Project. It will
require substantial analysing to take the proper decision.
It remains that at the level of each partner, Project Control activities
must also be carried out to determine the share of cost and risk for internal
reporting purpose, as per the original organization’s processes. In addition,
due consideration must be given to the consequential impact of the actions
of one partner on the other partners, in particular in case of delay or other
variance to the baseline. Specific processes and data streams must be put in
place for the purpose of that reporting. Consistency must also be maintained
with the overall Project data and reporting.
The setting up and effective operation of a Consortium or Joint-Venture
governance and steering committee is essential. It should play the
traditional role of Project Sponsor, which requires the designation of a
single representative from the steering committee to be the main contact
point for the Project Manager on a day-to-day basis. The steering
committee should also have the required level of financial authority to
enable the Project to be productive. Finally, it needs to be able to have frank
conversations around consequential impacts, and decide quickly on how
they should be allocated to each partners should they happen.
Conclusion
The Project Control setup process is essential and needs to be
addressed decisively from the first day of Project execution, because it will
in a large measure influence ultimate Project success. Also, a poor setup
can’t be recovered later during Project execution, which makes that initial
setup phase even more critical.
The first few months can be the harshest for the Project Control team
as they rush to setup the whole Project baseline configuration and all the
data streams that will be used for Project Control, supported by the relevant
systems.
Proper communication on the importance of Project Control and the
need to take its requirements seriously is essential. Leadership must be
demonstrated by both the Project Control Manager and the Project Manager
to embed this requirement in the Project organization. Contributors must in
particular be aware that some of the requirements of their jobs are related to
overarching Project needs, and should not be short-circuited. This
awareness and continuous communication reinforcement is essential, as
systems and processes are not useful if they are not understood and
followed.
 Chapter 5:
The Data Assurance Role
Introduction
In this Chapter and the next five Chapters we examine the different
roles of Project Control during the execution of the Project, from policing to
strategy:
Ensuring that the Project Control processes are implemented
with discipline to make sure that what is measured by the
monitoring systems corresponds to reality,
Making sure that relevant communication processes are firmly
established and effective in coordinating all relevant Project
functions,
Ensuring consistency between Cost, Schedule, Risk and
Contract at all time to have sound and candid data to base
decision-making, and question any discrepancy so as to
provide an additional data check,
Making effective updated visual dashboards and performance
indicators available to ensure Project team alignment and
facilitate decision-making,
Providing the Project Manager with the strategic support
required for effective data analysis and decision-making.
These roles represent a continuous evolution from ensuring the quality
of the basic data, to producing a proper image of the Project situation (both
current and in terms of forecast), and finally support the essential task of the
Project Manager, decision-making.
In this first Chapter we concentrate on making sure that the measures
of the Project condition are reliable.
As a note, all measurements in Project Control need to be accurate and
not necessarily precise (refer to our Cost Control and Scheduling
Handbooks for this discussion).

Figure 4: Precise vs Accurate

Project Control Processes –Measurement
of Actuals
Cost
The key cost measures which need to be reliable and available
according to the chosen breakdown structure are (refer to our Cost Control
Handbook):
Budget (initial budget plus approved changes, taking into
account any possible transfers due to changes in execution),
Actual Cost (which is different from Invoiced Cost),
Committed Amount.
The Budget (baseline) is set and updated only by Project Control, with
approval by the Project Manager. It has to reconcile to the proposal estimate
and all formally approved changes since the beginning of the Project.
Engineering
Actual Cost for Engineering is derived from timesheets coded
according to the CBS (sometimes detailed further at the CTR level) that
allow to track the actual cost spent with very little time-lag. This requires
that a strong discipline is maintained in the organization as to the timely
entry and approval of timesheets, generally on a weekly basis – in large
Projects it is not rare that a member of the Project Control team is dedicated
to maintaining that discipline.
Procurement
For procurement and contracting, the Actual Cost results from a
sometimes complicated process that can include physical progress measures
performed either by the Project team or by a supplier/ contractor; or actual
receipt of material and equipment on site. Most accuracy issues occur in
that area. The following processes need to be checked for discipline:
Receipt notification of equipment or material needs to be
immediate when those are effectively delivered on site (in
addition, a quality check and review of any outstanding work
is recommended to avoid any possible consequential effect),
 Physical progress measures need to be accurate (refer to the
Schedule discussion),
Regular checks are required to ensure that Actual Costs are
always higher than Invoiced Costs in particular in cases where
invoiced amounts appear to be significantly higher than
expected at this stage of the Project. This is reviewed regularly
with the relevant Scope Owners,
Regular checks are also required to ensure consistency with
the levels of commitment.
The committed amounts result from the procurement process and are
derived automatically from the procurement systems. Any update
performed by the post-award package manager needs to be included. Issues
occur mainly on these updates, which might be delayed by approval
processes and other factors. It is essential that any changes or updates to
these amounts which reflect the forecasts on these particular contracts be
entered in the system as soon as they are available.
Construction
Actuals for construction are generally closely linked to physical
progress or time. In addition there is also an element of mobilization/
demobilization.
Physical progress is the driver in particular in re-measurable or rate-
based contracts.
When using a very expensive asset (e.g. offshore construction) time is
more relevant notwithstanding actual progress. Time is also the driver of all
support and management costs.
Mobilization and preparation costs are to be value separately.
Data assurance will thus primarily rely on cost elements being mapped
properly as to their driver.
Schedule
Update of the schedule requires knowing for each activity what the
actual physical progress is, and what the actual start date was, and if
possible what the expected finish date is. It is essential here to ensure that
actual physical progress is measured, and not some other measure that is
related to cost and busy-ness.
 Data assurance issues related to physical progress measurement
include:
Delays in the update of relevant systems (e.g. document
control systems when progress is not updated automatically as
documents change status),
Delays in reporting or data transmittal (e.g. suppliers,
contractors, construction sites),
Inconsistencies in cut-off dates for different parties which
require extrapolation of physical progress data,
Inaccuracies in physical progress measurement due to the
utilization of poorly chosen indicators,
Inaccuracies due to inconsistent breakdown structures between
contributors (as the result of a poor start-up and requirements
definition).
Opportunity and Risk
Update of the Project risk model requires a periodic reassessment of
the list of Opportunities and Risks and of their prioritization. The status of
the mitigation actions must be tracked. Input into quantitative analysis (cost
or schedule) must also be periodically revisited, in particular as the
calculation will only be conducted on future activities (Estimate to
Complete).
Data assurance issues related to the Opportunity and Risk management
process include:
Ensuring that Opportunity and Risk identification and
prioritization activities occur with the Project Management
team present in workshops and not with individuals in
isolation,
Ensuring that prioritization inputs and quantitative inputs are
properly calibrated so as to ensure their consistency and
adequacy.
Main Contract
In the field of Contract management, checks are mostly related to
maintaining the relationship and contractual rights with the Client. Still, it is
an essential part of maintaining an adequate picture of the Project situation.
 Compliance checks to be performed in the area of Contract
management include:
Dates and methods of notification for all notifications under
the Contract,
Compliance with time-bars for the identification and report of
Changes,
Compliance with the periods set for the notification of quality
inspections,
Compliance with the document review cycle timelines and
correspondence response timelines,
Assessing the accuracy of all data to be reported to the Client
on a periodic or ad-hoc basis. This includes in particular such
areas as Change Orders, Financial and Cost reports, Schedule
etc.
Checking that all Client instructions are given in the expected
format and fall in the expected process for assessment and
contractual management. This is particularly an issue for:
Comments of the Client during the review of
documents, which may often border on an instruction
to Change,
Construction site/ fabrication yard/ manufacturing
plant comments and instructions.
Other Key Measurement Areas Managed
by Other Functions
A number of other data is also managed by the Project which accuracy
is essential to keep the Project under control. While not immediately under
the responsibility of Project Control, we believe that the Project Control
Manager as part of his extended role has a duty to verify from time to time
that these measurement processes are accurate enough: these measurements
are underlying substantial sources for Cost and Schedule.
It is not rare that the Project Control manager must step in to get those
processes and measurements setup and running in some Projects when
those are not put in place by the different functions, as their absence would
be too much a strain on the control of Project execution. In addition
functions must be sensitive to the fact that some measurement is being
required that is useful for the entire Project and not just for their own use.
In general, it is important not to underestimate the power of requesting
Scope Owners to commit on the finish budget and date of ongoing
activities. Such commitments must be challenged (in particular for
commitment-related padding or inversely for planning fallacy – being
overly optimistic when not understanding all the details), still, because they
include an element of commitment, can be powerful from the perspective of
team alignment. It will give strong data points for forecasting if properly
employed. Such a date forecast process is generally embedded in the risk
register, procurement plans and some areas of construction.
Engineering
In the Engineering area, the main issues that require proper control
include:
Master Document Register establishment including clear
document owner assignment, forecast dates and effort level for
all documents (and consistency with budget and schedule),
Proper and timely Master Document Register maintenance
including changes (additions and deletions of documents),
updates of actual, forecast dates for main stages of
 documentation production (planned dates should always be
aligned with the baseline),
Master Document Register updates regarding vendor
documents (sometimes kept in a separate register) including
actual and forecast dates,
Proper establishment of a Document Control system or
equivalent that allows to identify at any time, who is in charge
of which document at which stage of its development or
review, with relevant alerts and reports in case of delays.
The Master Document Register process will be the source of many
measurements such as engineering progress, productivity, document turn-
around cycle times, document review hold-ups etc. which are essential for
controlling the execution of Project Engineering. For example, it happens
quite often that analysis shows that one or two document reviewers act as
bottleneck and hold up a great part of the documentation.
Procurement
In the Procurement area, the key control points include the effective
control of commitments, the establishment of clear full costs for all
packages (including all ancillary costs on top of the basic cost of the
purchase order or contract), and the compliance to reporting requirements
by the suppliers and contractors.
Key issues that need to be monitored include:
Proper mapping of the Project breakdown structure for awards
(including where required to remain consistent with the
Project breakdown structure, split of contracts or at least clear
instructions to the supplier / contractor for splitting invoicing
by activity),
Clarity as to the system and process used for tracking Actual
Costs and reforecasting for the following key procurement
categories – plus a mapping of the Project’s procurement plan
accordingly:
Purchase Orders for bulk and small standards items,
Purchase Orders for large complicated manufactured
or fabricated items,
Service contracts,
 Transmittal to Cost Control of the full detailed bid comparison
forms for proper control of subsequent costs, and clear
determination of other costs such as growth allowance,
logistics and inspection that are related to the purchase order
or contract,
Clarity on available allowances and their justification (as a
best practice, allowances should be controlled in separate cost
Work Packages),
Clarity on ancillary scopes such as options, provision of spare
parts, commissioning spares and consumables, vendor
representative assistance for commissioning. They should be
budgeted and tracked in separate Work Packages,
Timely and compliant reporting by suppliers and contractors,
in particular regarding breakdown structures utilization in cost
and schedule reports,
Continuous update and tracking of delivery dates and on-site
delivery dates, and comparison to the baseline and Required-
On-Site dates for construction,
Proper and timely update of commitments (forecast) in the
procurement system, including subsequent updates due to
changes and other forecast issues, so that the commitment
picture of the Project remains consistent and comprehensive,
Associated complete register of variations and claims,
including non-agreed or rejected variation requests, list of
instructions and other processes that may impact the cost at
completion,
Associated register for retentions and back-charges to the
supplier / contractor for any part of the scope that the Project
might have had to cover itself,
Immediate raising of cases such as unexpected invoices
received from suppliers or contractors which might denote a
control issue.
The control of supplier/ contractor invoices regarding the work
performed is a particular process that should not directly be under the
responsibility of Cost Control, but Cost Control should be a second line of
defence to ensure compliance with the contractual terms. Best practice is a
two-step invoicing process:
 The contract/supplier issues first to the Scope Owner a
milestone or progress certificate, which is purely a technical
document based on quantities or physical progress, and
includes all the relevant backups, which can be substantial.
This certificate is reviewed and signed off after corrections if
required,
Upon receipt of the signed-off certificate the contract/supplier
subsequently issues the official invoice, with only that
certificate as a backup. The invoice control process can now
be restricted to contractual compliance, as the physical
progress of the work has already been assessed.
Construction
In the construction area, the main control issues include effective
control of local site commitments and effective productivity measurements.
Because of the intense nature of construction activities, it is essential that all
the proper processes and systems are put in place sufficiently early prior to
effective mobilization.
Key issues that need to be monitored include:
Clear delegations of authority to construction management
personnel, and escalations rules including for urgent approvals
outside office working hours,
Clear process and authority limits for site instructions and site
changes approval,
Proper and timely site commitment capture and approval
process, with relevant recording,
Proper and timely site reporting regarding resources utilization
(in particular for contractors),
Proper definition of physical progress and productivity
indicators,
Regular, timely and accurate reporting on physical progress
based on the Project breakdown structure.
Commissioning / Hand-over
In the commissioning area, the main control issues include effective
control of local site commitments, and effective progress measurements and
forecasts (productivity is not always a proper indicator when
commissioning activities are driven by construction and the effective
availability of systems).
Key issues that need to be monitored include:
Proper definition of physical progress indicators based on the
commissioning system detailing all activities that need to be
performed,
Proper mobilization plan for vendor representatives so as to
minimize cost,
Proper documentation of acceptance and hand-over, including
punch lists and associated action registers (including forecast
dates),
Proper forecast of achievement dates and milestones based on
construction progress (flow-down diagrams) and
commissioning resources availability,
Proper documentation of any outstanding work (punch lists) so
as to allow an estimate of the future rectification cost in the
future conditions where this work will have to be carried out.
Accounting & Finance
Accounting is a support activity for the Project. Important Project
Control issues can be uncovered by a proper setup of warning systems
within Accounting.
In the Cost Control Handbook we have underlined the importance of a
proper, regular reconciliation between Cost Control and Accounting at the
Work Package level to compare Commitment, Actual Cost and Invoiced
Costs.
Additional warning systems typically include:
Effective cash flow measurement (this requires a specific
systems setup if the Project does not benefit from separate
bank accounts). Compared with the expected cash flow issued
by Cost Control, a substantial difference will denote a control
issue, as cash is the ultimate line of defence with reality,
Immediate raising of cases such as unexpected invoices
received without proper reference to a commitment, or
substantial expenses claimed by team members for the on-site
 procurement of equipment or services that might denote
uncontrolled expenditures.
Challenging process changes in functions
As mentioned in the previous Chapter, as part of data assurance it is
essential that the Project Control Manager keep abreast of process or
measurement changes that could be instigated by individual functions.
These changes generally derive from the best of intention to accelerate
production of the function. However they might jeopardize the entire data
breakdown and recording setup.
Data Assurance for Advanced Indicators
From the raw data provided by other functions, and listed in the
previous section, and data available within Project Control, certain more
advanced indicators will be produced by Project Control and used for
forecasting and reporting. Their accuracy must also be guaranteed, which
includes the process to derive them.
In this section we limit ourselves to important parameters that can be
measured. We do not cover here the subsequent establishment of the Project
Forecast, which relies as well on the judgment of the various Scope Owners
and the proper establishment of dependency linkages, in particular in the
area of Scheduling.
Engineering
Engineering is often reforecast using manpower plans, challenged by
Earned Value management. The advanced parameters that need to be
measured as a basis for these processes include:
Delays in Client provided data,
Actual manpower usage / baseline,
Actual average manpower cost / baseline reference,
Actual physical progress / baseline and actual productivity
Actual engineering maturity (status of 3D model reviews),
Actual production and review cycle durations compared to
baseline (average and standard deviation).
One essential measure relates to the few deliverables that might have
been completed. They allow a full lifecycle productivity and lifecycle
duration measurement that can be used to challenge the average
productivity measures derived from partial progress. They can allow in
particular to observe if the last steps of production have or not a
significantly different level of productivity which could alter the overall
schedule. When some part of the Project or set of deliverables has been
completed, the related productivity is thus measured. It can then be applied
throughout the Project with the relevant adaptations to challenge current
forecast assumptions.
 In addition, certain key parameters resulting from the engineering
process need to be assessed. That is the case in particular for quantities,
which are key indicators for procurement and construction cost and time.
For quantity-based forecasts, such as typically bulk material or commodity
equipment, a proper follow-up of the different allowances is essential to
estimate the quantities at completion, as well as a proper management of
changes in types and quantities of material as engineering matures.
Essential parameters to check for accuracy and that need to be challenged
with the Scope Owner hence include:
Any major event that might have significantly impacted the
quantity estimates at completion (e.g. scope overseen at
estimate stage, change of plot plan etc.),
Accuracy of the design allowances from engineering, based on
the engineering maturity level and the current coverage of
engineering.
Procurement
Key parameters to follow for procurement which will be used to derive
or challenge forecasts are:
Latest knowledge of Client Provided Items delivery dates
for those that need to be included in fabrication or are a
pre-requisite to manufacturing,
Actual progress of purchase order issuance (weighted)/
baseline,
Actual time from Request for Quotation to Award (taking
into account all necessary approval steps), and then from
Award to start of manufacturing (taking into account all
necessary document approvals),
Actual dates of availability of vendor data vs baseline,
Actual status of Variation Order requests and claims from
suppliers and contractors.
Procurement allowances for commodities (damages, loss
of material during transport, constraints due to sizes
available on the market),
Effective cycle time for Factory Acceptance Tests and
other checks prior to final acceptance,
 Effective cycle time from item delivery ex-works to
delivery at the construction site logistics base, taking into
account customs clearances and other delays.
Any data showing substantial inconsistencies regarding
customs duties compared to the budget,
Proper and clear split in responsibility regarding
procurement of bulk material between the Project and the
fabrication yard / construction contractor, including
estimated quantities at completion,
Proper consideration of the particular yards used for
fabrication as soon as they are known (impact on
quantities and logistics),
Proper examination of any changes to already ordered
material or equipment due to changes in engineering, and
the availability of take-back clauses with the suppliers.
Construction
Key parameters to follow for construction on which forecast will be
based are:
Latest knowledge of Client Provided Items delivery dates
and/or interface data and equipment provided by others,
Latest update on free access slots to the facility (e.g. in
case of facility shutdown, after soil preparation etc.),
Actual progress and productivity, and the identification of
specific constraints impacting productivity such as
environmental conditions, limits to working hours etc.,
Mobilization curves by key trades (actual versus baseline),
Any particular construction bottleneck specific to the
Project (such as e.g. concrete batching station, pipe spools
pre-fabrication installation, etc.)
Construction allowances for commodities (cutting and
nesting).
The Reporting Cycles
Project periodic reports (internal and external) are essential tools. They
have to provide an accurate, consistent and up-to-date picture of the
situation and an updated forecast of the Project for three major groups of
stakeholders:
The Project Management Team,
The Project Organization (including Project sponsor, Finance
department and Senior Management),
External stakeholders such as the Owner and/or Main Contract
Client.
We believe that Project reports should be primarily produced for the
benefit of the Project Manager and his team: only a comprehensive report
where consistency has been ensured between disciplines can ensure a sound
basis for decision making. Reports thus need to be made usable for that
purpose.
Communication to external stakeholders - such as the Project Sponsor,
Senior Management or the Owner - is of course important, in particular
from the Main Contract perspective, but should not be seen as the primary
objective contrary to what happens too often in practice.
The value of periodic reporting depends a lot on its timeliness and
regularity, where utmost discipline must be followed by Project Control. In
addition, Projects should seek to minimize as much as possible the low
value-added information collection process to spend more time on high-
value added interpretation and synthesis work. As a result, a proper
information collection process must be setup by Project Control to ensure
that information is available at the proper time. This collection process
should be setup so that most information should be made available without
further action.
Best practices include:
Developing a clear responsibility matrix for all reports to be
produced, if possible section by section,
Developing a detailed calendar of cut-off dates (for the report
as well as for all the main inflows of data) that is transmitted
to all information producers,
For each single report, being very clear about what has been
included or not in terms of latest Project developments
notwithstanding the cut-off date. This is particularly important
for reforecasting exercises that might span over several weeks
and not be directly linked to present events,
Sometimes, information is produced or transmitted that does
not seem consistent with what was expected, in particular
when Third Parties are involved. If there is no time to
sufficiently check the accuracy of that information (using
independent sources) it is important to highlight that it is
subject to further investigation. Transparency is an essential
complement to immediacy. When it is better to hold off
incorporating information before it is confirmed and
corroborated, it should be mentioned explicitly.
Dealing with Management Pressure
In the real world it is not rare that significant pressure is exercised by
management on the Project to report a situation that differs substantially
from what best practices would normally dictate. It can typically be linked
to requests to delay the recognition of new events, to time-phasing (for the
current accounting period financial forecast), or even related to the
recognition of additional revenue while it is not formally approved by the
Client. This can be particularly an issue in organizations that have a
relatively lower maturity or experience in reporting Project-driven financial
results and their intrinsic volatility.
The Project Control Manager is at the centre of these issues. He will
generally sign-off together with the Project Manager the internal Periodic
Project Report that is the reference in the entire organization with respect to
the situation of the Project.
There is a fine line between introducing some tweaks in a schedule as
part of a commercial and contractual strategy or taking a position in a
matter subject to professional appreciation, and outright inaccurate
reporting. It is important that Project Control Managers recognize this limit
and proceed with integrity. The organization’s auditors will most often base
their judgment on the adequacy of the organization’s numbers on the
Project Manager’s and Project Control Manager’s signature of the Periodic
Project Report.
If a Project Control Manager feels uncomfortable with the content of
the report, he should not sign it off or otherwise request for a written
instruction from management to include those controversial elements in the
Project report.
Conclusion
Ensuring accuracy of data is a first essential role of Project Control. If
data is not accurate there is no chance to give a proper view of the current
and forecast state of the Project, and therefore to take proper decisions.
The Project Control Manager’s position gives him the possibility to
check the consistency of information supplied from various sources. He
needs to rely on the accountability of each ‘Scope Owner’ that need to take
ownership of cost and schedule. Still the Project Control Manager should
intervene to rectify situations even if strictly speaking the data in question
in not under his responsibility. Being in charge of making sure the Project is
effectively under control it is his duty to intervene and sometimes even
compensate failing segments of the Project to make sure it remains fully
watertight data-wise.
In the following Chapters we examine more in detail how to check and
ensure the consistency of data in particular between the areas of Cost,
Schedule, Risk and Contract.
 Chapter 6:
The Communication Assurance
Role
Introduction
Project Control has an essential role in making sure the relevant
internal interfaces are established from the beginning between the different
functions on the Project, and that they operate effectively. This includes of
course those interfaces between Project Control and other functions, as well
as some key transverse interfaces between functions.
Beyond establishing formal communication interfaces and designing
the overall Project data structure breakdown, the Project Control Manager
must also monitor the health of communication within the Project Team. A
clear indicator will be discrepancies in reports and expectations. Should a
significant issue arise in this area, the Project Control Manager must be able
to intervene to raise the issue and setup the necessary solution, which can
be either a workshop or other ad-hoc interventions that aim at re-
establishing alignment and commitment within the Project team.
Establishing Internal Interfaces between
Project Control and other Functions
In this section we detail the usual necessary interfaces between Project
Control and other Project functions.
Project Control and Finance
A continuous communication must be ensured between Project Control
and Finance to ensure consistency between the accounting books and Cost
Control.
Regular communication includes:
Providing cost control data in a format that can be used by
Finance for its own reporting (it is generally a more detailed
report than what is presented in internal cost reports),
Checking monthly the difference between Cost Control actual
costs and invoices costs at Work Package level, determining
accruals,
Assigning invoices to the relevant CBS work package,
Managing site cash reconciliation and any site direct
procurement, if applicable.
Particular areas of communication for global Projects include:
Managing hedging requirements in line with the updated cash
flow by currency,
Ensure that the breakdown structure is aligned with the legal
entity setup and that costs are properly assigned to the
appropriate legal entity.
Project Control and Engineering
Engineering execution is generally performed by internal resources
complemented by contractors (for man-hour intensive detailed engineering
or specialized work).
On the cost side, Project Control is often very involved in making sure
that timesheets are filled-in accurately and timely by engineers.
 On the schedule side, the Master Document register in the Document
Control system measures physical progress and contains actual and forecast
dates.
The combination of cost and progress data allows Earned Value
Management to be performed at a detailed breakdown level, thus deriving
useful productivity data.
Engineering contractors are often working on a reimbursable basis, in
that case the same level of reporting and data should be provided regarding
Actual Cost and Physical Progress according to the pre-agreed CBS or even
CTR list. This requires a very detailed information gathering and reporting,
i.e. onerous contractual requirements. Significant complication can occur
for the documents generated by contractors that will require a double
review cycle (Project and Owner). Hence the document review workflow
and associated physical progress measurement needs to be carefully thought
out in advance.
Even in those cases where engineering contractors work on a lump sum
basis, close monitoring is required on physical progress and actual manning
to anticipate deviations and issues. In addition progress is often used as a
basis for invoicing and should be closely monitored. Any lapse in the
delivery of outcomes - quality or time - should be investigated thoroughly
to understand if it might impact subsequent deliverables.
Most engineering contractors default to progress measurement methods
that are significantly optimistic, because they are often compensated based
on this measure. It is important to agree with engineering contractors
progress measurement principles that are consistent with the rest of the
Project and reflect accurately the significant level of effort that is needed to
finalize technical documentation.
On the Main Contract side, certain documents are contractual
deliverables that need to be delivered as per the Contract terms within
specified durations. In addition, during the engineering phase, needs for
clarifications and changes will appear that need to be communicated to the
Owner through processes such as Technical Clarifications / Technical
Queries. It is important that these processes remain focused on technical
exchanges and avoid the burden of the commercial discussions process. At
the same time they need to be monitored regularly by Project Control to
check that when any change is identified, the proper process is followed.
 In general, all potential impacts in terms of cost and schedule that
might result from engineering changes, irrespective of their origin (internal
or external) must be carefully assessed prior to their approval. Project
Control must check regularly that the Management of Change process is
implemented and remains healthy. This aspect is further detailed in Chapter
7.
Project Control and Procurement
One of the tightest interfaces required is with Procurement. On EPC
contracts it is often the area where the Project can lose visibility and control
if the interfaces are not set properly.
On the cost and schedule side, the following are required:
Clear designation of Scope Owners to validate forecasts in
Cost and Schedule and assess the situation regarding Change
Orders or Claims from the suppliers or service contractors,
Ensure that the CBS is split according to the procurement
strategy; this might require adjustments on both sides as there
are certain high-level elements of the CBS which are
mandatory within the organization, and the contract with
suppliers or service contractors might need to be split
accordingly (refer to our Cost Control Handbook),
Enforce the reporting requirements from suppliers and service
contractors, including:
Subset of WBS/CBS,
Schedule forecast updates,
Proper Actual Cost measurement, which can be based
on a physical progress measurement or a set of
milestones if they are representative,
Ensure that a proper coordination process is in place between
Engineering and Procurement (Engineering must produce the
required technical requisitions and get back the necessary
vendor data to proceed with the design). This must include
regular coordination meetings between Engineering and
Procurement, which a scheduler should attend on behalf of
Project Control,
Ensure that proper independent control of progress is exercised
by the expediting function with the support of site inspectors
 and/or site representatives,
Ensure that a proper coordination process is in place between
Procurement and Construction regarding actual delivery dates
on site. This must include regular coordination meetings
between Procurement and Construction from the moment of
the first delivery on site, which a scheduler should attend on
behalf of Project Control,
Ensure proper registration of any Claim and request for
Change Order from suppliers and service contractors, and
proper inclusion in the Project forecast (including
sensitivities).
On the Contract side, three issues need to be properly and carefully
addressed:
A proper flow-down from the Main Contract into the Purchase
Orders or Service Contracts terms and conditions so as to
protect the Project, in particular in terms of liabilities,
warranty duration and coverage (ref. Chapter 4),
The criteria and process for acceptance, charge-back clauses
for outstanding work and the remaining liabilities in case of
defect discovery during later integration or construction phase,
The contracting approach impact on the Project risk profile:
risk management needs to be involved in defining the
contractual strategy and what are the opportunities and risks
that are created by the Terms and Conditions agreed.
Changes created by the suppliers need to be captured properly in a
comprehensive Management of Change process that interfaces with the
Owner in case of Request for Deviations from the Owner’s specifications or
other Change under the Main Contract. Regular review of the suppliers’
Technical Query registers or equivalent is also needed to check that changes
are not actually hidden in that process.
Project Control and Construction (Pre-Mobilization)
We separate here pre-mobilization from the actual construction phase
because of the substantial amount of specific preparation work that must be
performed prior to effective on-site mobilization.
 A first pre-requisite is that the Construction management team must be
mobilized as part of the Project Management Team very early, ideally for
the Construction Manager from the Project kick-off. This will allow proper
inclusion of Construction phase input into the Project setup.
In the few months prior to effective mobilization on site, intense
collaboration is needed between Project Control and Construction
management in particular as to:
Build up a detailed construction schedule and progress
measurement system that is consistent with the rest of the
Project and the Integrated Project Schedule (some of this
detailed construction schedule might be provided by
contractors),
Build up a detailed mobilization plan,
Design and implement a site commitment process,
Assess the need for site cash management and setup the
relevant control processes,
Agree on data gathering and communication protocols from
site to Project office,
Check the contractors’ mobilization plans for realism, the
availability of key Client-provided items and of key contractor
resources,
Ensure Project resources planned to be relocated onsite are
available and will be properly inducted prior to site
mobilization,
Ensure proper systems and sufficient communication channels
will be available on site,
Design adequate Key Performance Indicators for construction
progress and work-front management.
Project Control and Construction (Construction Phase)
Construction generally involves a number of service contractors that
need to be coordinated on a work site. These contractors are often
sophisticated enough to be able to produce resourced construction
schedules, which can be used to control their activity. Notwithstanding
these schedules it is important for the Project to develop physical progress
indicators that can be measured easily and against which the numbers
announced can be checked independently.
 The Project must thus maintain a significant independent oversight on
the actual progress of the works. This is generally the role of the Quantity
Surveyors. For part of their capacity, they will be the eyes of Project
Control on the construction site as they will check in detail the contractors’
reports on progress. Quantity Surveyors are not always used by Projects
although it is best practice; if they are not, sufficiently qualified manpower
must be recruited to provide an independent measure of work progress.
The Project’s Construction Manager as the Scope Owner will be the
main interface of the Project Control team. He needs to provide the relevant
inputs for forecasting both in cost and schedule. In particular he needs to
produce a detailed construction schedule a few months before the start of
the works, and thereafter update this schedule very regularly. Regular
meetings must happen between the Construction Manager and the schedule
function to ensure consistency and identify deviations.
Specific contractual aspects require very careful monitoring:
Interfaces management between the different contractors on
site if there are several (which is often the case),
Site access terms (generally contracts are built on free and
unimpeded access) which can include interface issues between
contractors or other issues,
Availability of free-issued items from Owner or Project to
construction contractor, or hand-over of items or prepared sites
from a construction contractor to the next (e.g. soil
preparation),
Regulatory approvals for construction, and also for other on-
site activities such as catering, waste management, etc., which
can have to be provided by the Owner, the Project or the
contractors,
Work visa issues and constraints when using foreign
manpower.
Again, Project Control must ensure that a proper Management of
Change process is enforced on the construction site so as to identify and
assess any major change before it is approved; actual and possible Change
Order and claims must also be properly managed so as to be included in the
Project’s forecast (cost and schedule) as soon as they appear to be probable.
Project Control and Commissioning / Hand-Over
Commissioning and hand-over operations are often extremely
dependent schedule-wise from the construction operations and thus cannot
be controlled in isolation. It is important that Project Control checks that a
comprehensive commissioning approach is implemented early enough on
the Project, so as to ensure proper preparation and avoid delays at the
execution stage.
Cost must be controlled using trending and manpower forecasts, with
the complication that it involves manpower as well as logistical support.
Particular complications to be considered include:
Standby of resources due to schedule issues during
construction and interface issues with construction, which
makes productivity measurement for the works difficult,
Delays of formal partial acceptance by the Client,
Vendor representatives for equipment are often costly due to
travel and potential standby, and need to be managed
adequately,
Rework cost due to failed pre-commissioning and
commissioning can be substantial and some contingency must
be available.
Punch lists must be addressed specifically, because of the following
issues:
Conditional acceptance will produce carry-over work when the
infrastructure will be operating or transferred elsewhere. This
will foster much higher unit costs for the completion of the
work, which needs to be adequately re-forecast,
Modules or equipment delivered to the construction site must
be accompanied by an outstanding work register validated by
the construction team and taken into account in the
construction schedule and resource assignment,
The timing of closure of punch list items cannot be estimated
using productivity measurements, and needs to be assessed by
the Scope Owner.
The inability of the contractor to close-out the punch list – and thus the
transfer of punch list items to the Client / Owner will lead to the following
issued and risks:
Risk exposure in terms of liability and warranty validity:
possible delay in the start of the warranty period, leading to:
Actual extension of the warranty period end, possibly
beyond the back-to-back warranty terms of the
contractor with its suppliers,
Increased risk of encountering other quality issues
with unlimited liability prior to the start of the
warranty period, where liabilities are generally
capped.
If acceptance and transfer of the punch list to the Client, back-
charge of rectification works to the contractor.
Essential Internal Interface Meetings
To supplement and reinforce processes, certain regular meetings
between functions are essential in a Project.
In spite of improvements in systems, meetings remain essential to get
proper feedback and check on the data. Too many Project Control teams
rely excessively on data provided by systems and do not spend sufficient
time liaising with the relevant Project contributors or checking the reality
on site. Discussing with Project contributors does improve significantly the
quality of the information and effort should be made to maintain a regular
set of effective coordination meetings.
Most coordination meetings need to happen in the presence of a Project
Control representative because of the wealth of information that is
exchanged and can be used to update Cost, Schedule or Risk. In any case,
all these meetings need to be followed by actions lists that shall be copied
to Project Control.
The importance of these meetings will vary according to the Project
phase.
Project Weekly Coordination Meeting
An essential coordination tool is the Project weekly coordination
meeting involving the Project Management Team. Achieving an effective
meeting resulting in actions that will effectively be taken requires a specific
involvement of the Project Manager.
At this meeting, the general status of the Project is exposed as well as
events that can show a dysfunction, or a discrepancy with what is currently
shown on Project Control monitoring tools.
The Project Control Manager is a participant to the meeting and often
assumes as well the role of coordinator/ minutes and actions recorder.
In addition during those meetings the Project Control Manager needs to
use the opportunity to share the latest analysis available (e.g. productivity,
delays) for the team to reflect and take proper rectification action.
It is essential to run those weekly meetings with a proper structure to
make them effective. A running action list that is updated according to the
latest status and due dates is a recommended good practice.
Internal Management of Change and Change Order Weekly
Meeting
Generally held together with the Project weekly meeting, or just after
in a slightly reduced format, a specific meeting involving all Project
Management Team is required to review the new changes that were raised
during the week, and discuss the Change Order status (preparation of
submission, work to be performed on those under discussion).
Weekly Schedule Meeting
A Weekly Schedule Meeting is recommended to be held between the
lead planner and all functions to review the latest schedule update and
include the proper amendments required, in particular in terms of activities’
finish dates.
It is useful to have this meeting with all participants in the same room
so as to discuss consequential effects of delays on subsequent Project
activities.
The Project Control Manager must participate on those areas that are
highly critical or for which it is felt that proper focus of the Scope Owner is
not achieved.
Engineering/Procurement Weekly Meeting
This meeting is particularly essential in the first half the Project. It
helps coordinate engineering deliverables that are required by Procurement
(such as specifications and other documents required for Requests for
Quotation); the attendance to vendors’ or contractors’ kick-off meetings;
the technical review and approval of vendors’ documentation prior to
manufacturing, and the management of the vendor data that is required by
Engineering.
Regular participation of a Schedule representative is recommended,
who shall also note if there are any issues raised that might be investigated
by Cost.
Procurement/Construction Weekly Meeting
This meeting is essential as soon as actual delivery dates become
known from vendors, and in any case significantly before the start of
construction. It needs to cover three types of topics:
 On site procurement: frame agreement setup with local
suppliers, follow-up of commitments, etc.
Delivery of equipment and material from vendors to the site
(or to the consolidation point if the site is remote and the final
logistics is managed by Construction),
Contracts with construction contractors and other service
contractors involved on site.
Participation of Schedule and Cost representatives is recommended.
Construction/ Commissioning Weekly Meeting
This meeting is essential as soon as construction starts. It will manage
the transition from areas to systems and the interfaces that need to be
managed for safe and effective commissioning.
Participation of a Schedule representative is recommended.
Calling for Other Coordination Meetings and Workshops
In most Projects, specific coordination meetings and processes are
generally planned, with discrete occurrences during Project execution:
Constructability reviews between Engineering and
Construction,
Health, Safety and Environmental risk assessments and
alignment workshops, involving Engineering, Construction,
and key stakeholders,
Worksite / vendor kick-off meetings and pre-production
meetings
Etc.
While most of these meetings will happen during the course of the
Project, it is part of the Project Control Manager responsibility to monitor
their occurrence and raise to the attention of the Project Managers those
coordination issues which fester and might lead to significant discrepancies
and difficulties in Project execution.
In addition to these planned meetings, there will be instances where
issues will appear that will require enhanced communication and alignment.
This will be the case in particular, if some misalignment between several
Project functions is detected; or, if an event happens in some area that will
have significant consequential impact on a large section of the Project.
 In these cases, specific meetings must be held. When the issue is quite
open, requires creative thinking, or a major coordination and alignment
work, workshops will be a more effective solution (refer to Chapter 12 for
workshop best practices).
Project Control within a Consortium
In a consortium or unincorporated joint-venture, proper communication
must be established and maintained between partners.
This communication can be complicated at a detailed level if the entire
data management has not been integrated for the full Project (refer to
Chapter 4 for the setup), which may lead to data retreatment prior to
consolidation. In addition, even when the Project Management Team is
regrouped in a single office, consortiums will generally use the work of
several offices spread geographically, which may make communication
more difficult.
The Project Control Manager has a decisive role in managing these
communication and interface links between partners so as to provide a
proper picture of the Project that can be analysed and serve to take adequate
decisions. Specific attention must be devoted to make the coordination
meetings mentioned in the previous section effective. It is also
recommended that the Project Control Manager visits from time to time the
main offices of the partners to communicate on Project needs and iron out
any control issue. Project Management Team (PMT) members should also
organize themselves to be present on a regular rotation basis in all
significant offices and might be requested to check some Project Control-
related issues.
Difficult situations will emerge where events happening to a partner
will have consequences on another, or if the performance of one partner is
substantially lower than the others. Depending on the consortium setup, the
Project Control Manager will need to provide evidence of the various
impacts to support discussion and decision-making at the consortium
steering committee level. This will require substantial work and temporary
increase of resources, and this must be taken into account in the Project
Control team manning.
Project Control and EPC contractors
management
This particular section addresses the case where a service contract is
established with an EPC contractor. The recommendations of the different
sections above apply inasmuch that the contractual approach allows it (for
example, lump sum contracts will typically allow a much less onerous
Project Control setup but at the same time lead potentially to less control).
Key interface issues to be established at the Project Control side
include:
Requiring a detailed, high quality schedule from the EPC
Contractor (properly weighted and resourced when needed,
according to a pre-agreed WBS subset) that is baselined and
then subsequently updated regularly,
Requiring comprehensive cost reports according to the CBS
subset (the format will vary from very detailed for
reimbursable contracts to a low detail for lump sums),
Requiring substantial periodic reporting on all areas of
engineering, procurement and construction,
Approving the relevant contractor’s cost, schedule and
progress monitoring, risk and contract management
procedures, and checking subsequently by audits that they are
implemented fully,
Requiring risk analysis to be performed and the risk profile of
the Project to be reported (refer to our Risk Handbook) in the
form of:
a comprehensive risk register including impact
assessment, rating, mitigation action definition and
status reporting,
a schedule risk analysis, when needed,
Requiring communication of any potential Change Order as
soon as it arises.
Best practice contractual conditions to be included in the contract and
enforced by Project Control include:
 Together with an effective Change Order management process,
a time-bar for the identification and communication of
potential Change Orders to ensure early identification and
avoid Change Orders related to past events and submitted in
hindsight, ,
The possibility to audit the contractor’s records in their office,
which needs to be used at relevant points during Project
execution. While this possibility is included in most EPC
contracts, we find that it is not used frequently enough as part
of delivery assurance.
The Importance of a sufficiently strong Project oversight team for
EPC Contractors
One of the most common issues we encounter when it comes to EPC
contractors that have to deliver a sizeable part of the Project is a relative
weakness of the supervisory organization. Projects or Owners too often
underestimate the amount of control required to obtain a smooth delivery.
In addition, they fail to understand that the relatively limited supervisory
investment required is key to avoiding later major issues that may have
consequences several orders of magnitude larger.
We are not favouring here the excessive addition of technical experts as
part of this oversight, which sometimes have the opposite effect of affecting
significantly the progress of the contractor and its ability to propose
alternate solutions. We are focusing mainly on contract and control
personnel.
Delegation is not incompatible with control, and even with lump-sum
EPC contracts, it is essential to maintain substantial control in the interest of
the Project. This is ever more important if several contractors are involved
on the Project, as complexity has the potential to increase exponentially
with the number of interrelated contracts. The main issues include:
Schedule interface management, whereby the risk is that a
coordination failure will create substantial stand-by of another
contractor or of an expensive asset because contractors do not
deliver on time,
Physical interface management (site access, direct and indirect
work interference, shared resources, definition of physical
 interfaces between deliverables, delivery of free-issued
material between contractors),
Technical interface management, where all interface
clarification requests from one contractor are promptly
addressed to avoid commercial issues,
Quality of the deliverables and conformance to the
specifications (in particular for lump-sum or rate-based work,
where the contractor might fall to the temptation of cutting
corners to reduce cost),
Interface with the supplier of the process license/ supplier of
the basic design if applicable, which might be a contractor, the
Owner or a Third Party,
Operability and performance of the final facility, where most
of the time, knowledge and experience lies within the Owner
or the Project,
Early inclusion of the future operator of the facility at the
engineering, procurement and construction stages. The
interface to take into account operational improvements (from
ergonomics to maintainability) needs to be carefully managed
because it might create changes,
Involvement of the facility operators in the commissioning
stage in parallel with their training.
The most significant contributor to problems is often schedule, due in
particular to indirect consequences of delays. It is important to realize that
in spite of the contractual terms and conditions, the remedies for delays in
the contracts with EPC contractors are generally much limited compared to
the direct and indirect consequences for the Project. This is due in particular
to the fact that contractors would not accept conditions that would
jeopardize their business and cannot assume any indirect consequences. On
the other hand, consequences of delays are often very significant for the
Owner in terms of loss of revenue (therefore impacting the rate of return of
the facility and potentially the financing covenants) and other consequential
impacts. Therefore, prevention is always better than cure, in particular
because the cure would be imperfect and would not compensate the damage
done.
The issue of proper supervision by the Project is applicable in
particular to lump-sum contracts. Contrary to common belief, in reality
lump-sum EPC contracts often prove to be more risky for the Project due to
the lack of detailed visibility on the actual progress, and because any
change or interface issue from the side of the Project will be translated
immediately into a Change Order. In a number of circumstances, it is more
appropriate to use other contractual approaches. In any case, sufficient
supervision remains required on the Project side even in the case of lump-
sum EPC contracts.
Key guidance for the establishment of this supervision include:
In terms of governance:
Designation of Scope Owners accountable for all
aspects of each contractor’s delivery, including the
commercial aspect,
Involvement of the Project Manager as the sponsor of
the EPC contract (it is therefore recommended that the
Scope Owner be a different person to allow escalation
of issues), and designation of a sponsor at the highest
management levels of the EPC contractor,
Proper support in terms of control (cost, schedule, risk,
contract management) adapted to the size and complexity of
the contract, that also ensure consistency with the overall
Project control framework,
Definition and implementation of an independent audit plan to
check the accuracy of the contractor’s reports,
Availability of a very limited amount of suitably experienced
technical experts (engineering, procurement, construction,
quality, HSE) that are knowledgeable with the contractor’s
scope and can exercise effective and independent technical
supervision,
Provision of Project representatives on all contractor’s
worksites, either continuous or periodic as required, plus
definition of suitable checkpoints (Inspection and Test Plans,
participation to Acceptance Tests etc.).
Embedded Project teams in Contractor offices
A question which is always debated is whether there should be a team
of Project representatives in the contractor’s Project office. This practice
has pros and cons, which intensity will depend on the contract type:
 Pros:
Improved communication and ease of resolution of
issues,
Easier realization of the issues and difficulties faced
by the contractor,
Cons:
Risk of uncontrolled Management of Change through
numerous informal contacts between Project and
contractor,
Risk of prescribing methods in lump sum contracts.
We believe that the best solution is to have a team of Project
representatives in the same general geographical location and close to the
office of the Contractor, or in the same building to enhance communication,
but in a separate space. In addition, it should be visually very clear who is
working for whom (for example through different badge or lanyard
colours).
Conclusion
Project Control is not just about numbers. It needs to make sure that all
aspects of Project execution are constantly in control, and that coordination
is effective between all the contributors of the Project team.
Project Control must ensure that the proper interfaces have been
created on the Project between the different functions.
More generally, as part of its overall duty, Project Control must monitor
the communication and coordination in the Project team and raise to the
attention of the Project Manager any issue that needs to be resolved. In a
fast-pace environment, it is essential that this type of issue be managed
expeditiously.
Soft skills are thus essential for the Project Control Manager to assure
that proper communication and alignment happen. In addition, the Project
Control Manager needs to be able to detect and understand Weak Signals
from various contributors to the Project, so as to take action. This requires a
combination of analytical and soft skills to make sure that this information
is brought forward. Chapter 11 will further elaborate on the Project Control
Manager toolbox, and Chapter 12 on the necessary soft skills.
 Chapter 7:
Three Essential Transverse
Processes
Introduction
Project Control is at the centre of data gathering and sense-making. A
large number of interfaces between functions have to be monitored, and are
operated by the Project Control processes.
Still, Project Control must also make sure that some key transverse
processes are in place throughout the Project. Depending on the Project
organization, Project Control might not be responsible to establish and
maintain these processes. In all cases it must make sure they are functional
throughout the entire Project execution, and make good use of the data they
provide.
Management of Change
Management of Change is an essential process that is transverse to the
entire Project and is key to keep the Project in control.
The essential characteristics of a sound Management of Change
process include:
Changes are documented against a clear baseline that is
established and clearly defined at the start of the Project. This
baseline includes all relevant documentation (specifications,
technical requirements, schedule, budget, etc.). For each
change, precise references must always be included to the part
of the baseline that is changed,

Wide coverage of Management of Change:

all changes - it is absolutely not restricted to changes
that require the Owner’s formal agreement,
internal as well as external changes and changes
raised by suppliers and contractors,
physical changes as well as Project execution
changes,
There is a single Project-wide Management of Change process
across all disciplines,
Anybody in the extended team (including contractors) can
raise a change. The process should make it easy to do so, even
if it includes a first filter by supervision to make sure that
changes that are processed are real changes,
Consequences of any change are assessed across all functions
(Engineering – Procurement – Construction – Commissioning
– Cost – Schedule – Risk – HSE – Quality – Contract) prior to
any decision. A particular focus needs to be on consequential
impacts. As an additional line of defence, the changes are
preferably reviewed in a meeting in the presence of all
functions (a segment of the weekly PMT meeting is
recommended),
The initial consequence assessment is quick, and in particular
fits within any contractual time bar,
 No Change should be implemented prior to a formal decision
by the Project Manager. Decision on Change implementation
is then communicated to the team and all affected documents
and systems are updated to reflect the Change.
Changes can be implemented before contractual consequences
with the Owner are fully clarified if that is required, based on
the Project Manager appreciation,
When changes are implemented, consequences in terms of
interfaces with stakeholders are examined comprehensively
and documented.
Checks of proper operation of the Management of Change include in
particular:
Auditing that all internal and external changes are captured
adequately by the system (there should not be changes known
by part of the team and not captured, and there should rather
be some percentage of false alerts quickly closed-out),
Checking that assessment of the consequences is thorough
(including consequential impacts) and that the decision-
making cycle is timely to effectively take a decision prior to
the implementation of a Change,
Checking that the decision-making process is effective by
checking that some percentage of the changes proposed is
rejected,
Checking that the Project configuration (documentation) is
adequately modified and that updated versions are effectively
propagated to all concerned (in particular through version
control on site),
Checking that all approved changes are adequately included in
the updates of the Project Cost, Schedule and Risk models, if
possible as separate line items (at least for major changes),
Checking that Change Order requests are raised in a timely
manner to the Client where relevant.
Two types of changes are particularly the bane of Project Management:
Uncontrolled changes from the Client through informal
contact, comments to documents etc.,
 Uncontrolled changes by the engineering team sometimes due
to ‘over-engineering’, or after documents have been approved
and sent to suppliers or contractors.
To prevent these changes from by-passing without control the proper
Management of Change review process, some Project Managers even on
large Projects require their own signature on any revision of an Approved
for Construction document or its transmittal. This allows them to examine
systematically the justification for the revision and capture unapproved
changes.
Applicability of the Management of Change process at various
Project stages
The Management of Change should be applied to all changes
performed to the Project’s baseline, whatever its origin and time in the
Project.
One exception concerns the engineering design stage. The design
process is by nature iterative and it would not make sense to apply an
onerous Management of Change process at that stage. The Management of
Change should only be applicable once engineering documents have
reached a certain maturity stage, which is the earlier of:
Issued for Construction,
A revision sent to a third party (e.g. supplier) as a basis to
be used even if not formally ‘Issued for Construction’.
When it comes to changes happening during Construction, it is
essential to build on top of the normal Management of Change process a
simplified process that can be used on site to validate minor changes (after a
quick assessment mainly for safety). The scope of changes that can be
approved on site versus the changes that need to be fully reviewed and
approved in the office should be made extremely clear.
Changes happening during construction need also to be registered
carefully so as to be incorporated in the as-built documentation and the
lessons learned process.
Management of Change and productivity
One problem we often observe during Project reviews is the confusion
between Management of Change and variances to the baseline which are
due to productivity issues or events beyond the Project’s control.
Management of Change should not be used to justify (in hindsight)
productivity issues. Doing this confuses what are really changes to the
baseline and what are changes due to performance, making analysis blind
and raising the risk to lose control of the Project.
External Interface Management
Similarly to Management of Change, External Interface Management is
an essential process that is transverse to the entire Project and is key to keep
the Project in control.
The essential characteristics of a sound Interface Management process
include:
Ideally an Interface Management process is managed by the
Owner or its representative, which provides a single central
platform (register and the relevant process and forms) for
exchanging information between the main contractors,
It is always essential for contractors to setup an interface
management process between themselves and their own
suppliers and subcontractors, that interfaces seamlessly with
the Owner’s own interface management system when
available,
Any interface issue can be raised by any supplier or contractor,
either as a clarification to existing documents, or as a deviation
from existing documents,
Interface issues are preferably resolved quickly and
collaboratively. The objective of the interface process is to
agree on the interfaces between all interfacing parts of the
Project so as to enable all interfacing parts to meet the
associated technical requirements as specified in the Contract
or in standards and norms. In certain cases, one or both
interfacing parties may need to modify its intended
design/solution in order to achieve this. Such modification
should be subjected to a rigorous Management of Change
process. Where the change is a result of requirements that
were not covered by the Contract, a Change Order could be
requested prior to implementing the Change so as to ensure
that it is compensated for by the Client.
As part of the Interface management process, it is essential from a
contractual perspective to distinguish between technical clarifications and
technical deviations to an existing baseline. Only the latter can lead to
contractual discussions between parties.
Procurement / Contracting Post-Award
Package Management
Procurement activities cannot happen in isolation. Pre-award,
Supplier qualification exercises must involve all relevant
functions (HSE, Quality, Engineering, Construction)
Proper technical requirements must be prepared by
Engineering, with input from Construction and
Commissioning, HSE and quality, and possibly the future
Operator,
Proper control requirements need to be applied in terms of
Project Control and Contract management (ref. Chapter 4 for
the requirements).
The pre-award work is essential to ensure a successful outcome. In
particular, requirements, scope of work, compensation mechanisms and
schedule requirements as well as appropriate contractual mechanisms to
administer the subcontract must be appropriately defined.
It is the foundation for what comes next, the post award follow up,
which importance is too often underestimated in immature Project-driven
organizations. It is essential that the Project has a proper tracking and
follow-up in place until delivery. In addition to the follow-up of
manufacturing or service preparation itself, which is generally undertaken
by a special ‘Expediting’ function, it is important to designate ‘Package
Managers’ that will operate as contract and Scope Owners, coordinating
aspects belonging to all Project functions:
Act as a Single Point of Contact for all issues related to the
Purchase Order or Contract,
Ensure transmittal of all relevant Project requirements, in
particular regarding the format and periodicity of information
to be provided,
Ensure proper review of pre-production supplier documents
and other prerequisites by Quality and technical experts (in the
case of a contractor, pre-qualification and pre-mobilization
documentation); in particular, ensure that any double review
loop at Project and Owner levels happen in a consistent and
timely manner,
Expedite technical follow-up of Changes and Interface issues
that might be raised by the supplier or the contractor; or might
be required by the Project,
Expedite contractual follow-up of any issue, in particular
regarding changes or any other difficulty, in particular
regarding schedule,
Review regular Supplier/ Contractor progress reports, as well
as any reports such as third party inspections and Project /
third party meeting and visit reports to ensure a comprehensive
follow-up,
Participate to monthly status meetings in suppliers’ premises,
Participate to regular site visits,
Provide regularly updated cost and schedule forecasts for the
Project Control team, which might be distinct from the
supplier / contractor official forecasts.
Conclusion
The three transverse processes exposed in this Chapter are absolutely
essential for any Project to be successful. Sufficient attention must be
devoted to setting up and operating those processes. This will often warrant
to allocate a full-time experienced person to be allocated for Management
of Change and/or External Interface Management. Experience often can’t
be replaced when it comes to gauging quickly the impact of a Change or an
Interface Request over the entire Project, including consequential impacts.
Package Managers must also be clearly allocated to be responsible for
the coordination of all post-award aspects for suppliers and contractors.
Their profile may vary and they are not necessarily from the Procurement
department, as long as they are commercially sensitive and ready to
coordinate several functions. The package manager position can be an
entrance step in a personal development track towards a Project Manager
position and should be regarded as a development opportunity for
contributors with a few years’ experience.
 Chapter 8:
The Consistency Assurance Role
Introduction
After having ensured that the basic measurements are operating
normally and that proper communication and basic coordination processes
are in place in the Project Team, Project Control needs to put together a
picture of the Project both in terms of current status and in terms of end-of-
Project forecast. This picture needs to remain consistent at all times. This
requirement might highlight some discrepancies that need to be addressed
quickly to ensure continuous control of the Project.
Key Consistency Points between Project
Controls Processes
The consistency requirement covers naturally the usual Project triangle
of cost, schedule and scope (represented in our case by the Main Contract’s
requirement completed by the Project execution baseline). In addition, the
risk process is deeply intertwined with all these three dimensions and it is
essential to ensure consistency so as to avoid double-dipping or outright
oversight of certain risk components.
The table on the following page summarizes the main consistency best
practices between all those four dimensions.

Cost & Time-dependent resource costs updated

Schedule when schedule updated (Project

Management, key resources utilization),
Project Cost Model time-phasing
consistent with Project schedule,
Cash Flow (revenue receipt minus
payments issued) consistent with Project
schedule (milestones achievement, or
progress-based revenue),
If schedule is resourced, consistency
between schedule resource utilization
histograms and cost model
Forecast consistent with Actual cost and
actual physical progress (Earned Value
Management, productivity)
Cost & All scope comprehensively covered (full

Scope WBS coverage),

Approved internal Scope changes,
(Contract)
Client or Contractor claims and
approved external Change Orders
accounted for in Project Cost Model (if
possible in separate work packages for
tracking purpose),
 Cost forecast and quantities consistent
(quantity-based forecast)
Sensitivities for submitted but
unapproved Change Orders accounted
for,
Lump Sum, Rate-based and
Reimbursable cost elements clearly split
in Project Cost Model.
Cost & Cost & Revenue sensitivities consistent

Risk with identified Opportunities and Risk

register,
Contingency element consistent with
Opportunity & Risk register,
No double-dipping between allowances
and quantitative risk elements (to be
checked at the risk model line level),
Highly probable risk elements taken as
deterministic prudent cost forecast,
‘Achievable’ margin needs to be better
than reported margin (prudency
principle).
Schedule Approved Scope changes and Change
& Scope Orders accounted for, in particular
regarding new activities and Extensions
(Contract)
of Time on key milestones,
Reference to the latest contractually
approved schedule baseline
Consistent management of interfaces (in
particular, 3rd party supplied / free
issued elements)
Schedule Activity durations not padded, clear
& Risk identification of float and buffers
Contingency calculation takes into
account additional cost due to expected
additional duration
Scope Opportunities and risk linked to future
additional or removed scope are taken
(Contract) into account in the risk model,
& Risk Liquidated Damages accounted for in
the risk model,
Other applicable Incentive / Penalty
schemes taken into account in the risk
model.
Root Causes of Discrepancies
Supposing that Cost, Schedule, Risk and Scope (Contract) were
perfectly consistent at the establishment of the first baseline at Project start-
up, any subsequent discrepancy is the result of a change of circumstances.
These can roughly be separated based on their origin between:
Changes due to internal Project causes,
Changes due to the Owner / Main Contract Client (this
includes the interface with other Main Contractors on the
same overall Project),
Changes due to Vendors / Contractors,
Changes due to other external stakeholders (e.g.
regulators, customs, other authorities).
Changes are also generally of two different types.
Changes due to conscious decisions related to Project
execution (change of scope, of supplier, of execution
approach etc.),
Changes due to unexpected productivity issues of the
resources used by the Project (which might be intrinsic to
a given discipline or due to lack of coordination between
disciplines).
The first type of changes should be captured by the relevant
Management of Change process and all the other information management
processes. The second type of changes is more elusive because it does not
result from a decision, it can thus only be observed happening and the
resulting consequences established after the relevant activity has started.
The resulting 4 x 2 table describing all the root-causes of change allows
determining what processes need to be enhanced to avoid discrepancies. It
is not a surprise that we refer back to the major coordination processes
described in Chapter 7. (Note: internal discrepancies inside each discipline
have been addressed in the respective Handbooks).

Control Processes for the Treatment of

Discrepancies between Cost, Schedule and
 Scope
Decision- Productivity-
related related change
change
Internal to Management of Joint cost- schedule-
Change (MoC) - risk forecast (refer to
Project detection and our Cost Control,
treatment (ref. Schedule handbooks)
Chapter 7)
Owner/ Link between Contractual
Management of Management of Client’s
Client Change and Client free-issued items
Instruction/ Change delivery dates,
Order management mobilization windows,
(ref. Chapter 7) interface constraints
(refer to our Schedule
handbook)
Vendor/ Link between Vendor post-award
Management of management (Package
Contractor Change and vendor Manager role) (ref.
post-award Chapter 7)
management (ref.
Chapter 7)
Other External Interface Management (and link with
stakeholders Management of Change) (ref. Chapter 7)

As we can observe in the table, productivity-related changes pose the

larger challenge in terms of consistency maintenance, because they do not
result from a clear decision as a starting point. Constant monitoring is thus
necessary to ensure that the forecasting exercise happens consistently across
all Project Control functions.
Consistency Management Best Practice
Monthly Project Control alignment meetings
To ensure consistency, it is essential that Cost, Schedule, Risk and
Contract forecast updates be coordinated, with a particular focus on those
issues related to productivity-issues. A good practice is thus to have regular
coordination meetings between these functions under the responsibility of
the Project Control Manager. The following section is written on the
assumption of a monthly reporting cycle, which is generally the case on
large Projects.
A monthly coordination meeting involving all Project Control
disciplines is held at the start of the monthly update cycle, just after the
review of the Project Periodic Report by management, to frame the longer
term upgrading and forecasting efforts that need to be implemented for the
next cycle. These can result from management requests during the last
Project Periodic Report review meeting, or from the identification of topics
which require significant effort because of their widespread impacts. These
longer term forecasting efforts typically need to be implemented in the first
two-third of the month before the data comes in for the Project update
taking into account the current actual progress of the Project.
A second coordination meeting is held ten days to one week prior to
the issuance of the next Monthly Project Periodic Report, to frame what are
the key forecasting activities to perform on the basis of the new data on
Project progress. These re-forecasts are typically less wide-ranging due to
the limited time available. At this stage it might happen that some re-
forecasts that require more work cannot be achieved within the time
constraint. The bulk of the exercise then needs to be postponed to the next
monthly cycle. It is up to the Project Control manager to decide whether to
include in the present forecast (cost or schedule) some provision for the
new event, before it can be fully re-forecast and substantiated during the
next monthly cycle. In any case it is recommended to try to maintain
consistency at all times between cost and schedule, e.g. if the reforecasting
exercise cannot be done in time for cost but can be done for schedule, to
decide either not to publish any, or to publish the schedule update together
with a quick estimate for Cost.
Checking for Consistency in Reports
Project Periodic Reports are documents where consistency between
Cost, Schedule, Risk and Contract need to be specifically achieved. Lack of
consistency will significantly reduce the credibility of the reports and
undermine management confidence that the Project effectively under
control.
The Project Control Manager is directly responsible to ensure that this
consistency is achieved.
In addition to the general consistency issues described in the previous
table, the following aspects need to be closely monitored:
Reported monthly burn-rate (man-hours) of the Project
management and engineering team versus its known size –
discrepancy might indicate a lack of control on timesheets and
allocation of time to the Project,
Overall consistency issues between reported commitment
levels, status of the procurement plan and actual cost incurred,
Consistency between the “top Opportunities and Risks”
mentioned in the report, the cost sensitivities and the
contingency basis,
Field progress reports (including pictures) need to be
consistent with the reported physical progress from the
schedule. Discrepancies will indicate issues regarding
schedule progress update.
Continuous improvement and evolution of Project Control
processes
The analysis of discrepancies often results in improving or correcting
data transmission and treatment processes within the Project, involving
other disciplines as well (such as, typically, Procurement).
Because of the evolving nature of any Project as it moves between its
different phases from engineering to construction, it is to be expected that
the Project Control processes will have to evolve as well. Any discrepancy
identified can be the sign that such evolution needs to happen in the
information management process.
Assessing Consequential Impacts
Consequential impacts need to be addressed adequately in all analysis
and decision-making. The Project Control Manager is the only person that
can coordinate the assessment of consequential impacts, because of his
overview on the Project.
The Project Control Manager must have the tools to identify inter-
dependencies and establish what could be the consequential impacts of
events reported by individual functions. The main effects are often in terms
of schedule with delays propagating through the schedule network,
creating:
Extension of time for Project Management and other fixed
time-dependent costs,
Possible standby of resources (or alternatively, additional
mobilization/ demobilization costs),
Interface issues with stakeholders,
Additional storage of equipment and material,
Need for unforeseen or additional preservation,
Loss of availability windows for key equipment and
contractors,
Loss of seasonal weather windows,
Contractual issues with vendors, contractors or clients (such as
liquidated damages and claims for changes of site availability
dates).
Keeping on top of consequential impact is an essential piece of
maintaining consistency of the Project Model (Cost, Schedule, Risk and
Contract), by proactively modelling and responding to these consequential
impacts in advance of their possible effect. In addition it does not make
sense to update the Project Model for an event by only considering direct
consequences and forgetting about consequential impacts that can be very
significantly more onerous.
Consequential impacts due to mixed reimbursable / lump sum
elements
One particular case that requires attention involves Main Contracts
involving a mix of reimbursable or rate-based work with lump sum work.
 Delays or additional scope on the reimbursable portion of the work
must lead to an extension of time that generally needs to be formally
requested as a Change Order. It may also lead to substantial consequential
cost impacts on the Project that are much harder to justify and claim, such
as:
Extension of the Project Management Team,
Impacts due to change of dates on item delivery, asset
availability,
Etc.
In these situations, discussions with the Client will always evolve on
how to estimate the share of the impact of the delay when the Project was
also supposed to perform other work under its lump-sum in the meantime.
The only easy way is to include the cost of consequential impacts in the
rates for extra work, but it is not always easy to do so and remain
competitive. Otherwise, the only solutions are to:
implement a fine enough measurement system of the work
done under the Lump Sum portion to be able to justify a
Change Order request for consequential impact,
put a clear limit in the contract as to permissible time
extensions of the reimbursable segments.
Identifying and Assessing Weak Signals
Complexity, Weak Signals and Consequential Impacts
The more complex the Project, the more:
Isolated events will generally have consequential impacts,
Small disturbances, also called Weak Signals (even remote
from the core of the Project) can have very significant impact,
up to the point of significantly disrupting the Project.
This is due to the fact that Project complexity is a direct consequence
of the interdependency of activities and responsibilities between
contributors.
Tracking small disturbances (Weak Signals) and assessing
systematically their consequential impacts is thus an essential task. In
complex Projects, a forecasting process that would not consider Weak
Signals and consequential impacts would be very insufficient.
An essential role of the Project Control Manager is to help identify and
manage Weak Signals and consequential impacts of individual variances. It
is a role that only the Project Control Manager, sitting at the confluence of
Cost, Schedule, Risk and Contract, can exercise.
Early detection of Weak Signals
Weak Signals are generally detected in the form of:
a significant recurring discrepancy between the baseline
and the actual events,
a discrepancy within the Project Model,
a discrepancy between what is reported informally and the
Project Model,
a contextual element that changes the environment of the
Project and might impact Project execution.
Significant difference between the baseline and the actual unfolding of
events, be it cost or schedule, is an indicator of a potential issue that might
be more widespread on the Project and have significant consequential
impact. It might just be an estimating issue, but that always needs to be
analysed and understood further.
 The identification and treatment of discrepancies between Cost,
Schedule and Scope is the subject of the previous section. It is also useful to
consider each discrepancy not just as a dysfunction of the Project Control
processes, but also as a potential indicator of a Weak Signal and assess it as
such.
As described in the previous Chapter about independent
communication checks, Weak Signals can also be picked up through
informal conversations with the Project Team members. Informal
conversations often allow to identify Weak Signals before they become
visible in aggregated Project indicators, in the form of discrepancies
between official reports and actual situations.
These conversations can also highlight contextual elements that are not
immediately visible in the Project monitoring. These contextual elements
can be internal to the Project or impact the Project environment and the
assumptions that were made at the start of the Project. Internal contextual
elements include for example particular preferences/ blind spots of key
managers, behavioural issues of key contributors, specific lack of attention
to certain areas, particular communication issues in particular when English
is not the first language of most workers on site, specific morale and
comfort issues at the Project office or on site (remoteness and food being
often a key factor) etc. Environmental contextual elements include all sorts
of events or situations such as the change of a key stakeholder’s
representative, local community politics, Project site’s country politics,
weather and other natural events, etc.
Weak Signals can be very significant in terms of impact. Some initial
filtering must be made to identify those events that might impact the Project
and that needs to be subjected to some additional investigation. One must
keep in mind that the biggest disruptions sometimes come from far-flung
events that have impacts that can be initially remote but that gain
momentum and impact the Project significantly. This is in particular the
case when the Project mobilizes workers or uses suppliers from distant
countries.
Treatment of Weak Signals
Weak signals must be investigated, filtered and their potential
disruption assessed. Many will reveal to be innocuous, few will not. This
initial filtering is generally based on:
An in-depth understanding of the resilience of the Project
execution model and where critical activities are, in particular
in terms of schedule and availability of alternate execution
options,
Some quick scenario planning,
The joint Project experience of the Project Management Team.
Upon identification of a Weak Signal of concern, investigations must
be done quickly to identify whether it would actually warrant an action to
protect Project execution. In that case, in addition to treating the symptom
that has been discovered (such as a discrepancy) it is always essential to
perform a root-cause analysis to check that the underlying cause is well
understood. Then it is essential to perform the following additional steps to
check that the underlying cause is not:
pervading further aspects of Project Control and Project
execution,
creating substantial consequential impacts or domino effect on
other areas of Project execution,
combining with other simultaneous disruptions with the
potential to create a much larger impact.
Weak Signals identification also has a close link with Project
Opportunity and Risk Management as some Weak Signals with high
potential consequences will be candidate for the update of the Risk
Register, including definition and assignment of mitigation actions.
Re-baselining
In the course of the Project execution, changes might happen that have
such a major significance that the entire Project execution plan needs to be
re-baselined, because the current baseline is not any more a useful reference
point and it is impossible to revert back close to it. It might result either
from a very significant change, or from a less important change that has
major consequences due to some external factor (e.g. in some conditions a
relatively minor schedule delay might lead to missing the adequate season
and push Project execution by one year). A key criterion is whether there is
still some hope to come back close to the baseline through a recovery plan,
or if that appears impossible due to the circumstances.
Re-baselining is a very significant exercise which aims as re-
establishing a consistent baseline encompassing the Project execution
strategy, scope, cost, schedule, risk. The amount of work is substantial and
quite similar to the initial baselining (ref. Chapter 4), although most of the
data structure will not have to be redesigned. The Project Control manager
has a fundamental role in orchestrating the re-baselining exercise and
verifying that the final result demonstrates consistency between all
disciplines.
When the re-baseline is applied, historical reference to the previous
baseline needs to be maintained as a comparison point.
Managing the re-baselining exercise in parallel to Project
execution
Implementing a re-baseline exercise at the same time as continuing to
run the normal Project reporting and updating cycles on the basis of the
previous baseline can be a challenge from the resource point of view, and
needs to be carefully planned. The effort will typically span over several
months. Issuance of updated reference registers and schedules need to be
coordinated in a clear manner to avoid confusion. Proper communication
need to be maintained will all contributors regarding new expectations for
planned dates.
During that period it is essential to continue updating the previous
reference for actual and forecast data to ensure a continuous Project
piloting. However, that reference is now not really applicable to the Project.
This will create problems between what is reported and what is really
happening and it is a dangerous situation from the perspective of keeping
the Project in control.
Unfortunately this transition phase sometimes lasts longer than it
should due to the ongoing commercial discussions that are inevitably tied to
the re-baselining exercise. Project and Client alike will use the schedule to
found commercial arguments, which might lead to stretch the use of the
initial obsolete schedule reference, and produce schedule extracts that are
commercially-driven. The Project baseline generally needs formal approval
by the Client. This might delay significantly the formal application of the
new baseline.
There is no good solution to that bind. It is not recommended for the
Project to work against a second non-official Integrated Project Schedule.
Because only the Integrated Project Schedule is generally due for approval,
the recommended way forward for the transition phase is to update all the
lower level registers and detailed schedules that drive the work at
deliverable level according to the new baseline intent in terms of forecast
dates, and manage the inconsistencies with the Integrated Project Schedule
which will retain the initial baseline for a while.
Conclusion
Ensuring consistency between the four functions of Project Control
(Cost, Schedule, Risk and Contract) is an essential role of the Project
Control Manager, who is the only person to have a full overview of these
functions’ output.
Ensuring and reporting consistent data is essential to demonstrate in a
credible manner that the Project is effectively under control. Each time
some discrepancy is identified the Project Control Manager should raise the
issue to those members of the Project Management Team accountable for
the relevant areas. Moreover, the Project Control Manager needs to identify
and implement data gathering process upgrades if required after a thorough
root-cause analysis.
The Project Control Manager is also the only person that can
apprehend and analyse fully the consequential impacts of events – actual or
potential such as in the case of Weak Signals. He must play this role
systematically together with the identification and assessment of Weak
Signals – internal or external to the Project. Actually the identification,
observation and analysis of Weak Signals is an essential Project Control
capability.
 Chapter 9:
Independent Data Checks and
Project Reviews
Introduction
In addition to the continuous data gathering and transmittal it is
essential to keep independent reality checks in place.
These independent checks need to cover all aspects of data assurance,
communication assurance and consistency assurance, which is why they
have been gathered in a separate Chapter.
Challenging data with reality:
Independent Data Checks
In addition to the data flows that are setup at Project start-up, it is
important to verify that data is accurate and effectively represents reality.
Data consistency checks should of course be carried out continuously
(consistency with previous reports, between different datasets etc.).
Notwithstanding these intrinsic checks, it is essential that Project Control
develops an independent data check system.
This independent data check should be focused on the most critical
issues for the Project (activities close to critical path, cost items most prone
to large deviations), and/or the suppliers and contractors for which limited
track record exists. Still it is also important to include some random checks
on less critical elements to verify that the overall data available is not
corrupted.
Data checks should be carried out by Project Control personnel and site
Quantity Surveyors.
The best way to run an independent data check is to go on site
(worksite, construction site, vendor site) to check effectively what is the
actual progress, and whether commercial issues are looming that have not
been identified. Typical examples of findings include:
Equipment and resources level on site significantly different
from what is reported (generally higher),
Actual manpower on the work face compared to expectations
(as an indication for expected progress and billings),
Material and equipment is delivered in poor conditions, not
compliant with expected drawings or specifications or with
substantial outstanding work to be performed,
Vendor / contractor expects commercial bonuses or envisages
claims that have not been reported,
Actual progress significantly lower than reported, most often
in terms of work remaining to be done than on work actually
performed (e.g. re-work required due to quality issues,
 significant changes of the production or quality check
process),
Forecast date of delivery substantially different from what is
envisaged by the Project.
While these checks should be carried out liaising with the Scope
Owners who are normally responsible for ongoing updates of that sort, they
should remain independent to make sure that Project Control benefits from
an unimpaired view on what is really happening with the Project. While
generally, site personnel tend to have a fairly reliable picture of when and
how their remit can be completed, it might not be the case for site
management. Issues such as relationship with the supplier / contractor or
certain contractual strategies can also influence the Scope Owner’s
judgment.
Construction site personnel being also at the end of the Engineering-
Procurement-Construction chain generally have a good view of any issues
permeating Project execution such as for example:
Excessive or too late engineering changes (leading to
rework and delays),
Material delivery timing and condition,
Issues requiring changes of priorities such as lack of
suitable material or as-built drawings,
Lack of effective work front planning leading to
inefficiencies,
Etc.
Project Control Managers are encouraged to formalize this independent
data check through a sampling plan, which has to be flexible to respond to
the situation. The intensity of these checks will depend on the reputation
and track record of the suppliers and contractors involved.
Independent Communication Checks
In an interesting parallel with the independent data checks for data
assurance, we believe that the Project Control Manager should also
implement an independent Communication Check program. This aims at
ensuring through an independent check the effectiveness of all the formal
communication channels described above.
A sampling program must hence be developed which also needs to
include some random elements for completeness.
The random element should be informal conversations between Project
Control and Project team members, completed by field trips to remote
offices, main contractors’ facilities and construction site(s).
Possible discrepancies in understanding or vision between contributors
might be revealed in these interactions. These informal conversations can
also identify issues with the data that is reported or forecast, even before it
becomes visible in the aggregated Project indicators. In particular, site visits
are known to often identify substantial differences in status and
understanding with the Project office, and are thus a mandatory part of the
communication assurance check. For example, it is not rare that a site visit
allows to identify significant issues with engineering and procurement.
In the case of multiple engineering and Project offices, and even more
if they are using different systems and processes (such as typically in a
consortium), visits are essential to understand the reality of the work. It
might be that there are confusions in terminology or definition of key
indicators used for Project Control, and this must be challenged and
understood.
The most successful Project Control Managers are good listeners and
must entice their teams to listen well to the informal communications going
on within the team and on the worksites.
Independent Project Health Checks and
Peer Reviews
The most essential element of independent check is to expose the
Project from time to time to external eyes at the detailed level. The form of
this exposure varies but generally involves a team of experienced external
reviewers spending one to two weeks within the Project, in the Project
office as well as on the construction site where relevant.
Having outsiders will allow a fresh view on the Project execution and
its strategy. The review if successful will confirm a number of actions and
will ask challenging questions on other areas.
Large Project organizations will use for these reviews reviewers from
the organization that have not been involved in the Project or its tender/
feasibility study. Often this leads to using reviewers from other
geographical centres and is also very beneficial to ensuring a consistent
Project execution practice throughout the organization. Smaller
organizations will often ask recognized external consultants or Project
professionals to provide the service. The latter practice has the additional
advantage to challenge the ways of working of the organization compared
to best international practice, and should also be used from time to time
with much value by established organizations.
The most mature organizations generally have a review framework and
methodology in place, with a detailed questionnaire covering all aspects of
Project execution that needs to be covered by the reviewers. This
questionnaire allows identifying those areas that warrant closer inspection
and deeper analysis. Such a framework is provided by external reviewers
when not available internally.
Consistency checks should be part of those reviews, with usage of tools
such as Earned Value, cash versus cost analysis etc. Orders of magnitude
and rules of thumb should be used as well to challenge the Project’s data
and reports. Benchmarks from other Projects can be used, either on the
basis of the reviewers experience or in a more structured manner.
Visits on site are always extremely revealing of the condition of a
Project and its odds of success – they should generally be included in these
independent checks notwithstanding the logistical difficulties to reach the
work sites.
Project health checks or Peer Reviews involving reviewers external to
the Project are not well received in all organizations. Many organizations
still exist where the Project Manager considers the Project to be his own
playing field and is ready to forbid the presence of inquisitive aliens.
However modern transparency requirements and requirements in terms of
Enterprise Risk Management for listed companies support increasingly
those independent reviews as an assurance of proper control avoiding major
issues to remain hidden. It is thus definitely the trend to have more and
more thorough independent reviews of Projects in most organizations.
Another area of caution is that sometimes the recommendations from
Peer Review and other external reviews are simply ignored by the Project.
It is important to check that these recommendations are followed up and
closed by the Project.
Conclusion
Checks of data and Project condition independently of the normal
processes are a must to detect major control issues. A specific program
must be put in place that also needs to include some random element to
avoid any blind spots.
Independent health checks and peer reviews are essential control
processes that must be implemented as best practice and to respond to
increasing internal control requirements.
Due to some organizational cultural reasons some of these independent
checks are not always implemented whereas they do provide consistently
substantial value to Projects, and provide assurance to senior management
that what is reported is consistent with reality. Independent reviews and
check must be applied, in particular if there is resistance from the Project,
which may indicate that some issues might need to be uncovered.
 Chapter 10:
Devising Custom Indicators, Using
Visual Dashboards and War-
Rooms
Introduction
At the end of the day, all the work done by the Project Control Manager
aims at allowing the Project Manager and its management team take the
right decisions at the right moment.
The challenge is quite similar to building the relevant indicators in an
airplane cockpit. Over time, the number of sensors on commercial aircrafts
has increased tremendously from a dozen in the 1920s up to several
thousand in the most modern jetliners. Cockpit design has had to evolve,
and it is not possible anymore to show at all times all sensors indications,
contrary to what was attempted until the 1960s. Modern cockpit displays
thus need to filter what will be displayed. They attempt to show the most
important and relevant information at all times in a usable manner to allow
the pilot to take the right decision. The information displayed will change
with the flight phase, aircraft condition, flight configuration and input from
the pilots. This filtering ability results from extensive studies that define
prioritization rules for information. Displays allow digging deeper in
aircraft systems to understand the cause of an alarm. A key issue to avoid
overwhelming the pilot in case of massive multiple failure so that at all
times the most important and relevant information is always shown – so as
to allow the pilot to take the right decision.
In a Project, the role of the Project Control Manager is quite similar to
a cockpit’s engineer. The challenge of dealing with very large number of
information sensors is also a reality for large Projects. Beyond the ‘usual’
Project indicators, the Project Control Manager must make sense of all the
incoming information. What needs to be displayed will change with the
Project phase and condition. During the Project course the Project Control
Manager must also be ready to develop specific temporary indicators to
help the Project Manager take the right decisions.
Another useful image is a three-dimensional object. It is necessary to
take several perspectives to understand fully its depth and shape. At any
moment these indicators must be designed so that when brought together
they give a sufficient variety of perspectives on the Project to enable a full
grasp of its multi-dimensional shape.
In addition, management experience for example in the Total Quality /
Lean Management movement has shown the power of visual management,
whereby key indicators are posted visually on the workplace to guide and
motivate workers. In the same spirit, and with the help of increasingly
available data aggregation and visualization systems, the Project Control
Manager must setup relevant visual displays in the Project Office to foster
communication and alignment of the Project Team. Some Projects
nowadays go as far as to create ‘war-rooms’ where all the important Project
execution dashboards and indicators are displayed and updated
continuously.
Devising Indicators
Standard indicators
Some key aggregated indicators are used by all Projects and are
standard in all Project Periodic Reports.
These are typically:
HSE and Quality standard Key Performance Indicators (both
lagging (e.g. incident and accident statistics) and leading
(effort on prevention measures)) and comparison with targets,
Overall physical progress and progress by main function
(Engineering, Procurement, Construction, Commissioning)
often with associated S-curves and comparison with the
baseline,
Actual and forecast dates of key Project milestones compared
to the baseline, convergence plan deliverables dates and actual
gate dates, and float monitoring indicators (refer to our
Scheduling Handbook)
Overall cost forecast and comparison with updated budget, and
overall Project financial performance (Project-end and
reporting period end),
Project invoicing and cash flow status,
Change Order amounts (including those identified, submitted,
in dispute, rejected and approved),
Man-hours, bulk & commodity quantity growth indicators,
Procurement status for the main packages (including changes
and comparison with baseline budget),
Procurement status for bulk, materials and critical
consumables (including delivery status),
Sensitivity analysis on expected Project’s completion cost, and
updated value of contingency,
Actual and forecast utilization of key shared resources.
Additional indicators generally recommended include:
‘Cost of non Quality’ – generally derived by a simple category
analysis of all cost variances since the start of the Project, that
 allow to focus management attention on those areas where
estimating or predictability is weak,
Overall cost progress and comparison with physical progress
(at high breakdown level),
Overall and detailed level of allowances (cost that is expected
to be spent but has not formally been allocated to a precise
budget),
Productivity of Engineering at a fine granularity level,
Construction tasks performed versus planned in the last period
and other productivity indicators,
Indicators related to the Project Management Team’s
production performance:
General Engineering production (e.g. time from
document start to IDC, from IDC to submission
including average, spread and target to foster
alignment),
Specific indicators on critical documents (sub-set of
documents that have been identified as such in the
document register),
Purchase Orders (number and value),
Indicators of the Project risk register status (e.g. number of
high level risks, of actions closed etc.),
Short term indicators – Project successes, achievements in the
past week or month; and key milestones planned in the next
week or month.
Custom indicators
An essential role of the Project Control Manager is to develop, track
and display relevant specific performance indicators for the benefit of the
team. They need to support key areas of Project performance through the
known effect that what gets measured gets done. The Project Control
Manager needs to rely on the other members of the Project Management
Team to propose and update those indicators.
At any given time, these custom indicators must be in limited number
and aligned with the priorities of the Project Manager. They thus need to be
carefully chosen and possibly renewed regularly. Some will be used for a
large part of the Project duration, while some might be devised and used
only for a few weeks during a critical phase.
The following suggestions are examples only, as it is necessary to seek
always the most relevant indicator for the topic and the objective that is
sought. Those custom indicators will also be highly dependent on the actual
Project activities. It is natural that some indicators will have to be created or
turned off depending on the Project progress.
Examples of long duration custom indicators [in brackets, the typical
period of usefulness]:
Key contractual deliverables status versus plan [first 6 months
of the Project],
Mobilization rate of Project team vs plan [first 6 months of the
Project],
Management of Change statistics (number of changes
submitted, approved, cycle-time etc.) [entire Project]
Procurement (technical specifications to award duration)
[Procurement phase],
Airfreight costs for remote worksites (as an early indicator of
delays in deliveries requiring to switch the expedition mode)
[second half of Procurement phase],
Project Management Team full running monthly cost vs
expected [second half of Project],
Etc.
Examples of short duration custom indicators:
Float monitoring for specific milestones or Convergence Plan
gates [refer to our Schedule Handbook]
Identification of bottlenecks for document review with
indicators on review by lead/ manager [engineering],
Time and effort for final production of documents (from
sending to the Client for review until Approved for
Construction) [end of Engineering],
Number of revisions of Approved for Construction documents
[end of Engineering to Construction],
Welder qualification status [Construction],
Short term productivity indicators on specific critical path
operations that can be described by a simple indicator (e.g.
pipeline/ welding/ drilling/ building/ earth moving production
rate etc.) [Fabrication and Construction],
Run down curves, punch list extent and close-out rate [end of
Fabrication, end of Construction and commissioning],
Allowance and contingency convergence; as-built documents
progress ; procurement packages close-out [end of
Construction, Project close-out],
Etc.
Project Data-Mining
Since modern Projects produce more and more data, and since this data
is increasingly available in an electronic format in various databases, it is
possible to extend the concepts of ‘Big Data’ mining to single Large
Projects.
The traditional indicators referred to in the previous section were
mainly produced from a single data source or system. A number of data-
mining tools now allow to easily cross-reference data from a variety of data
sources to produce indicators that are useful and make sense to the Project.
The extent of data-mining and the way it can be implemented is heavily
dependent on the IT systems and data structure of the Project. It will be
much more effective when all data is available in the form of databases,
hence this is another incentive to move away from Excel-based systems.
The increasing usage of mobile handsets to capture data, and of cloud-
based applications to store it, is a strong enabler because remote site data is
increasingly captured in digital form (instead of paper) and instantly
available for analysis. We can thus expect to see a significant development
in this area in the next years, and further developments in real-time
dashboards for time sensitive parts of the Project.
The following examples assume a usual systems setup where the
Project uses separate tools for Scheduling, Cost Control, Procurement &
Accounting, Document Control, Construction follow-up, Local
Commitments, Site receipt and storage/ warehousing, Commissioning and
defects management.
Earned Value analysis [crossing Schedule & Cost] possibly in
a much finer breakdown than usual (e.g. by document
production stage),
Detailed Construction Earned Value analysis [crossing
Construction follow-up, Schedule and Cost],
Engineering Data Management from engineering to
construction,
Material site reject and site material efficiency,
Material allowances detailed analysis and material status,
 Material availability at site vs drawings available for
construction (these two processes run in parallel and in most
Projects, a statistical rule of thumb is used instead of a detailed
analysis and dashboard, giving poor visibility on the actual
workfront),
Vendor inspection data flow in all relevant systems,
Site commitments and logistics tracking,
Defects management analysis, repair rates and costs forecasts,
Etc.
Warning: automated dashboard generation still needs a check for the
validity of the data as it happens often that changes in a database will lead
to inaccurate dashboard. A validation process thus needs to be put in place.
Producing and Using Visual Dashboards
Visual dashboards on the workplace
In addition to raw Key Performance Indicators, experience shows that
communicating with the Project team through visual indicators is a great
way to foster continuous alignment. This has been recognized also by the
early practitioners of Total Quality Management such as Toyota, to enhance
teamwork: Kanban boards[1] or Heijunka boxes[2] are in fact visual
dashboards on the workplace, to which the workers are to refer regularly.
Where in the past this required physical paper-based dashboards, with
the production and printing constraints associated, those dashboards can be
today easily produced and updated on large screens. This gives the potential
capability to update the situation in a continuous manner (although there is
still the need to check the quality of what is displayed), and also show more
data and messages (although it always remains important to prioritize the
right information).
Visual dashboards need to be well designed so as to convey meaningful
information, including how it fits within the wider context of the Project.
Usage of trend curves or similar indicators that show how a particular
indicator evolves over time will always give much more value to the
information.
As a general recommendation, we suggest to try to minimize the
number of visual dashboards and make sure their meaning is easily
understood by Project Team members (if necessary, by including legends
and explanations).
Recommended visual dashboards include:
The Project Objectives and Project Charter,
The updated Convergence Plan[3] (refer to Scheduling
Handbook),
Progress S-curves by function or sub-function where relevant,
Maps of the facility showing updated progress by zones,
Count-down prior to key milestones (e.g. worksite
mobilization, start of commissioning) with associated
remaining activities,
 Run-down curves towards the end of Construction and during
Commissioning.
Participative Forecast
An interesting technique is to use the ‘wisdom of the crowd’ effect to
forecast some short term performance related to productivity, or a particular
milestone date, preferably for activities outside the Project Office such as
Construction activities.
This technique not only produces a forecast and a sensitivity around it.
It will allow the Project Manager to gauge the feeling of the team. It is also
a great tool to foster alignment and interest of the whole Project Team
around Project activities outside the Project office, and on Key Performance
Indicators for the Project. The steps to be followed are simple:
Identify an activity spanning over 3-6 months that is critical to
the Project, or a key milestone date,
Let the entire Project Team (including secretaries and
assistants, document controllers, tea lady or janitor…) vote on
their view of the key indicator (e.g. productivity) or date – this
will create great buzz and internal communication within the
Project team,
From the votes, produce an average and a standard deviation,
Produce a visual dashboard to track the actual update versus
the team’s vote,
Give an award to the vote that was the closest to the final
indicator or date.
War-Rooms
A relatively new trend in the Project industry is to systematically
implement ‘war-rooms’ where lots of indicators are displayed graphically
on the walls. This room normally serves also as the main meeting room for
the Project Management Team.
This is not a new concept – again, the Toyota Way promotes the
concept of ‘Obeya’, the “great room” of Lean Management where the
management gathers to undertake a higher level of effectiveness in
communication and decision-making.
Leveraging on new technology, modern war-rooms not only have static
displays of visual dashboards. They should also provide data-mining tools
and interface to allow for further data analysis.
Conclusion
Developing the adequate set of Key Indicators is an essential skill for
the Project Control Manager. He needs to demonstrate a pro-active attitude
to define standard indicators for the Project duration as well as custom
indicators to respond to temporary concerns and focus areas. These
indicators brought together must give a sufficient variety of perspectives on
the Project to enable a full grasp of its multi-dimensional shape.
It needs furthermore to be leveraged with visual management tools,
whereby meaningful information is made available to the entire Project
Team in a visual manner.
The concept of war-rooms is developing rapidly in the Large Project
community as a way to concentrate and take advantage of the capabilities of
visual management and data mining.
With increasing data generation on large Projects, coupled with mobile
device data capture and cloud-based systems, the possibilities of developing
meaningful indicators expand significantly. It is essential to develop in
parallel an increased capability to make sense of the information and
produce the right aggregated dashboards that will drive the Project
Manager’s actions. The challenge in the next years will be to avoid
information overwhelm and understand how to better produce meaningful
synthesis to effectively drive proper decision-making.
 Chapter 11:
The Strategist Role
Strategy is about making sense of complexity.

In complex Projects, strategy is about taking a medium/ long term view

and devising long-term action plans. Strategy is all about making sense of
current events with sufficient perspective so as to respond adequately to
what is happening. This capability builds on a systemic understanding of all
the key drivers of Project success. In large Projects, the Project Control
Manager is the only Project Team Member apart from the Project Manager
that has the time and the means to develop that strategic capability.
Why Are Only the Project Manager and
the Project Control Manager Focusing on
the Medium / Long Term Perspective?
In Projects, most contributors are focused on short term urgent issues.
It is the nature of Project execution that it appears often to the practitioner
as a succession of activities to be performed and issues to be resolved in a
high time pressure context. This is often accompanied by a high level of
stress.
This effect is partly due to the fact that Project planning does not
account for natural variation and thus is always too optimistic (refer to our
Schedule Handbook). Any common disruption such as contributors absent
for sickness or even business travel will create stress to the Project
organization, in particular if it has not organized itself to have substantial
organizational reserves.
Project Managers are sometimes not immune to that operational
pressure, which is added to the time spent to demonstrate leadership
through visits on various sites and participation to collective events. The
larger the Project, the more globally spread it generally is, resulting with the
Project Manager spending easily half of his time outside the Project office.
The Project Control Manager is often the one who holds the house in
the absence of the Project Manager. Having a relatively sedentary role
outside the operational pressures of Project execution, and by nature being a
keen observer of the Project’s events, the Project Control Manager ends up
having both a comprehensive overview of the Project status and evolution,
and the liberty to examine with a cold eye what is happening on the
medium and long term. As a result, the Project Control Manager is often the
only Project Management Team member outside the Project Manager that
can develop and maintain a comprehensive medium term outlook, beyond
the next few weeks.
This role on the Project is absolutely essential. It often consists in
evaluating possible consequences on the medium term, when relevant - in
particular when Project Management Team members propose reactive
approaches to events by proposing some short term patches. In this case, it
is a must to remind the team that responding cleverly to events is better than
reacting to them.
To come back to our ocean sailing race image, the routing team
onshore has the capability to devise the appropriate strategy through
superior access to information and also, removal from the urgencies of
sailing a ship, which allows it to propose the best strategy. And when the
navigator happens to be on board the ship, he is also removed from normal
watch duty so as to be able to take the time to devise the best strategy.
Projects where this capability is missing, either because the Project
Control Manager has let himself be overwhelmed by data collection and
consistency assurance tasks, or because the Project Control Manager does
not have the seniority and experience, are clearly marked for failure. The
experienced Project Manager can try to compensate, but in large Projects
will often miss the time to do this part sufficiently well.
The split of the roles between the Project Manager and the Project
Control Manager will vary depending on their circumstances, experience
and preferences. Ideally they should complement each other in terms of
focus area. In any case the Project Control Manager should play the role of
Strategy Manager for the Project, running the number and performing
scenario analysis to support strategic decisions.
How to Fulfil the Project Strategist Role
The keys to success include:
Making sufficient time and keeping sufficient resources for the
strategist role:
Spend sufficient time on forecasting apart from
actuals gathering and reporting,
Always look for the root-cause beyond the obvious,
Exploit inconsistencies from different functions as
signals for evaluation.
Making sufficient time after Project start-up
It is essential for the Project Control Manager to have effectively setup
the Project data collection system so as to require minimum time from his
part, and leave free space to implement the strategist role when the Project
is in full execution. Having the Project Control Manager spend time trying
to plug holes in the data collection system – or worse, spending inordinate
time trying to reconcile inconsistent data - is the number one failure mode
of an effective Project Control Manager.
Establishing an effective data collection system at the start of the
Project requires a lot of personal discipline and leadership capabilities. At
the start of a long Project people also do not necessarily feel the urgency.
The Project Control Manager hence needs to be able to create that sense of
urgency, supported by specific tools such as the Convergence Plan (refer to
our Scheduling Handbook) which creates early milestones and the
associated tension.
Successful Project Control Managers will thus concentrate in the first
2-3 months of Project execution in building efficient, scalable and as
automatized as possible data collection systems to cover at least those areas
of activity in the first months of the Project (refer to the detail in Chapter 4).
A bit more time will usually be available to setup data collection systems
for Construction, but their setup still needs to be planned significantly in
advance, so they the corresponding requirements for reporting and data
transmittal are included in the Terms & Conditions for the contractors.
 After the initial setup phase the Project Control Manager needs to
change his focus and take a more strategic role. This requires less time
spent churning numbers and reports, and more time thinking, analysing and
observing. This change can be difficult for some Project Control Managers
with limited experience, and might require some coaching and mentoring,
because it means getting out of a comfort zone churning numbers. As a rule
of thumb, the Project Control Manager should be able to spend at least
30%-40% of his time on strategy-related roles (middle and long term
considerations) after the first quarter of the Project duration. This is an
average; typically more time will be available in the middle of the month
and less during month-end reporting period.
Three Levels of Project Strategy Maturity
There are three levels at which the Project Control Manager can
operate in his role as Project strategist:
A basic level, where after the initial setup period the
Project Control Manager positions himself as the go-to
person of the Project Manager for any kind of analysis,
scenario planning and forecast,
An intermediate level where the Project Control Manager
proactively raises to the Project Manager those deviations
which appear after analysis to have possible significant
consequences, as well as any evidence of a dysfunction in
processes applied by the Project team,
An advanced level where the Project Control Manager
will propose creative, not immediately obvious strategies
to enhance the value of the Project, taking a long term
strategic view. These strategies often require a very long
consistent implementation to be effective. At this level,
the Project Control Manager acts effectively as a deputy
Project Manager.
Depending on his experience, it is also not rare that the experienced
Project Control Manager be pulled by the Project Manager to fill gaps or
compensate on some process and systems-related issues, even if they appear
in other functions such as Engineering, Procurement or even Construction.
Developing and Implementing a
Contractual Strategy
Perhaps one of the most effective contributions of the Project Control
Manager is to help the Project Manager develop and implement a long term
contractual strategy that will need to be consistently applied throughout the
Project execution so as to optimize the value of the Project to the
organization. This is applicable both to the Main Contract and to the
contracts with the main service contractors.
A contractual strategy is best developed already at the bid stage, in the
way the contractual terms will be formed and negotiated. It is the time to try
to transfer as much as possible risk that the other Party can better manage,
and to minimize the possible consequences of unexpected events.
Developing a long term contractual strategy is still needed even when
the rules have been formally set in a signed document, like in the case of a
Project in execution after the signature of the Main Contract. The approach
needs to be different, as it needs to happen within rules that have been set.
In all cases finding and putting into words a relevant contractual strategy is
a creative endeavour.
Why a Contractual Strategy is indispensable
Having a contractual strategy is indispensable but too often overlooked.
We consider that it should be available after the Project start-up phase, and
as such it is a key question in our Project reviews as soon as the Project has
been started more than three months ago. It needs to be relatively stable
during Project execution, so as to allow consistent implementation: more
often than not, the most effective contractual strategies require very early
and consistent preparation to reach their goals towards the end of the
Project.
The contractual strategy of course needs to be consistent with the
Project objectives. It is also heavily informed by the Project context and
intelligence gathered about all contributors and stakeholders to the Project.
It also needs to take into account the cultural context of the Client (refer to
Chapter 12).
The reasons why such contractual strategy is needed include:
 There will generally be a very significant improvement in the
Project commercial outcome if there is a strong contractual
strategy in place that is consistently implemented,
A clear contractual strategy will focus the efforts of the
contract team, avoid spending time on issues of low
importance and allow to capture opportunities aligned with the
strategy in a much more comprehensive manner,
A clear contractual strategy will be shared with the sponsor so
that his actions can be consistent.
Consistent implementation of a Contract strategy requires close
attention. This means establishing the basis for future variations or claims
through timely and appropriate correspondence, reporting, communication
and data collection.
Examples of contractual strategy

Pre-Contract signature
For both Parties:
Mix between reimbursable/ rate-based/ lump sum elements,
Acceptance or not of segments of the risk, and related contingency pricing,
Definition of the different scope packages for different contractors so as to minimize
interfaces and risks of claims for delays,
Level and rate of Liquidated Damages,
Level of incentives or penalties,
Conditions of partial or total termination,
Windows and notification mechanisms,
Invoicing and payment mechanisms,
Etc.

Post Contract signature

For an Owner:
Not accepting any Change Order except in exceptional circumstances (note - this also
requires internal discipline to avoid any change to the original scope),
Deciding that changes beyond a threshold require renegotiation of contracts (low
termination fees),

For a Contractor:
In general, flawless delivery of the scope within its full control is a pre-requisite for
solid contractual positions (comply with all contract obligations, meet dates for
document issue and delivery of interface information, ensure procurement and
construction activities comply with the plan). It will also avoid discussions about
concurrent delays and similar issues.
Insisting on the promised delivery dates from the Owner’s supplied studies or items
(including regulatory authorizations if required) and making sure that there cannot be
argument about readiness and need by prioritizing own related activities,
Starting early the section of the work that might have a change to be terminated or
transferred to another contractor,
In case of doubt of the readiness of another contractor for delivering part of the Project,
making sure to be on time to get further scope or be compensated for standby,
Issue timely correspondence as per contractual requirements and standards on any
subject related to a possible Change Order.
Etc.
The Project Strategist Analytical Toolkit
Comparison with benchmarks
A first important data point is to compare what is happening in the
Project with available benchmarks and other ball-park figures, and
understand the root causes of discrepancies. Contribution from the
experience of the Project Management Team should be sought in that
respect, as well as discussions with the estimating team.
Trend Analysis
Trend analysis is an extremely powerful and under-utilized tool in
Project Control. It can be applied to Cost, Schedule and Risk. Trend
analysis can be used very simply by plotting the outcomes of the successive
Project Periodic Reports on a timeline, or in a more complicated manner, by
extracting successive status information from databases.
In terms of cost, trending of the forecast of particular items can be an
interesting indicator showing poor control.
Analysis of systematic variance to the baseline dates and
durations for similar activities (e.g. document production,
procurement cycle),
Analysis of repeated variances on the same cost items which
are generally an indicator of poor forecasting or understanding
of the underlying causes,
At the lower level, trending of invoiced cost against progress
can also show that there is an issue with the committed
amounts or the mutual understanding of a contract with the
supplier or contractor,
Trending of specific indicators such as airfreight costs, last-
minute local procurement through agents etc. can be early
indicators of potential high-value consequential impacts on
fabrication or construction. It also reveals organizational
coordination issues which may have more far-reaching
potential consequences.
For Schedule, the Schedule Handbook has described in detail how float
can be monitored on particularly critical activities against fixed dates.
Additional trend monitoring can include the progress of a particular
segment of the work, productivity trends or the successive forecast start
dates of certain activities.
For Risk, beyond the trending of the quantitative contingency, trends
can be developed on the proportion of high-criticality opportunities and
risks, and on the number of opportunities and risks effectively closed.
Scenario Development
Scenario development is an essential tool to investigate possible
alternative execution pathways. A full assessment generally requires the
combined effort of all Project Control functions – Cost, Schedule and Risk,
and possibly Contract as well.
Scenario development involves building alternate credible solutions for
Project execution (or segments of it) and strength testing these scenarios. In
an advanced application, optimization approaches can be used so as to
determine what the optimal solution between two extreme scenarios is.
Because it requires substantial time and effort, large scale scenario
planning is generally not a very common event during Project execution,
still it needs to be done at some crossroads points to support important
Project execution decisions.
When implementing advanced systems for Cost Control and Risk
Management, the capability to run scenario analysis is a key feature that is
required; otherwise, scenario development becomes an even more tedious
work which generally deters the team.
The Project Control Manager needs to head the scenario development
efforts, because it is essential to include the intricacies of Cost, Schedule
and Risk together to really evaluate the different alternatives.
Exploiting Inconsistencies and Looking for Root-Causes
One of the primary sources of information for the Project Control
Manager is the identification of inconsistencies between the different
control functions. By looking for the root cause of these inconsistencies and
discrepancies, useful conclusions can be drawn on the performance of
Project processes or on the unfolding of a situation that needs to be better
understood and controlled. In addition, they are useful sources of Weak
Signals that are required to be analysed and fully understood (the concept of
Weak Signals is detailed in Chapter 8).
It is essential that the Project Control Manager involves himself
personally in the identification and investigation of these discrepancies so
as to be able to draw useful conclusions.
Conclusion
The Project Control Manager must develop into a trusted advisor to the
Project Manager.
He must make the time after Project start-up to play an indispensable
role of taking systematically a medium to long term view and help the
Project Team respond rather than react to external events. Further, the
Project Control Manager must be a key contributor and primary
implementer of the Project strategy, in particular regarding Contract
management. The full availability of Project data must enable him to
develop fine analysis of events, identify Weak Signals and propose
improvements and alternatives for the benefit of the Project.
Being relatively sedentary the Project Control Manager should also act
as the reliable delegate of the Project Manager when he is on the road.
 Chapter 12:
Project Control Soft Power
Introduction
In this section we will delve into Soft Power (refer to our book Project
Soft Power). The Project Control Manager has the responsibility of an
effective control on the Project and cannot be disinterested from the
dynamics of the Project Team. A Project Team that is not aligned, that
shows disengagement or even outright visible conflicts, it not prone to
transparency. It is also a major cause of loss of efficiency in a Project.
Therefore, the Project Control Manager cannot hide from these issues even
from the forecasting perspective.
The Project Control Manager thus must be able to exert judgment on
the health of the Project Team so as to inform his control actions. Beyond
this, he also should influence the Project Team effectiveness by providing
suitable tools, and raise any issues to the Project Manager.
Taking into Account Cultural Differences
Cultural differences express themselves at two levels on a Project:
Large Projects are always global when it comes to the entire
value chain (suppliers, contractors) and often at the Project
team level as well,
The Contractual approach and strategy needs to be adapted to
the cultural context of the Client.
Large Projects are Global
Large Projects nowadays are always global in nature. Even if they are
performed in a single country, the supply chain will be global, and
significant parts of the work can be expected to be performed in sometimes
far-away countries. In addition, Project teams themselves are increasingly
multi-cultural, consistently with the evolution of society and the global
nature of specialist manpower. Construction contractors will also often
utilize foreign manpower or at least manpower of foreign origin.
One immediate issue is to deal with language – while English is often
used as a common language in global Projects, all contributors might not
master it and misunderstandings are common. This issue is often
underestimated but it may significantly impact the effectiveness of a Project
team, in particular because people often do not want to confess that they
have difficulties to understand. Difficulties in this area must be addressed
upfront. Translations of key documents might be needed for the workforce
and even for part of the Project team.
In addition, the impact of cultural differences on Project
communication and performance should not be underestimated. It will
inform the leadership styles that need to be used. It will also require
substantially more investment in team members’ integration for the team to
be fully effective in an atmosphere of trust. Cultural differences also too
often lead to general categorization which relates to blame, and this effect
needs to be carefully avoided in the Project team in particular in periods of
stress.
A good way to address cultural differences upfront is to use one of the
available tools mapping cultural differences such as the Hofstede national
culture dimensions (available for a set of large countries online at
http://geert-hofstede.com/countries.html). It is useful to share such a general
mapping with the team and play around these differences in a fun manner.
Of course country averages do not represent the preferences of individuals,
which may be significantly different. However we have found that some
dimensions such as the deference to authority (Hofstede’s “power
distance”) or short/long term orientation ((Hofstede’s “long term
orientation”) are excellent indicators of default modes people of a certain
culture tend to retreat under stress.
Certain aspects must be taken into account when setting up the Project
team’s organization:
For foreign supplier/ contractor from very different cultures
(and language barriers), it is best to assign as ‘Package
Manager’ a person from the same country or from a close
culture,
The Project Management Team itself should have a good
diversity reflecting most cultures in the team,
At the same time it is very important to try to avoid to have
clusters of people from the same origin in certain functions, as
this has the potential to increase blame effects,
When needed, in particular regarding the country where the
work will be performed, do not hesitate to provide the team
with a cultural difference briefing.
In summary, it is an illusion to believe that there is nowadays a
universal culture. We are all marked by some cultural traits linked to our
origin. While diversity is a great asset in any Project, it needs to be
carefully managed and nurtured to deliver its promised value.
Why the Contractual Approach Must Fit the Culture
An aspect which is often underestimated by (western) organizations is
that the British or American tough and formal contractual approach does
not work universally. While it is formally the manner in which most large
global contracts are setup nowadays, the way those contracts should be
managed varies greatly with the local culture of the Client.
To the contractor’s dismay, in a lot of countries, trust is more important
and issues tend to be resolved at the end of the Project in a single wash-out
package where both parties aim at not losing face. If the contractor has done
great efforts to respond to the Client, he can generally hope to be rewarded
at the end. However this creates difficult situations with respect to the
formal accounting rules for profit recognition because this generally leads
to a substantial degradation of the formally recognized Project bottom-line
in the second half of the Project. In these cultures, writing tough contractual
letters in the midst of the Project might also not be acceptable to the other
party because of face-keeping issues and the expected deference to the
Client.
In general, cultural issues should not prevent proper formalization of
contractual issues and notifications, as these are important evidence for any
future court case or arbitration, which may always happen. However it is
important to adapt the tone of the correspondence to the cultural
circumstances.
The development of the contractual strategy (mentioned in Chapter 11)
must also be deeply informed by the cultural context. It is important to note
that what will be remembered from the Project after it is closed is its final
cost or profit, and not so much the ups and downs that happened during the
Project. Therefore, showing a temporary degradation is not so important
compared to the longer term aim of a successful Project. We recommend
that the long term view should always be the priority of the contractual
strategy. In certain cultures it might involve working mostly on the client
trustful relationship and living without written agreements to Change
Orders and extensions of time until final Project closure. Project sponsors
and senior management must understand these aspects to protect the long
term interest of the organization and get involved to create an adequate
atmosphere of trust.
Initiating Workshops
When issues arise that require significant coordination or the input
from many different functions, it is often more effective to set aside half a
day or a full day for a workshop. While a workshop needs to be prepared to
be effective, it is often more efficient to do so rather than hope that an issue
can be resolved without. This is in particular the case for issues that hang
around without clear closure and that might hamper Project progress.
Workshops can also involve vendors and client representatives if needed to
unblock a situation, although this needs to be carefully managed from a
contractual point of view and might require the involvement of a neutral
third party.
The Project Control Manager should have the skill to organize and
facilitate effective workshops. In addition he will often be at the forefront of
the detection of issues that need to be resolved that way, and can advise
how to best bring the issue to closure.
Best practices for the organization of workshop are enclosed on the
next page.
Workshops Best Practice
Define clearly the objective of the workshop and what are the deliverables.
Maximum 12-15 people for a collaborative workshop.
Define a timeframe for the workshop. Don’t be too ambitious on the content of the
workshop related to the available time, so as to let powerful conversations unfold if
necessary. On the other hand if the workshop deliverables are delivered more quickly
than expected, do release people early.
People are busy, so if the scope is large, prefer a series of half-day/one day workshops
with time in-between to a succession of workshop days. Never exceed three consecutive
days, and try to limit to two consecutive days.
Organize workshops outside the office to minimize interruptions, but not too far to allow
people to drop back to the office if the workshop finishes early or if they need to finish
their work after normal hours.
Use the opportunity to facilitate networking and even possibly team-building activities,
in particular at the start of the Project or if there is any team effectiveness issue.
Have an experienced facilitator. This is mandatory if the issue is somewhat controversial
and in that case the facilitator needs to be from outside the Project or considered
sufficiently neutral. A facilitator is recommended in all cases so that ‘elephants dancing
on the table’ can be identified and addressed, to avoid groupthink, and to ensure
effectiveness of the workshop process.
The facilitator role includes:
timekeeping, but sufficiently flexible to allow important conversations to
unfold;
capability of synthesis and take some distance in particular in case of emotional
issues;
developing a workshop plan with the usage of a number of collaboration
methods to achieve the expected outcome, while remaining flexible on what the
workshop will reveal.
Use collaborative processes such as post-it based brainstorming and rankings, visual
expression tools, etc to help the team work together and foster teamwork. Minimize
screen reviews of documents. If the group is large, use the opportunity to divide in
subgroups and create some competition and diversity of opinion.
Make sure the workshop outcomes and deliverables are properly recorded and quickly
available to the team, and are action-oriented
Checking the Project Team Health
Successful Projects always have a very close-bound team that works in
an effective and performing manner. Blame is forbidden inside the Project
and everyone works in the same direction. It is essential to understand what
the actual development stage of the Team is. The Tuckman team stages
framework (Forming, Storming, Norming and Performing) can be used as
guide to understand the performance capability of the team. If the
development stage is unsatisfactory at this stage of the Project, action must
be taken immediately.
The Project Control Manager is in an ideal situation to help the Project
Manager monitor the health of the Project Management Team as an
effective team:
By maintaining essential coordination tools, in particular the
Integrated Project Schedule, and detecting discrepancies in
priorities,
By participating or having delegates participate to many
regular meetings internal to the Project team and with major
stakeholders (Client, Senior Management),
By identifying inconsistencies between the plans of the
different functions, which reflect a lack of coordination and
communication,
Being almost permanently in the office, the Project Control
Manager is well placed to foster bottom-up informal
communication of problems or concerns and relay this
information to the Project Manager. The best is to identify
those empathic persons who people confide in naturally and
encourage upward feedback through active listening and
appropriate early and decisive actions. This will further
encourage upward communication.
The success of Project execution is very much related to the health of
the Project Management Team as a team. Essentials include:
The effectiveness of the team in coordinating their priorities
and efforts (including meetings).
 The capability for team members to compensate the
weaknesses of others and go out of their way to support the
Project in critical moments,
The capability for open debate before decision-making, and a
clear execution discipline after decision-making,
Consistent behaviour on important values such as quality and
safety,
A strict no-blame structure even when things do not work out
as expected,
At the same time, the capability to take immediately action
directly and to the point, without blame, when people do
deviate from the expected norm of behaviour or from the
established values. This will reinforce progressively values
and behavioural norms.
Half-way between the effectiveness of the team and the effectiveness of
the processes are meetings. Too often, long meetings are the bane of Project
Management Team. Meeting effectiveness is also a major parameter that
needs to be monitored. Of course meetings are needed for coordination; still
some basic rules need to be followed for effectiveness. In a Project where
people are busy and subject to the pressure of operational issues they will
quickly vote with their feet whether meetings are useful or not. As a rule,
regular coordination meetings should be few, focused, and limited in time
and attendance, except the main Project coordination meeting.
In case of dysfunction, the Project Control Manager should
immediately raise the alarm and support the Project Manager in finding an
adequate solution to the situation. In a number of instances, the Project
Control Manager might detect a situation before it becomes visible to the
Project Manager.
Remedies need to be decided by the Project Manager, and may include
specific workshops and other communication methods; or even, the
removal of a member of the team if that appears to be the most effective
way of re-establishing effectiveness.
Signs of a Healthy Project Team
Each of the points below is a significant mark of Project Team Health.
Indication of opposite behaviour must be treated immediately in a
powerful and non-equivocal manner.

Real commitment to Safety and Quality,

Adherence to Constructive Conflict prior to decision-making,
Conflicts (work or individual-related) are addressed
professionally, non-emotionally and quickly,
Full commitment and unequivocal alignment after a decision has
been taken,
Full accountability and acknowledgment of areas of
responsibility,
Presence of Trust, and absence of Blame between segments of the
Project Team (in particular in difficult times),
Respect for other team-members’ point of view,
Adequate integration and recognition of local contributors /
cultural differences between team members (international
Projects),
Project interest is recognized to be above individual’s interest, in
particular in relationships and communications outside the
Project,
Acceptance that sacrifices might have to be done in one’s area for
the overall Project’s sake,
Team members support each other, and help compensate each
other’s weaknesses; team members are ready to work beyond their
normal remit or go the extra mile to help the Project / other team
members.

Treatments of unhealthy signs can vary depending on the circumstances.

They will rely on the leadership capabilities of the Project Manager.
Solutions can include:
Clarification workshops,
Teambuilding (all or part of Project Team),
One-to-one or one-to-team conversations,
Removal of divas/ trouble-makers that don’t play the team game,
Etc.
Conclusion: Always Remember a Project
is a Human Adventure
The relatively sedentary role of the Project Control Manager places
him in a unique position to continuously monitor the health of the Project
team and its effectiveness. Because at the end of the day, a Project is a
human adventure, it is on this aspect that a Project will or not be successful.
Being a ‘trusted advisor’ to the Project Manager also requires to be able to
seize the subtleties of Soft Power and help shape a winning Project team.
Apprehension of the cultural issues at stake, the ability to conduct
effective workshops, monitoring the Project team’s health and acting in case
of an issue, are essential capabilities of the successful Project Control
Manager.
 Chapter 13:
The Project Close-Out Process
Project Close-Out is a process, it is not a time period
Introduction: Why Project Close-Out is a
Process
A successful Project Close-Out is a process that needs to start at the
beginning of the Project.
Project Close-Out importance is often too disregarded. We believe that
a properly organized and driven close-out can be a substantial source of
savings and can avoid substantial liabilities to the organization. It therefore
needs to be executed properly and with the right level of urgency and focus.
The Project Close-Out phase itself is an important moment for Project
Control. It is the moment where all the good work carried out during
Project execution should bear fruit, in particular in the area of contract
management (Claims and Change Orders final negotiation), cost control
(cost close-out and final reconciliations) and documentation preparation
(as-built and quality records).
The Project Close-Out Process Starts from
the Project Start-up Onwards
The Project Close-Out as a process must be conceived and triggered
from the very beginning of the Project.
Project Close-Out Process at Project Start-Up
Some essential close-out planning and requirements are to be
incorporated from the Project Start-up:
Requirements to suppliers and contractors regarding format
and timing of as-built drawings and provision of quality
records,
Policy regarding retention on suppliers’ and contractors’
payment linked to the provision of final documents,
Organization of the archiving of the Quality Control
certificates and activities in particular when activities happen
in remote areas,
Agreement with the Client on the as-built and final
documentation lay-out, formatting and referencing,
Organization of a separate document archiving centre
according to the final documentation format.
Project Close-Out process from Engineering to Construction
Stage
During the course of the Project it is essential to close out external
contracts as soon as they are completed to avoid having them linger over
time.
Delays in closing contracts upon completion of the work will create
uncertainty on the forecast. Because of the team turnover it will also lead to
loss of control as the memory of the events might be lost.
A comprehensive close-out process for all external contracts and
purchase orders must thus be put in place, with a maximum timeline. This
timeline should be monitored by the Procurement department.
Final contractual close-out should always be accompanied by a formal
certificate signed by the supplier or contractor and certifying that final
reconciled amounts have been agreed, and including a commitment that no
further claim will be raised against each other for the work (outside the
specific case of warranty).
In case of equipment suppliers, the close-out on equipment supply must
be agreed early irrespective of the provision of additional services (vendor
representative presence on site for construction and commissioning) or
spare parts.
A check point when anyone is demobilized from the Project team
should relate to the close-out of the contracts she has been working on.
As-built documentation and final documentation continuous
production
As-built documentation is an essential Project deliverable for the
Owner and the future operator. Substantial payment is often tied to its
delivery and acceptance. It is important to plan the production of these
documents early on the Project, at least in terms of format and table of
contents, so that the relevant information can be captured progressively as
the different components of the facility are manufactured. These detailed
requirements must also be transmitted to suppliers and contractors
preferably before their award.
While it is not per se a Project Control responsibility, lack of finished
As-Built documentation can be a significant hurdle for final payment and
can create significant additional cost and time at Project close-out stage. It
is thus wise that the Project Control Manager ensures that this background
task of information capture and retention happens smoothly and regularly.
Project Close-Out Phase planning during Construction
The final Project Close-Out phase should start to be prepared when
Construction activities are under way. In large Projects, it is not uncommon
to start intensive final close-out preparation at least 6 months prior to
Project completion, or even earlier if there is a substantial demobilization of
the engineering team.
Substantial planning is required in particular in the following areas:
Project Management Team demobilization plan, and related
changes of assignment of responsibilities,
Main worksites (own and contractors’) demobilization and
reinstatement as required, including personnel and equipment,
with a particular focus on rented equipment and surplus
material,
Risk closure and cost contingency release strategy,
Allowances and contingency run down plan,
Cost Work Packages progressive closure,
As-built documentation generation and hand-over,
Production of an internal Project close-out report detailing the
experience and lessons learnt on the Project,
Detailed lessons-learnt capture process,
Formal close-out process with vendors and contractors, which
should start progressively as soon as their services are fully
rendered (including delivery of documentation),
Formal hand-over and close-out process with the Client/
Owner, including management of punch lists and carry-over
work if relevant,
Formal handover of remaining liabilities (e.g. warranty) to the
designated part of the organization for long term management.
Close-Out Phase Execution
It is in the close-out phase that the commercial activities (Claims and
Change Orders management) will be the most active with both vendors,
contractors and Client / Owner. Some of negotiations might have very
substantial impact on the Project numbers, create positive or negative
surprises and this cannot be fully avoided but should remain marginal – and
rather only limited positive surprises - if the Project Control process has
operated properly. Adequate comprehensive documentation and recording
throughout the Project are factors that will facilitate resolutions of these
final negotiations in favour of the Project.
Project Close-Out Traps
The traps listed below exist irrespective of final negotiations with the
Client, suppliers and contractors:
Demobilization plans that are too optimistic, resulting in cost
and time overruns when they can’t be implemented,
A particular issue might occur if Project personnel are
unsure to find work after Project close-out because of
the current economy, and work might drag as a result,
Demobilization plans that are designed and implemented too
aggressively, resulting in:
poor as-built documentation generation (leading to
additional costs and delays),
absence of relevant personnel with history to
challenge the close-out with vendors and suppliers,
poor capture of proper lessons-learnt (including
absent or poor Project close-out reports) and
continuous improvement suggestions,
Inadequate level of allowances kept in the forecast creating
significant surprises (positive or negative) upon final close-out
with the suppliers or contractors and final reconciliation with
accounting. This is often linked with an inadequate control of
allowances (e.g. not identified separately in the breakdown),
Inadequate contingency release strategy resulting in a sudden
positive improvement of the Project result. While a significant
 amount of contingency needs to be kept until late in the
Project (as the most significant risks are generally at the
Construction stage), it is nevertheless important to release it
progressively at the end of the Project so as to avoid sudden
step change of the Project financial results,
Lack of formal closure with vendors and contractors resulting
in receipt of unexpected late invoices, or new Claims received
while the Project thought that the contract was closed,
Inadequate process for formal handover to the Client and
mechanical completion of the work resulting in delays to
payment and delayed commencement of warranty period(s).
Best practices to respond to these issues include:
Close-out cost codes in the time tracking system as soon as
those tasks are deemed finished, to maintain control and avoid
idle personnel booking time on past activities,
Agree in advance on the format of the as-built documentation
(early in the Project), and of the Project close-out report,
Design aggressive demobilization plans to minimize time and
cost, but take into account time for proper lessons learnt, as-
built documentation compilation, etc., identifying these tasks
separately in the budget and time tracking (dedicated CTR),
and keep some allowance for delays,
Do not allow demobilization of key personnel from the Project
team (including middle management) without a proper close-
out and handover process,
Create a specific indicator on the level of allowance and on the
level of contingency on the Project, with both amounts
converging progressively towards zero in the last months of
the Project,
Agree in advance with the Client, beyond the contractual
requirements, what will be the exact process for handover, and
ensure that it will be practical including if it has to happen
outside office working hours.
Handover of the Remaining Project
Liabilities
Upon completion of the close-out, some liabilities will remain with the
organization, including in particular contractual warranty commitments.
The final acceptance of the works may only be given several years after the
end of the Project itself. Insurance claims’ resolution might also exceed
significantly the closure of the Project itself.
In most organizations, as the Project is completed, the Project team is
fully disbanded and the remaining issues and files transferred to a single
department that handle the entire portfolio of closed-out Projects. The exact
organizational setup varies: it could typically be a dedicated department
within the Projects department, or the Contracts/Legal department.
It is essential to transfer to this organization a comprehensive file,
including all relevant archives that might be required in case of a warranty
claim. This means in practice, handing over comprehensive and organized
document and correspondence repositories, in addition to the entire records
of the Project. Organizations generally maintain checklists of
documentation to be handed over and the hand-over meeting should be
formalized and documented. It is only at this stage that the Project can be
considered to be fully closed-out.
Handling of warranty claims
Depending on the industry, the probability to have warranty claims, and
the degree to which those claims may be covered by insurance, Project
organizations may or may not provision for warranty claims. If these
provisions exist, they are generally aggregated in a centralized warranty
fund at portfolio level that is available for any warranty issue the
organization may face. From the Project perspective, this provision is a cost
element which is generally set as a percentage of revenue. It therefore acts
as a kind of internal insurance system.
If a substantial warranty claim is raised that requires rectification work,
the easiest way to handle warranty work is to consider that it is a new
Project, assign a budget, mobilize a team and control it as any Project.
Proper Closure of the Project as a Human
Adventure
A Project is a human adventure. People have toiled together to create
something unique and often extraordinary. They might have suffered along
the way. It is a significant chunk of their professional life.
What people remember from an experience is often how it ended. It is
essential to make sure that people depart from the Project with fond
memories of companionship. A key component of successful Project close-
out is therefore the organization of a send-off party and the provision to
team members of some memories in the form of tokens, trophies, or even a
special Project book. The community may be maintained on social
networks in a more or less organized manner.
Do not underestimate the importance of the soft side of Project close-
out – it is often the foundation for a community that will work again and
keep in touch in the years to come.
Conclusion: Project Close-Out, an
essential success factor
Project close-out is a process that starts at Project start-up. This is an
essential truth that needs to be understood and promoted by the Project
Control Manager. Project Close-Out must be organized and executed
properly to ensure that no undue liabilities will remain that might tarnish
the success of the Project.
The Project close-out phase in itself is often overlooked, because it
comes at a time of relief where the hardest hurdles are overcome. Many
contributors already look forward to new challenges and possibly,
significant changes on a personal and professional level. Still, it is like
when an aircraft lands: it is not enough to touch the wheels on the runway -
the pilot must maintain control until the final stop. It is the moment of truth
where all the numbers should reconcile between accounting and cost
control. Some planning and foresight is required here to land the Project
without generating surprises and remain on the runway!
There are numerous examples of the Project Control Manager
becoming de-facto Project Manager during the later close-out phase, as the
Project Manager is reassigned elsewhere in the organization. The Project
Control Manager might thus be fully in charge of this phase for the Project.
Do not forget the soft power side and organize a proper celebration and
community building event so that people keep fond memories of the
Project!
 Chapter 14:
Project Control Forensics
Introduction
This Chapter aims at giving practical checkpoints to assess the level of
maturity of Project Control on a given Project. To that effect, three levels of
maturity have been identified:
Level 1 - Data assurance, including communication assurance
and consistency assurance, so as to ensure that what is
measured and reported is accurate,
Level 2 – Pertinent analysis and indicators used to enable early
and proactive decision making ,
Level 3 – strategic support to the Project Manager, including
identification and analysis of Weak Signals, development of
medium term strategies for the Project, and development and
consistent implementation of long term commercial strategies.
The checklists that follow are particularly aimed at periodic assessment
of Project Control’s maturity level. They are complemented in the
appendices by check-lists for Project start-up, monthly update and Project
close-out.
Note – these checklists focus on those areas that are cutting across
Cost, Schedule, Risk and Contract management. Refer to the respective
handbooks for specific checklists covering each specific area.
Level 1 checks – Data Assurance
This first set of check lists cover
Data assurance (accuracy),
Communication assurance,
Consistency assurance.
Level 1A – Data Assurance
Is the Project baseline Check the quality and consistency of
consistent, realistic and the baseline (cost, schedule,
resilient? documentation, manpower plan, risk,
breakdown structures etc.) Is there a
clear data structure defined as part of
the baseline?
Has Project Control been Check that Project Control was one
given a slot in the Project of the key speakers at the overall
kick-off meeting/ induction kick-off meeting, and that the Project
to emphasize the importance induction includes key Project
of data recording Control points.
compliance?
Is there a functional Check the timesheet system and check
timesheet system and is the by sampling whether:
data comprehensive, and it is filled in a timely manner,
approved each week without
delay? cost code allocation is
accurate,
and data is approved with
minimum delays.
This can be done quite easily by
preparing a report showing recorded
hours by week per person. A sudden
end to booked hours (typically last
few weeks) would indicate that the
person is not up to date with time
sheets. Review with leads will further
identify whether people are absent
from the list and whether hours have
been booked incorrectly.
Are all the charge codes in Check whether charge codes are
the timesheet system used as being used properly. When there are
expected? too many charge codes, the risk is
that people charge on the wrong code
creating data accuracy issues. Too
many codes will lead to codes not
being used, which can be checked.
 Specific checks need to be
implemented for personnel charging
from remote offices (including
approvals).
Is the document control Check that the updated status in the
system properly updated and document control system reflects
the physical progress reality (should be straightforward
measured from actual with modern electronic systems, but
document progress warrants checks e.g. for supplier
milestones? documents). Check that forecast dates
are regularly updated.
Check for consistency with client and
subcontractor document registers to
see that there are no delays to
entering and processing new
documents in the system
Check the impact of adding/ Identify documents that have been
removing documents removed or added since the start of
the Project (after baselining), and
check the change has propagated
properly – progress measurement
update, link to schedule.
Note: it is not good practice to take
100% progress credit when removing
a document.
Have engineering forecasts Check that productivity data has been
(cost & schedule) been produced to challenge Scope Owners
validated by the Scope (in particular regarding the level of
Owner and challenged using effort to finalize documentation). Is
productivity data? the level of engineering required
consistent with the manning plan?
Are suppliers and Check that all suppliers and
contractors using the contractor reports are consistent with
Project’s required Project’s requirements (as issued at
breakdown, physical the start of the Project and normally
progress and reporting embedded in all contracts)
guidelines?
Is the physical progress from Check that there is no significant
suppliers and contractors delay in physical progress updates
reflective of reality? from supplier / contractor reports.
Check by sampling that reported
progress reflects reality.

Are all costs committed While this point is a compliance

according to the Project’s check per se, it will also be an
financial authorization indicator or poor control on
matrix? commitments and potential for
inaccurate data in that respect.
Is the Actual Cost and Check that Actual Cost is computed
forecast for procurement and independently of invoicing.
service contracts computed The standard methods for Actual Cost
according to clear physical- computation will vary depending on
progress based rules? organizations. Usual methods include
For simple items, upon
receipt,
Milestone-based progress
recognition,
Value of Work Done
calculation based on detailed,
weighted schedule for
contractors.
Check that at all times Actual Cost is
higher than invoicing excluding
advanced payments, and lower than
commitment.
Check by sampling on critical
elements that recognized Actual Cost
is consistent with expediting /
inspection / site visit reports status.
Have procurement forecasts Check with Scope Owners that
(cost & schedule) been forecasts have been validated
validated by the Scope accordingly
Owner and challenged using
productivity data or quantity
allowance data?
Are commitment levels Check that procurement commitments
timely updated taking into are updated as soon as changes are
account changes and claims? approved.
Is the Actual Cost for Check that Actual Costs for
construction computed construction are effectively computed
according to physical on the basis of physical usage of
progress and physical usage resources or physical progress, and
of resources? that it is consistent with progress
Have construction & reports.
commissioning forecasts Check that construction forecasts are
(cost & schedule) been updated regularly consistently with
validated by the Scope actual site physical progress and
Owner and challenged using utilization of major resources.
productivity data?
Is the contingency Check that the contingency
calculation updated taking calculation has been updated and that
into account the latest opportunities and risks therein are
knowledge? consistent with:
The latest Risk Register
updates,
 The top Opportunities and
risks of the last Project
Periodic Reports.
Is there a clear follow-up of Check that the rules about
Change Orders and Client recognition of Change Orders are
Instructions including their properly followed, including for Cost
status, and is it properly and Schedule, but that nevertheless
reflected in the Forecast and the potential impact of unapproved
Sensitivities? Change Orders are understood and
included in the sensitivities.
Is there an independent Check that an independent program
check program in place to is in place to check Actual Cost. It
check the accuracy of Actual should concentrate on the most
Cost / physical progress by critical elements, plus add a few
sampling? random checks, and be implemented
regularly.
Is there a peer review/ Check that external and peer reviews
external independent health are organized regularly and have an
check program? adequate level of independence.
Check that recommendations have
been taken into account.

Level 1B – Communication Assurance

Have there been Best practice is that at Project’s Kick
presentations by Project Off Meeting and some subsequent
Control to the entire team to townhalls, the Project Control
reinforce key data assurance Manager would present to reinforce
messages? cost awareness and other data
assurance requirements.
Is there an induction pack Check for an induction pack for
for newcomers on the newcomers. Check that it does
Project and does it include include specifics of Project Control
specifics of Project Control? including Contract familiarization,
time charging and other specifics.
Are there regular meeting Check that regular meetings (at least
covering Actual and monthly) are held at Project Control
Forecast between: level (in addition to meetings for Cost
Project Control and and Schedule) to discuss both Actual
and Forecast, and any further
Engineering relevant topic.
Project Control and Check that Engineering, Procurement
Procurement and Construction functions are
satisfied that they see their view
Project Control and reflected in the Project Model and
Construction that they are challenged where
needed.
 Project Control and
commissioning?
In case of EPC Contractors, Check that this meeting happens, and
is there a regular meeting more importantly that it is not just an
where relevant Project exercise of style. Minutes of meetings
Control issues are and action lists should be produced.
addressed? Actual issues should be addressed
and closed promptly.
Is the Management of Check that there is a clear process
Change process properly that makes it easy to raise Changes
implemented? by anyone in the team. It should be
known by everyone, and there should
be very regular coordination
meetings about changes. Audit the
process.
Is the Interface Management Check that there is a clear process
process properly that covers interfaces with Clients,
implemented? other Client’s contractors, suppliers
and contractors. There should be
regular coordination meetings about
interfaces. Audit the process.
Is the Procurement post- Check that procurement post-award
award process properly covers properly expediting (with
implemented in all its regular updates of delivery dates),
dimensions? commercial follow-up, vendor
inspection triggering and follow-up,
organization of Factory Acceptance
Tests and final shipping & packing.
Is the as-built generation Check that the table of contents and
process clear, as well as format for the as-built documents has
format/ table of contents? been agreed early in the Project
execution with the Client, and that it
has been communicated internally
and to suppliers/contractors.
Is the Project Management Check the effectiveness of the meeting
Team weekly meeting by checking minutes and action points
effective? (those should be closed promptly),
attendance records; and interview
participants.
Are there periodic (weekly) Check this meeting effectively
meetings between happens, minutes/ actions are
Engineering and recorded and schedule (cost)
Procurement, and is Project representatives are invited. This is
Control invited? particularly important in the first half
of the Project.
Are there periodic meetings Check this meeting effectively
(weekly) between happens, minutes/ actions are
Procurement and recorded and schedule (cost)
Construction, and is Project representatives are invited. This is
Control invited? particularly important in the 6
months prior to mobilization.
Are there periodic meetings Check this meeting effectively
(weekly) between happens, minutes/ actions are
Construction and recorded and schedule (cost)
Commissioning, and is representatives are invited. This is
Project Control invited? particularly important from
construction mobilization onwards.
Have there been instances In a normal Project there should be
where one-off workshops from time to time, specific decision
have been called to discuss meetings or workshops to take
specific issues involving decisions on complex matters
several functions? involving more than two functions. It
should generally be chaired by the
PM or his deputy.

Level 1C – Consistency Assurance

Is the cost time-phasing Check consistency based on the latest
consistent with the updates.
schedule?
Is the cash flow (receipt Check consistency based on the latest
milestones/progress) updates. Payment milestones should
consistent with the be linked to the schedule and updated
schedule? accordingly. Payment on progress
should be consistent with forecast
progress taking into account any
Client issues on previous billings.
Are the resource histograms Check consistency based on the latest
used for cost forecasting updates.
consistent with the
schedule?
Is the cost forecast Check consistency based on the latest
consistent with actual updates. This is more a challenge
progress (Earned Value)? than an exact science, however cost
forecast has to be prudent, and hence
too much discrepancy because of
slow progress can be an issue. It
depends also on the rules of physical
progress calculation so the difference
must be explainable.
Is the cost progress Check that the Actual Cost progress
consistent with the physical is consistent with the Physical
progress? Progress (it should be lower, with less
than 10% progress difference)
Is the entire scope covered Check contract + Change Orders vs
in the schedule, updated latest schedule and cost models
budget and forecast (initial
scope, Change Orders, etc)
Are unapproved Change Check unapproved Change Orders
Orders that require actual for any work that has to be
work notwithstanding anticipated or is required anyway,
approval accounted for in and check it is included in schedule
cost and schedule? and cost (not in revenue).
Are all Change Orders Check for Change Orders that
reflected in the schedule and Extensions of Time arising as a
Extension of Times granted consequence have been properly
for their impact? analysed, requested and granted
either as part of the Change Order or
separately.
Are all extensions of time- Extensions of time-rate work under
rate work leading to instruction of the Owner should give
contractual Extension of rise to Extension of Time for Project
Time? completion. Check that this is
formalized.
Are all interfaces for free- Check that free-issued items
issued items clearly availability are identified and linked
identified in the schedule? into the schedule.
Are the cost and revenue Review the risk register to appreciate
sensitivities consistent with whether the sensitivities shown are
the Project Risk Register? consistency with the risk profile of the
Project
Is the contingency level and Review the contingency calculation
its calculation inputs basis in detail and make sure it is
consistent with the Project consistent with the risk register (at
Risk Register? least the high priority & probability
risks)
Is the contingency level If the contingency does not contain a
consistent with probabilistic schedule element, check that the
extension of schedule contingency level is not overly low
durations due to risks? compared to possible delays in the
works and its cost consequences (as
ascertained through a Schedule
Statistical Analysis or expert
judgment).
Are all cost allowances and Check that cost allowances are
any schedule activity clearly separated and tracked. They
allowance (padding) clearly should be trended at Project close-
identified or known? out. Check that any schedule
allowance is known and tracked (it is
often not shown explicitly).
Is double dipping avoided Check by sampling that there is a
between allowances and strict non-double-dipping between
contingency contributors? allowances in cost and contingency
elements
Are probable risk events An issue is sometimes that risks are
(>75% chance) taken in the identified that have a high probability
cost and schedule forecast? of occurrence but they are not
included in the Project Model. High
probability events should be
considered deterministic.
Are opportunities and risks Some contracts make it possible to
related to possible additional carve out or add-on very large
or removed scopes taken segments of scope. Check that this is
into account? properly accounted for. It will have a
link with the contractual strategy.
Are Liquidated Damages Check that Liquidated Damages are
taken into account in the risk indeed taken into account in the risk
model? model/ sensitivities consistently with
possible delays.
Are any other contractual Check that any other penalty/
penalty/ incentive schemes incentive schemes are properly
taken into account in the risk considered in the sensitivities and
model? contingency (applies to Main
Contract and suppliers/ contractors)
Are changes due to Check that when productivities are
productivity issues lower than expected , forecasts are
effectively taken into revised including consequential
account in the Project impacts of schedule delays or the
reforecast (schedule/cost)? need to mobilize additional resources
Are consequential impacts Check by sampling that the
of Management of Change Management of Change impact
properly assessed and assessment process properly covers
reflected in cost and consequential changes in all
schedule? dimensions (including risk, HSE,
quality)
Are the consequential Check that when there are
impacts of variances due to productivity issues (not identified as
productivity issues properly pre- approved changes),
assessed and reflected in consequential impacts are effectively
cost and schedule? taken into account after analysis.
Level 2 checks – Support to decision-
making
This second set of checklists covers:
Whether the Project Control team has sufficient time for
analysis work,
Proper content of periodic reports,
Whether customized indicators have been developed,
Whether visual management methods have been deployed.

Level 2a – Available time for analysis

Does the Project Control Interview the Project Control team
team have enough time for about their monthly cycle effort and
analysis and additional assess whether they would spend too
investigations? much time on data crunching instead
of having time for analysis. As a
guide at least 30% of the time should
be spent on analysis.
Look for evidence that analysis efforts
have been made in the recent months
on specific topics (analysis /
reforecasting etc)
Does the Project Control Check that the Project Control team
team maintain a monthly has a monthly cycle plan, and that in
program of work – addition it decides on monthly topics
improvements to forecast, for further investigations and
analysis, re-baselining of upgrade.
part of the scope etc.?
Is the time spent on Time to produce reports should be
producing periodic reports managed so as to keep time for other
(internal & external) Control activities. Spending more
reasonable? than 20% of time on reporting for the
Project Control Manager is an issue.
Level 2b – Reports
Does the Project produce Refer to Chapter 10 for a list of
periodic reports with the expected indicators.
minimum required contents? In addition the report should contain
Are the reports intrinsically a short summary of the Project, and
consistent between Cost- write-ups by the Project Manager on:
Schedule-Risk and contract? Project current status
 Planned activities in the
next 2-3 months
Issues and concerns
HSE and quality situation
and concerns
Top risks and opportunities
Are Periodic Project Reports Check by sampling previous periods
produced on time and with a report their quality and timeliness.
consistent quality?
Are Periodic Project Reports Review the attendance sheets of the
reviewed monthly by Project Periodic Project Report reviews for
Sponsor and other key regularity of presence of key senior
managers? managers of the organization.

Level 2c – Customized indicators

Does the Project track “cost Check that all cost variances are
of non-quality” or as a categorized and that analysis is
minimum, broad categories performed on the trends and the
of cost variance for major categories as the Project
analysis? progresses, allowing to draw
conclusions and actions.
Is the Project tracking Check that customized Project-wide
customized Project-wide indicators have been defined that
indicators to track critical relate to the Project Objectives and
processes? the particulars of the Project.
Examples - can the Project readily
give figures for:
Documentation production
cycle,
Procurement timecycle
(specifications to award),
Management of change
statistics,
Airfreight costs,
Monthly running cost of
PMT.
Is the Project regularly Check that specific and short-term
devising customized short- indicators are regularly defined and
term indicators to track changed that relate to the Project
specifically sections of the critical activities.
work depending on Examples
priorities?
 Time and effort for final
production of documents,
Number of revisions to AFC
documents,
Welder qualification status,
Critical resource
productivity,
Run-down curves.
Level 2d – Visual management
Has the Project developed a Check that visual dashboards are
number of visual dashboards posted in the office.
that are posted on the Project Suggested minimum posts:
office walls? Are these The Project Objectives and
dashboards representative
and meaningful for the Project Charter,
team? The updated Convergence
Plan
Progress S-curves by
function or sub-function
where relevant,
Maps of the facility showing
the overall plot plan and
showing updated progress
by zones.
Are these visual dashboards Check that these visual dashboards
updated regularly (at least are updated regularly (at least
once a month)? monthly) with fresh data. (Often even
when visual dashboard are used, they
are unfortunately not updated
regularly and this can create a very
negative impact on the team)
Has the Project developed a Check that temporary visual
number of temporary visual dashboards are added according to
dashboards that reflect the needs. Examples of temporary
current particularly critical dashboard include:
operations/ temporary Count-down prior to key
custom indicators?
milestones (e.g. worksite
mobilization, start of
commissioning) with
associated remaining
activities,
 Run-down curves towards
the end of Construction and
during Commissioning.
Has the Project team setup a Check whether the war-room concept
war-room where all relevant is used (the walls of the main meeting
dashboards and indicators room for the PMT should be full of
are posted on the walls? updated visual dashboards).
Level 3 checks – Strategic Support
This last set of check lists covers:
The ability to identify and analyse Weak Signals,
Team effectiveness,
Support to strategy development.

Level 3a – Weak Signals identification and

treatment
Is trend analysis being Check whether trend analysis is being
carried out in a continuous used.
manner as a way to detect Example of trend analysis include:
Weak Signals? Float monitoring,
Milestone forecast date
monitoring,
Trends on specific parts of the
cost (e.g. airfreight, logistics,
travel, etc),
Contingency and risk level
trends,
Allowances trend (second half
of Project).
Are inconsistencies Check whether any discrepancy
appearing between or within discovered between Cost, Schedule,
Schedule, Cost, Contract Contract has been analysed for root
exploited as Weak Signals? cause and whether in some case,
further investigations have been
carried out.
Are near-misses reported by Near-misses should be analysed as
HSE and Quality exploited possible Weak Signals, and the root
as Weak Signals? causes should be reviewed
accordingly
Are possible consequential Check when Weak Signals have been
impacts of Weak Signals analysed, that all consequences have
being investigated? been assessed across all functions
Level 3b – Team Effectiveness
Is there a real and Assess the actual commitment to
demonstrable commitment safety and quality as an indicator of
to Safety and Quality? behavioural compliance.
Is there evidence of Sit in a PMT meeting and observe
constructive conflict prior to whether arguments are effectively
decision-making? being exchanged, or whether there is
fear to speak out.
Have there been ad-hoc Check the history of ad-hoc
workshops called to discuss workshops to check that they have
difficult issues and been called up whenever tough issues
decisions? had to be discussed.
Are conflicts (work or Interview Project team members to
individual-related) addressed collect anecdotal evidence on conflict
professionally, non- management
emotionally and quickly?
Is there full commitment and Check that people commit to team’s
alignment after a decision decisions even if they don’t agree
has been taken? (interviews)
Is there full accountability Check that people that are supposed
and acknowledgment of to be accountable (Scope Owners)
areas of responsibility? effectively feel accountable
(interviews)
Is Blame avoided between Check that no part of the team blames
segments of the Project another one, by sampling events and
Team (in particular in issues that have been difficult for the
difficult times) and in Project
general is there a sufficient
level of trust?
Is there respect for other Check through interviews and
team-members point of observation of team dynamics
view? whether mutual respect is
demonstrated.
Is there a satisfactory Check through interviews and
integration and recognition observation of team dynamics
of local contributors / whether there is demonstrable team
cultural differences between integration between nationalities and
team members (international cultures
Projects)?
Is Project interest clearly Check when people speak whether
recognized to be above they identify whether the Project or
individuals’ Interest, in whether they speak for themselves,
particular in relationships dissociating themselves from the
and communications outside Project.
the Project?
Do team members support Check whether team members remain
each other, and help in their own remit or whether they
compensate each other’s support their colleagues. Interview
weaknesses? people to determine how much time
Are team members ready to they spend on supporting others.
work beyond their normal
remit or go the extra mile to
help the Project / other team
members?
Level 3c – Strategy development
Are alternate scenario being Check that alternate scenario have
produced regularly and been developed and analysed in the
analysed (including past.
consequential impacts on Check that these scenario properly
Project execution)? addressed consequential impacts.
When significant strategic Sample one or two key decisions that
choices are made, is there a have been taken by the Project team
full backup through scenario (e.g. significant change of execution
analysis? strategy, key contractor). Check that
a thorough analysis of the pros and
cons (taking into account
consequential impacts) has been done
in a traceable manner.
Has the Project developed a Check that the Project has developed
clear Contractual strategy a clearly verbalized contractual
and is it acting consistently strategy. Sample that the Project
with it? Manager and key PMT members have
the same understanding of the
strategy.
Has Project Control Check with the PM whether the
proposed to the Project Project Control team has come
Manager alternate execution spontaneously with alternate
strategies based on their execution plans.
knowledge and
understanding of the
Project?
Conclusion
This Chapter gives powerful check points to assess the proper
operation of the Project Control function, up to the strategic level. We
expect that in most cases these lists will highlight those areas of
improvement for the function to really fulfil the Project strategist role. They
can form the basis for internal or external reviews of the Project Control
function.
 Conclusion:
The Project Control Manager,
a Trusted Advisor to the Project
Manager
Project Control Management is a role
which potential importance is often
underestimated. This role can really be a key
success factor for any Large, Complex
Project.
In smaller Projects, this role is filled in by the Project Manager. In
larger, more complex or Projects more onerous to administer, the Project
Manager cannot assume it any more due to constant demands on his time by
various stakeholders and the often global nature of the activity. A Project
Control Manager then becomes required, and this role needs to be filled by
people with sufficient seniority and Project understanding to be a trusted
advisor to the Project Manager.
We have described in this handbook how the Project Control Manager
is at the centre of the data collection of the Project, assuring data
structuring, reliability and accuracy. Except the Project Manager, he is often
the only person with a broad enough vision so as to anticipate possible
direct and indirect consequences of events across the entire Project
execution.
The successful Project Control Manager works under the hood to make
sure that all the data sensors are working. He needs to be able to add some
if required by the circumstances. This role requires significant leadership as
it requires Project contributors to do their part without the Project Control
Manager having direct authority.
 At the same time, the Project Control Manager helps the Project
Manager navigating the treacherous waters of Project execution by devising
and presenting the required decision-making dashboards and tools. In that
instance the Project Control Manager must be able to devise relevant
indicators and visual management dashboards that suit the situation. He also
needs to bring substantial analysis and scenario development capabilities
that allow deeper understanding and better decision-making.
In addition, the Project Control Manager must act as the deputy of the
Project Manager for all commercial and contractual issues.
The most successful Project Control Managers also demonstrate solid
Soft Power capabilities. In the end, Project success in complex
environments will depend on the effectiveness of the Project Team. Projects
are human adventures of teams trying to build things that have never been
done before. Beyond numbers and analytics, the Project Control Manager
must be able to gauge the team’s effectiveness and propose remedies. He
must monitor the quality of communication, coordination and alignment
with the Project Objectives.
Project Control is an essential support to the Project Manager’s
leadership for this human adventure to be a success. To achieve this, Project
Control must be at the forefront of Project execution and not an
administrative back-office. Only then can the Project Control Manager
pretend to the coveted title of ‘trusted advisor’ to the Project Manager.
 Appendix 1:
Project Proposal and Handover
Checklist
The Proposal phase checklist is to be run through by a Project Control
Manager although he/she will generally not have been appointed full time at
that stage. It aims to assure that a minimum of Project Control specifics
have been addressed at that stage, to facilitate the start and the future
control of the Project.
PROPOSAL
1 Payment milestones are well
defined (wording) and refer
clearly to a single deliverable and
a certain status
2 Administration clauses’
onerousness have been limited as
much as possible and Project
team has been sized according to
the requirements (particularly
important for reimbursable
contracts)
3 Contract schedule includes
sufficient float to make Project
execution resilient; alternatively,
a strategy is in place to manage
an unrealistic contract schedule
and is adequately provisioned for.
4 Mobilization curves for Project
team and for construction site
manpower (for essential trades
 and globally) are realistic, taking
into account geographical and
logistical challenges.
5 Project Management and
Engineering costs/ Contingency
have not been slashed
unrealistically as a way to
diminish the selling price
6 Procurement and construction
costs are based on quotes and/or
proven/backed up benchmarks (in
particular, as to the duration of
construction)
7 Bids for long lead items to be
awarded as soon as the Project
starts contain adequate
requirements regarding reporting,
Main Contract flow down and
other essential requirements (ref
Chapter 4).
8 Tax, customs fees, hedging
requirements have properly been
considered and accounted for.
9 (Optional) Legal entities have
been setup or will be setup in
time so as to impact Project
setup.
Note: The handover checklist below includes a few key points to be
checked at the very start of the Project. It is complemented by the start-up
checklist to be applied 2-3 months after the Project kick-off (appendix 2).
HANDOVER
1 Has there been a formal handover
meeting with the
tender/feasibility team (even if
 the same Project Manager
continues on the Project)
2 Have all documents from the
tender/feasibility been safely
recovered including detailed
backup and saved in a secure
area?
3 Have any last minute changes to
the Contract been identified that
require to update the
tender/feasibility reference?
4 Is the estimating team remaining
contactable for the next 3-4
months after handover?
 Appendix 2:
Project Control Setup Checklist
Note: This checklist is applicable at the end of the Project Start-up phase
(depending on the size, pace, and amount of pre-sanction preparation of the
Project, 2-3 months after kick-off).
1 Have Project Objectives been
clearly defined?
2 Have all Project stakeholders
been identified, prioritized and
communication protocols
established for the key
stakeholders?
3 (Optional) Have required legal
entities been created and are they
fully operational?
4 Has an appropriate breakdown
structure been developed and
charge codes inserted in all
relevant systems (including
timesheets, procurement,
accounting, document control
etc.)?
5 Has the Project execution budget
been ventilated across the
execution breakdown structure
with clear history from the
estimating structure? Have Scope
Owners endorsed the
Budget/Schedule allocated?
6 Has the Project budget, schedule,
risk been revised if needed to
take into account last minute
contractual changes and the
actual Project execution plan?
7 Have required hedging /
guarantees / insurances been
issued?
8 Has there been a Project
execution review workshop
(recommended to be done as a
Convergence Plan workshop)
9 Has there been an Opportunity &
Risk review workshop?
(evidenced through a qualitative
risk register with allocation of
mitigating actions to individual
team members)
10 Has there been an update of the
quantitative risk analysis (cost
and schedule)?
11 Has a consistent cost / schedule /
risk baseline been established and
approved?
12 Has a Convergence Plan been
established by the PMT as a
team?
13 Has a clear RACI matrix been
established for the Project? Have
all Work Packages accountability
been assigned each to a single
Scope Owner?
14 Has a regular meeting schedule
been established between Project
Control and other Functions, and
 between Engineering/
Procurement, Procurement/
Construction where Project
Control is invited?
15 Has a Project Calendar been
established including cut-off
dates and intermediate dates for
reports content submission?
16 Has a Main Contract flow-down
been issued to Procurement?
17 Have communication and
reporting requirements with the
suppliers and contractors been
issued to Procurement (including
physical progress norms,
reporting and communications
process, etc.)? Have they been
adapted to the size and
complexity of each purchase /
contract?
18 Has a Contract familiarization
Plan been developed and
implemented, together with the
associated material and unpriced
copies of the Contract?
19 Has an internal Management of
Change process and an Interface
Management process been
established and communicated?
20 Has a Change Order process been
established that includes
identification and tracking of
potential Changes?
21 Have the internal (Project
Sponsor) and external (Client)
 reporting routines been
established?
22 Are there tracking systems for all
types of commitments that will
be encountered on the Project
(including local commitments for
logistics and construction)
23 Is there a clear financial
authorization matrix that covers
all types of expected
commitments on the Project
(including site commitments)?
24 Has a clear physical progress
measurement process been
established for all types of
activities?
25 Have some areas been identified
that require new systems
implementation and is there a
plan to implement those systems?
26 Has a Project kick-off meeting
been organized for the entire
Project team, and has there been
a specific slot for Project Control
to reinforce the message of
compliance to data recording
processes?
27 Has a familiarization / induction
package been developed for all
newcomers on the Project and
does it include basic contract
familiarization and Project
Control requirement sections?
 Appendix 3:
Monthly Project Control Checklist
BASICS
1 Are the regular coordination
meetings happening and are they
effective and are actions defined
and tracked (adapt the list to the
Project phase):
Weekly Project
Coordination meeting
Weekly Schedule
coordination
Weekly
Engineering/Procurement
Weekly Procurement/
Construction
Weekly Internal
Management of Change
and Change Orders
Weekly
Construction/Commissioni
ng
2 Have all known events been taken
into account into the forecast
(cost, schedule), even as an order
of magnitude (immediacy
principle)
3 For each variance, have all root
causes as well as direct and
 indirect consequences been
identified and quantified?
4 Have there been new opportunities
and risks uncovered and are they
taken into account in the Project
Model?
Are existing risks and
opportunities within the register
maintained? E.g. updated effect,
probability, closure status of
actions, new actions identified,
etc.
5 Have all known potential Change
Orders or Claims to the Client
been accounted for, at least in
sensitivities?
6 Have all known potential Change
Orders or Claims from suppliers,
contractors been accounted for, at
least in sensitivities?
7 Have discrepancies e.g. regarding
periodic productivity
measurements, physical progress
etc. been convincingly explained?
8 Has consistency between Cost,
Schedule, Risk and Contract been
checked at least regarding all
changes and variances?
9 Have changes to the schedule due
to productivity issues or other
delivery delays been properly
reflected in Cost, Risk and
Contract?
10 Is the Project weekly coordination
meeting effective in exchanging
 information and updates across the
Project Management Team?
11 Are the Management of Change
and Interface management
processes working properly? Has
there been recently an audit/
review?
12 Is post-award package
management/ expediting working
properly? Has there been recently
an audit/ review?
13 Is the report from the worksite
accurate? Has there been recently
a review/ site visit by Project
Control personnel?
14 Have all the visual dashboards
been updated including
convergence plan, etc.?

ADVANCED
16 Is it worth developing new
specific Key Indicators, visual
management tools to address
the current situation, and is it
worth retiring some that might
be obsolete?
17 As part of the independent data
check, have you implemented
some actions this month to
check the accuracy of key
Project data?
18 Is there a plan to have a peer
review performed on part of
the scope or the entire Project?
19 Have document review
comments, Technical Queries
or equivalent formal exchanges
been reviewed for possible
hidden changes?
20 Is there a particularly complex
transverse issue that might be
better resolved through a short
workshop? What is preventing
the organization of this
meeting?
21 Are there medium-term trends
appearing that would require
response to avoid significant
impacts?
22 Have Weak Signals been
consistently identified and
analysed? Are there currently
Weak Signals detected and
under investigation?
23 Is the Project’s contractual
strategy consistently
implemented?
 Appendix 4:
Project Control Close-Out
Checklist
Project Control close-out needs to be organized in advance. On large
Projects, this check list should be typically considered 6 months prior to the
expected close-out.
1 Has a comprehensive close-out
plan been developed including
a realistic demobilization plan
and necessary allowances?
Does it take into account the
necessary time for producing
close out reports and lessons
learned reports?
2 Is there a template for the
Project close-out report and
Lessons Learnt capture?
3 Have Project close-out
activities been identified as
separate activities with a
relevant budget?
4 Has a contingency and
allowance close-out
management strategy been
decided and relevant indicators
setup?
5 Are cost codes in the time
tracking system being
progressively closed-out?
6 Is it planned to have a formal
close-out and close-out
certificate signature with all
vendors and contractors?
7 Is there a realistic close-out
plan with vendors and
contractors and has this close-
out been anticipated as much as
possible with suppliers?
8 Is there a clear template for as-
built documentation and has
this documentation been
collected for all complete
portions of the work?
9 Is the handover/ close-out
process with the Client/ Owner
clarified so as to avoid loss of
time and enable prompt
closure?
10 Is it clear to what part of the
organization the remaining
liabilities (warranty, possibly
insurance claims etc.) will be
handed over upon Project
close-out?
Is there a formal process
(meeting, check-list, punch list
tracking) put in place for this
formal handover?
11 Has a Project close-out
celebration and reminder token
been organized?
 Abbreviations
and Glossary
Actual Cost (of The actual cost that the Project
Work Performed) has incurred to date. It was
previously called ACWP
(Actual Cost of Work
Performed). It is not the same
as Invoiced Cost (refer to Cost
Control Handbook)
Allowance Specific amounts of money that
corresponds to costs that are not
fully defined but for which
there is a high certainty that
they will happen. They can be
reasonably quantified through
benchmarks and past
experience. Allowances are
defined for specific budget line
items.
CBS Cost Breakdown Structure
Claim A contractual change that is
administered outside the
Contract provision for changes.
Change Order A contractual change that is
administered under the
provision of the Contract for
changes.
Commitments The amount to which the
Project has committed itself to
spend (sum of the value of all
 Purchase Orders, subcontracts
and commitments with regard
to personnel)
Contingency A single amount of money that
is budgeted so as to cover up to
a reasonable level uncertainty
as to the execution of a Project.
It is a reserve available to the
Project Manager, generally only
usable with permission of its
management. It should always
remain commensurate with the
remaining future risks on the
Project.
In some organizations,
Contingency is called
Management Reserve.
(Project) Cost A detailed cost breakdown of
Model the Project (time-phased, by
Work Packages and source
currency and including the
latest forecasts) that is
continuously updated by Cost
Control and serves as a
reference for all subsequent
financial calculations.
The Cost model includes
original budget, tracking of
changes, actual costs, booked
costs, commitments, estimate to
complete and estimate at
completions as well as variance
analysis.
CPI Cost Performance Index, used
in Earned Value Management to
compute the cost productivity.
 CPI = Earned Value/ Actual
Cost. CPI < 1 indicates a lower
than expected cost productivity.
CTR Cost, Time, Resource. A
description of a scope together
with estimated man-hours and
cost (generally used to control
engineering scope)
EAC (Estimate At The Forecast at the end of the
Completion) Project.
EDMS Electronic Document
Management System
EPC Projects Engineering – Procurement –
Construction Projects. This
term designates Projects where
a substantial package including
all associated Engineering,
Procurement and Construction
is included in a single contract
for which a contractor is
responsible.
ETC (Estimate to The amount the Project needs to
Completion) expend to complete the Project
scope, on top of the Actual Cost
of Work Performed.
EVM Earned Value Management
HAZOP HAZard Operability. An
inductive risk assessment
method that is suited to improve
the reliability of processes.
IT Information Technology
KPI Key Performance Indicator
MDR Master Document Register
P&L Profit & Loss
PCM Project Control Manager
PM Project Manager
PMT Project Management Team
Project Model A detailed, consistent
description of the Project,
consisting of the Project Cost
Model, Schedule, Risk Register
and Main Contract (including
approved Change Orders).
RACI A matrix defining
organizational accountability
and responsibility. RACI stands
for Responsible, Accountable,
Consult/ Contribute, Inform.
Risk Register A register of all Opportunities
and Risks identified with regard
to the Project that also includes
ratings and mitigation actions
(where applicable). In advanced
organizations it can present
itself in the form of a database.
ROI Return On Investment
Scope Owner A person that is designated to
be fully responsible for a
section of the Project scope. He
is responsible to update the
forecast (Cost and Schedule),
and needs to drive the related
management activities (e.g.
supplier/ contractor
management).
SMART An action or an objective is
SMART if it is Specific,
Measurable, Achievable,
Relevant and Time-defined.
SPI Schedule Performance Index,
used in Earned Value
Management to compute the
schedule productivity.
SPI=Earned Value/Budgeted
Cost. SPI < 1 indicates a lower
than expected schedule
productivity.
SSA Schedule Statistical Analysis
WBS Work Breakdown Structure
Weak Signals In complex systems, Weak
Signals are slight disruptions
that need to be investigated for
possible significant distruption
on the system due to
consequential impacts.
 Acknowledgments
Many people have taken the time to review and comment earlier drafts
of this handbook, amongst which Jean-Pierre Capron, Johann Declercq,
Babu Surendran, Anthony Nouveliere, Jonathan Crone, Thierry Linares.
Special thanks to Ingvar Skogland, Stanislas Lefort, Antoine Guillard for
very detailed reviews and transformational suggestions.
Companies in general, and consulting companies in particular, are
shaped by their clients. In this instance, we would like to thank particularly
Project Value Delivery’s long-standing clients for their support and input in
giving us the inspiration and drive to produce this handbook. We would like
to thank in particular Subsea 7, SBM Offshore, Eramet Weda Bay Nickel /
Technip, McDermott, Petrofac, SapuraAcergy, who all have provided very
worthwhile inspirations in different contexts.
What would be an author without his family? Warm gratitude go to my
wife and children who have endured the torments of the writer during the
production of the series of books on Project Control.
A tip of the hat to all clients and colleagues with whom I have worked
in the past twenty years for all the great conversations and insights into
Project Control Management – sometimes when we did not even know that
what we discussed would end up in a book!
All mistakes and oversights are the responsibility of the author only.
Corrections, suggestions or feedback should be sent to
[email protected] for inclusion in subsequent editions.
 Table of Figures
FIGURE 1: A TYPICAL LARGE PROJECT ORGANIZATION
FIGURE 2: PROJECT VALUE DELIVERY'S PROJECT START-UP PROCESS
FIGURE 3: PROJECT VALUE DELIVERY'S PROJECT CONTROL SETUP PROCESS
FIGURE 4: PRECISE VS ACCURATE
 Index

A
Accounting, 13, 65, 74

B
Baseline. See Project Baseline
Budget Accountability, 23, 28, 40, 44
Budget Setup, 43

C
Commissioning, 64, 80, 84
Communication Protocols, 28, 35, 47, 73
Consequential Impacts, 24, 107
Consortium Projects, 34, 52, 85
Construction, 58, 64, 68, 78, 83, 153
Contract management, 12, 44, 59, 83
Contract Flow-Down, 44, 77
Contract Strategy, 25, 135, 143
Convergence Plan, 39, 123, 125, 128, 134
Cost Control, 12, 20, 40, 56, 101
Cultural Differences, 141

D
Data Assurance, 55, 115
Data Structure, 28, 35, 37, 38
Document Control, 12, 61, 153

E
Engineering, 57, 61, 66, 74, 83
External Interface Management, 21, 24, 44, 97

I
Immediacy principle, 24
Independent data checks, 115
Independent Reviews, 25, 118

K
Key Performance Indicators, 25, 66, 122, 126

M
Management of Change, 21, 24, 44, 83, 93, 103

P
Procurement, 13, 40, 44, 47, 57, 61, 67, 75, 76, 83, 152
EPC Contractors, 86
Post-Award Management, 98
Project Baseline, 35, 38
Rebaselining, 112
Resilience, 39
Project Close-Out, 25, 151, 189
Project Control
at Project Start-Up Stage, 18, 24, 35, 40, 133, 181
at Tender Stage, 14, 179
Consistency, 101
Coordination, 41, 105, 185
Coverage, 12, 20, 131
Definition, 6, 14
Golden Rules, 23
in Company Organization, 20
in Project Organization, 16, 20
Project Team Education, 51
Project Control Manager
Appointment, 11, 14
Career Path, 17
Competencies, 18
Role, 20, 133
Soft Skills, 51, 70, 141
Project in Consortium. See Consortium Projects
Project Model, 24, 107
Project Objectives, 23, 27, 31
Project Organization, 15
Project Reporting, 69
Project Start-Up, 27, 152
Project Weekly Meeting, 82

R
Reporting. See Project Reporting
Risk Management, 12, 20, 59, 101, 111

S
Schedule Management, 12, 20, 40, 58, 83, 88, 101
Supplier and Subcontractor Requirements, 44
Systems
Project Control, 49
Project Supporting, 40, 47

T
Team Effectiveness, 25, 28, 30, 147

V
Visual Dashboards, 25, 127, 129

W
War Rooms, 129
Weak Signals, 24, 109, 140
Workshops, 30, 144
 Project Value Delivery,
a Leading International Consultancy for
Large, Complex Projects
This cutting-edge Project management book is
sponsored by Project Value Delivery, a leading international consultancy
that “Empowers Organizations to be Reliably Successful in Executing
Large, Complex Projects”.
Part of our mission is to identify and spread the world-class practices that
define consistent success for Project leadership. Ultimately, we want to be
able to deliver a framework that makes Large, Complex Projects a reliable
endeavor.
Our Book Series are a crucial part of this framework, spreading
indispensable good practices and skillsets for leaders in Projects.
Our approach to Project success
At Project Value Delivery we believe that Project success is based on three
main pillars which require sets of skills and methodologies specific to
Large, Complex Projects. All three need to be strong to allow for ultimate
success:
Project Soft Power™ (the human side)
Systems
Processes
We focus on embedding these skills and methodologies in organizations
through consulting, coaching and training assignments. We develop what
organizations need and then help them implement it sustainably,
transferring the knowledge and skills.
We recognize that to be effective, our interventions will involve access to
confidential business information and make it a point to treat all
information provided to us with the utmost confidentiality and integrity.
Our Products
Our
products
are
directly
related to
our three
pillars. We
have developed proprietary methods and tools to deliver the results
that are needed for Large, Complex Projects. In a number of areas,
they are significantly different from those conventional Project
management tools used for simpler Projects.
We focus on consulting, coaching and training interventions where
we come in for a short to medium duration, analyze the situation,
develop customized tools if needed, and transfer skills and methods
to our clients so that they can implement them in a sustainable
manner.
Contact
Contact us to learn more and get great resources for free!
Contact @ ProjectValueDelivery.com, and visit our website
www.ProjectValueDelivery.com where you can register to receive
regular updates on our White Papers.

[1] A board showing the current status of each item in the production process. It is part of the
Kanban Just-in-Time lean production system.
[2] A visual production scheduling tool, part of the Toyota production system, covering the work to
be done immediately as well as the work to be done in the few next time periods.
[3] As mentioned in the Scheduling Handbook, the Convergence Plan is also originally a concept
spread by Toyota for automotive Projects.