See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/301267757

Project Management Traditional Principles

Chapter · December 2016

DOI: 10.1007/978-1-4471-6787-7_1

CITATIONS READS

3 13,015

2 authors:

Franck Marle Ludovic-Alexandre Vidal

CentraleSupélec CentraleSupélec
73 PUBLICATIONS 2,291 CITATIONS 37 PUBLICATIONS 1,526 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Franck Marle on 03 December 2019.

The user has requested enhancement of the downloaded file.

Chapter 1. Project Management Traditional
Principles

Abstract This chapter aims at introducing the reader to a wide range of project
management traditional principles and approaches. It is divided according to the
four phases of the project management process: project definition, project plan-
ning, project execution and project closure. It enables the reader to understand and
handle the basic and widespread concepts and tools of project management, and
practice with an exercise.

1/ Projects

Broadly, the activity of an organization (a firm, an association, a non-profit

organization, etc…) can be divided into two main categories: operations and pro-
jects. Operations involve repetitive and ongoing activities, such as production,
whereas projects are in essence unique and one-shot initiatives, which means that
projects are “not a routine segment of ongoing operations” (Prabhakar 2008a).
Examples of projects can be the following ones:
• Developing and launching new products (new product development projects).
• Designing new organizations (organization projects).
• Improving existing processes within a firm (process improvement projects).
• Staging a play (event project).
• Searching for an innovative process, product, or material (R&D projects).
• Developing a new software (IT projects).
• Constructing a building (construction projects).

As Shenhar and Dvir underline it (Shenhar & Dvir 2007), “with high demand
for growth and innovation, the share of operations in most organizations is decli-
ning and the share of projects is on the rise”, as shown on Fig. 1.1.. As they ex-
plain it, this trend is present in almost every organization and industry since “the
only way organizations can change, implement a strategy, innovate, or gain com-
petitive advantage is through projects”.
2

!
Fig. 1.1. The increasing share of projects (Shenhar & Dvir 2007)

However, when most of firms or organizations have kept on improving their

operations (through theories and concepts such as lean manufacturing or six sig-
ma), despite the fact that projects have been encountered everywhere, few organi-
zations have been paying as great attention to their projects. This is a pity since
the conjoint improvement and collaboration between projects and operations is a
crucial success factor for a firm (Cooke-Davies 2002). As a consequence, focusing
on projects, focusing on innovative, efficient and effective approaches to manage
them is to create great value for modern organizations. That is why this book pro-
poses to study projects and project management, particularly focusing on the phe-
nomenon of project complexity and its implications on project management and
project risk management. This book is divided into three parts:
• PART I – Project Management traditional approaches and their limits regarding
complexity
• PART II – Systems oriented approaches to assist complex project management
• PART III – Graph and matrix oriented approaches to assist complex project
management
Before carrying out any pertinent research on the subject, one is first to define
properly what a project is. Basically, a lot of definitions do exist, as highlighted in
(Turner 1992; AFITEP 1999; Marle 2002; AFNOR 2004; Lock 2007; Walker
2007; Gido & Clements 2011; Meredith & Mantel Jr. 2011; Kerzner 2013) for
instance. The definition proposed in this book is an adaptation of the Project Ma-
nagement Institute definition (PMI 2013):
 3

Definition – adapted from (PMI 2013)

A project in an organization is a temporary endeavor undertaken to deliver a
result.

Fig. 1.2. The five steps of the commonly-accepted project management process

As mentioned before, this result is always a change in the organization, whate-

ver it is in its processes, performance, products or services (Reiss 2013). This
transformation consists then in a gap between a start (definitive beginning) and a
final state (definite ending). Time and resources are consumed to produce results,
which may be deliverables and/or performance improvement and/or resource im-
provement (skills, knowledge). Each project is unique because there is always at
least one of the following parameters that changes: targets, resources and envi-
ronment.
As projects became more and more present into organizations, and as they had
bigger and bigger amounts at stake, it became impossible to let them live without
specific and rigorous methodology. As a consequence, project management was
created as a formalized and structured methodology which could permit to assist
the completion of projects through the application of adapted tools and techniques.
It is usually admitted than modern project management appeared during World
War II and was initially dedicated to big military and construction projects, when
the first principles of organization, planning, and overall management were propo-
sed. Project management has then grown up and spread around the world to be-
come what it is today, that is to say a set of theories, principles, methodologies and
practices (WBS -Work Breakdown Structure, PERT -Programme Evaluation and
Review Technique- networks, Gantt charts, Earned Value Methodology, etc…),
sometimes included in a standard body of knowledge such as PMI (PMI 2013) and
IPMA (IPMA 2006). However, there can still be some lack of consensus on the
definition and description of projects as well as their objectives, processes and
elements.
4

The aim of this first chapter is to present a theoretical and practical overview of
these traditional project management approaches and tools. In order to do so, they
will be presented while navigating through the commonly-accepted project mana-
gement process which is composed of five steps: project initiation (Paragraph 2),
project planning (Paragraph 3), project execution (Paragraph 4), project monito-
ring and control (Paragraph 5), project closure (Paragraph 6) (Fig 1.2.).

2/ Initiating projects

The very first question when starting to discuss about a future project / working
on a new project is: “How can I ensure a good start for this project?”. Indeed, the
issue of initiating a project is all the more important since an unclear definition of
the project attributes during this phase (scope, specifications, objectives, etc…) is
likely to generate many failures later. But initiating a project is among the most
difficult part of project management, notably for several reasons:
• The piece of information that one may have in possession when initiating a
project is generally small and unclear. This fuzzy and uncertain environment is
part of a particularly difficult context to work in.
• The different stakeholders generally meet / discuss with each other during the
initiation of the project, sometimes for the first time. It is often (very) difficult
to understand all the stakes which are behind the project for communication is
not facilitated since it is the beginning of the project (often with people work-
ing together for the first time and not knowing each other).
• The reasons why the project is initiated are not always clearly known, and the
objectives / final deliverables of the project are sometimes very unclear. Differ-
ent visions and concepts might even be in competition.
• …

The initiation phase of the project should permit to bridge the existing gaps
between different visions and clarify all the aspects of the project before starting
it. It aims at clearly defining the raison d’être of the project, its objectives and de-
liverables in terms of clarified specifications, and fixing them through contracting
processes between the stakeholders of the project. This section proposes methodo-
logies and tools to reach success in this initiation phase, using a three step clarifi-
cation of the project elements.
 5

The project launching phase should be addressed through three principal

steps.

• Step 1 : Specifying project values and objectives

• Step 2 : Defining project scope

• Step 3 : Project contracting

2-1/ Specifying project values, objectives and deliverables

If the vision of the project is not shared, it will not meet success. Therefore, in
order to ensure a good launching (and a good execution) of a project, the project
values and objectives need to be clearly and consistently defined so that they can
be shared by the whole project team and the project stakeholders. An intuitive
approach, based on systems thinking (Boulding 1956; Von Bertalanffy 1972; Le
Moigne 1990) is presented here.

2-1-1/ Understanding the raison d’être of the project

First, the project manager (and possibly the steering committee which might be
already created during the launching phase) should study why the project is initia-
ted. Whether in the context of a public institution, a firm, a consortium, etc…, the
reasons for launching the project need to be clarified: they are the raison d’être of
the project and every project value / objective which is to be listed later on during
the process is to be considered in light of what the raison d’être of the project is.
As a consequence, time should be taken to identify and understand these reasons.
It is all the more important to know them since they can permit to understand and
give priorities to objectives better later on. For instance, if one of the objectives of
the project is to reduce cost by 10%, this objective will clearly have a different
meaning if the raison d’être of the project is whether:
• to make more profit through an increase of the sales,
• to try to reduce a loss of market share which has been observed for competitors
are cheaper,
• to change of paradigm for all the projects of the firm (change processes, etc…)
since there is not enough liquidity anymore to ensure the production of prod-
ucts as before.
6

2-1-2/ Cutting the project in a priori phases

Once the raison d’être of the project understood, the project timeline should be
decomposed into a priori phases, which corresponds to the evolution of the project
over time, often known as the genetic view of the project.

Definitions and characteristics

A phase of a project is a part of a project (including every aspect of the

project) which covers a period of its existence. It is defined by a number
and/or a name, a start date SD and an end date ED.

The phases of a project are generally disjoint and separated by one or sever-
al milestones of the project. The successive phases should cover the entire
period of existence of the project (its lifecycle).

The cutting of the project lifecycle into phases can be done according to several
criteria. For instance, a phase can be defined according to an ensemble of delive-
rables which must be delivered at a certain date ED after a period of work starting
on SD. Another way to decompose a project into phases can be linked to the suc-
cessive geographical locations the project occurs in.
Another traditional example for decomposing the project into phases in the
case of new product development projects can be to follow the product lifecyle
(Saaksvuori & Immonen 2008):
• Phase 1 : Market study about the new product / concept,
• Phase 2 : Research and conception of the product (definition of the specifica-
tions of the product, design of the product, ...),
• Phase 3 : Industrialization to perform the production of the product (acquisi-
tion of infrastructures and machines, definition of production processes, …),
• Phase 4 : Starting the production of the product,
• Phase 5 : Starting the distribution, marketing and retail of the product,
• Phase 6 : Following the first sales of the product,
• Phase 7 : Identifying potential future improvements / innovations for the
product (customer-driven or not) and production / distribution / marketing /
retail /… processes (the outputs of this phase might be the data to launch one
or several new projects),
• Phase 8 : Closing the project.2-1-3/ Listing project stakeholders, understand-
ing their expectations and constraints
Once the phases of the project being identified, one should list the stakeholders
of the project during each phase.
 7

Definition

A project stakeholder is a person, a group, a firm or any organizational sys-

tem which affects or can be affected (for it has interest or concern in the
project) by the project.

Fig. 1.3. Description of phases and stakeholders

Project stakeholders can be within or outside the project organization. They can
for instance foster the project (industrial sponsors, organizations which give sub-
sidies, banks,…), affect or be affected by the execution and completion of the pro-
ject (the organization which executes the project, employees, unions , suppliers,
customers,…), whether negative or positive. The project stakeholders are not the
same during the project. Indeed, if some are present all over the project, some are
present only in some phases. That is why when trying to identify all project stake-
holders, one should focus on each phase and perform this identification within
each phase of the project. Once a project stakeholder is identified in a phase, two
questions should necessarily be answered :

• What does this stakeholder expect from the project in this phase ?
This question permits to identify the expectations which should be reached to
contribute to the satisfaction of this stakeholder during this phase. The project can
satisfy these expectations to a certain satisfaction level or not. Examples of these
expectations within a phase can be “Good working conditions” and “Good sala” f
• What are the constraints of this stakeholder within this phase ?
This question permits to identify the constraints which are related to a stakeholder
during a given phase. Such constraints can be for instance norms, contractual as-
pects, which have no flexibility. The combined identification of all stakeholders
and their expectations / constraints during each phase correspond to what is often
known as the teleological view of the project (which permits to define the project
values and objectives as seen later). At the end of this process, two kinds of docu-
ments are important deliverables of the initiation phase:

Doc. 1.P.: For a given phase of a project (phase P), a document including a
short description of phase P with all stakeholders present in this phase, and
the related expectations and constraints.

Doc. 1.S.: For a given stakeholder of a project (stakeholder S), a document

including a short description of stakeholder S all phases in which the stake-
holder is present, and the related expectations and constraints.
8

With Doc. 1.P., the project team is able to know at a glance all the stakeholders
which are to be satisfied during phase P. With Doc. 1.S., the project team is able to
see at a glance the evolution of expectations/constraints related to stakeholder S
throughout the project, which permits to guarantee its satisfaction better. When
doing so, an exhaustive stakeholders-oriented list of measurable goals is obtained
and can be used permanently during the project in order to drive and control it.
Empty models for these documents are given hereinbefore (Fig 1.3.) as practical
hints which can be used directly or slightly adapted to any project-oriented envi-
ronment.

1.1.5. Understanding the project values, objectives and deliverables

In the end, all stakeholders expectations/constraints have been listed when

using this process. These requirements need to be met during the project in order
to guarantee the satisfaction of the project stakeholders. For all practical purposes,
they can be synthesized under certain common denominations. These denomina-
tions are the values of the project (for instance economic value, social value, envi-
ronmental value, etc…), which should be described with a short summary of what
the related expectations/constraints that should be reached during each phase. The
project values are crucial issues to communicate on during the project (internally
and/or externally) since they permit to focus on the aims of the project. In particu-
lar, they are good way to understand the connection of the project to the strategic
objectives of the firm/organization and thus to answer the “so what?” question.
These values can be subdivided into project objectives. The project objectives
are measurable achievements which the project should meet. For instance, under
the environmental value, two objectives could be “O1 – Reduce carbon footprint
by 25% during the production and distribution processes” and “O2 – Reduce toxic
waste by 10% during the production process”. Another example could be for the
economic value : “O1 – Reduce production costs by 5%” and “O2 – Increase pro-
fit by 10%”. Project objectives can of course be interdependent (whether comple-
mentary or contradictory): understanding the relationships between project objec-
tives is absolutely crucial. Finally, the project deliverables (what should effective-
ly be produced during the project) need to be identified and described. Each pro-
ject deliverable contributes to one or several project objectives. At this time, one
should check that any deliverable contributes to at least one objective and that any
objective is guaranteed by at least one deliverable.
When defining the project objectives and deliverables, an important aspect is to
understand them through the filter of project values. Indeed, re-reading the objec-
tives/deliverables of the project by understanding the relationships and stakes with
 9

project values permits to have constantly in mind the essence of the project and
why it exists, which is more than desirable in order to bring success (Vidal &
Marle 2012). In the end, two kinds of documents should be produced:

Doc. 1.O.: For each project objective O, a document including a short de-
scription of objective O, with the impacted values and stakeholders (in terms
of expectations/constraints).

Doc. 1.D.: For each deliverable D, a document including a short description

of deliverable D, with the impacted objectives (and thus objectives and
stakeholders when referring to the corresponding Doc. 1.O. documents).

These documents permit to define properly the frontiers of the project scope.
At anytime, project team members should remember that what is outside project
scope is outside the project and should not be performed.

2-2/ Contracting in projects

As stated by (Danayand & Padman 2012), “contractual agreements have assu-

med significant complexity in recent times because of the emergence of strategies
like outsourcing and partnering in the successful completion of large software
development, manufacturing and construction projects”. Project contracting activi-
ties occur throughout the project, either by bidding or negotiation, an important
number of them being performed just before starting the project, during the initia-
tion phase. If possible, all the documents which were presented before should be
constructed before project contracting since they permit to understand and des-
cribe perfectly the needs and requirements of all stakeholders (through the exhaus-
tive description of expectations and constraints). For all practical purposes, it is
never the case since a large amount of precise information are needed to complete
them, and that such information is not always obtainable before contracting. The
documents are partially built up before launching the contracting process, and the
final discussions/negotiations permit to finish them. This often implies that discus-
sions are likely to be carried out during the execution of the project, to amend /
complete some parts of some contracts, to fix them when they have been fixed
(Badenfelt 2011).
An effective contracting process permits to build a sane project environment,
due to the fact that “the project contract provide a basis for the project company’s
[…] operation of the project” (Yescombe 2002) and that contracts are in essence
the documents people refer to when disputes occur (Zhu et al. 2013). Project
10

contract are the first tiles which permit to build up a cooperative organization “in
which all participants, clients and contractors, are motivated to achieved common
objectives” so that “their goals are aligned” (Turner & Simister 2001). Every
contract in a project is very specific to the context of the project and the nature of
the contract and the related stakeholders (public, private, public-private, etc…/
supplier, customer, etc…). In order to execute properly the project contracting
activities, one should focus on the specificities of each contract and to the rules of
the corresponding field. However, a certain number of rules should be followed
for every project contract:
• Investigate if any contract of this kind was formerly signed. If so, refer to it,
notably if any good points / problems had been identified.
• Avoid generic contracts (notably best practices found on the Internet) since a
contract is in essence specific to a context. Formulating a contract using
generic formulations implies forgetting clauses, unclear specifying, etc…
• In particular, investigate if any contract of this kind was formerly signed with
the stakeholder one is going to sign with. If so, refer to it, notably if any good
points / problems had been identified. Moreover, knowing the former con-
tracts or the presently existing contracts with a given stakeholder increases
the numbers of levers during the negotiation process (scale effects, historicity
of the relationship and loyalty, etc…).
• Particular attention should be paid to the exhaustive description of objectives
and deliverables, and the criteria / scales / tools which will be used to measure
their production (notably through the construction and use of documents Doc
1.O and Doc. 1.D, which can easily become appendices to the contract).
• As a whole, every contracting process during a process should include discus-
sions on the eight key drivers listed by Von Branconi and Loch (von Branconi
& Loch 2004): technical specifications, price (quality of cost estimates), pay-
ment terms, schedule, performance guarantees, warranties, limitation of liabil-
ity and securities.

3/ Planning projects

Once the project initiated, planning the project is necessary in order to build
initial reference documents for project execution as well as project monitoring and
control (PMI 2013). For all practical purposes, the outputs of this planning process
are more than likely to be revised into successive versions, depending on the pro-
ject execution, monitoring and control activities, re-planning being often necessa-
ry. Whatever the number of iterations which are likely to happen during a project,
project planning processes can be divided into several processes which are presen-
 11

ted afterwards. A possible division into sub-processes is the one presented herei-
nafter:

• Scope and work planning (see 3-1/)

• Time planning and scheduling (see 3-2/))
• Resource and cost planning (see 3-3/)
• Quality and performance planning (see 3-4/)
• Risk planning (see 3-5/)

Due to the orientation of the rest of the book, parts 3-2/ and 3-5/ will be the
most developed ones.

3-1/ Scope and work planning

Two main issues correspond to the scope and work planning activities. The first
one corresponds to the correct definition of the scope and specifications of the
deliverables of the project, for instance the produce / service / system which is
created by the project (3-1-1). The second one corresponds to the correct defini-
tion of the scope and decomposition/organization of the work and activities which
are to be carried out during the project (3-1-2).

3-1-1/ Specifying deliverables

Describing the deliverables of the project in terms of precise specifications and

requirements is an input to identify more accurately the work which will have to
be done during the project. The definition of good-quality and stable requirements
is even an important success factor of projects (Yang et al. 2015). This is particu-
larly true for new product development projects (need to define the specifications
of the developed product), IT projects (need to define the requirements of the de-
veloped software), or construction projects (need to define the characteristics of
the infrastructure which is going to be built) for instance. Many methodologies do
exist to define the specifications and requirements of the deliverables of a project.
As underlined in (Cano & Lidón 2011), such specification definition process is the
logical continuation of the stakeholders (as well as their expectations and
constraints) identification (as presented before). A proper and robust approach to
identify requirements is all the more needed that the latter a change of requirement
occurs during a project, the more important (in terms of cost, rework, etc…) its
impact is.
12

Some of these methodologies can be considered as “internal”, meaning that the

deliverables of the project and their components are studied a priori so that their
specifications are correctly defined. Functional Needs and Solutions Analysis is
one of these methodologies and permits to define the specifications of a system by
studying its interactions with its environment in all the phases of its lifecycle
(Yannou 1998). Other methodologies are on the other hand considered as “exter-
nal”, meaning that the requirements are defined without studying the deliverables
themselves, but asking clients and stakeholders how they would specify the deli-
verable. Customer listening methods are for instance a group of methodologies
which permit to define the specifications of a system in order to meet the needs of
their users, clients and market (Garver 2003), (Gannon-Leary & Mccarthy 2010).
As a whole, the conjoint use of such internal and external methods provide the
best results in practice.

3-1-2/ Decomposing and organizing work

Project scope and work planning includes the process of decomposing and or-
ganizing the entire project work into smaller and thus more manageable packages
of work (Tiner 1985). Such an organizational structure which permits to subdivide
the overall project processes into sub-processes permit to manage more efficiently
the execution of the project and measure its performance, given the fact that smal-
ler units of work are in essence accountable more easily. The traditional tool
which permits to decompose and organize work in a project is the Work Break-
down Structure (WBS), which consists in a hierarchical structure which decom-
poses units of work into smaller units of work. Several rules should be kept in
mind when the WBS (examples given in Fig 1.4) of the project is built up:
• The WBS should be a bijection of the project scope: what is inside the WBS
must be done during the project, what should be done during the project must
be inside the WBS(Stal-Le Cardinal & Marle 2006).
• Each parent unit of work, when decomposed into smaller units, should be
decomposed into 3 to 7 children, so the decomposition is useful and still easi-
ly understandable and manageable, the children units of work being sufficient
enough to completely describe the parent unit of work (bijection) (Marle
2002).
• Each parent unit of work, when decomposed into smaller units, should be
decomposed into homogeneous children units of work (for instance according
to project phases, geographical locations, customers/users/stakeholders, prod-
uct components, etc…).
• Each elementary unit of work should be possibly measured in terms of cost,
time, and performance (quality, project values, etc…).
 13

Fig. 1.4. Examples of Work Breakdown Structures (two different projects)

3-2/ Time planning and scheduling

Once the project work is organized and decomposed, it can be planned in terms
of time and scheduling. In order to do so, two processes should be addressed first.
First of all, a logical arborescence should be built up to express the sequencing
relationships which exist between the project identified tasks, meaning that, for
each task, its predecessors (the tasks which need to be completed as a direct input
for the considered task) must be identified. Second, the duration of tasks should be
addressed. In most cases, the duration of a task is estimated by analogy (with for-
mer or other projects in the firm), parametric estimation (using equations) or ex-
pert judgment. The duration of a task is of course dependent of the number of re-
sources which will be attributed to the task, and that is why, it is firstly associated
with the number of human resources which are necessary to complete the task so
it can have this duration. All this piece of information can be summed up into a
tasks description table (e.g. Fig 1.5., example which will be used throughout the
chapter).
14

Task number Predecessors Expected Duration Resources

T1 / 3 1
T2 T1 2 2
T3 T1 4 1
T4 T2 5 3
T5 T3 8 2
T6 T3,T4 4 3
T7 T3 3 2
T8 T5,T6 5 5
T9 T7 5 2
T10 T6 4 6
T11 T8,T9 2 3
T12 T10,T11 2 2
T13 T9 11 1
T14 T12,T13 3 2

Fig. 1.5. Tasks description table (duration in weeks)

Fig. 1.6. Template for project planning and scheduling for each task

3-2-1/ Scheduling without uncertainty

Under the hypothesis that the data included in the tasks description table are
certain, it is possible to perform an exact project time planning and scheduling
process. In order to so, we propose to use a template to complete necessary data
for each task (Fig 1.6.). The methodology and formalism proposed in this book is
somewhat a direct extension of the famous Program Evaluation and Review Tech-
nique (PERT) methodology (Fazar 1959), (PMI 2013), in which the expected du-
ration ED of a task is often calculated as:

(Pessimistic duration (Ti) + 4 Mean Duration (Ti) + Optimistic Duration (Ti )

ED (Ti) =
6
(1.1)

The approach proposed here can be divided into four steps (Fig 1.7.):
• Step 1/ Draw the task network using empty task templates
 15

• Step 2/ Calculate earliest start and end dates from the left to the right
• Step 3/ Calculate latest start and end dates from the right to the left
• Step 4/ Calculate total and then free floats
Step 1 T7 3 T9 5 T13 11

T3 4 T5 8 T8 5 T11 2 T12 2 T14 3

T1 3 T2 2 T4 5 T6 4 T10 4

Step 2 T7 3 T9 5 T13 11
7 10 10 15 15 26

T3 4 T5 8 T8 5 T11 2 T12 2 T14 3

3 7 7 15 15 20 20 22 22 24 26 29

T1 3 T2 2 T4 5 T6 4 T10 4
0 3 3 5 5 10 10 14 14 18

Step 3 T7 3 T9 5 T13 11
7 10 10 15 15 26
7 10 10 15 15 26

T3 4 T5 8 T8 5 T11 2 T12 2 T14 3

3 7 7 15 15 20 20 22 22 24 26 29
3 7 9 17 17 22 22 24 24 26 26 29

T1 3 T2 2 T4 5 T6 4 T10 4
0 3 3 5 5 10 10 14 14 18
0 3 6 8 8 13 13 17 20 24
16

Step 4 T7 3 T9 5 T13 11
7 10 10 15 15 26
7 10 10 15 15 26
0 0 0 0 0 0

T3 4 T5 8 T8 5 T11 2 T12 2 T14 3

3 7 7 15 15 20 20 22 22 24 26 29
3 7 9 17 17 22 22 24 24 26 26 29
0 0 0 2 0 2 0 2 2 2 0 0

T1 3 T2 2 T4 5 T6 4 T10 4
0 3 3 5 5 10 10 14 14 18
0 3 6 8 8 13 13 17 20 24
0 0 0 3 0 3 0 3 4 6

Fig. 1.7. Building up the complete project network – schedule calculations

Commenting Fig 1.7., Step 1 permits to draw the complete project network
according to sequencing relationships using the template presented in Fig 1.6.
Step 2 permits to complete the earliest start and end dates for each test, from
the left to the right, given three rules. Let the unit of time in this example be weeks
(it would obviously be the same with any time unit). First, the first earliest start
date in the network should be 0 with this formalism (meaning the first task starts at
the end of week 0). Second, with this formalism, for every task, the relationship
between the earliest start and end dates is given by the formula:

Ea rliest End Date (Ti ) = Ea rliest Sta r t Date (Ti) + Duration(Ti )

(1.2)

For instance, for task T1, since its earliest start date is 0 and its duration is 3, its
earliest end date is 3. Third, Step 2 can finally be completed using the rule that if a
task has predecessors in the project network, then its earliest start date equals the
maximum earliest end date of its predecessors (the task cannot start before all of
its predecessors ended, which is the direct logical information for earliest start
date calculation).For instance, task T2 has only one predecessor T1: the earliest
start date of T2 is thus the earliest end date of T1, which means 3. Focusing on task
T6, it has two predecessors in the network, T3, the earliest end date of which is 7,
and T4, the earliest end date of which is 10: as a consequence, the earliest start
date of T6 is 10, since T3 and T4 must be completed before it can start.
Step 3 permits to complete the latest start and end dates for each test, from the
right to the left, given three rules. First, the first latest end date which can be com-
pleted in the network in the network is the one of the last task, since its latest end
date equals its earliest end date. Here, it corresponds to T14, the latest end date of
which is the same as its earliest end date, that is to say 29. Then, with this forma-
lism, for every task, the relationship between the latest start and end dates is simi-
lar to the one for earliest start and end dates, and given by the formula:
 17

Latest Sta r t Date (Ti) = Latest End Date (Ti) − Duration(Ti )

(1.3)

For instance, for task T14, since its latest end date is 29 and its duration is 3, its
latest start date is 26. Finally, Step 2 can finally be completed using the rule that if
a task has successors in the project network, then its latest end date equals the mi-
nimum latest start date of its predecessors (the task cannot end after one of its suc-
cessors should start, which is the direct logical information for latest end date cal-
culation). For instance, task T12 has only one successor T14: the latest end date of
T12 is thus the latest start date of T14, which means 26. Focusing on task T6, it has
two successors in the network, T8, the latest start date of which is 17, and T10, the
latest start date of which is 20: as a consequence, the latest end date of T6 is 17,
since it must be completed before T8 or T10 should start.
Task/Week 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
T13
T14

Non critical task (duration - earliest) Critical task (duration)

Non critical task + free float
Non critical task + total float

Fig. 1.8. Gantt chart of the project (without sequencing relationships between tasks)

Step 4 can then be completed to calculate the free and total floats of each task.
Let us start with total floats. The total float of a task corresponds to the number of
units of time (weeks here) a task can be delayed without affecting the end date of
the project. As a consequence, it is directly given by the following formula:

Total Float (Ti) = Latest End Date (Ti) − Ea rliest End Date (Ti )
(1.4)

For instance, for task T10, since its latest end date is 24 and its earliest end date
is 18, its total float is 6. Then, free floats can be calculated. The free float of a task
corresponds to the number of units of time (weeks here) a task can be delayed
without affecting the earliest start dates of any of its successors in the network. As
a consequence, it is directly given by the following formula:
18

Free Float(Ti) = min (Ea rliest Sta r t Date (Tj)) − Ea rliest End Date(Ti)
Tj, Successor of Ti
(1.5)

For instance, for T10, it has one successor, T12, the earliest start date of which is
22, thus the free float of T10 equals to 22 minus 18 (T10 earliest end date), that is to
say 4. Another example is T6 (the earliest end date of which is 14), which has two
successors, T8, the earliest start date of which is 15, and T10, the earliest start date
of which is 14: as a consequence, the free float of T6 is 0. Once the network com-
pleted, one can identify the critical tasks of the network, which are the ones, the
total float of which is null (Lockyer 1976; Veitch 1984; Willis 1985). The critical
path(s) is (are) the path(s) of the project network which is (are) constituted by cri-
tical tasks only. Deeper attention should be paid to the execution of critical tasks
due to absence of total float: any delay for these tasks implies a delay for the ove-
rall execution of the project.
If this approach and formalism permit to perform calculations quickly and easi-
ly, they are not the best tools to communicate with the project team / stakeholders.
Gantt charts (such as in Fig. 1.8.) are a widespread tool which permits to represent
easily with horizontal bars the overall planning of the project. Such Gantt charts
can be built for earliest dates or latest dates (earliest in Fig. 1.8.). In order to build
up a Gantt chart from the data which are present in the complete project network
with the formalism of Fig. 1.7., one should notice that for each task, the end dates
are the same in the network and in the Gantt chart, and that the Gantt start dates
equal the project network start dates plus 1. This is a direct consequence of the
fact that with the formalism used in project networks as presented before in Fig.
1.7., the start dates should be understood as the end of the corresponding time
unit. For instance, in Figure 1.7., T1 starts at the end of week 0, thus at the begin-
ning of week 1, as illustrated in the Gantt chart in Fig. 1.8. Another example is T6,
which starts at the end of week 10 in the project network, and thus at the begin-
ning of week 11 in the Gantt chart.

3-2-2/ Scheduling with uncertainty

During the scheduling process, the estimation of task duration and thus the
theoretical scheduling is uncertain. Some tools permit to cope with such uncertain-
ty. For instance, advanced methodologies permit to determine the most likely cri-
tical path within a probabilistic project network (Soroush 1994). Other models
have been developed to propose solutions to the project scheduling problems with
uncertain durations: based on sensitivity analyses (Samikoglu et al. 1998), Markov
 19

chains-based models (Hao et al. 2014), fuzzy logic (Shi & Blomquist 2012; Mas-
moudi & Haït 2013), stochastic models and associated heuristics (Bruni et al.
2011).
Under uncertain conditions, before using such more advanced approaches, di-
rect calculations and comments can be performed with the models presented in
Fig. 1.7 in order to study the robustness of a project schedule when facing some
uncertainty for task duration evaluation. For instance, in Fig. 1.9, one can see a
summary of the potential impacts on the project and on the direct / indirect suc-
cessors of T6 of an uncertain evaluation of T6 duration. In order to build up such a
table, one should follow the changes in the project network using Fig. 1.7. Initial-
ly, T6 is supposed to last 4 weeks. Let the evaluation of T6 be uncertain, with T6
lasting from 2 to 8 weeks, each of these possibilities being equally likely. Since
T6’s free float equals 0 and total float equals 3, we already know that for durations
under 7 weeks (initial duration + total float), there is no impact on the project du-
ration , and for durations under 4 weeks, there is no impact on the successors of
T6, whether direct or indirect. When T6’s duration equals 8 (4 weeks delay for T6),
the project has 1 week delay (Delay of T6 – Total float of T6). For durations of T6
from 5 to 7, the impacts on its successors can be assessed step by step, first on its
direct successors (T8 and T10), and then on indirect successors (T11 and T12), which
permit in the end to complete all values in Fig. 1.9. As a whole, with such uncer-
tainty about T6’s duration, the probability of project late completion equals 0,143
(1 case out of 7) when the probability of changes in the project network equals
0,571 (4 cases out of 7).
T6 duration Impact on T8 Impact on T10 Impact on T11 Impact on T12 Impact on the project
2 No change No change No change No change No change
3 No change No change No change No change No change
4 No change No change No change No change No change
5 No change Plus 1 week No change No change No change
6 Plus 1 week Plus 2 weeks Plus 1 week Plus 1 week No change
7 Plus 2 weeks Plus 3 weeks Plus 2 weeks Plus 2 weeks No change
8 Plus 3 weeks Plus 4 weeks Plus 3 weeks Plus 3 weeks Plus 1 week

Fig. 1.9. Impacts of uncertain T6 duration

20

T10 duration T8 duration Impact on T11 Impact on T12 Impact on the project
6 6 Plus 1 week Plus 1 week No change
7 6 Plus 1 week Plus 1 week No change
8 6 Plus 1 week Plus 1 week No change
9 6 Plus 1 week Plus 1 week No change
10 6 Plus 1 week Plus 2 weeks No change
11 6 Plus 1 week Plus 3 weeks Plus 1 week
6 7 Plus 2 weeks Plus 2 weeks No change
7 7 Plus 2 weeks Plus 2 weeks No change
8 7 Plus 2 weeks Plus 2 weeks No change
9 7 Plus 2 weeks Plus 2 weeks No change
10 7 Plus 2 weeks Plus 2 weeks No change
11 7 Plus 2 weeks Plus 3 weeks No change
6 8 Plus 3 weeks Plus 3 weeks Plus 1 week
7 8 Plus 3 weeks Plus 3 weeks Plus 1 week
8 8 Plus 3 weeks Plus 3 weeks Plus 1 week
9 8 Plus 3 weeks Plus 3 weeks Plus 1 week
10 8 Plus 3 weeks Plus 3 weeks Plus 1 week
11 8 Plus 3 weeks Plus 3 weeks Plus 1 week

Fig. 1.10. Impacts of simultaneous uncertainties about T10 and T8

Similarly, such step by step approach can be used to study the impacts of the
simultaneous variation of duration of two tasks in the project network. For ins-
tance, Fig. 1.10 studies the impacts on T11, T12 and the project of a simultaneous
under-evaluation of T10’s duration from 6 to 11 weeks and of T8’s duration from 6
to 8 weeks. As a whole, the probability of project late completion under such
conditions equals 0,389 (7 cases out of 18).
Such information corresponds to a direct study of the project network comple-
ted in Fig. 1.7. without using advanced scheduling methods and can be easily per-
formed in any project in order to ensure the robustness of initial traditional sche-
duling.

3-3/ Resource and cost planning

The next step when planning a project is then to allocate resources (either hu-
man, material, etc…) and plan cost. Each of these processes are now presented in
this section.
 21

3-3-1/ Resource allocation

In order to allocate resources, one should be able to describe its resource pool
using several parameters, depending on the type of resources. For instance, in
terms of human resource parameters, such parameters could be: skills, experience,
availability (holidays/working on another project/…), cost per week, etc… Or in
terms of material, such parameters could be: cost per unit, quality, supplier, etc…
The resource allocation process permits to allocate resources to the project accor-
ding to its scope and schedules, given these description of possible resources. Due
to the number of parameters, this resource allocation problem is in essence a mul-
ti-criteria problem.
This paragraph will specifically focus on human resources allocation, even
though many of its aspects can easily be transposed to other kinds of resources.
When dealing with human resources, one of the stakes of the resource allocation
problem is the consistence between the skills of selected human resources and the
skills needed to perform project tasks, since low skills are likely to cause project
delay (due to errors implying rework, due to the necessity to plan some training
activities, etc…) (Otero et al. 2009). In order to answer this problem, advanced
approaches have been proposed: based on system dynamics and control theory
models (Joglekar & Ford 2005), based on decision theory and dynamic program-
ming (e Silva & Costa 2013), or based on operations research, optimization mo-
dels and associated heuristics (Konstantinidis 1998; Brucker et al. 1999).
If these methods are interesting and permit to answer complex problems, basic
approaches often permit to allocate resources, using simple reasoning on the
constraints of the problem. Let the project tasks be described by the skills needed,
with the skills being assessed on a cardinal scale (from 1 to 5 for instance). Let
each possible actor of the project be described by a certain number of parameters,
such as skills (on a cardinal scale), cost, availability (holidays,…). Using the pro-
ject network and schedules, and using rules about the skills, one can determine the
actor(s) which should perform a given task. Such rules about the skills could be
for instance that for each skill required, at least one allocated actor should have the
skill at the required level. Step by step, human resource allocation can be perfor-
med for the whole project by following such rules. Let us consider for instance the
example given in Fig. 1.11, knowing that the number of human resources needed
for each task were already given in the table in Fig. 1.5, and that we focus on hu-
man resource planning until Week 10.
22

Task Marketing Design Logistics Information systems

T1 5 1 2 4
T2 2 5 2 5
T3 4 5 0 0
T4 4 5 5 4
T5 4 5 5 3
T7 5 2 4 5

Actors Marketing Design Logistics Information systems Cost / week Holidays

Bernadette 5 2 4 4 1200 $ 4/5
John 4 1 2 5 1500 $ 2/12
Paul 4 5 3 3 1200 $ 1/15
Fred 4 2 5 3 1000$ 3/4
Olivia 3 5 2 2 800 $ 5
Jane 3 2 5 4 1400 $ 2
Julian 2 0 3 4 700 $ 1/2/3
Tanya 0 5 2 3 1000 $ 8/9

Fig. 1.11. Task and possible actors description

Given all the piece of information present in Fig. 1.11, one can allocate human
resources to project tasks until Week 10. For T1, one actor is needed. The limiting
skill is Marketing since a 5 is needed, Bernadette is the only one who has a 5 in
Marketing. Her other skills are sufficient for T1 and she is has no holiday during
the execution of T1, so she can be allocated on T1. Similarly, for T7, there is no
choice but allocating John and Bernadette. As for T2, two persons are needed. Due
to the 5 needed, similarly as Bernadette for T1, John is allocated on T2. Given his
other skills in Marketing and Logistics, anyone available for T2 who has got a 5 in
Design is a good candidate: Paul and Tanya are eligible, since available whereas
Olivia is not. As for T3, which is simultaneously performed, one person is needed,
and due to the required skills, Paul is the only one who can perform T3. As a
consequence, Tanya is allocated to T2 (with John) and Paul is allocated to T3.
Now, for T4, three persons are needed. Some persons cannot be allocated on T4
since performing simultaneous tasks: John and Bernadette are working on T7 and
Paul on T3. Since a 5 is needed in Design for T4, and since Tanya is not available
during the execution of T4, Olivia is necessarily allocated to T4. A 5 is also needed
in Logistics, which can be obtained with Fred or Jane, who are both available. Due
to the skills needed for T5 and the simultaneity of this task with T4, one will be
allocated to T4 and the other one to T5: they will not work together on the same
task. The combination (Olivia/Fred) permits to obtain a (4/5/5/3) skill vector when
the combination (Olivia/Jane) permits to obtain a (3/5/5/4) skill vector when a
(4/5/5/4) skill vector is needed for T4. It means that, in order to meet the require-
ments of skills for T4, if the combination (Olivia/Jane) is selected, the third person
should at least have a 4 in Marketing, which is possible with Fred, Paul, John or
 23

Bernadette. The three last ones are unavailable as seen before, and Fred cannot be
allocated to T4 with Jane at the same time. (Olivia/Jane) is therefore an impossible
combination: Olivia and Fred should
Task/Week 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
T1 1 1 1
T2 2 2
T3 1 1 1 1
T4 3 3 3 3 3
T5 2 2 2 2 2 2 2
T6 3 3 3 3
T7 2 2 2
T8 5 5 5 5 5 5
T9 2 2 2 2 2
T10 6 6 6 6
T11 3 3
T12 2 2
T13 1 1 1 1 1 1 1 1 1 1 1
T14 2 2 2

Workload 1 1 1 3 3 4 4 7 7 7 7 7 7 7 13 12 12 12 6 6 4 4 3 3 1 1 2 2 2

Fig. 1.12. Workload calculation using the Gantt chart of the project

Fig. 1.13. Workload diagram of the project

be allocated to T4 and the third person who can complete the required skills is Ju-
lian (due to the unavailability of John and Bernadette), who is therefore allocated
to T4. Finally, in order to allocate actors to T5, one should notice that the persons
allocated to T4 and T7 are excluded from allocation, which means John, Berna-
dette, Olivia, Fred and Julian. With Tanya being unavailable, there are only Paul
and Jane left: this combination works perfectly for T5.
Even without performing such a process, much information can be obtained by
simply using the Gantt chart and the number of resources needed for each task in
order to build up the workload diagram of the project in order to identify peaks of
24

activities during the project (Fig. 1.12). The workload diagram (Fig. 1.13) is an
histogram which describes the number of actors who are working for the project
during its execution. In this example, a peak of activity can be identified from
week 15 to week 18, with 12 to 13 people working simultaneously for the project.
Task/Week 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
T1 1 1 1
T2 2 2
T3 1 1 1 1
T4 3 3 3 3 3
T5 2 2 2 2 2 2 2
T6 3 3 3 3
T7 2 2 2
T8 5 5 5 5 5 5
T9 2 2 2 2 2
T10 6 6 6 6
T11 3 3
T12 2 2
T13 1 1 1 1 1 1 1 1 1 1 1
T14 2 2 2

Workload 1 1 1 3 3 4 4 7 7 7 7 7 7 7 7 6 6 6 6 6 10 10 7 7 3 3 2 2 2

Fig. 1.14. T10 and T12 delaying in order to level the workload (modified Gantt chart)

Fig. 1.15. Modified workload diagram (and comparison with the initial one in light blue)

Dealing with peak of activities can be difficult during a project. Indeed, level-
ling the workload by balancing it more during the project can be interesting for
several reason such as giving more flexibility for other projects in the firm or re-
ducing stress in the project team thanks to a more balanced level of activity during
the project. In order to do so, one can easily use the total and free floats of the pro-
ject tasks. Indeed, some of the tasks which contribute to the peaks of activity are
not critical tasks and can thus be delayed, which permits to balance the workload
as seen in Fig. 1.14 and Fig. 1.15 (here tasks T10 and T12 can be delayed so that the
 25

maximum number of actors working simultaneously for the project is now 10).
However, one should be aware of the fact that the margins of delayed tasks are
consequently reduced (and can sometimes become null, such as in this example),
which could increase the risk of project late completion. As a consequence, such
workload levelling strategies should always be performed with caution.

3-3-2/ Cost planning

Once the resources allocated (whether human or not) to the different tasks of
the project, one can build the overall budget of the project and perform the project
cost planning process, the output of which is the complete schedule for all project
expenses and earnings. “Project cost management includes the processes required
to ensure that the project is completed within an approved budget” (Schwalbe
2013), therefore the construction of the approved budget, which is the output of
the cost planning process is all the more important, since, as for the time planning
process, it will serve as an input for project monitoring and control processes. This
is all the more important that “accurate forecasting of an ongoing project cost is a
major issue” in project management (Narbaev & Marco 2011).
The main input of the cost planning process is the estimation of the costs of the
activities of the WBS (notably given the information about activity duration and
resources). By adding up the costs of a set of activities which guarantees the com-
pleteness of cost estimates within the WBS, the project can be given a total cost
estimate. In order to ensure the completeness of this estimation, one should be
sure that each parent of the first hierarchical level of the WBS can be estimated,
either directly, either by adding up the costs of some of its children in the hierar-
chical structure of the WBS. The lower the hierarchical level of the activity in the
WBS is, the more accurate will be the overall estimation (if all the activities which
are at the bottom of the WBS can be estimated, this corresponds to the traditional
bottom-up estimation).
The main output of the cost planning process is the construction of the project
cost baseline, “consistent with a defined scope and schedule”, which defines what
the nature of costs is and when they occur during the project, “when the scope of
all major cost items can be adequately defined” (NCHRP 2007). The nature of
costs can be detailed according to a subdivision into categories such as in (Mendel
1976), where capital project costs are divided into six groups: Engineering costs,
Equipment costs, Bulk Materials costs, Construction Labor costs, Construction
Management costs and Indirect Construction costs. Such definition of categories
can permit to identify better cost drivers and thus serve as a basis for efficient pro-
ject cost management (Bhimani et al. 2011).
26

The typical shape of the project cost baseline is a S-curve if drawn on a cost/
time two axis graph (see Figure 1.16). In order to be more precise, the project cost
baseline can be divided into several sub-baselines, depending on the nature of
costs studied, with as many cost/time two axis graphs drawn to describe project
costs. Project cost baseline and sub-baselines can also be built up, not in terms of
money spent, but in terms of money inputs (depending on their nature and origin)
during the project.

Fig. 1.16. Traditional S-curve shape of a project cost baseline

3-4/ Quality planning

3-4-1/ Project quality and performance as multi-criteria parameters

Project quality and performance planning is one of the core processes of project
planning processes. Still, contrary to operations, a complete system of quality as-
surance processes is difficult to be established for projects, since unique and time-
limited (Winkler & Biffl 2012), even though some models and frameworks like
the PMBOK (PMI 2013) or the CMMI - Capability Maturity Model Integration
(CMMI Product Team 2002) present good project quality planning and manage-
ment approaches.
The definitions of “quality” or “performance” are often unclear, which makes it
all the more difficult to plan. Ensuring the quality of a project is to ensure the sa-
tisfaction of all project stakeholders, so all of them can assess it with a high stan-
dard of quality and consider it a success (Baccarini 1999; Cleland 2004). Indeed,
 27

the different stakeholders might have different points of view about the quality /
success of a project (Stuckenbruck 1986; De Wit 1988; Prabhakar 2008b; Barclay
& Osei-Bryson 2010).
Success and project quality criteria should thus properly be defined during the
project quality planning process so that the targets for project quality can be un-
derstood and widely shared by all project actors and stakeholders (Milosevic &
Patanakul 2005), or at least the key ones. Such criteria can for instance be the le-
vel of achievement of specifications, safety, etc. (Wu 2012) and are a prerequisite
for efficient and effective execution of project processes, as well as their monito-
ring and control (Ford 1995). As a whole, project performance and quality reflect
the level of fulfillment of the objectives of project stakeholders.

3-4-2/ Building up project scorecards quality and performance management

Knowing this, the advancement of a project should be monitored and controlled

during its execution using a scorecard which reflects the multiple aspects of pro-
ject quality and performance. Key Performance Indicators (KPIs) should thus be
defined during the project quality planning process and gathered into different
groups of indicators, in order to build up a balanced scorecard “which allows visi-
bility of performance at different levels as well as ensuring coherence between
these views” (Marques et al. 2011). As a whole, a global project quality and per-
formance management system can be defined as a set of metrics which will permit
to quantify the results of the project processes, these metrics addressing both pro-
ject outcomes and project management outcomes (Cicmil & Hodgson 2006). As
for any multi-criteria problem, the definition of project performance and quality
can be done using traditional multi-criteria methodologies (Marques et al. 2011),
an extensive list of which will be presented in Chapter 2.
Various well-established methodologies are likely to contribute to the project
quality planning process. PDCA (Plan-Do-Check-Act) approach, TQM (Total
Quality Management), QFD (Quality Function Deployment), Kaizen, 6-Sigma or
Taguchi methods are examples of methods (Stamatis 1994; APM 2004; PMI 2013)
which permit to increase the robustness of project quality management processes
within an organization and thus enrich project quality planning activities. The in-
tegration of quality-related norms principles (like the ISO:9000) into project ma-
nagement processes can also be assisted, notably using systems or process based
approaches (Winkler & Biffl 2012). The interested reader should directly refer to
these methodologies to have more information about their use.
28

3-5/ Risk planning

3-5-1/ Definitions and concept around project risk planning

From the birth of project management, the notion of risk has grown within the
field of project management, even if there are still lots of theoretical problems and
implementation lacks (Gautier 1991). For all practical purposes, the growing in-
terest in risk management is often pushed by law & regulation evolutions. The
society is namely more and more risk averse, and stakeholders are more and more
asking for risk management, in order to cover themselves against financial or juri-
dical consequences. People can be accountable during or after the project for safe-
ty, security, environmental, commercial or financial issues.
Everybody have to manage their own responsibility and own risks. That is why
it has become more and more important to manage effectively and efficiently pro-
ject risks (Ariyo et al. 2007), in order to give more success warranty and comfort
to project stakeholders, or at least to warn them from possible problems or disas-
ters (Cooper & Chapman 1987). But before, managing them, one should first pro-
perly define what a project risk is.
Many definitions of project risks can be found in the literature:
• A risk corresponds to the possibility that the objectives of a system regarding
a certain goal are not achieved (Haller 1976).
• A risk measures the probability and the impact of possible damaging events
(Lowrance 1976).
• A risk consists in the realization of a feared event with negative consequences
(Rowe 1977).
• A project risk is the possibility that a project is not executed with conformity
to the previsions of end date, budget and requirements, the gaps between pre-
visions and reality being considered as not or moderately acceptable (Giard
1991).
• A project risk is the possibility that an event occurs, an event the occurrence
of which would imply positive or negative consequences for the project exe-
cution (Gourc 2006).
• A project risk is defined as an event that, if it occurs, causes either a positive
or a negative impact on a project (PMI 2013)

According to Raz and Hillson, “the origins of operational risk management can
be traced to the discipline of safety engineering”. Modern risk management has
evolved from this concern with physical harm that may occur as a result of impro-
per equipment or operator performance (Raz & Hillson 2005). Lots of risk mana-
gement methodologies and associated tools have been developed, with qualitative
 29

and/or quantitative approaches, often based on the two concepts of probability and
impact (or gravity) of the risky event. As for it, the PMI, in its worldwide standard
PMBOK (PMI 2013), describes project risk management purpose as “the increase
of probability and impact of positive events, and the decrease of probability and
impact of negative events”. Other processes aim at increasing the success probabi-
lity.
As a consequence, various risk management methodologies have been develo-
ped (Gautier 1995): some standards have indeed developed risk management me-
thodologies, which are specific or non-specific to project context (IEC 1995; AFI-
TEP 1999; APM 2004; IPMA 2006; BSI 2008; PMI 2013). Note that, when non-
specific, these methodologies may have been introduced in several fields, like pro-
ject management, systems analysis, design, insurance, food industry, information
systems, chemical systems, industrial safety. A benchmark was done over various
risk management methodologies, notably thanks to the exhaustive works of Marle
(Marle 2009). Of course, the question of relevance to project context has been
discussed, and the benchmark was only conducted on selected methods. Figure
1.17 displays the four steps that appear as present in most of iterative risk mana-
gement processes (Marle 2002; Pingaud & Gourc 2003; Ravalison 2004; PMI
2013).

Risk Management
Planning

Risk Identification

Risk Analysis

Risk Response
Planning

Risk Monitoring
and Control

Lessons
learned

Fig. 1.17. Traditional project risk management process (adapted from (PMI 2013))

It must be noted that the steps of risk management planning and lessons learned
were not present in every methodology enlightened by the benchmark and were
not selected as a consequence. Moreover, the names of the four steps are not al-
30

ways the same in every methodology and it appears that some of the steps are so-
metimes gathered, but the underlying principles and goals tend to remain similar.
The rest of the section is therefore organized according to the three first general
steps of the risk management process, “Risk Monitoring and Control” being dealt
with in the paragraph for Project Management monitoring and control processes.

3-5-2/ Project Risk Identification

Risk identification is the process of determining events which could impact

project objectives. Risk identification methods are classified according to two dif-
ferent families: direct and indirect identification of risks. The most classical tools
and techniques for direct risk identification are diagnosis and creativity-based me-
thods, meaning that direct identification is mainly performed thanks to expertise:
• The assessment of the present situation relies upon the analysis of its parame-
ters in order to identify areas of risk. An example is systems thinking, which
is used to describe exhaustively the studied area of the project, and then to
identify potential problems.
• On the contrary, the assessment of the future situation can rely upon the abili-
ty that one has to imagine the risks that can affect a project. An example is
brainstorming.
Another way to identify risks is to collect data about problems that occurred
during previous projects (indirect risk identification, based on experience). Eve-
ryone should stay aware that issues of the past are risks of the future. Examples of
such methods are the “5 why?” method, Ishikawa diagram, the Pareto diagram-
ming technique or the use of check lists.
Simple Average Complex
methods methods methods

Direct Risk Brainstorming Systems analysis, Scenario analysis

Identification constraints analy-
sis

WWWWHW (Who FMEA ( Failure TRIZ

What When Where Mode and Effects
How Why?) Analysis)

SWOT analysis Stakeholder analy-

(Strengths, Weak- sis
nesses, Opportuni-
ties and Threats)
 31

Direct/Indirect Ishikawa diagram Expert opinion, Hazard and ope-

Risk Identifica- (combined with 5M) q u e s t i o n n a i r e s , rability studies
tion Delphi technique (HAZOP)

“5 why”, root- Cause tree, event Influence dia-

causes analysis tree analysis, fault grams
tree analysis

Balanced scorecard

Indirect Risk Pareto analysis Affinity diagram Data sampling,

Identification (KJ) Design of experi-
Check-lists, expe- ments
rience feedback,
Risk Breakdown
Structure

“Non identical Peer review Benchmarking

twins” method

Matrix diagram, Correlations me- Data analysis,

diagraming tech- thod Variance analysis
niques

Fig. 1.18. Most common project risk identification methods (Marle 2009)

Fig. 1.18. hereinbefore sorts the principal project risk identification methods
(direct and indirect risk identification) which had been identified with an extensive
state of the art (Marle 2009), functions of their complexity degree.
Several studies or surveys were carried out to summarize and categorize the
most common problems in project management. One of them described the most
relevant causes of failure in IT projects (The Standish Group 2000)Those main
causes have been categorized and sorted with a Pareto analysis. It appeared that
less than 20% of the causes were responsible for more than 80% of failures. In the
end, after risk identification, due to the high number of risks, they are grouped into
smaller groups (or clusters) in order to permit practical management (notably for
the identification of risk ownership, risk provision, etc…). Such classification can
notably be obtained using traditional Risk Breakdown Structures.
32

Probability Threats Opportunities Probability

0,9 R6 R1 0,9 R4 R5
0,7 O1 O2 0,7 R1
0,5 R3 R2 0,5 R3
0,3 R4 0,3 R2
0,1 R5 O3 0,1
Impact => 1 2 3 4 1 2 3 4 Impact => 1 2 3 4

Fig. 1.19. Project risk analysis Probability/Impact matrices and diagrams (Marle 2009)

3-5-3/ Project Risk Analysis

Risk analysis is the process of prioritizing risks, essentially according to their

probability and impact (Raftery 2003). This is all the more necessary that the pro-
ject risk identification process often leads to build up a list of tens or hundreds of
risks, which makes it impossible to manage the complete list. There are two main
types of risk analysis, which are discussed hereunder: quantitative and qualitative
analysis.
Quantitative risk analysis is notably based on the proper estimation of probabi-
lity through mathematical models, notably built on former experience. Qualitative
risk analysis is the process of assessing by qualitative means the probability (P)
and impact (I) of each risk. It assists risk comparison and prioritization. It is nota-
bly used when these parameters are difficult to calculate, using scales.
The main risk analysis’s output is the risk prioritization, often as a function of
their criticality. Criticality is often defined by the product of P and I, but other
formulation should be proposed. Indeed, as underlined by Terry Williams
(Williams, 1996) who carries out some calculations to prove his vision, “multi-
plying impact and [probability] to ‘rank’ risks is misleading, since the correct
treatment of the risks requires both dimensions” and probably even some other.
However, the widespread use of criticality permits to define a useful index for
risk analysis. Indeed, criticality enables to classify risks into three categories: high
risk (red or heavy grey), moderate risk (yellow or middle grey) and low risk
(green or light grey). The result has often the shape of a P-I matrix or grid, which
uses scales and points out each risk on this P-I graph.
Farmer diagrams can be used to plot identified risks, as seen in figure 2, or to
define acceptability baselines, like in Fig. 1.19. The principle is to define the ac-
ceptable curves and to measure if the project is below or above this curve, which
will influence the decision made about this project. These values can be obtained
by expert judgement or experience feedback.
 33

3-5-4/ Project Risk Response Planning

The process of risk response planning aims to determine a set of actions which
are likely to reduce the overall project risk exposure at least cost. It addresses pro-
ject risks by priority, defining actions and resources, associated with time and cost
parameters. Almost every method mentions the same possible treatment strategies:
• Avoidance
• Probability and/or impact reduction (mitigation), including contingency plan-
ning
• Transfer, including subcontracting and insurance buying
• Acceptance

In order to understand these strategies, if one follows an analogy with health

and the risk of suffering from influenza, the avoidance strategy would be to avoid
being in contact with the influenza virus (for instance by staying in a sterile room).
The mitigation strategy would be to get a vaccination for vaccination is proved to
reduce the probability and/or impact of suffering from influenza. The transfer stra-
tegy would be for instance to be protected by any health insurance so that the im-
pacts of suffering from influenza are (at least partly) dealt with by one’s insurance
company. Finally, the acceptance strategy would be to do nothing and accept the
risk of suffering from influenza, meaning that the situation did not change and the
risk stays the same, but still it is a decision made.
In the cases when the method permits to deal simultaneously with the concept
of opportunity (positive risks), the same strategies exist, but with opposite names:
exploitation, probability or impact enhancement, risk sharing. Acceptance does
not change.
The set of preventive actions which are going to be undertaken correspond to
the overall project risk action plan. The complete list of risks and their parameters
of probability, impact and criticality should be recalculated so that the conse-
quences of preventive actions on project risks are correctly documented. A refined
actualised list of project risks is then built up. Curative actions should also be lis-
ted in the eventuality that the mitigated / accepted risks would occur (see Fig.
1.20.).
As the overall action plan is decided, with preventive actions and potential cu-
rative actions, it finally has to be implemented into the project plan, the documents
of which should all be updated. Only preventive actions appear, as curative actions
are only planned in case of event occurrence, and not before since they will not
necessarily be done. For instance, the project WBS or its Gantt chart should be
34

updated since preventive actions might change the decomposition of project work
and scheduling (see Fig. 1.21). Although this update seems obvious and mandato-
ry, it is still a sign of maturity for an organization to apply it systematically.

Risk Probability Impact Criticality Preventive action Residual criticality Curative action
Change management
Customer changes in template, change
3 4 12 6 Contract update
requirements assessment before
acceptation
Lack of motivation about Kick-off meeting, Top Motivation actions (social,
3 4 12 8
the project management support financial)
Correction by experts,
Estimation errors 4 3 12 6 Frequent plan updates
estimation methods use
Product delivery delay 3 4 12 12 Project crashing or fast-tracking
Normative change during Study of impact of the new norm
2 3 6 6
the project on the project delivery
Skill assessments, pre-
Lack of internal Subcontracting or external
2 3 6 assignments of key 3
competence staffing
members
Study of impact of the new
Technology shift during Benchmark, use of robust technology on the product
1 4 4 3
the project technologies performance and project
parameters
Pre-contract or order
Bankruptcy of a Subcontractor update by pre-
2 2 4 sharing with other 2
subcontractor contract confirmation
subcontractors

Estimation of preventive
action impact= criticality
gap

Fig. 1.20. Example of project risk residual criticality due to preventive actions as well as
curative actions (Marle 2009)
 35

Fig. 1.21. Example of an updated Gantt chart after the risk response planning process

4. Carrying out the project

Once the project planned, it is executed. The execution phase should permit to
deliver the expected project deliverables of objectives, and thus guarantee the sa-
tisfaction of project stakeholders.

4-1/ Monitoring and controlling projects

In order to assist the execution of projects, project monitoring and control me-
thodologies have been developed. The overall purpose of project monitoring and
control processes is to understand the evolution of the project and measure (quan-
titatively or qualitatively) its progress, so that actions can be taken to correct the
36

trajectory of the project and drive its performance when it deviates from the pro-
ject plan (in terms of schedule, cost, performance, etc…). The project planning
processes outcomes which were presented in section 3 are therefore necessary
inputs to project monitoring and control activities.
Standards and frameworks like the CMMI (CMMI Product Team 2002) or the
PMBOK (PMI 2013) notably propose a certain number of activities to monitor
and control projects.

4-1-1/ Schedule and budget monitoring and control

Among the methods and tools proposed to monitor and control a project in
terms of schedule and budget, the Earned Value Method (EVM) is one of the most
famous (Fleming & Koppelman 1998; Anbari 2003; Budd & Budd 2009). This
method permits to measure project performance in terms of cost and delay with
easily calculated indicators.
In order to so, the progress of the project (or of a project task, or of a part of a pro-
ject) is represented on a two axis progress (in any Money Unit, for instance Dol-
lars) and Time (in any Time Unit) graph. Three curves can be drawn. The first one
corresponds to the Planned Value (PV) curve, which shows the progress (evalua-
ted in Dollars) which was planned during the execution of project planning pro-
cesses. This curve can be built up before project execution. The second one cor-
responds to the Actual Cost (AC) curve, which shows the amount of money which
is actually spent during the project. Therefore, this curve is built up during the
execution of the project, since its values correspond to actually spent money. Fi-
nally, the third curve is the Earned Value (EV) curve, which represents the actual
progress (evaluated in Dollars): it thus represents the value which is actually crea-
ted during the execution of the project. As a consequence, this curve is also built
up during the execution of the project and not a priori, contrary to the PV one (see
Fig. 1.22.).
 37

Fig. 1.22. The three different progress curves used in the Earned Value Method

Several indicators are defined in this methodology. Cost Variance (CV) is the
difference between EV and AC. If CV>0, then EV>AC, which means that more
value was actually created than what was actually spent, which means that we are
in advance in terms of budget. On the contrary, if CV>0, then over-cast has to be
faced. Similarly, Time Variance (TV) is the difference between EV and PV. If
TV>0, then EV>PV, which means that that more value was actually created than
was initially planned, which means that we are in advance in terms of delay. On
the contrary, if TV>0, then delay has to be faced. The reader should notice that
with this definition of TV, a time is therefore measured and expressed in a finan-
cial unit. These indicators permit to study the progress of the project and its tasks,
and thus make decisions about them to correct their potential negative deviations
compared to the initial schedule and budget.
It should be noted that people often calculate the difference between AC and
PV, and for instance on Fig. 1.22, at t1, can be happy of their result, since the diffe-
rence between AC and PV is negative, meaning that less money was actually spent
than at planned. But without comparing these values to EV, this difference has no
actual significance. Indeed, here at t1, AC is indeed inferior to PV, but most of all,
EV is inferior to AC, which means that too much money was spent for the value
38

which was actually created: therefore the project faces over-cost, which is the
exactly opposite conclusion that one would draw if comparing AC to PV.
Task Budget Actual status Actual cost Earned Value Planned status Planned Value Time Variance Cost Variance Time Index Cost Index
T5 3000 $ 100% 3500 $ 3000 $ 86% 2580 $ 420 $ -500 $ 1,163 0,857
T6 2000 $ 40% 1500 $ 800 $ 75% 1500 $ -700 $ -700 $ 0,533 0,533
T7 2500 $ 60% 2000 $ 1500 $ 100% 2500 $ -1000 $ - 500 $ 0,6 0,75
T8 5000 $ 10% 200 $ 500 $ 0% 0$ 500 $ 300 $ Started in advance 2,5
T9 1000 $ 50% 300 $ 500 $ 60% 600 $ -100 $ 200 $ 0,833 1,667

Fig. 1.23. Project monitoring and control indicators using Earned Value Method

If we consider the same project that the one which was use throughout section
3 to illustrate planning methods and tools, and consider that the project is present-
ly ongoing, assuming that we are at the end of Week 13, with some data which are
known (Budget, Actual Status, Actual Cost), one can calculate all indicators in
Fig. 1.23. with the hypothesis that the value (whether planned or earned) corres-
ponds to the budget multiplied by the status (whether planned or actual). With
such indicators, an analysis of the project tasks and their situation can be perfor-
med. Here for instance, one can say that at the end of Week 13, T6 is facing both
delay and over-cost while T8 is on the contrary in advance both in terms of time
and budget. Due to the actual status of T6 (40%), meaning that less than half of
the task was actually performed, something should be done to correct its trajecto-
ry. But another task, T7, also faces difficulty both in terms of schedule and budget:
given the fact that T7 belongs to the critical path of the project, priority should be
given to control its delay since a delay for T7 directly provokes a delayed comple-
tion of the project.

4-1-2/ Performance, quality and risk monitoring and control

The project performance and quality monitoring and control processes require
the use of the balanced scorecards and/or Key Performance Indicators which were
developed during the project quality planning process. As stated in (Devine et al.
2010), “control of quality requires monitoring the project to ensure everything is
going according to plan, identifying when preventive or corrective actions are
necessary, determining root causes of problems, providing specific measurements
for quality assurance, and implementing change through the integrated change
control system. The timing for inspections and quality audits may be included in
project schedules and checklists that become part of a project BSC.
Information should constantly be communicated to the project actors and sta-
keholders, in a prompt and accurate way, which means that an effective and effi-
 39

cient information and communication systems should be developed, in relation

with the balanced scorecard / KPIs of the project so that anyone in the project
team can know in a glance the main indicators of the project. As a consequence,
during the execution of the project, , reports should be done and communicated
regularly in order to express what has been done, what is currently done, and what
will be done next.
Alongside, risk monitoring and control is according to PMBOK the ongoing
process of “identifying, analysing and planning for newly arising risks, keeping
track of the identified risks and those on the watchlist, reanalyzing existing risks,
monitoring trigger conditions for contingency plans, monitoring residual risks, and
reviewing the execution of risks responses while evaluating their
effectiveness” (PMI 2013). It includes five traditional tools:
• Risk reassessment: for new risks or for refinement of existing assessments,
• Risk audit: return on investment on the global risk management process,
• Variance and trend analysis: deviations from project plan may indicate poten-
tial threats for the project (Fig. 1.24.),
• Technical performance measurement: deviations from planned scope may
indicate potential threats for future delivery and client acceptance (Fig. 1.24),
• Reserve analysis: use of planned contingency reserves is tracked, in order to
estimate the consistence between remaining reserves and remaining risks
(Fig. 1.24.).

Fig. 1.23. Example of a S-curve used to monitor and keep project under control (Marle
2009)
40

3.2. Closing projects

As a whole the project scope and execution have been planned, monitored
and control, but once the project deliverables accepted, the project needs to be
closed. Closing includes the formal acceptance of the project and the ending the-
reof. Administrative activities include the archiving of the files and documenting
lessons learned. This phase consists of:
• Activity closure: Finalize all activities in order to close the project.
• Contract closure: Complete and settle each contract (including the resolution
of any open items) and close each contract applicable to the project or project
phase.
• Knowledge management activities (Devine et al. 2010): A precise and ex-
haustive identification of project successes or failures is necessary to capture
lessons learned (such successes/failures should have been listed during the
execution of the project, but the project closing phase permit to synthetize
them), which might help the organization to get more mature in terms of
project management for their future projects.
• Stakeholder and opportunity management: Time should be taken in order to
understand the extent to which the completed project might contribute to the
organization and the future projects it could carry out. In particular, new op-
portunities with stakeholders or new markets should be identified, as they
might result in new activities for the organization.

5. An exercise to practice traditional project management

concepts

In order to finish introducing the reader with traditional project management

concepts and tools, an exercise is now proposed to handle some project planning
as well as monitoring and control processes.

5.1. Wording

You are meant to plan, monitor and control a project which should be delivered
within 26 weeks. Information about the project can be found on Fig. 1.25. as well
as on Fig. 1.26.

Question 1 : Planning time and human resources

 41

1.1. Build up the overall project network given the information about project
tasks.
1.2. What are the durations of phase 1 (T1 to T8), phase 2 (T9 to T15) and phase
3 (T16 to T18)?
1.3. Which tasks do have free and total floats?
1.4. Build up the Gantt chart of the project.
1.5. Build up the workload diagram of the project.
1.6. Until Week 13, no more than 8 people can work simultaneously for the
project. From Week 14, you can have as many actors as you wish working for
your project. What do you suggest to do?

Question 2 : Resource allocation

2.1. Knowing that at least one allocated actor should have the required skill for
each level for each task, who are the actors that we can allocate to Tasks T1 to T6?
2.2. If Riley takes a holiday on Week 3 instead of Week 2, what can be done?
In the rest of the wording, the data of Question 2 are not taken into account.
Tasks Duration Predecessors Resources

T1 2 / 1

T2 8 T1 2

T3 4 T1 1

T4 5 T1 1

T5 5 T3 2

T6 4 T3 1

T7 6 T4 2

T8 4 T4 3

T9 4 T2, T5 1

T10 3 T5, T6 2

T11 4 T7 3

T12 2 T7, T8 2

T13 4 T9 3

T14 4 T10 1

T15 1 T11, T12 1

42

T16 3 T13, T14 2

T17 2 T14, T15 3

T18 4 T16, T17 1

Fig. 1.25. Information about project tasks

Information sys-
Tasks Marketing Design Logistics tems

T1 5 2 3 1

T2 4 5 5 4

T3 2 5 0 0

T4 0 0 2 5

T5 5 0 4 4

T6 2 5 0 3

Information sys-
Actors Marketing Design Logistics tems Cost / week Holidays

Laura 5 3 4 2 1200 $ 3/4

Riley 4 5 2 1 1500 $ 2 / 12

Mi-
chael 3 5 3 3 1200 $ 13

Annie 4 2 5 4 1100 $ 13

Kim 2 0 3 5 1200 $ 2

Dilip 0 5 2 5 900 $ 8/9

Fig. 1.26. Information about project tasks

Question 3 : Planning under uncertainty

3.1. What are the impacts on T15, T17 and the project if T12 can last from 1 to 7
weeks?
3.2. What happens for T15, T16, T17 and the project if T11 and T13 can vary si-
multaneously, with T11 between 3 and 7 weeks, and T13 between 3 and 5 weeks?
 43

Task Budget Actual status Actual cost

T9 5000 $ 60% 4000 $

T10 4000 $ 100% 2000 $

T11 3000 $ 100% 5000 $

T12 2000 $ 100% 2000 $

T13 4000 $ 0% 0$

T14 6000 $ 40% 3000 $

T15 1000 $ 15% 1000 $

Fig. 1.27. Project information at the end of Week 16.

Question 4 : Project monitoring and control

We are at the end of Week 16 and know the information in Fig. 1.27.
4.1. Study the state of the project through the calculation of Time and Cost Va-
riances and Indexes.
4.2. What could be done to control the execution of the project ?

5.2. Solution

Question 1 : Planning time and human resources

1.1. See next page Fig. 1.XX. The project can be delivered within 26 weeks.
1.2. To calculate the duration of phase 1 (T1 to T8), one should calculate the
difference between the maximum earliest end date and the minimum earliest start
date among the tasks of phase 1. Here it is 13 (for T7) minus 0 (for T1), which
gives a duration of 13 weeks for T1. With the same approach, one can calculate
that the duration of phase 2, which equals 8 (19-11). Similarly, the duration of
phase 3 equals 8 (26-18). Note that the sum of the duration of phases equals 29
weeks, which is superior to the duration of the project, since the phases are not
disjoint.
1.3. The tasks which have free and total floats can directly be seen on Fig.
1.XX. Free float can be read at the bottom left corner of each task description and
total float at the bottom right corner. The critical path is constituted by the tasks,
the total float of which equals is null. The critical path is: T1 - T3 - T5 - T9 - T13 -
T16 - T18.
1.4. The Gantt Chart can be seen on Fig. 1.XX.
1.5. The workload diagram can be seen on Fig. 1.XX.
44

1.6. Considering that tasks T2, T5, T6, T7 an T8 contribute to the high workload
level (10) which cannot be managed during Weeks 8, 9 and 10 (before Week 13),
and considering the total float of these tasks (respectively 1, 0, 2, 2, 6), one should
consider moving T8 as a good option for workload levelling. If T8 starts on Week
11 and finishes on Week 15 (instead of 7 and 11), then T12 starts on Week 15 and
finishes on Week 17 (instead of 13 and 15). There is no other change in the project
network and the project finishes in due time. With that changes, the new work-
loads on Weeks 8, 9, 10, 11, 12 and 13 are respectively 7, 7, 7, 4, 8 and 8, which
make them fully acceptable.
T2 8 T9 4 T13 4
2 10 11 15 15 19
3 11 11 15 15 19
1 1 0 0 0 0
T5 5 T16 3
6 11 19 22
6 11 19 22
0 0 0 0
T1 2 T3 4 T10 3 T14 4 T18 4
0 2 2 6 T6 4 11 14 14 18 22 26
0 2 2 6 6 10 12 15 15 19 22 26
0 0 0 0 8 12 0 1 0 1 0 0
1 2 T17 2
18 20
T7 6 T11 4 T15 1 20 22
7 13 13 17 17 18 2 2
T4 5 9 15 15 19 19 20
2 7 0 2 0 2 0 2
4 9
0 2 T8 4 T12 2
7 11 13 15
13 17 17 19
2 6 2 4

Fig. 1.XX. Project network and scheduling

 45

Task/Week 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
T1 1 1
T2 2 2 2 2 2 2 2 2
T3 1 1 1 1
T4 1 1 1 1 1
T5 2 2 2 2 2
T6 1 1 1 1
T7 2 2 2 2 2 2
T8 3 3 3 3
T9 1 1 1 1
T10 2 2 2
T11 3 3 3 3
T12 2 2
T13 3 3 3 3
T14 1 1 1 1
T15 1
T16 2 2 2
T17 3 3
T18 1 1 1 1

Workload 1 1 4 4 4 4 6 10 10 10 7 5 5 8 7 7 7 5 6 5 2 2 1 1 1 1

Fig. 1.XX. Gantt chart of the project and workload calculation

Fig. 1.XX. Workload diagram of the project

Tasks Actor Cost

T1 Laura 2400 $
T2 Riley, Annie 20800 $
T3 Michael 4800 $
T4 Dilip 4500 $
T5 Laura, Kim 12000 $
T6 Michael 4800 $

Total cost 49300 $

Fig. 1.XX. Human resource allocation results for Tasks T1 to T6 and related costs
46

Question 2 : Resource allocation

2.1. Given the data of the problem, the good actor allocation to tasks T1 to T6
would be the one given in Fig. 1.XX.
2.2. If Riley wants to take a holiday on Week 3 instead of Week 2, there is a
conflict with T2 since T2 starts on Week 3 and Riley should work on it. But instead
of forbidding him to take a holiday on Week 2, a solution can be to use the total
float of T2, which equals 1 week, and start only on Week 4, which does not affect
the completion of the project. This would be all the more possible that Annie may
start working alone on T2 during Week 3 while Riley takes his holiday.

Question 3 : Planning under uncertainty

3.1. The impacts on T15, T17 and the project of a variation of the duration of T12
from 1 to 7 weeks can be seen on Fig. 1.XX.
3.2. The impacts on T15, T16, T17 and the project if T11 and T13 vary simulta-
neously, with T11 between 3 and 7 weeks, and T13 between 3 and 5 weeks, can be
seen on Fig. 1.XX (if the variations are independent and follow uniform laws).
T12 duration Impact on T15 Impact on T17 Impact on the project
1 No change No change No change
2 No change No change No change
3 No change No change No change
4 No change No change No change
5 Plus 1 week Plus 1 week No change
6 Plus 2 weeks Plus 2 weeks No change
7 Plus 3 weeks Plus 3 weeks Plus 1 week

Fig. 1.XX. Solution to question 3.1.

T11 duration T13 duration Impact on T15 Impact on T16 Impact on T17 Impact on the project Probability
3 3 Minus 1 week Minus 1 week No change Minus 1 week 0,06666667
4 3 No change Minus 1 week No change Minus 1 week 0,06666667
5 3 Plus 1 week Minus 1 week Plus 1 week Minus 1 week 0,06666667
6 3 Plus 2 weeks Minus 1 week Plus 2 weeks No change 0,06666667
7 3 Plus 3 weeks Minus 1 week Plus 3 weeks Plus 1 week 0,06666667
3 4 Minus 1 week No change No change No change 0,06666667
4 4 No change No change No change No change 0,06666667
5 4 Plus 1 week No change Plus 1 week No change 0,06666667
6 4 Plus 2 weeks No change Plus 2 weeks No change 0,06666667
7 4 Plus 3 weeks No change Plus 3 weeks Plus 1 week 0,06666667
3 5 Minus 1 week Plus 1 week No change Plus 1 week 0,06666667
4 5 No change Plus 1 week No change Plus 1 week 0,06666667
5 5 Plus 1 week Plus 1 week Plus 1 week Plus 1 week 0,06666667
6 5 Plus 2 weeks Plus 1 week Plus 2 weeks Plus 1 week 0,06666667
7 5 Plus 3 weeks Plus 1 week Plus 3 weeks Plus 1 week 0,06666667

Fig. 1.XX. Solution to question 3.1.

 47

Task Budget Actual status Actual cost Earned Value Planned status Planned Value Time Variance Cost Variance Time Index Cost Index
T9 5000 $ 60% 4000 $ 3000 $ 100% 5000 $ - 2000 $ - 1000 $ 0,6 0,75
T10 4000 $ 100% 2000 $ 4000 $ 100% 4000 $ 0$ 2000 $ 1 2
T11 3000 $ 100% 5000 $ 3000 $ 75% 2250 $ 750 $ -2000 $ 1,33 0,6
T12 2000 $ 100% 2000 $ 2000 $ 100% 2000 $ 0$ 0$ 1 1
T13 4000 $ 0% 0$ 0$ 25% 1000 $ - 1000 $ 0$ 0 (not started yet) not relevant
T14 6000 $ 40% 3000 $ 2400 $ 50% 3000 $ -600 $ - 600 $ 0,8 0,8
T15 1000 $ 15% 1000 $ 150 $ 0% 0$ 150 $ - 850 $ started in advance 0,15

Fig. 1.XX. Solution to question 4.1.

Question 4 : Project monitoring and control

4.1. The different Time and Cost variance and indexes at the end of Week 16
can be seen on Figure 1.XX.
4.2. In order to control the project given these data, nothing can be done for
T10, T11 and T12 since they are completed. T13 has not yet started whereas it should
have, so great attention should be paid to its delay, especially since it belongs to
the critical path. Similarly, T9 is critical, is late, and faces over-cost: actions should
be planned to control it. If the project budget allows it, something can be done to
control the delay of T14 but since it is not a critical task, this action would not be a
priority. Finally, both T14 and T15 already face over-cost although their actual sta-
tus is under 40%, so deeper attention should be paid on their execution to control
their cost.

6. References

AFITEP, 1999. Le management de projet, principes et pratique.,

AFNOR, 2004. Management de projet, recueil de normes,
Anbari, F.T., 2003. Earned value project management method and extensions.
Project Management Journal, 34, pp.12–23.
APM, 2004. Project Risk Analysis and Management Guide 2nd Edition 2nd ed.,
Association for Project Management APM.
Ariyo, O.O., Eckert, C.M. & Clarkson, P.J., 2007. Prioritising enginnering change
propagation risk estimates. In International Conference on Engineering De-
sign, ICED’07, Paris, France.
Baccarini, D., 1999. The logical framework method for defining project success.
Project Management Journal, 30, pp.25–32. Available at: http://www.men-
deley.com/research/the-logical-framework-method-for-defining-project-suc-
cess/.
48

Badenfelt, U., 2011. Fixing the contract after the contract is fixed: A study of in-
complete contracts in IT and construction projects. International Journal of
Project Management, 29(5), pp.568–576. Available at: http://dx.doi.org/
10.1016/j.ijproman.2010.04.003.
Barclay, C. & Osei-Bryson, K.M., 2010. Project performance development fra-
mework: An approach for developing performance criteria & measures for
information systems (IS) projects. International Journal of Production Eco-
nomics, 124(1), pp.272–292. Available at: http://dx.doi.org/10.1016/j.ijpe.
2009.11.025.
Von Bertalanffy, L., 1972. Théorie Générale des Systèmes, Dunod.
Bhimani, A. et al., 2011. Management and Cost Accounting 5th Editio., Financial
Times/ Prentice Hall.
Boulding, K., 1956. General Systems Theory, the Skeleton of Science. Manage-
ment Science, 2(3), pp.197–208.
Von Branconi, C. & Loch, C.H., 2004. Contracting for major projects: Eight busi-
ness levers for top management. International Journal of Project Manage-
ment, 22, pp.119–130.
Brucker, P. et al., 1999. Resource-constrained project scheduling: Notation, classi-
fication, models, and methods. European Journal of Operational Research,
112, pp.3–41.
Bruni, M.E. et al., 2011. A heuristic approach for resource constrained project
scheduling with uncertain activity durations. Computers and Operations
Research, 38(9), pp.1305–1318. Available at: http://dx.doi.org/10.1016/j.cor.
2010.12.004.
BSI, 2008. Risk management: Code of practice,
Budd, C.I. & Budd, C.S., 2009. A practical guide to Earned Value Project Mana-
gement, Management Concepts.
Cano, J.L. & Lidón, I., 2011. Guided reflection on project definition. International
Journal of Project Management, 29(5), pp.525–536.
Cicmil, S. & Hodgson, D., 2006. New possibilities for project management theo-
ry: A critical engagement. Project Management Journal, 37, pp.111–122.
Available at: http://www.kth.se/polopoly_fs/1.228078!/Menu/general/co-
lumn-content/attachment/pmj-criticalpm.pdf.
Cleland, D.I., 2004. Field Guide to Project Management 2nd ed., Wiley.
CMMI Product Team, 2002. Capability Maturity Model ® Integration ( CMMI
SM ), Version 1.1, Pittsburgh, USA.
 49

Cooke-Davies, T., 2002. The “real” success factors on projects. International

Journal of Project Management, 20, pp.185–190.
Cooper, D. & Chapman, C., 1987. Risk analysis for large projects, Models, Me-
thods & Cases, Wiley.
Danayand, N. & Padman, R., 2012. Project contracts and payment schedules: the
client’s problem. Management Science, 47(12), pp.1654–1667.
Devine, K., Kloppenborg, T.J. & O’Clock, P., 2010. Project Measurement and
Success: A Balanced Scorecard Approach. Journal of Health Care Finance,
36(4).
e Silva, L.C. & Costa, A.P.C.S., 2013. Decision model for allocating human re-
sources in information system projects. International Journal of Project
Management, 31(1), pp.100–108. Available at: http://dx.doi.org/10.1016/
j.ijproman.2012.06.008.
Fazar, W., 1959. Program Evaluation and Review Technique. The American Statis-
tician, 13(2(10)).
Fleming, Q. & Koppelman, J., 1998. Earned value project management. Crosstalk
- The Journal of Defense Software Engineering, (July), pp.19–23. Available
at: http://www.crosstalkonline.org/storage/issue-archives/
1998/199807/199807-fleming.pdf.
Ford, D.N., 1995. The Dynamics of Project Management: An Investigation of the
Impacts of Project Process and Coordination on Performance. Massachu-
setts Institute of Technology.
Gannon-Leary, P. & Mccarthy, M.D., 2010. Customer Care, Elsevier. Available at:
http://www.sciencedirect.com/science/article/pii/B9781843345701500061
[Accessed March 3, 2015].
Garver, M.S., 2003. Best practices in identifying customer-driven improvement
opportunities. Industrial Marketing Management, 32, pp.455–466.
Gautier, R., 1991. L’analyse des risques dans les projets industriels pour une mise
en synergie des démarches Qualité et Innovation,
Gautier, R., 1995. Qualité en conception de produits nouveaux, Proposition d’une
méthode de fiabilisation du processus de management de l'information.
Ecole Nationale Supérieure des Arts et Métiers de Paris.
Giard, V., 1991. Gestion de projet, Economica, Paris.
Gido, J. & Clements, J.P., 2011. Successful Project Management, 6th edition 5th
ed., South-Western.
50

Gourc, D., 2006. Vers un modèle conceptuel du risque pour le pilotage et la

conduite des activités de biens et de services. Propositions pour une
conduite des projets et une gestion des risques intégrées. Institut National
Polytechnique de Toulouse.
Haller, M., 1976. Les objectifs du Risk Management, Les Cahiers de Genève, 2.
Hao, X., Lin, L. & Gen, M., 2014. An Effective Multi-objective EDA for Robust
Resource Constrained Project Scheduling with Uncertain Durations. Proce-
dia Computer Science, 36(3), pp.571–578. Available at: http://www.science-
direct.com/science/article/pii/S1877050914013052.
IEC, 1995. Dependability management, International Standard,
IPMA, 2006. IPMA Competence Baseline (ICB). Version 3.0, International Project
Management Association.
Joglekar, N.R. & Ford, D.N., 2005. Product development resource allocation with
foresight. European Journal of Operational Research, 160, pp.72–87.
Kerzner, H.R., 2013. Project Management: A Systems Approach to Planning,
Scheduling, and Controlling 11th Editi., John Wiley.
Konstantinidis, P.D., 1998. A model to optimize project resource allocation by
construction of a balanced histogram. European Journal of Operational
Research, 104(97), pp.559–571.
Lock, D., 2007. The Essentials of Project Management 3rd Editio., Gower Publi-
shing.
Lockyer, K.G., 1976. An introduction to Critical Path Analysis, Pitman, London.
Lowrance, W.W., 1976. Of acceptable risk, William Kaufmann.
Marle, F., 2002. Modèles d’information et méthodes pour aider à la prise de déci-
sion en management de projets. Ecole Centrale Paris.
Marle, F., 2009. Project risk management methodologies: a critical state of the
art,
Marques, G., Gourc, D. & Lauras, M., 2011. Multi-criteria performance analysis
for decision making in project management. International Journal of Project
Management, 29(8), pp.1057–1069. Available at: http://linkinghub.elsevier.-
com/retrieve/pii/S0263786310001419 [Accessed October 30, 2012].
Masmoudi, M. & Haït, A., 2013. Project scheduling under uncertainty using fuzzy
modelling and solving techniques. Engineering Applications of Artificial
Intelligence, 26, pp.135–149.
 51

Mendel, O., 1976. Elements of a cost control program for capital projects. Engi-
neering and Process Economics, 1, pp.67–74.
Meredith, J.R. & Mantel Jr., S.J., 2011. Project Management: A Managerial Ap-
proach 8th Editio., Wiley.
Milosevic, D. & Patanakul, P., 2005. Standardized project management may in-
crease development projects success. International Journal of Project Ma-
nagement, 23, pp.181–192.
Le Moigne, J.-L., 1990. La théorie du système général. Théorie de la modélisa-
tion, Presses Universitaires de France.
Narbaev, T. & Marco, A. De, 2011. Cost Estimate at Completion Methods in
Construction Projects. , 15, pp.32–36.
NCHRP, N.C.H.R.P., 2007. Guidance for cost estimation and management for
highway projects during planning, programming and preconstruction
NCHRP Repo.,
Otero, L.D. et al., 2009. A systematic approach for resource allocation in software
projects. Computers & Industrial Engineering, 56(4), pp.1333–1339. Avai-
lable at: http://dx.doi.org/10.1016/j.cie.2008.08.002.
Pingaud, H. & Gourc, D., 2003. Démarche de pilotage d’un projet industriel par
l'analyse des risques. In 5ème Congrès International de Génie Industriel.
Laval, Canada.
PMI, 2013. A Guide to the Project Management Body of Knowledge: PMBOK
Guide 5th Editio., Project Management Institute.
Prabhakar, G., 2008a. Projects and their management: A literature review. Interna-
tional Journal of Business and Management, 3(4), pp.3–9. Available at:
http://www.ccsenet.org/journal/index.php/ijbm/article/view/1290.
Prabhakar, G., 2008b. What is project success: A literature review. International
Journal of Business and Management, 3(9), pp.3–10. Available at: http://
www.ccsenet.org/journal/index.php/ijbm/article/view/1244.
Raftery, J., 2003. Risk Analysis in Project Management 1st ed., Routledge.
Ravalison, B., 2004. Méthodologie d’identification des risques des projets de sys-
tèmes d'information: quelle place pour les acteurs? In Congrès EDSYS. Tou-
louse, France.
Raz, T. & Hillson, D., 2005. A comparative review of risk management standards.
Risk Management: An international journal, 7(4), pp.53–66.
52

Reiss, G., 2013. Project Management Demystified: Today’s Tools and Techniques
2nd Editio., Routledge.
Rowe, W.D., 1977. An anatomy of risk, Wiley.
Saaksvuori, A. & Immonen, A., 2008. Product Lifecycle Management 3rd Editio.,
K, Springer-Verlag Berlin and Heidelberg GmbH & Co.
Samikoglu, Ö. et al., 1998. Sensitivity analysis for project planning and schedu-
ling under uncertain completions. Computers & Chemical Engineering,
22(98), pp.S871–S874.
Schwalbe, K., 2013. Information Technology Project Management 7th ed., Cen-
gage Learning.
Shenhar, A.J. & Dvir, D., 2007. Reinventing Project Management - The diamond
approach to successful growth and innovation, Harvard Business School
Press, Boston.
Shi, Q. & Blomquist, T., 2012. A new approach for project scheduling using fuzzy
dependency structure matrix. International Journal of Project Management,
30(4), pp.503–510. Available at: http://dx.doi.org/10.1016/j.ijproman.
2011.11.003.
Soroush, H.M., 1994. The most critical path in a PERT network: A heuristic ap-
proach. European Journal of Operational Research, 78, pp.93–105.
Stal-Le Cardinal, J. & Marle, F., 2006. Project: The just necessary structure to
reach your goals. International Journal of Project Management, 24(3), pp.
226–233. Available at: http://linkinghub.elsevier.com/retrieve/pii/
S0263786305001079 [Accessed October 30, 2012].
Stamatis, D.H., 1994. Total Quality Management and Project Management. Pro-
ject Management Journal, pp.48 – 54.
Stuckenbruck, L.C., 1986. Who determines project success? In Proceedings of the
18th Annual Seminar/Symposium. Montreal, Canada: Project Management
Institute, pp. 85–93.
The Standish Group, 2000. Extreme Chaps,
Tiner, W.D., 1985. Subdivision of work on construction projects. International
Journal of Project Management, 3(1), pp.13–18.
Turner, J.R. & Simister, S.J., 2001. Project contract management and a theory of
organization. International Journal of Project Management, 19, pp.457–
464.
 53

Turner, R., 1992. The Handbook of Project-Based Management: Improving the

Processes for Achieving Strategic Objectives, McGraw-Hil.
Veitch, M.D., 1984. THE USE OF NETWORK ANALYSIS IN PLANNING IM-
PLEMENTING PROJECTS. International Journal of Educational Deve-
lopment, 4(I), pp.31–52.
Vidal, L.-A. & Marle, F., 2012. A systems thinking approach for project vulnerabi-
lity management. Kybernetes, 41(1/2), pp.206–228. Available at: http://
apps.webofknowledge.com/full_record.do?
product=WOS&search_mode=GeneralSearch&qid=3&SID=T26BMHFian-
jfMM1CedD&page=1&doc=1 [Accessed December 3, 2012].
Walker, A., 2007. Project Management in Construction 5th Editio., Wiley-Black-
well.
Willis, R.J., 1985. Critical path analysis and resource constrained project schedu-
ling — Theory and practice. European Journal of Operational Research, 21,
pp.149–155.
Winkler, D. & Biffl, S., 2012. Improving Quality Assurance in Automation Sys-
tems Development Projects. In Quality Assurance and Management. In
Tech, pp. 379–398.
De Wit, A., 1988. Measurement of project success. International Journal of Pro-
ject Management, 6.
Wu, X., 2012. The Contract and Project Quality Management System Based on
Fuzzy Mathematics Methods. International Journal of Digital Content
Technology and its Applications, 6(August), pp.77–85.
Yang, L.R., Chen, J.H. & Wang, X.L., 2015. Assessing the effect of requirement
definition and management on performance outcomes: Role of interpersonal
conflict, product advantage and project type. International Journal of Pro-
ject Management, 33(1), pp.67–80.
Yannou, B., 1998. Analyse fonctionnelle et analyse de la valeur. In M. Tollenaere
& Hermes, eds. Conception de produits mécaniques, méthodes, modèles et
outils.
Yescombe, E.R., 2002. Principles of Project Finance, Elsevier. Available at: http://
www.sciencedirect.com/science/article/pii/B9780127708515500063 [Acces-
sed January 18, 2015].
Zhu, R.J., Peng, Y. & Sun, Y., 2013. The Research of Risk Management in Project
Contracts. In 3rd International Conference on Civil Engineering, Architec-
 54

ture and Building Materials. TRANS TECH PUBLICATIONS LTD, LAU-

BLSRUTISTR 24, CH-8717 STAFA-ZURICH, SWITZERLAND.

View publication stats