Vous êtes sur la page 1sur 233

Le Guide PMBOK ®

Édition 2000

Guide du référentiel
des connaissances en
gestion de projet

PROJECT MANAGEMENT INSTITUTE


Le Guide officiel du Project Management Body of Knowledge
Guide du
Référentiel des
connaissances en
gestion de
projet
(Guide PMBOK®)

An American National Standard


ANSI/PMI 99-001 2000
Guide du
Référentiel des
connaissances en
gestion de
projet
(Guide PMBOK®)

Édition 2000

Project Management Institute


Newtown Square, Pennsylvania, États-Unis
ISBN: 1-930699-68-9
ISBN: 1-930699-23-9 (Couverture souple français)
ISBN: 1-880410-23-0 (Couverture souple anglais)
ISBN: 1-880410-22-2 (Couverture rigide anglais)
ISBN: 1-880410-25-7 (CD-ROM anglais)

Publié par : Project Management Institute, Inc.


Four Campus Boulevard
Newtown Square, Pennsylvania 19073-3299 USA
Téléphone : 610-356-4600 ou visitez notre site Internet : www.pmi.org
Courriel : pmihq@pmi.org

© 2003 Project Management Institute, Inc. Tous droits réservés.

Le service de publication du PMI accepte volontiers les corrections et les commentaires concernant ses
documents. N’hésitez pas à nous envoyer vos commentaires concernant la typographie, la mise en page ou
d’autres erreurs éventuellement identifiées, ainsi que tous vos commentaires destinés au PMI et portant sur le
contenu du Guide du référentiel des connaissances en gestion de projet. Faites simplement une copie des
pages en question dans le Guide PMBOK®, indiquez les erreurs et envoyez le tout à : Book Editor, PMI
Publications, Four Campus Boulevard, Newton Square, PA 19073-3299, Etats-Unis, téléphone : +1 610 356 4600,
télécopie : +1 610 356 4647, courriel : booked@pmi.org.

« PMI » et le logo PMI sont des services et des marques commerciales déposés aux États-Unis ainsi que dans
d’autres pays ; « PMP » et le logo PMP sont des marques de certification déposées aux États-Unis ainsi que dans
d’autres pays ;

« PMBOK », « PM Network » et « PMI Today » sont des marques déposées aux États-Unis ainsi que dans
d’autres pays ; « Project Management Journal » et « Building professionalism in project management » sont des
marques du Project Management Institute, Inc.

Les livres publiés par le PMI sont disponibles au prix de gros pour une distribution dans le cadre d’activités
promotionnelles, ou pour inclusion dans des programmes de formation d’entreprises ou d’un autre type. Pour plus
d’informations, merci d’écrire à Bookstore Administrator, PMI Publications, Four Campus Boulevard, Newtown
Square, PA 19073-3299 USA. Ou bien, contactez votre libraire local.

Imprimé aux États-Unis. Aucune partie de ce document ne peut être reproduite ou transmise de quelque manière
que ce soit ou par quelque moyen que ce soit, électronique, manuel, photocopie, enregistrement, ou par
l’intermédiaire d’un système d’archivage quelconque sans la permission expresse écrite de l’éditeur.

Le papier utilisé pour ce livre est conforme au Permanent Paper Standard émis par le National Information
Standards Organization (Z39.48—1984).

Équipe de traduction :
Jean-Pierre Estibals, PMP ; Didier Estibals, PMP.

Édition et mise en page réalisées par Lexicomm International Ltd., Jenkintown, Pennsylvania, États-Unis.

Couverture conçue par Melinda Possinger.

Imprimé et relié par Automated Graphic Systems, White Plains, Maryland, États-Unis.

10 9 8 7 6 5 4 3 2 1
SOMMAIRE

AVANT-PROPOS
SOMMAIRE ----------------------------------------------------------------- v
LISTE DES FIGURES ----------------------------------------------------- vii
PRÉFACE À L’ÉDITION 2000 ---------------------------------------------- ix

SECTION I — CADRE DE LA GESTION DE PROJET --------------------- 1


Chapitre 1 — Introduction ------------------------------------------------- 3
1.1 Objectif de ce guide -------------------------------------------------------- 3
1.2 Qu’est-ce qu’un projet ? -------------------------------------------------- 4
1.3 Qu’est-ce que la gestion de projet ? ------------------------------------- 6
1.4 Relations avec les autres disciplines de gestion ------------------------- 9
1.5 Activités connexes --------------------------------------------------------- 10
Chapitre 2 — Contexte de la gestion de projet ------------------------- 11
2.1 Phases et cycle de vie du projet ------------------------------------------ 11
2.2 Acteurs du projet ----------------------------------------------------------- 16
2.3 Influences organisationnelles ---------------------------------------------- 18
2.4 Compétences majeures en gestion -------------------------------------- 21
2.5 Influences socio-économiques et environnementales ------------------ 26
Chapitre 3 — Processus de la gestion de projet ----------------------- 29
3.1 Processus du projet -------------------------------------------------------- 29
3.2 Groupes de processus ---------------------------------------------------- 30
3.3 Interactions entre processus ---------------------------------------------- 32
3.4 Personnalisation des interactions entre processus --------------------- 37
3.5 Matrice de présentation des processus de gestion de projet ---------- 38

SECTION II — DISCIPLINES DE LA GESTION DE PROJET -------------- 39


Chapitre 4 — Gestion de l’intégration du projet ----------------------- 41
4.1 Élaboration du plan de projet --------------------------------------------- 42
4.2 Mise en œuvre du plan de projet ----------------------------------------- 46
4.3 Contrôle intégré des changements --------------------------------------- 47
Chapitre 5 — Gestion du contenu du projet ---------------------------- 51
5.1 Démarrage ------------------------------------------------------------------ 53
5.2 Planification du contenu --------------------------------------------------- 55
5.3 Définition du contenu ------------------------------------------------------ 57
5.4 Vérification du contenu ---------------------------------------------------- 61
5.5 Contrôle des changements du contenu --------------------------------- 62
Chapitre 6 — Gestion des délais du projet ----------------------------- 65
6.1 Définition des activités ----------------------------------------------------- 65
6.2 Jalonnement des activités ------------------------------------------------- 68
6.3 Estimation de la durée des activités -------------------------------------- 71
6.4 Élaboration du planning ---------------------------------------------------- 73
6.5 Contrôle du planning ------------------------------------------------------- 79
Chapitre 7 — Gestion des coûts du projet ------------------------------ 83
7.1 Planification des ressources ----------------------------------------------- 85
7.2 Estimation des coûts ------------------------------------------------------- 86
7.3 Budgétisation --------------------------------------------------------------- 89
7.4 Contrôle des coûts --------------------------------------------------------- 90

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
v
Chapitre 8 — Gestion de la qualité du projet --------------------------- 95
8.1 Planification de la qualité -------------------------------------------------- 97
8.2 Assurance de la qualité ---------------------------------------------------- 101
8.3 Contrôle de la qualité ------------------------------------------------------ 102
Chapitre 9 — Gestion des ressources humaines du projet ----------- 107
9.1 Planification de l’organisation --------------------------------------------- 108
9.2 Obtention des ressources humaines ------------------------------------- 112
9.3 Développement de l’équipe ----------------------------------------------- 114
Chapitre 10 — Gestion des communications du projet --------------- 117
10.1 Planification des communications ---------------------------------------- 119
10.2 Diffusion de l’information -------------------------------------------------- 121
10.3 Rapports d’avancement --------------------------------------------------- 122
10.4 Clôture administrative ------------------------------------------------------ 125
Chapitre 11 — Gestion des risques du projet -------------------------- 127
11.1 Planification de la gestion des risques ----------------------------------- 129
11.2 Identification des risques -------------------------------------------------- 131
11.3 Analyse qualitative des risques ------------------------------------------- 133
11.4 Analyse quantitative des risques ------------------------------------------ 137
11.5 Développement des stratégies de réponse ------------------------------ 140
11.6 Suivi et contrôle des risques ---------------------------------------------- 144
Chapitre 12 — Gestion des approvisionnements du projet ----------- 147
12.1 Planification des approvisionnements ------------------------------------ 149
12.2 Planification des appels d’offres ------------------------------------------ 152
12.3 Appels d’offres ------------------------------------------------------------- 153
12.4 Choix des fournisseurs ---------------------------------------------------- 155
12.5 Administration des contrats ----------------------------------------------- 156
12.6 Clôture du contrat ---------------------------------------------------------- 158

SECTION III—ANNEXES ------------------------------------------------------ 161


Annexe A — Processus de normalisation du Project Management
Institute - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 163
Annexe B — Évolution du Guide du référentiel des connaissances en
gestion de projet du PMI - - - - - - - - - - - - - - - - - - - - - - - - - - - 167
Annexe C — Collaborateurs et réviseurs du Guide PMBOK®,
Édition 2000 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 175
Annexe D — Notes - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 179
Annexe E — Extensions des champs d’application - - - - - - - - - - - 181
Annexe F — Autres sources d’information sur la gestion de
projet - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 185
Annexe G — Résumé des domaines de compétence de la gestion
de projet - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 189

SECTION IV — GLOSSAIRE ET INDEX ------------------------------------- 193


Glossaire -------------------------------------------------------------------- 195
Index ------------------------------------------------------------------------- 215

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
vi © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Liste des figures

Figure 1-1. Vue d’ensemble des disciplines et des processus de la gestion de projet ----------------------- 8
Figure 1-2. Relations entre la gestion de projet et les autres disciplines de gestion -------------------------- 9
Figure 2-1. Exemple type de cycle de vie ------------------------------------------------------------------------- 13
Figure 2-2. Cycle de vie représentatif d’un approvisionnement militaire, selon la directive
US DODI 5000.2 (en cours de révision finale, avril 2000) ------------------------------------------- 14
Figure 2-3. Cycle de vie représentatif d’un projet de construction, selon Morris ------------------------------ 15
Figure 2-4. Cycle de vie représentatif d’un projet de produit pharmaceutique, selon Murphy --------------- 16
Figure 2-5. Cycle de vie représentatif d’un développement de logiciel, selon Muench------------------------ 17
Figure 2-6. Influences des structures organisationnelles sur les projets ---------------------------------------- 19
Figure 2-7. Organisation fonctionnelle ------------------------------------------------------------------------------ 20
Figure 2-8. Organisation par projets -------------------------------------------------------------------------------- 21
Figure 2-9. Structure matricielle faible ------------------------------------------------------------------------------ 22
Figure 2-10. Structure matricielle équilibrée ------------------------------------------------------------------------- 22
Figure 2-11. Structure matricielle forte ------------------------------------------------------------------------------- 23
Figure 2-12. Structure mixte ------------------------------------------------------------------------------------------ 23
Figure 3-1. Liens entre les groupes de processus d’une phase ------------------------------------------------- 31
Figure 3-2. Chevauchement des groupes de processus d’une phase------------------------------------------ 31
Figure 3-3. Interaction entre les phases --------------------------------------------------------------------------- 31
Figure 3-4. Relations entre les processus de démarrage -------------------------------------------------------- 32
Figure 3-5. Relations entre les processus de planification ------------------------------------------------------- 33
Figure 3-6. Relations entre les processus de réalisation --------------------------------------------------------- 35
Figure 3-7. Relations entre les processus de contrôle ----------------------------------------------------------- 36
Figure 3-8. Relations entre les processus de clôture ------------------------------------------------------------- 37
Figure 3-9. Matrice de présentation des processus de gestion de projet répartis
selon les groupes de processus et les disciplines --------------------------------------------------- 38
Figure 4-1. Vue d’ensemble de la gestion de l’intégration du projet -------------------------------------------- 42
Figure 4-2. Coordination des changements sur l’ensemble du projet ------------------------------------------ 48
Figure 5-1. Vue d’ensemble de la gestion du contenu ----------------------------------------------------------- 52
Figure 5-2. Exemple d’organigramme des tâches pour du matériel de défense ------------------------------ 58
Figure 5-3. Exemple d’organigramme des tâches organisé par phases --------------------------------------- 59
Figure 5-4. Exemple d’un organigramme des tâches pour une usine de traitement des eaux usées ------- 60
Figure 6-1. Vue d’ensemble de la gestion des délais du projet ------------------------------------------------- 66
Figure 6-2. Diagramme réseau du projet selon la méthode des antécédents --------------------------------- 69
Figure 6-3. Diagramme réseau du projet selon la méthode du diagramme fléché ---------------------------- 70
Figure 6-4. Calcul de la durée d’une seule activité à l’aide de la méthode PERT ----------------------------- 76
Figure 6-5. Diagramme réseau du projet avec dates ------------------------------------------------------------- 77
Figure 6-6. Diagramme à barres (Gantt) --------------------------------------------------------------------------- 78
Figure 6-7. Echéancier ---------------------------------------------------------------------------------------------- 79
Figure 7-1. Vue d’ensemble de la gestion des coûts du projet ------------------------------------------------- 84
Figure 7-2. Courbe illustrant la référence de coûts (budget) ----------------------------------------------------- 90
Figure 8-1. Vue d’ensemble de la gestion de la qualité du projet ----------------------------------------------- 96
Figure 8-2. Diagramme de causalité -------------------------------------------------------------------------------- 99
Figure 8-3. Exemple de schéma de processus ------------------------------------------------------------------- 100
Figure 8-4. Fiche de contrôle des performances de délais du projet ------------------------------------------- 104
Figure 8-5. Diagramme de Pareto ---------------------------------------------------------------------------------- 105

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
vii
Figure 9-1. Vue d’ensemble de la gestion des ressources humaines du projet ------------------------------- 108
Figure 9-2. Matrice des responsabilités ---------------------------------------------------------------------------- 111
Figure 9-3. Histogramme des ressources ------------------------------------------------------------------------- 112
Figure 10-1. Vue d’ensemble de la gestion des communications du projet ------------------------------------- 118
Figure 10-2. Rapport des performances sous forme de graphique ---------------------------------------------- 124
Figure 10-3. Rapport d’avancement sous forme de tableau ------------------------------------------------------ 124
Figure 11-1. Vue d’ensemble de la gestion des risques ----------------------------------------------------------- 128
Figure 11-2. Évaluation de l’impact des risques -------------------------------------------------------------------- 136
Figure 11-3. Matrice Probabilité-Impact ----------------------------------------------------------------------------- 137
Figure 11-4. Estimations et fourchette des coûts définis après des entretiens sur les risques ---------------- 139
Figure 11-5. Exemples de distributions des probabilités couramment utilisées --------------------------------- 140
Figure 11-6. Méthode de l’arbre de décision ----------------------------------------------------------------------- 141
Figure 11-7. Simulation des risques de coût ----------------------------------------------------------------------- 142
Figure 12-1. Vue d’ensemble de la gestion des approvisionnements du projet -------------------------------- 148

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
viii © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Préface à l’édition 2000

Cet ouvrage remplace et annule le livre publié en 1996 par le Project Management Ins-
titute (PMI®) et intitulé A Guide to the Project Management Body of Knowledge (PMBOK®
Guide).
Le projet de mise à jour de l’édition de 1996 comprenait :
■ L’ajout de nouvelles informations reflétant le développement des connaissances et
pratiques dans le domaine de la gestion de projet par la présentation des outils, pra-
tiques, méthodes et autres éléments pertinents et désormais d’un usage généralisé.
(Usage généralisé signifiant : être applicable à la majorité des projets, la plupart du
temps, et recueillir un large consensus quant à sa valeur et son utilité.)
■ La clarification du texte et des figures afin de rendre cet ouvrage plus pratique pour
les utilisateurs.
■ La correction des erreurs de l’ouvrage précédent.
Afin d’aider les utilisateurs de cet ouvrage qui connaissent peut-être l’ouvrage pré-
cédent, nous en avons résumé les principales différences ci-dessous.
1. Tout au long de ce livre, nous avons clarifié le fait que les projets gèrent des exi-
gences émanant de nécessités, de besoins et d’attentes.
2. Nous avons renforcé les liens avec la stratégie de l’organisation dans tout le docu-
ment.
3. Nous avons beaucoup plus insisté sur l’élaboration progressive à la section 1.2.3.
4. Nous avons reconnu le rôle du service Projet (Project Office en anglais) à la sec-
tion 2.3.4.
5. Nous avons ajouté des références à la gestion de projet dans les économies émer-
gentes, ainsi qu’à l’impact social, économique et environnemental, à la section 2.5.4.
6. Nous avons traité plus amplement de la gestion de la valeur acquise aux chapitres
4 (Gestion de l’intégration du projet), 7 (Gestion des coûts du projet) et 10 (Gestion des
communications du projet).
7. Nous avons réécrit le chapitre 11 (Gestion des risques du projet). Il contient désor-
mais les six processus ci-après, au lieu de quatre auparavant : planification de la ges-
tion des risques, identification des risques, analyse qualitative des risques, analyse
quantitative des risques, planification des stratégies de réponse, et suivi et contrôle des
risques.
8. La vérification du contenu ne fait maintenant plus partie des processus d’exécu-
tion mais des processus de contrôle.
9. Le processus 4.3, « Gestion d’ensemble des changements », a été rebaptisé « Contrôle
intégré des changements », pour souligner l’importance du contrôle des changements
tout au long du projet.
10. Nous avons ajouté un tableau (figure 3-9), pour représenter le rapport entre les
trente-neuf processus de la gestion de projet, les cinq groupes de processus de gestion de
projet et les neuf domaines de compétence de la gestion de projet.
11. Nous avons ajouté plusieurs outils et méthodes :

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
ix
■ Chapitre 4 (Gestion de l’intégration du projet)
◆ Gestion de la valeur acquise (EVM en anglais)
◆ Action préventive
■ Chapitre 5 (Gestion du contenu du projet)
◆ Mises à jour du cahier des charges
◆ Plan de projet
◆ Référence de base mise à jour
■ Chapitre 6 (Gestion des délais du projet)
◆ Durées sur base quantitative
◆ Réserve de durée (contingence)
◆ Structure de codification
◆ Analyse des écarts
◆ Étapes jalons
◆ Attributs des activités
◆ Outils informatiques
■ Chapitre 7 (Gestion des coûts du projet)
◆ Ouvrages sur l’estimation
◆ Mesure de la valeur acquise
■ Chapitre 8 (Gestion de la qualité du projet)
◆ Coût de la qualité
■ Chapitre 10 (Gestion des communications du projet)
◆ Rapports du projet
◆ Présentations du projet
◆ Clôture du projet
■ Chapitre 11 (Gestion des risques du projet ; ce chapitre a été réécrit)
Le référentiel des connaissances nécessaires à la profession de gestionnaire de projet est en
constante évolution. Le PMI a l’intention de mettre le Guide PMBOK® à jour régulièrement. Par
conséquent, si vous souhaitez faire des commentaires sur cet ouvrage ou suggérer des amé-
liorations, veuillez les envoyer à :

PMI Project Management Standards Program


Project Management Institute
Four Campus Boulevard
Newtown Square, PA 19073-3299 USA
Téléphone : + 1 (610) 356-4600
Télécopie : + 1 (610) 356-4647
Courriel : pmihq@pmi.org
Internet : http://www.pmi.org

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
x © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
SECTION I

CADRE DE LA GESTION DE PROJET

1. Introduction

2. Contexte de la gestion de projet

3. Processus de la gestion de projet


Chapitre 1

Introduction

Le Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®) est un terme
global qui décrit l’ensemble des connaissances au sein du domaine professionnel de la gestion
de projet. Comme dans d’autres professions, telles que le droit, la médecine ou la comptabi-
lité, le référentiel des connaissances dépend des intervenants et des enseignants qui l’appli-
quent et le font progresser. Le référentiel complet des connaissances en gestion de projet
recense des méthodes classiques, éprouvées et largement utilisées, ainsi que des méthodes
nouvelles et originales dont l’usage est relativement limité. Il comprend aussi bien de la docu-
mentation publiée que non publiée.
Ce chapitre définit et explique plusieurs termes clés et offre une présentation générale du
reste de l’ouvrage. Il comprend les sections principales suivantes :
1.1 Objectif de ce guide
1.2 Qu’est-ce qu’un projet ?
1.3 Qu’est-ce que la gestion de projet ?
1.4 Relations avec les autres disciplines de gestion
1.5 Activités connexes

1.1 OBJECTIF DE CE GUIDE


La gestion de projet est une profession nouvelle en plein essor. Le principal objectif de cet
ouvrage est de définir et de décrire les sous-éléments du PMBOK® qui sont d’un usage géné-
ralisé. Par usage généralisé, on sous-entend que les connaissances et les méthodes décrites
sont applicables à la majorité des projets, la plupart du temps, et qu’il s’est établi un consensus
général sur leur valeur et leur utilité. Cela ne signifie pas que les connaissances et les méthodes
décrites sont ou doivent être appliquées à tous les projets sans distinction ; l’équipe de gestion
de projet a toujours autorité quant au choix des méthodes à utiliser pour un projet donné.
Ce livre a également pour objectif d’offrir un lexique commun à la profession, ainsi que des
méthodes de communication orale et écrite. La gestion de projet est une profession relative-
ment jeune, et bien qu’il existe des pratiques communes, la terminologie utilisée varie souvent.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
3
Chapitre 1 — Introduction

Cet ouvrage fournit une référence de base pour toutes les personnes intéressées par la pro-
1.2 | 1.2.3

fession de gestionnaire de projet. Ce public comprend, entre autres :


■ les cadres supérieurs ;
■ les responsables des chefs de projet ;
■ les chefs de projet et autres membres de l’équipe de projet ;
■ les clients des projets et les autres acteurs ;
■ les responsables des services fonctionnels dont certains membres sont impliqués dans les
projets ;
■ les enseignants en gestion de projet et disciplines connexes ;
■ les consultants et autres spécialistes en gestion de projet et champs connexes ;
■ les formateurs qui créent des programmes de formation en gestion de projet.
En tant qu’ouvrage de référence, ce guide ne prétend pas traiter le sujet dans tous ses
détails. L’annexe E traite de l’extension des champs d’application, alors que l’annexe F propose
une liste de références supplémentaires sur la gestion de projet.
Cet ouvrage est également utilisé par le Project Management Institute comme référence de
base en matière de connaissances et méthodes de gestion de projet pour ses programmes de
développement professionnels, et notamment :
■ la certification PMP® ;
■ l’accréditation de programmes de formation en gestion de projet.

1.2 QU’EST-CE QU’UN PROJET ?


Les organisations réalisent des travaux. Ces travaux sont généralement composés d’opérations
ou de projets, les deux pouvant être identiques. Les opérations et les projets ont de nom-
breuses caractéristiques communes. Ils sont par exemple :
■ réalisés par des personnes ;
■ limités par des ressources réduites ;
■ planifiés, exécutés et contrôlés.
Les projets sont souvent mis en œuvre pour réaliser le plan stratégique d’une organisation.
Les opérations et les projets diffèrent en premier lieu parce que les premières sont continues
et répétitives, alors que les seconds sont temporaires et uniques. On peut donc définir un
projet par les caractéristiques distinctives suivantes : un projet est une entreprise temporaire
mise en œuvre en vue de créer un produit ou un service unique. Temporaire signifie que tout
projet a un début et une fin bien déterminés. Unique signifie que le produit ou service se dif-
férencie de façon caractéristique de tous les autres produits et services. Pour de nombreuses
organisations, les projets sont un moyen de répondre aux demandes qui ne peuvent pas être
traitées dans le fonctionnement normal de l’organisation.
Des projets sont entrepris à tous les niveaux d’une organisation. Ils peuvent occuper une
seule personne ou plusieurs milliers. Leur durée peut aller de quelques semaines à plus de cinq
ans. Les projets peuvent impliquer un seul service d’une entreprise ou dépasser les limites de
l’organisation, comme dans le cas de groupements d’entreprises et de partenariats. Ils sont
essentiels à la réalisation de la stratégie de l’organisation maîtresse d’œuvre car ils constituent
le moyen de la mettre en œuvre. On peut citer les exemples de projet suivants :
■ développement d’un nouveau produit ou service ;
■ mise en place de changements de structure, de personnel ou de style d’une organisation ;
■ conception d’un nouveau véhicule de transport ;
■ développement ou acquisition d’un système d’information nouveau ou modifié ;
■ construction d’un bâtiment ou d’une installation ;
■ construction d’un circuit d’alimentation en eau pour une communauté d’un pays en voie
de développement ;
■ conduite d’une campagne électorale ;
■ mise en place d’une nouvelle procédure ou d’un nouveau processus.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
4 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 1 — Introduction

1.2.1 Temporaire
Temporaire signifie que tout projet a un début et une fin bien déterminés. La fin arrive lorsque
les objectifs du projet ont été atteints ou lorsqu’il devient évident que ces objectifs ne seront
ou ne pourront pas être atteints, ou que le projet n’est plus nécessaire et qu’il est abandonné.
Temporaire ne veut pas nécessairement dire de courte durée ; de nombreux projets durent plu-
sieurs années. Mais dans tous les cas, la durée d’un projet est limitée ; les projets ne sont pas
des entreprises continues.
En outre, temporaire ne s’applique généralement pas au produit ou au service créé par le
projet. Les projets peuvent souvent avoir un impact social, économique ou environnemental,
voulu ou non, qui leur survit. La plupart des projets sont entrepris pour obtenir un résultat
durable. Par exemple, le projet de construction d’un monument national aboutira à un résultat
qui, on l’espère, durera des siècles. Une série de projets et/ou des projets complémentaires
menés en parallèle peuvent être nécessaires pour atteindre un objectif stratégique.
Les objectifs des projets et des opérations sont fondamentalement différents. L’objectif d’un
projet est d’atteindre un but et de mettre un terme au projet. L’objectif d’une opération continue
se résume normalement à soutenir l’entreprise. Les projets sont fondamentalement différents,
parce que le projet cesse d’exister quand ses objectifs déclarés ont été atteints, alors que les
opérations adoptent une nouvelle série d’objectifs et continuent d’exister.
La nature temporaire des projets peut s’appliquer aussi à d’autres aspects de l’effort entre-
pris :
■ L’opportunité ou le créneau du marché est généralement temporaire — la plupart des pro-
jets n’ont qu’une durée limitée pour produire leur produit ou service.
■ L’équipe de projet, en tant qu’équipe, survit rarement au projet ; la plupart des projets sont
réalisés par des équipes réunies dans le seul but de leur réalisation et lorsqu’ils sont ter-
minés, les équipes sont dissoutes.

1.2.2 Produit, service ou résultat unique


Les projets impliquent la réalisation d’une action nouvelle et donc unique. Un produit ou ser-
vice peut être unique même s’il appartient à une catégorie plus large. Par exemple, des milliers
d’immeubles de bureaux ont été édifiés, mais chaque installation est unique : propriétaires dif-
férents, conceptions différentes, emplacements différents, entrepreneurs différents, etc. L’exis-
tence d’éléments répétitifs ne change pas le fait que les activités du projet sont
fondamentalement uniques. Par exemple :
■ un projet de développement d’un nouvel avion commercial peut nécessiter plusieurs pro-
totypes ;
■ un projet de commercialisation d’un nouveau médicament peut nécessiter la préparation
de milliers de doses pour les essais cliniques ;
■ un projet immobilier peut comporter des centaines de logements individuels ;
■ un projet de développement (par ex., alimentation en eau courante et système sanitaire)
peut être mis en place dans cinq zones géographiques.

1.2.3 Élaboration progressive


L’élaboration progressive est une caractéristique des projets qui intègre les notions « tempo-
raire » et « unique ». Le produit de chaque projet étant unique, les caractéristiques particulières
du produit ou service doivent être élaborées progressivement. Progressivement signifie « pro-

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
5
Chapitre 1 — Introduction

céder par étapes ; continuer sans interruption par incréments », tandis qu’élaboré signifie « pré-
1.3 | 1.3.2

paré soigneusement et dans les détails ; développé complètement » (1). Ces caractéristiques
particulières seront définies dans leurs grandes lignes au tout début du projet et de façon plus
explicite et détaillée au fur et à mesure que l’équipe de projet acquerra une connaissance plus
approfondie du produit.
L’élaboration progressive des caractéristiques du produit doit être soigneusement coor-
donnée avec une définition précise du contenu du projet, surtout si ce dernier est réalisé sous
contrat. Une fois que le contenu du projet (le travail à réaliser) est correctement défini, il ne
doit pas varier, même lors de l’élaboration progressive des caractéristiques du produit. L’in-
troduction du chapitre 5 traite plus amplement de la relation entre le contenu du produit et
le contenu du projet.
Les deux exemples suivants illustrent cette élaboration progressive dans deux différents
champs d’application.
Exemple 1. La construction d’une usine de produits chimiques commence à l’ingénierie des
procédés pour définir les caractéristiques du processus. Ces caractéristiques sont utilisées pour
concevoir les principales unités de traitement. Ces informations deviennent la base des études
de conception définissant, d’une part, le plan détaillé de l’usine et, d’autre part, les spécifica-
tions mécaniques des principales unités de traitement et des installations auxiliaires. On en tire
des plans détaillés conduisant aux plans de fabrication (isométriques de construction). Pendant
la construction, des interprétations et des adaptations sont faites, lorsque nécessaire, et sou-
mises pour approbation. Cette élaboration supplémentaire des caractéristiques est officialisée
par des plans conformes à l’exécution. Durant les essais et la mise en service, l’élaboration des
caractéristiques se poursuit souvent sous forme d’ultimes ajustements de fonctionnement.
Exemple 2. Le produit d’un projet de développement économique peut initialement être
défini comme suit : « Améliorer la qualité de vie des résidents aux revenus les plus faibles de
la communauté X ». Au fur et à mesure que le projet avance, on peut décrire les produits plus
spécifiquement comme, par exemple : « Offrir, dans la communauté X, l’accès à l’eau et à la
nourriture à 500 résidents à faibles revenus ». L’étape suivante de l’élaboration progressive peut
se concentrer exclusivement sur l’augmentation de la production agricole et du marketing, alors
que le ravitaillement en eau devient une priorité secondaire, et sera entrepris une fois que la
réalisation de l’élément agriculture aura débutée.

1.3 QU’EST-CE QUE LA GESTION DE PROJET ?


La gestion de projet est l’application de connaissances, de compétences, d’outils et de méthodes
aux activités d’un projet afin de répondre à ses besoins. La gestion de projet est accomplie
grâce à l’utilisation de processus tels que le démarrage, la planification, l’exécution, le contrôle
et la clôture. L’équipe de projet gère les travaux composant les projets, lesquels comprennent
en général :
■ des exigences concurrentes : contenu, délais, coûts, risques et qualité ;
■ des acteurs, avec des besoins et des attentes différents ;
■ des besoins identifiés.
Il est important de noter que de nombreux processus composant la gestion de projet sont,
par nature, itératifs. Ceci est dû en partie à l’existence et à la nécessité d’une élaboration pro-
gressive tout au long du cycle de vie d’un projet : plus vous connaissez votre projet, mieux
vous êtes capable de le gérer.
Le terme gestion de projet est parfois employé pour décrire une approche organisationnelle
de la gestion des opérations courantes. Cette approche, mieux définie par l’expression gestion
par projets, traite de nombreux aspects des opérations courantes comme des projets afin de

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
6 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 1 — Introduction

leur appliquer des méthodes de gestion de projet. Bien que la compréhension de la gestion de
projet soit essentielle pour une organisation qui gère par projets, l’étude détaillée de cette
approche est hors du propos de cet ouvrage.
On peut organiser les connaissances en gestion de projet de différentes façons. Cet ouvrage
comporte deux sections principales réparties sur douze chapitres, tel que décrit ci-dessous.

1.3.1 Le cadre de la gestion de projet


La section I, intitulée « Cadre de la gestion de projet », présente une base à la compréhension
de la gestion de projet.
Le chapitre 1, Introduction, définit les termes clés et offre une vue d’ensemble du reste
du livre.
Le chapitre 2, Contexte de la gestion de projet, décrit l’environnement dans lequel les
projets se déroulent. L’équipe de gestion de projet doit maîtriser ce contexte plus large. La ges-
tion au jour le jour des activités du projet est nécessaire à sa réussite, mais n’est pas suffisante.
Le chapitre 3, Processus de la gestion de projet, présente une vue générale de l’inter-
action habituelle entre les divers processus de gestion de projet. Il est indispensable de com-
prendre ces interactions pour comprendre le contenu des chapitres 4 à 12.

1.3.2 Disciplines de la gestion de projet


La section II, intitulée « Disciplines de la gestion de projet », décrit les connaissances et les pra-
tiques de la gestion de projet en fonction des processus. Ces processus ont été organisés en
neuf disciplines comme décrit ci-dessous et illustré à la figure 1-1.
Le chapitre 4, Gestion de l’intégration du projet, décrit les processus nécessaires pour
assurer une bonne coordination des divers éléments du projet. Il comprend l’élaboration du
plan de projet, la mise en œuvre du plan de projet et le contrôle intégré des changements.
Le chapitre 5, Gestion du contenu du projet, décrit les processus nécessaires pour véri-
fier que le projet comprend toutes les activités nécessaires, et uniquement celles-ci, à sa réa-
lisation. Il comprend le démarrage, la planification du contenu, la définition du contenu, la
vérification du contenu et le contrôle des changements du contenu.
Le chapitre 6, Gestion des délais du projet, décrit les processus nécessaires pour assurer
la réalisation du projet en temps voulu. Il comprend la définition et le jalonnement des acti-
vités, l’estimation de la durée des activités, l’élaboration et le contrôle du planning.
Le chapitre 7, Gestion des coûts du projet, décrit les processus nécessaires pour s’assurer
que le projet est réalisé en respectant le budget approuvé. Il comprend la planification des res-
sources, l’estimation des coûts, la budgétisation et le contrôle des coûts.
Le chapitre 8, Gestion de la qualité du projet, décrit les processus nécessaires pour s’as-
surer que le projet répond aux besoins définis au départ. Il comprend la planification, l’assu-
rance et le contrôle de la qualité.
Le chapitre 9, Gestion des ressources humaines du projet, décrit les processus néces-
saires à une meilleure utilisation du personnel impliqué dans le projet. Il comprend la plani-
fication de l’organisation, l’obtention de ressources humaines et le développement de l’équipe.
Le chapitre 10, Gestion des communications du projet, décrit les processus nécessaires
pour assurer, en temps voulu et de façon appropriée, la génération, la collecte, la diffusion,
l’archivage et le traitement final des informations du projet. Il comprend la planification des

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
7
Chapitre 1 — Introduction

Figure 1–1 | 1.4

Figure 1-1 Vue d’ensemble des disciplines et des processus de la gestion de projet

communications, la diffusion de l’information, les rapports d’avancement et la clôture admi-


nistrative.
Le chapitre 11, Gestion des risques du projet, décrit les processus liés à l’identification,
l’analyse et la réponse aux risques d’un projet. Ceci comprend la planification de la gestion des
risques, l’identification des risques, les analyses qualitative et quantitative des risques, la pla-
nification des stratégies de réponse, le suivi et le contrôle des risques.
Le chapitre 12, Gestion des approvisionnements du projet, décrit les processus néces-
saires à l’acquisition de biens et services à l’extérieur de l’entreprise maîtresse d’œuvre. Ceci
comprend la planification des approvisionnements, la planification des appels d’offres, les
appels d’offres, le choix des fournisseurs, l’administration et la clôture des contrats.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
8 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 1 — Introduction

Figure 1-2 Relations entre la gestion de projet et les autres disciplines de gestion

1.4 RELATIONS AVEC LES AUTRES DISCIPLINES DE GESTION


Bien des connaissances nécessaires à la gestion de projet sont spécifiques à cette discipline
(par exemple, l’analyse du chemin critique et l’organigramme des tâches). Cependant, le
PMBOK® recouvre partiellement d’autres disciplines de gestion, comme illustré à la figure 1-
2.
La gestion englobe la planification, l’organisation, l’obtention des ressources humaines,
l’exécution et le contrôle des opérations d’une entreprise. Elle englobe également des disci-
plines connexes, telles que le droit, la planification stratégique, la logistique et la gestion des
ressources humaines. Le PMBOK® recouvre partiellement ou modifie la gestion dans de nom-
breux domaines : conduite organisationnelle, prévision financière et techniques de planifica-
tion, entre autres. La section 2.4 traite de la gestion plus en détail.
Les champs d’application sont des catégories de projets ayant en commun des éléments
importants du projet, mais qui ne sont pas nécessaires ou présentes dans tous les projets. Les
champs d’application sont définis habituellement en fonction des :
■ services fonctionnels et disciplines de support, tels que le juridique, la gestion de la pro-
duction et des stocks, le marketing, la logistique et le personnel ;
■ caractéristiques techniques, telles que le développement de logiciels, la pharmacie, l’hy-
drotechnique, les systèmes sanitaires et le génie civil ;
■ domaines spécialisés de gestion, tels que les marchés publics, le développement de com-
munautés ou le développement de nouveaux produits ;
■ types d’industrie, tels que l’automobile, les produits chimiques, l’agriculture ou les services
financiers.
L’annexe E traite plus en détail des champs d’application de la gestion de projet.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
9
Chapitre 1 — Introduction

1.5 | 2.1.1
1.5 ACTIVITÉS CONNEXES
Certains types d’activités sont très proches de la notion de projet. Il existe souvent une hiérar-
chie entre plan stratégique, programme, projet et sous-projet grâce à laquelle un programme
comprenant plusieurs projets associés contribuera à l’accomplissement d’un plan stratégique.
Ces entreprises liées sont décrites ci-dessous.
Programmes. Un programme est un groupe de projets gérés de façon coordonnée afin d’en
retirer des avantages que ne permettrait pas une gestion individuelle (2). De nombreux pro-
grammes comprennent aussi des éléments appartenant à des opérations courantes. Par
exemple :
■ Le « programme de l’avion XYZ » comprend aussi bien le projet ou les projets de concep-
tion et de développement de l’avion que sa fabrication en série et sa maintenance ensuite.
■ De nombreuses sociétés d’électronique ont des chefs de programme qui sont responsables
à la fois du lancement des produits particuliers (projets) et de la coordination de plusieurs
lancements sur une certaine période (opération continue).
Les programmes peuvent également comporter un certain nombre d’activités répétitives ou
cycliques, par exemple :
■ Les services publics parlent souvent de « programme de construction » annuel, une opéra-
tion régulière continue qui implique de nombreux projets.
■ Nombre d’organismes à but non lucratif ont des « programmes de collecte de fonds » menés
régulièrement afin d’obtenir des subsides et comportant souvent une série de projets de
recherche d’adhérents ou de vente aux enchères.
■ La publication d’un journal ou d’une revue est aussi un programme : la publication pro-
prement dite est une activité continue, tandis que chaque numéro correspond à un projet.
Dans certains champs d’application, gestion de programme et gestion de projet
sont considérées comme synonymes ; dans d’autres, la gestion de projet est un sous-
ensemble de la gestion de programme. Cette diversité de signification rend indis-
pensable de faire précéder toute discussion sur ce sujet d’un accord sur le sens précis
de chacun de ces termes : gestion de programme et gestion de projet.
Sous-projets. Les projets sont souvent décomposés en éléments plus faciles à
gérer, les sous-projets. Les sous-projets sont souvent donnés en sous-traitance à une
entreprise externe ou à un autre service fonctionnel de l’entreprise réalisatrice. On
peut citer comme exemples de sous-projets :
■ les sous-projets basés sur un processus, tels qu’une phase du projet ;
■ les sous-projets qui correspondent à une décomposition, selon les besoins, en compétence
des ressources humaines, tels que la plomberie ou l’installation électrique dans un projet
de bâtiment ;
■ les sous-projets impliquant une certaine technologie, tels que les tests automatisés de pro-
grammes informatiques dans un projet de développement de logiciels.
Les sous-projets sont généralement vus et gérés comme des projets.
Gestion d’un portefeuille de projets. La gestion d’un portefeuille de projets désigne la sélec-
tion et le soutien des investissements en projets ou programmes. Ces investissements en pro-
jets et programmes sont guidés par le plan stratégique et les ressources disponibles de
l’organisation.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
10 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 2

Contexte de la gestion de
projet

Les projets et la gestion de projet se déroulent dans un environnement plus vaste que celui du
projet lui-même. L’équipe de gestion de projet doit maîtriser ce contexte plus large. La gestion
au jour le jour des activités du projet est nécessaire à sa réussite, mais n’est pas suffisante. Ce
chapitre décrit les aspects majeurs du contexte de la gestion de projet, qui ne sont pas traités
ailleurs dans cet ouvrage. Les sujets abordés sont :
2.1 Phases et cycle de vie du projet
2.2 Acteurs du projet
2.3 Influences organisationnelles
2.4 Compétences majeures en gestion
2.5 Influences socio-économiques et environnementales

2.1 PHASES ET CYCLE DE VIE DU PROJET


Les projets étant des entreprises uniques, ils comportent un certain degré d’incertitude. Les
organisations maîtresses d’œuvre les décomposent généralement en plusieurs phases de projet
pour assurer une meilleure gestion et les relier à leurs opérations courantes. L’ensemble des
phases du projet est appelé cycle de vie du projet.

2.1.1 Caractéristiques des phases du projet


Chaque phase du projet est marquée par la production d’un ou de plusieurs produits livrables.
Un produit livrable est un résultat tangible et vérifiable, tel qu’une étude de faisabilité, une
étude de détail ou un prototype en état de marche. Les produits livrables, et par conséquent
les phases, font partie d’une logique généralement séquentielle qui assure une définition cor-
recte du produit du projet.
La conclusion d’une phase de projet est généralement marquée par un passage en revue
des principaux produits livrables et des performances du projet à ce jour, afin de a) décider
si le projet doit passer à la phase suivante et b) déceler et corriger les erreurs de façon éco-
nomique. Ces révisions de fin de phase sont souvent appelées sorties de phase, portes ou points
de contrôle.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
11
Chapitre 2 — Contexte de la gestion de projet

Chaque phase de projet comprend normalement une série de produits livrables précis,
2.1.2 | 2.1.3

définis pour établir le niveau de contrôle de la gestion souhaité. La majeure partie de ces élé-
ments est liée au produit livrable principal de la phase. Habituellement, les phases tirent leur
nom de ces éléments : besoins, conception, construction, test, démarrage, mise en service. Plu-
sieurs cycles de vie de projet types sont décrits à la section 2.1.3.

2.1.2 Caractéristiques du cycle de vie du projet


La notion de cycle de vie est utilisée pour définir le début et la fin d’un projet. Par exemple,
lorsqu’une organisation décèle une opportunité à laquelle elle voudrait répondre, elle autori-
sera souvent une évaluation des besoins et/ou une étude de faisabilité pour décider si le projet
est viable. La définition du cycle de vie du projet déterminera si l’étude de faisabilité est traitée
comme la première phase du projet ou comme un projet séparé et indépendant.
La définition du cycle de vie du projet déterminera également les activités de transition à
inclure ou à exclure en début et en fin de projet. De cette façon, la définition du cycle de vie
du projet pourra être utilisée pour relier celui-ci aux opérations courantes de l’entreprise maî-
tresse d’œuvre.
La succession des phases, telle que définie par la plupart des cycles de vie de projet,
implique en général une certaine forme de transfert de technologie, comme le transfert des
besoins à la conception, de la construction à l’exploitation ou des études à la fabrication. Les
produits livrables de la phase en amont sont généralement approuvés avant le début des acti-
vités de la phase suivante. Cependant, une phase en aval peut parfois débuter avant l’appro-
bation des produits livrables de la phase en amont, lorsque les risques encourus sont jugés
acceptables. Cette pratique de chevauchement des phases est souvent appelée construction en
régime accéléré.
En général, les cycles de vie du projet déterminent :
■ les travaux techniques à exécuter à chaque phase (par exemple, le travail de l’architecte
fait-il partie de la phase de définition ou de la phase d’exécution ?) ;
■ les intervenants de chaque phase (par exemple, les responsables de la mise en œuvre qui
doivent participer aux processus de définition des besoins et de conception).
Les descriptions des cycles de vie de projet peuvent être très générales ou très détaillées.
Les descriptions très détaillées peuvent comporter de nombreux formulaires, tableaux et listes
de contrôle afin de donner structure et cohérence au projet. Ces approches détaillées sont sou-
vent appelées méthodologies de la gestion de projet.
La plupart des descriptions des cycles de vie de projet ont un certain nombre de caracté-
ristiques communes :
■ Le niveau des coûts et des ressources humaines est bas en début de projet, plus élevé vers
la fin pour baisser rapidement au fur et à mesure que le projet arrive à son terme. Ce
modèle est illustré à la figure 2-1.
■ La probabilité d’achever le projet avec succès est plus faible et, de ce fait, les risques et l’in-
certitude sont plus élevés en début de projet. En général, la probabilité d’achever le projet
avec succès croît progressivement avec son avancement.
■ L’influence des acteurs sur les caractéristiques finales du produit et le coût final du projet
est maximale au début du projet et décroît progressivement avec son avancement. Ce phé-
nomène est dû principalement au fait que le coût des changements et de la correction des
erreurs augmente au fur et à mesure que le projet avance.
Il faut faire attention de ne pas confondre cycle de vie du projet et cycle de vie du produit.
Par exemple, un projet entrepris pour mettre sur le marché un nouvel ordinateur de bureau
n’est qu’une phase ou étape du cycle de vie du produit.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
12 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 2 — Contexte de la gestion de projet

Figure 2-1 Exemple type de cycle de vie

Bien que de nombreux cycles de vie de projet utilisent des noms de phases similaires, avec
des produits livrables demandés semblables, peu sont identiques. La plupart comportent quatre
ou cinq phases, alors que d’autres en ont neuf ou plus. Il peut exister des variations considé-
rables, même dans un champ d’application unique ; dans une société, le cycle de vie de déve-
loppement de logiciels peut comporter une seule phase de conception, alors que dans une
autre, les phases d’étude fonctionnelle et de conception détaillée sont séparées.
Les sous-projets, à l’intérieur des projets, peuvent également avoir leur propre cycle de vie.
Par exemple, un cabinet d’architectes chargé de la conception d’un nouvel immeuble de
bureaux, participe d’abord à la phase de définition avec le propriétaire lors de la conception,
et participe ensuite à la phase de mise en œuvre lors de la supervision des travaux. Cependant,
le projet d’étude de l’architecte comportera sa propre succession de phases, de l’étude concep-
tuelle à la clôture, en passant par la définition et la mise en œuvre. L’architecte peut même
définir l’étude du bâtiment et la supervision des travaux comme des projets distincts compor-
tant chacun leurs propres phases.

2.1.3 Exemples types de cycles de vie de projet


Les cycles de vie de projet suivants ont été choisis pour illustrer la diversité des approches uti-
lisées. Il s’agit d’exemples types ; aucun n’est préconisé. Dans chaque cas, le nom des phases
et les principaux produits livrables sont ceux décrits par l’auteur de chacun des schémas.
Approvisionnement militaire. La directive du ministère de la défense américaine 5000.2 en
phase de révision finale, avril 2000, décrit une série de jalons d’approvisionnement et de
phases, comme illustré à la figure 2-2.
■ Développement conceptuel et technologique : études sur papier des différents concepts
possibles pour répondre aux besoins d’une mission ; développement de sous-
systèmes/composants et démonstration de concept/technologie des concepts du nouveau
système. S’achève par le choix de l’architecture de système et de la technologie mature
devant être utilisées.
■ Développement et démonstration du système : intégration du système ; réduction des
risques ; démonstration des modèles d’études techniques ; développement et premier test
opérationnel puis évaluation. S’achève par la démonstration du système dans un environ-
nement fonctionnel.
■ Production et mise en œuvre : petite pré-série (LRIP) ; développement complet des capa-
cités de fabrication ; phase étalée sur les opérations courantes et le support.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
13
Chapitre 2 — Contexte de la gestion de projet

Figure 2–2 | Figure 2–3

Figure 2-2 Cycle de vie représentatif d’un approvisionnement militaire, selon la directive US DODI 5000.2 (en
cours de révision finale, avril 2000)

■ Support : cette phase fait partie du cycle de vie du produit ; il s’agit en fait de gestion per-
manente. Divers projets peuvent être menés durant cette phase, afin d’améliorer les capa-
cités, de corriger les défauts, etc.
Construction. Selon Morris (1), décrit le cycle de vie d’un projet de construction, comme
illustré à la figure 2-3.
■ Faisabilité : formulation du projet, études de faisabilité, conception de la stratégie et appro-
bation. La décision de lancer ou non le projet est prise à la fin de cette phase.
■ Planification et étude : étude de base, coûts et délais, termes et conditions du contrat et pla-
nification détaillée. Les principaux contrats sont conclus à la fin de cette phase.
■ Construction : fabrication, livraison, génie civil, installation et essais. L’installation est prati-
quement achevée à la fin de cette phase.
■ Mise en marche et mise en production : essais finaux et maintenance. L’installation fonc-
tionne normalement à la fin de cette phase.
Produits pharmaceutiques. Murphy (2) décrit le cycle de vie d’un projet de développement
d’un nouveau produit pharmaceutique aux États-Unis, comme illustré à la figure 2-4.
■ Découverte et sélection : comporte les recherches fondamentales et appliquées pour iden-
tifier les candidats aux tests précliniques.
■ Recherche préclinique : constituée des tests en laboratoire et sur animaux pour évaluer la
sécurité et l’efficacité, ainsi que de la préparation et la présentation d’un nouveau médi-
cament de recherche (IND).
■ Dossier d’homologation : comporte les tests cliniques de phase I, II et III, ainsi que la pré-
paration et le dépôt de la demande d’homologation (NDA).
■ Activités après la demande d’homologation : comprennent tous les travaux supplémentaires
demandés pour l’examen de la demande d’homologation (NDA) par la fédération de la
santé publique américaine (FDA).

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
14 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 2 — Contexte de la gestion de projet

Figure 2-3 Cycle de vie représentatif d’un projet de construction, selon Morris

Développement de logiciels. Il existe divers modèles de cycle de vie d’un logiciel, tels que
le modèle « en cascade ». Muench, et al. (3) décrivent un modèle de développement de logi-
ciel en spirale avec quatre cycles et quatre quartiers, comme illustré à la figure 2-5.
■ Cycle de vérification du concept : identifier les besoins, définir les objectifs de ce cycle,
effectuer l’étude conceptuelle et logique du système et réaliser la validation conceptuelle,
produire les plans des tests de réception, faire l’analyse des risques et faire des recom-
mandations.
■ Cycle du premier niveau de réalisation : en déduire les besoins du système, définir les
objectifs de premier niveau, faire l’étude logique du système, étudier et produire le premier
niveau, faire des plans de tests du système, évaluer le premier niveau et faire des recom-
mandations.
■ Cycle du second niveau de réalisation : en déduire les besoins du sous-système, définir les
objectifs du second niveau, réaliser l’étude physique, produire le second niveau, faire des
plans de tests du sous-système, évaluer le second niveau et faire des recommandations.
■ Cycle final : satisfaire aux besoins détaillés et compléter l’étude finale, produire le niveau
final et effectuer les essais unitaires, de sous-systèmes, de système et de réception.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
15
Chapitre 2 — Contexte de la gestion de projet

Figure 2-4 | Figure 2–5

Figure 2-4 Cycle de vie représentatif d’un projet de produit pharmaceutique, selon Murphy

2.2 ACTEURS DU PROJET


Les acteurs d’un projet sont les personnes et les sociétés activement impliquées dans le projet
ou dont les intérêts peuvent être affectés positivement ou négativement par l’exécution ou
l’achèvement du projet. Les acteurs peuvent aussi influencer le projet et ses résultats. L’équipe
de gestion de projet doit identifier les acteurs, déterminer leurs besoins, puis gérer et infléchir
ces besoins de façon à assurer le succès du projet. L’identification des acteurs est souvent dif-
ficile. Par exemple, un monteur, dont l’emploi futur dépend de l’issue du projet d’étude d’un
nouveau produit, est-il un acteur ?
Les principaux acteurs de tout projet sont :
■ le chef de projet : responsable de la gestion du projet ;
■ le client : personne ou organisation qui utilisera le produit émanant du projet. Plusieurs
niveaux de clients sont possibles. Par exemple, les clients d’un nouveau produit pharma-
ceutique peuvent être les médecins qui le prescrivent, les patients qui le prennent et la
sécurité sociale et les assurances maladie qui le payent. Dans certains champs d’applica-
tion, client et utilisateur sont synonymes, alors que dans d’autres on parle du client comme
de l’entité qui achète les résultats du projet et des utilisateurs comme de ceux qui utilise-
ront directement le produit du projet ;
■ l’organisation maîtresse d’œuvre : entreprise dont les salariés sont le plus directement impli-
qués dans l’exécution du projet ;
■ les membres de l’équipe de projet : groupe qui effectue les travaux compris dans le projet ;
■ le commanditaire : personne ou groupe, au sein de l’entreprise maîtresse d’œuvre ou
externe à celle-ci, qui finance le projet, en argent ou en nature.
Il existe en outre différentes dénominations et catégories d’acteurs du projet : internes et
externes, propriétaires et bailleurs de fonds, vendeurs et fournisseurs, membres de l’équipe
et leurs familles, agences gouvernementales et réseaux de média, simples citoyens, groupes
d’influence temporaires ou permanents, et la société dans son ensemble. Nommer ou
regrouper les acteurs sert surtout à déterminer les personnes ou organisations se définissant
comme acteurs. Le rôle et les responsabilités des acteurs peuvent se chevaucher : par exemple,
lorsqu’une société d’ingénierie assure le financement de l’usine qu’elle est en train de conce-
voir.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
16 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 2 — Contexte de la gestion de projet

Figure 2-5 Cycle de vie représentatif d’un développement de logiciel, selon Muench

Gérer les attentes des acteurs peut s’avérer difficile, parce qu’ils ont souvent des
objectifs divergents et parfois conflictuels. Par exemple :
■ Le chef de service qui a demandé un nouveau système d’information souhaite un
programme bon marché, l’architecte du système vise l’excellence technique et le
fournisseur chargé de la programmation cherche à optimiser ses bénéfices.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
17
Chapitre 2 — Contexte de la gestion de projet

■ Le vice-président de la recherche d’une société d’électronique définira la réussite d’un nou-


2.3 | 2.3.3

veau produit comme la « technologie à la pointe du progrès », le vice-président de la pro-


duction le définira comme des « utilisations de niveau international », alors que la
préoccupation majeure du vice-président du marketing sera le nombre de nouvelles fonc-
tions.
■ Un promoteur immobilier s’intéressera aux délais de réalisation, les autorités locales vou-
dront lever un impôt sur le revenu maximal, un groupe d’écologistes souhaitera minimiser
les effets nuisibles sur l’environnement et les habitants du voisinage espéreront que le
projet se réalisera ailleurs.
En général, les divergences entre ou parmi les acteurs doivent être tranchées en faveur du
client. Ceci ne veut pourtant pas dire que les besoins et attentes des autres acteurs ne peuvent
ou ne doivent pas être pris en compte. Trouver la solution appropriée à ces divergences
constitue l’un des défis majeurs de la gestion de projet.

2.3 INFLUENCES ORGANISATIONNELLES


Les projets font habituellement partie d’organisations plus grandes qu’eux : sociétés, agences
gouvernementales, institutions de protection de la santé, organismes internationaux, associa-
tions professionnelles, et autres. Même lorsque le projet est l’organisation (coentreprises et par-
tenariats), il sera toujours influencé par l’organisation ou les organisations qui l’ont mis sur
pied. La maturité d’une organisation quant à ses systèmes de gestion de projet, sa culture, son
style, sa structure organisationnelle et sa fonction de gestion de projet peut également avoir
une influence sur le projet. Les sections suivantes décrivent les aspects majeurs de ces grosses
structures organisationnelles importantes qui vont probablement influencer le projet.

2.3.1 Systèmes organisationnels


Les organisations basées sur les projets sont celles dont les opérations sont principalement
constituées par des projets. Ces organisations font partie de deux catégories :
■ Les organisations dont la source de revenus principale est la réalisation de projets pour le
compte d’autres entités : cabinets d’architectes, sociétés d’ingénierie, consultants, entrepre-
neurs des secteurs privé et public, organisations privées, etc.
■ Les organisations qui ont adopté la gestion par projets (voir la section 1.3).
Ces organisations ont souvent mis en place des systèmes visant à faciliter la gestion de
projet. Par exemple, leurs systèmes financiers sont souvent conçus spécifiquement pour la
comptabilité, le suivi et le compte rendu de plusieurs projets simultanés.
Les organisations qui ne sont pas basées sur des projets ne disposent pas, en général, de
systèmes de gestion prenant efficacement en charge les besoins des projets. L’absence de sys-
tèmes orientés projet rend la gestion de projet plus difficile. Dans certains cas, ce type d’or-
ganisation sera divisé en services ou autres unités, fonctionnant comme des organisations
gérées par projets, disposant de systèmes adaptés.
L’équipe de gestion de projet doit être particulièrement sensibilisée à l’influence des sys-
tèmes de l’organisation sur le projet. Par exemple, si l’organisation récompense ses respon-
sables fonctionnels lorsqu’ils facturent au projet le temps passé par leur personnel, l’équipe de
gestion de projet devra alors peut-être prévoir des contrôles pour s’assurer que les membres
du personnel facturés sont réellement affectés au projet.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
18 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 2 — Contexte de la gestion de projet

Figure 2-6 Influences des structures organisationnelles sur les projets

2.3.2 Cultures et styles organisationnels


La plupart des organisations ont développé une culture propre. Cette culture se reflète dans les
valeurs, normes, convictions et attentes que partagent leurs membres ; dans leurs règles et leurs
procédures ; dans leur perception de la hiérarchie ; et dans bien d’autres facteurs. Les cultures
organisationnelles ont souvent une influence directe sur le projet. Par exemple :
■ Une équipe qui propose une approche inhabituelle ou très risquée aura plus de chances
d’obtenir un accord dans une organisation agressive ou dynamique.
■ Un chef de projet au style très participatif rencontrera probablement des problèmes dans
une organisation très hiérarchisée, alors qu’un chef de projet autoritaire aura tout autant de
problèmes dans une organisation participative.

2.3.3 Structure organisationnelle


La structure de l’entreprise maîtresse d’œuvre impose souvent des contraintes et des conditions
quant à la disponibilité des ressources. Les structures organisationnelles peuvent être caracté-
risées par un éventail allant de fonctionnel à par projets, avec diverses structures matricielles
entre les deux. La figure 2-6 présente les caractéristiques principales liées au projet des types
de structures organisationnelles rencontrées dans les entreprises. L’organisation des projets est
traitée à la section 9.1, « Planification de l’organisation ».
L’organisation fonctionnelle classique, représentée à la figure 2-7, est une hiérarchie selon
laquelle chaque salarié a un supérieur clairement identifié. Les membres du personnel sont
regroupés par spécialité, tels la production, le marketing, l’ingénierie et la comptabilité au
niveau supérieur, l’ingénierie étant ensuite divisée en unités fonctionnelles qui recouvrent les
activités de l’entreprise (par exemple, mécanique et électrique). Les organisations fonctionnelles
réalisent elles aussi des projets, mais le contenu perçu du projet se limite à la fonction : le ser-
vice d’ingénierie, dans une organisation fonctionnelle, effectuera son travail indépendamment

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
19
Chapitre 2 — Contexte de la gestion de projet

Figure 2–7 | 2.4

Figure 2-7 Organisation fonctionnelle

du service de fabrication ou de marketing. Par exemple, lors du développement d’un nouveau


produit dans une organisation purement fonctionnelle, la phase d’étude est souvent appelée
projet d’étude et n’inclut que le personnel du service d’ingénierie. Si des questions se posent
au sujet de la fabrication, elles sont transmises par la voie hiérarchique au chef de service qui
s’en entretient avec le chef du service de fabrication. Le chef du service technique communique
par la suite la réponse par la voie hiérarchique à son chef de projet.
À l’autre bout de l’éventail, on trouve l’organisation par projets, représentée à la figure
2-8. Dans ce type d’organisation, les membres de l’équipe sont souvent regroupés physique-
ment. La majorité des ressources de l’organisation est impliquée dans les activités du projet et
les chefs de projet disposent d’une indépendance et d’une autorité importantes. Les organisa-
tions par projets sont souvent divisées en unités organisationnelles appelées services, mais ces
groupes soit dépendent directement du chef de projet, soit fournissent un support à divers pro-
jets.
Les organisations matricielles, comme illustré dans les figures 2-9 à 2-11, sont un mélange
des structures fonctionnelles et par projets. Les matrices faibles conservent de nombreuses
caractéristiques des organisations fonctionnelles, et le rôle du chef de projet est plutôt celui
d’un coordinateur ou agent d’ordonnancement que celui d’un directeur. De la même façon, les
matrices fortes conservent de nombreuses caractéristiques des organisations par projets : chefs
de projet à plein temps disposant d’une autorité importante et personnel administratif de projet
à plein temps.
On retrouve toutes ces structures, à divers niveaux, dans la plupart des organisations
modernes, comme illustré à la figure 2-12. Par exemple, même une organisation fondamen-
talement fonctionnelle peut créer une équipe spéciale pour un projet important. Cette équipe
présente de nombreuses similitudes avec un projet réalisé dans une organisation par projets :
équipe de projet à plein temps issue de divers services fonctionnels, développant ses propres
procédures de fonctionnement et travaillant en marge du système hiérarchique officiel.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
20 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 2 — Contexte de la gestion de projet

Figure 2-8 Organisation par projets

2.3.4 Cabinet de projet


Un cabinet de projet remplit diverses fonctions. Il peut être en place en permanence et ses
fonctions vont du soutien aux chefs de projet, sous forme de formation, logiciels, modèles, etc.,
jusqu’à la prise en charge effective des résultats du projet.

2.4 COMPÉTENCES MAJEURES EN GESTION


La gestion est un vaste domaine qui touche à tous les aspects de la gestion d’entreprise. Elle
comprend, entre autres :
■ Finances et comptabilité, ventes et marketing, recherche et développement, et fabrication
et distribution.
■ Planification stratégique, tactique et opérationnelle.
■ Structures organisationnelles, comportements au sein de l’entreprise, administration du per-
sonnel, rémunération, avantages et plans de carrière.
■ Gestion des relations de travail par la motivation, la délégation, l’encadrement, l’esprit
d’équipe, le gestion des conflits et autres techniques.
■ Gestion personnelle par la gestion de son temps, du stress et autres techniques.
Les compétences en gestion constituent une base importante de l’acquisition des connais-
sances nécessaires à la gestion de projet. Ces compétences sont souvent essentielles pour le
chef de projet. La maîtrise d’un certain nombre de domaines de gestion est nécessaire à la réa-
lisation d’un projet donné. Cette section décrit les compétences en gestion les plus susceptibles
d’affecter un projet et qui ne seront pas traitées ailleurs dans cet ouvrage. La documentation

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
21
Chapitre 2 — Contexte de la gestion de projet

Figure 2–9 | Figure 2–12

Figure 2-9 Structure matricielle faible

Figure 2-10 Structure matricielle équilibrée

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
22 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 2 — Contexte de la gestion de projet

Figure 2-11 Structure matricielle forte

Figure 2-12 Structure mixte

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
23
Chapitre 2 — Contexte de la gestion de projet

qui traite de la gestion définit bien ces compétences d’ordre général, que l’on applique fon-
2.4.1 | 2.4.5

damentalement de la même manière tout au long d’un projet.


Cependant, un bon nombre de ces compétences en gestion sont utilisées uniquement dans
certains projets ou champs d’application. Par exemple, la sécurité des membres de l’équipe est
essentielle dans tous les projets de construction, mais elle compte très peu dans les projets de
développement de logiciels.

2.4.1 Aptitude à diriger


Kotter (4) fait la distinction entre diriger et gérer, tout en insistant sur la nécessité de l’un et de
l’autre : il est probable que l’un ne peut fonctionner sans l’autre si l’on veut obtenir de bons
résultats. Il affirme que gérer consiste surtout à « produire de façon régulière les résultats impor-
tants attendus par les acteurs », tandis que diriger consiste à :
■ établir les orientations : développer aussi bien une vision pour l’avenir que des stratégies
pour produire les changements nécessaires à la réalisation de cette vision ;
■ former une équipe : communiquer cette vision, par le geste et la parole, à tous ceux dont
la coopération est nécessaire à sa réalisation ;
■ motiver et inspirer : aider les intervenants à trouver en eux-mêmes l’énergie pour surmonter
les obstacles politiques, bureaucratiques et matériels au changement.
Dans un projet, surtout de grande envergure, on attend généralement du chef de projet
qu’il dirige aussi. L’aptitude à diriger ne se limite d’ailleurs pas au chef de projet : de nom-
breuses personnes peuvent en avoir besoin à maintes reprises au cours du projet. L’aptitude
à diriger doit être démontrée à tous les niveaux d’un projet (direction du projet, direction tech-
nique et direction d’équipe).

2.4.2 Communication
La communication implique l’échange d’informations. L’expéditeur a la responsabilité de com-
muniquer des informations claires, complètes et sans ambiguïté pour que le destinataire puisse
les recevoir correctement. Ce dernier a la responsabilité de s’assurer qu’il a bien reçu toutes les
informations et qu’il les a bien comprises. La communication a de multiples dimensions :
■ écrite et orale, écouter et parler ;
■ interne (au sein du projet) et externe (à l’attention du client, des médias, du public, etc.) ;
■ formelle (rapports, briefings, etc.) et informelle (mémos, conversations ad hoc, etc.) ;
■ verticale (par les voies hiérarchiques de l’entreprise) et horizontale (entre collègues et avec
une entreprise partenaire).
Les compétences en gestion dans le domaine de la communication s’apparentent, mais ne
sont pas identiques, à la gestion des communications du projet (décrite au chapitre 10). La
communication est un sujet plus vaste qui comporte des connaissances plus larges ne s’appli-
quant pas uniquement au contexte du projet. Par exemple :
■ les modèles expéditeur-destinataire : boucles de retour d’informations, obstacles à la com-
munication, etc. ;
■ le choix des moyens de communication : quand communiquer par écrit, quand commu-
niquer oralement, quand écrire un mémo informel, quand écrire un rapport en bonne et
due forme, etc. ;

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
24 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 2 — Contexte de la gestion de projet

■ le style : voix active ou passive, structure des phrases, choix des mots, etc. ;
■ les techniques de présentation : attitude, conception des aides visuelles, etc. ;
■ les méthodes de conduite de réunion : préparation d’un ordre du jour, gestion des conflits,
etc.
La gestion des communications du projet est l’application de ces concepts généraux aux
besoins spécifiques d’un projet ; par exemple, décider quand, comment, sous quelle forme et
à qui rendre compte de la progression du projet.

2.4.3 Négociation
La négociation implique qu’on discute avec les autres pour s’entendre ou arriver à un accord.
Les accords peuvent se négocier directement ou avec une aide extérieure ; la médiation et l’ar-
bitrage sont deux types de négociation assistée.
Les négociations servent à régler divers problèmes, à différents moments et à différents
niveaux du projet. Au cours d’un projet typique, l’équipe du projet est susceptible de négocier
sur tout ou partie :
■ des objectifs du contenu, des coûts et du planning ;
■ des changements du contenu, des coûts ou du planning ;
■ des termes et conditions du contrat ;
■ des affectations de personnel ;
■ des ressources.

2.4.4 Résolution des problèmes


La résolution des problèmes comprend à la fois leur définition et la prise de décision.
La définition des problèmes nécessite de faire la distinction entre causes et symptômes. Les
problèmes peuvent être internes (un membre principal du projet est affecté à un autre projet)
ou externes (l’obtention d’un permis dont on a besoin pour commencer les travaux est
retardée). Les problèmes peuvent être d’ordre technique (différences d’opinion quant à la
meilleure façon de concevoir un produit), dus à la gestion (les résultats d’un groupe fonc-
tionnel ne sont pas conformes au plan) ou interpersonnels (conflits de personnalités ou de
styles).
La prise de décision consiste à analyser le problème afin de trouver des solutions viables,
puis de choisir la meilleure d’entre elles. La décision peut être prise ou imposée (par le client,
l’équipe ou un responsable fonctionnel). Une fois prises, les décisions doivent être appliquées.
Les décisions comportent aussi un facteur temps, la « bonne » décision n’étant pas nécessaire-
ment la « meilleure » si elle est prise trop tôt ou trop tard.

2.4.5 Influencer l’organisation


Influencer l’organisation consiste à « s’assurer que les choses sont faites ». Cela demande que
l’on comprenne à la fois les structures formelles et informelles de toutes les organisations impli-
quées dans le projet : entre autres, l’organisation maîtresse d’œuvre, le client, les partenaires,
les fournisseurs. Influencer l’organisation implique également la compréhension des méca-
nismes du pouvoir et de la politique.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
25
Chapitre 2 — Contexte de la gestion de projet

Les termes « pouvoir » et « politique » sont employés ici dans un sens positif. Pfeffer (5)
2.5 | 2.5.4

définit le pouvoir comme « la capacité potentielle d’influer sur les comportements, de changer
le cours des événements, de vaincre les résistances et d’amener les intervenants à faire des
choses qu’ils ne feraient pas normalement ». De même, Eccles et al. (6) affirment que la « poli-
tique se résume à obtenir une action collective d’un groupe de personnes qui peuvent avoir
des intérêts tout à fait différents. Elle traite de la volonté d’utiliser de façon créative les conflits
et le désordre. Le sens négatif, bien sûr, vient du fait qu’essayer de concilier ces intérêts aboutit
à des épreuves de force et à des stratagèmes au sein de l’organisation, qui parfois n’en finis-
sent pas et sont totalement improductifs ».

2.5 INFLUENCES SOCIO-ÉCONOMIQUES ET ENVIRONNEMENTALES


Comme en gestion, les influences socio-économiques comportent un grand nombre de sujets
et de problèmes. L’équipe de gestion de projet doit comprendre que les conditions du moment
et les tendances dans ce domaine peuvent avoir des répercussions importantes sur son projet :
un petit changement à ce niveau peut se traduire, habituellement avec un certain délai, par des
bouleversements aux proportions cataclysmiques dans le projet lui-même. Parmi les nom-
breuses influences socio-économiques possibles, plusieurs catégories majeures, qui ont fré-
quemment des répercussions sur les projets, sont brièvement décrites ci-après.

2.5.1 Normes et réglementations


L’organisation internationale de normalisation (ISO) fait une différence entre normes et régle-
mentations comme suit (7) :
■ Une norme est un « document approuvé par un organisme reconnu, qui donne, pour une
utilisation généralisée et répétée, des règles, des directives ou des caractéristiques pour des
produits, des processus ou des services, et dont l’application n’est pas obligatoire ». Il existe
de nombreuses normes en usage, qui régissent tout, de la stabilité thermique des liquides
hydrauliques à la taille des disquettes en informatique.
■ Une réglementation est un « document qui établit les caractéristiques de produits, de pro-
cessus ou de services, y compris les dispositions administratives applicables, et dont l’ap-
plication est obligatoire ». Les codes concernant la construction sont un exemple de
réglementation.
Il faut être prudent lorsque l’on parle de normes et de réglementations, car la distinction
entre les deux n’est pas toujours très nette :
■ Dans la plupart des cas, les normes sont principalement des directives qui décrivent l’ap-
proche à privilégier, pour devenir ensuite des réglementations de facto lorsqu’elles sont
adoptées par la majorité (par exemple, l’utilisation de la méthode du chemin critique pour
établir le planning des gros projets de construction).
■ L’application peut être prescrite par différentes autorités (par exemple, par une agence gou-
vernementale, par la direction de l’entreprise maîtresse d’œuvre ou par l’équipe de gestion
du projet).
Dans de nombreux projets, les normes et les réglementations (quelle que soit leur défini-
tion) sont bien connues, et les plans de projet peuvent en tenir compte. Dans d’autres cas, leur
influence est inconnue ou incertaine et doit faire partie de la gestion des risques du projet
(décrite au chapitre 11).

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
26 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 2 — Contexte de la gestion de projet

2.5.2 Internationalisation
De plus en plus d’organisations ayant des opérations à l’étranger, un nombre croissant de pro-
jets s’internationalisent. Au-delà des préoccupations classiques de contenu, de coûts, de délais
et de qualité, l’équipe de gestion de projet doit également tenir compte du décalage horaire,
des jours fériés nationaux et régionaux, des voyages pour les réunions de travail face à face,
de la logistique des téléconférences et de différences politiques qui peuvent être sources de
nombreux conflits.

2.5.3 Influences culturelles


La culture est « l’ensemble des structures de comportements, des arts, des convictions, des ins-
titutions et de tous les autres produits de la réflexion et du travail humains transmis par la
société » (8). Tout projet doit se réaliser dans le contexte d’une ou plusieurs normes culturelles.
Ce domaine d’influence s’exerce au travers des pratiques, convictions et attitudes politiques,
économiques, démographiques, pédagogiques, éthiques, ethniques, religieuses et autres, qui
affectent les relations entre les personnes et les organisations.

2.5.4 Durabilité socio-économique et environnementale


Presque tous les projets sont planifiés et réalisés dans un contexte social, économique et envi-
ronnemental et comportent des répercussions positives et/ou négatives, voulues ou non. Les
organisations sont de plus en plus tenues pour responsables de l’impact d’un projet (par
exemple, la destruction accidentelle de sites archéologiques dans un projet de construction rou-
tière), ainsi que des effets d’un projet sur la population, l’économie et l’environnement, et ce
bien après l’achèvement de celui-ci (par exemple, une route peut faciliter l’accès à une zone
inhabitée, mais aussi faciliter sa destruction).

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
27
Chapitre 3

Processus de la gestion de
projet

La gestion de projet est un effort intégratif, c’est-à-dire qu’une action ou le manque d’action
dans un domaine a généralement des répercussions dans d’autres domaines. Les interactions
peuvent être directes et bien comprises, ou subtiles et incertaines. Par exemple, la modifica-
tion du contenu affecte presque toujours le coût d’un projet, sans pour autant avoir des réper-
cussions sur le moral de l’équipe ou la qualité du produit.
Ces interactions obligent souvent les acteurs à accepter de faire des compromis entre les
différents objectifs du projet ; les performances dans un domaine ne peuvent être améliorées
qu’en sacrifiant celles d’un autre. Les compromis particuliers en matière de performances peu-
vent varier d’un projet à l’autre et d’une organisation à l’autre. Le succès de la gestion de projet
passe par la gestion active de ces interactions. De nombreux professionnels de la gestion de
projet qualifient la triple contrainte d’un projet de « structure servant à évaluer les demandes
concurrentes ». La triple contrainte d’un projet est souvent illustrée par un triangle dont les
côtés ou les angles représentent l’un des paramètres gérés par l’équipe de projet.
Pour éclairer la nature intégrative de la gestion de projet et pour insister sur l’importance
de cette intégration, cet ouvrage décrit la gestion de projet selon ses processus constitutifs et
leurs interactions. Ce chapitre fournit une introduction au concept de gestion de projet en tant
qu’ensemble de processus liés et donne donc les bases nécessaires à la compréhension des
descriptions de processus proposées dans les chapitres 4 à 12. Il comprend les sections prin-
cipales suivantes :
3.1 Processus du projet
3.2 Groupes de processus
3.3 Interactions entre processus
3.4 Personnalisation des interactions entre processus
3.5 Représentation des processus de gestion de projet

3.1 PROCESSUS DU PROJET


Les projets sont constitués de processus. Un processus est une « série d’actions aboutissant à un
résultat » (1). Les processus sont exécutés par des personnes ; ils font en général partie de l’une
des deux principales catégories suivantes :

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
29
Chapitre 3 — Processus de la gestion de projet

■ Les processus de gestion de projet décrivent, organisent et réalisent les travaux du projet. Les
3.2 | Figure 3–3

processus applicables à la majorité des projets, la plupart du temps, sont décrits brièvement
dans ce chapitre et en détail dans les chapitres 4 à 12.
■ Les processus orientés produit définissent et créent le produit émanant du projet. Habituel-
lement, les processus orientés produit sont définis par le cycle de vie du projet (traité à la
section 2.1) et varient selon le champ d’application (traité à l’annexe E).
Les processus de gestion de projet et les processus orientés produit se chevauchent et inter-
agissent tout au long du projet. Par exemple, il n’est pas possible de définir le contenu du
projet sans une connaissance minimale des modalités de réalisation du produit.

3.2 GROUPES DE PROCESSUS


Les processus de gestion de projet peuvent être classés en cinq groupes comprenant chacun
un ou plusieurs processus :
■ les processus de démarrage : pour autoriser officiellement le projet ou l’une de ses phases ;
■ les processus de planification : pour définir et préciser les objectifs, et choisir la meilleure
ligne de conduite possible, pour atteindre les objectifs qui sont à l’origine du projet ;
■ les processus de réalisation : pour coordonner le personnel et les autres ressources afin de
réaliser le plan ;
■ les processus de contrôle : pour s’assurer que les objectifs du projet sont atteints en sur-
veillant et en mesurant l’avancement de façon systématique ; ceci permet d’identifier les
écarts par rapport au plan afin de prendre, le cas échéant, des mesures correctives ;
■ les processus de clôture : pour officialiser l’acceptation du projet ou d’une phase et
l’amener à une fin ordonnée.
Les groupes de processus sont reliés par les résultats qu’ils produisent, les résultats de l’un
devenant souvent les données d’entrée d’un autre. Parmi les principaux groupes de processus,
les liens sont itératifs — la planification fournit, en début de projet, un plan d’exécution docu-
menté, puis, au fur et à mesure de la progression du projet, en fournit des mises à jour. Ces
liens sont illustrés à la figure 3-1. De plus, les groupes de processus de gestion de projet ne
sont pas des événements discrets et uniques ; ce sont des activités qui se chevauchent avec
plus ou moins d’importance tout au long de chaque phase du projet. La figure 3-2 illustre l’in-
teraction et l’évolution des groupes de processus au cours d’une phase.
En outre, les interactions entre les groupes de processus dépassent le cadre des phases. Les
données de clôture d’une phase fournissent les données d’entrée de la phase suivante. Par
exemple, la clôture d’une phase de conception nécessite l’acceptation des documents de
conception par le client. En même temps, ces documents de conception forment la description
du produit utilisée pour la phase de mise en œuvre qui s’ensuit. Cette interaction est illustrée
à la figure 3-3.
Répéter les processus de démarrage au début de chaque phase permet de concentrer le
projet sur les besoins qu’il est censé satisfaire. Ceci doit également permettre d’arrêter le projet
si ces besoins n’existent plus ou s’il s’avère que le projet ne répondra pas à ces besoins. L’in-
troduction de la section 5.1, « Démarrage », traite plus en détail des besoins.
Il est important de noter que les données réelles d’entrée et de sortie des processus dépen-
dent de la phase à laquelle elles appartiennent. Bien que la figure 3-3 représente des phases
et des processus bien distincts, les projets réels se recoupent souvent. Le processus de plani-
fication, par exemple, ne doit pas seulement détailler les actions à accomplir pour la réalisa-

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
30 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 3 — Processus de la gestion de projet

Figure 3-1 Liens entre les groupes de processus d’une phase

Figure 3-2 Chevauchement des groupes de processus d’une phase

Figure 3-3 Interaction entre les phases

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
31
Chapitre 3 — Processus de la gestion de projet

Figure 3–4 | Figure 3–5

Figure 3-4 Relations entre les processus de démarrage

tion de la phase en cours, mais également fournir une description préliminaire du travail à
effectuer pour les phases suivantes. Cette progression dans le détail du plan du projet est sou-
vent appelée « planification par vagues successives » pour indiquer que la planification est un
processus itératif et continu.
L’implication des acteurs dans les phases du projet augmente les chances de satisfaction des
besoins du client, et entraîne un engagement, ou partage de la propriété du projet, de ces
acteurs qui est essentiel à la réussite du projet.

3.3 INTERACTIONS ENTRE PROCESSUS


À l’intérieur de chaque groupe de processus, les processus individuels sont reliés entre eux par
leurs données d’entrée et de sortie. En se concentrant sur ces liens, on peut décrire chaque
processus selon ses :
■ données d’entrée : documents ou éléments pouvant être documentés et sur lesquels por-
tera une action ;
■ outils et méthodes : opérations appliquées aux données d’entrée pour produire les données
de sortie ;
■ données de sortie : documents ou éléments pouvant être documentés et résultant du pro-
cessus.
Les processus de gestion de projet communs à bon nombre de projets, dans la plupart des
champs d’application, sont énumérés ci-dessous et décrits en détail dans les chapitres 4 à 12.
Les chiffres entre parenthèses renvoient au chapitre et à la section en question. Les interactions
entre processus illustrées ci-dessous sont également communes à la plupart des projets et des
champs d’application. La section 3.4 traite de la personnalisation des descriptions des processus
et de leurs interactions.

3.3.1 Processus de démarrage


La figure 3-4 illustre le seul processus constituant ce groupe.
■ Démarrage (5.1) : l’autorisation officielle du projet ou d’une phase fait partie de la ges-
tion du contenu du projet.

3.3.2 Processus de planification


La planification est d’une importance capitale pour le projet, car il s’agit de réaliser une action
nouvelle. De ce fait, cette section comporte davantage de processus. Le nombre de processus
ne signifie toutefois pas que la gestion de projet se réduit à la planification : l’effort de plani-
fication doit être proportionnel au contenu du projet et à l’utilité des informations produites.
La planification est un effort continu tout au long du projet.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
32 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 3 — Processus de la gestion de projet

Figure 3-5 Relations entre les processus de planification

Les relations entre les processus de planification du projet sont illustrées à la figure 3-5
(diagramme éclaté de l’ellipse intitulée « Processus de planification » à la figure 3-1). Ces pro-
cessus sont souvent répétés avant l’achèvement du plan de projet. Par exemple, si la date de
fin de projet initiale est inacceptable, les ressources, les coûts, voire le contenu du projet doi-
vent être redéfinis. En outre, la planification n’est pas une science exacte : deux équipes peu-
vent concevoir des plans tout à fait différents pour le même projet.
Processus principaux. Certains processus de planification dépendent clairement les uns des
autres, ils doivent donc être exécutés essentiellement dans le même ordre dans la plupart des
projets. Par exemple, il faut identifier les activités avant de les planifier ou d’en estimer les
coûts. Ces processus principaux de planification peuvent être répétés plusieurs fois au cours
d’une même phase de projet. Ils comprennent :

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
33
Chapitre 3 — Processus de la gestion de projet

■ la planification du contenu (5.2) : élaborer un énoncé du contenu par écrit comme base des
3.3.2 | 3.3.3

décisions ultérieures ;
■ la définition du contenu (5.3) : décomposer les principaux produits livrables du projet en
éléments plus petits et plus faciles à gérer ;
■ la définition des activités (6.1) : définir les activités spécifiques que l’on doit accomplir pour
la production des divers produits livrables du projet ;
■ le jalonnement des activités (6.2) : identifier et documenter les liens entre les activités ;
■ l’estimation de la durée des activités (6.3) : évaluer le nombre de périodes de travail néces-
saires à l’achèvement de chaque activité ;
■ l’élaboration du planning (6.4) : analyser l’enchaînement des activités, leur durée et les res-
sources nécessaires pour établir le planning du projet ;
■ la planification de la gestion des risques (11.1) : décider l’approche et la planification à
adopter pour la gestion des risques d’un projet ;
■ la planification des ressources (7.1) : déterminer les ressources (personnel, matériel, maté-
riaux) à utiliser pour réaliser les activités du projet ;
■ l’estimation des coûts (7.2) : évaluer approximativement (estimer) les coûts des ressources
nécessaires à l’achèvement des activités du projet ;
■ la budgétisation (7.3) : répartir le coût total estimé entre les différentes activités ;
■ l’élaboration du plan de projet (4.1) : rassembler tous les résultats des autres processus de
planification et en tirer un document logique et cohérent.
Processus de support. Les interactions entre les autres processus de planification dépendent
davantage de la nature du projet. Par exemple dans certains projets, il peut être totalement
ou quasiment impossible d’identifier les risques avant que la majeure partie de la planifica-
tion n’ait été achevée et avant que l’équipe n’ait fini d’évaluer l’agressivité des objectifs de coût
et de délai, ce qui entraîne donc des risques considérables. Bien que ces processus se dérou-
lent de façon intermittente et selon les besoins pendant la planification du projet, ils n’en sont
pas pour autant facultatifs. Ils comprennent :
■ la planification de la qualité (8.1) : identifier les normes de qualité applicables au projet
et déterminer comment les respecter ;
■ la planification de l’organisation (9.1) : identifier, documenter et attribuer les rôles, les res-
ponsabilités et les relations hiérarchiques au sein du projet ;
■ l’obtention des ressources humaines (9.2) : faire en sorte que les ressources nécessaires
soient affectées au projet et travaillent sur celui-ci ;
■ la planification des communications (10.1) : déterminer les besoins en information et com-
munication des acteurs : qui a besoin de quelle information, à quel moment et sous quelle
forme ;
■ l’identification des risques (11.2) : déterminer les risques pouvant affecter le projet et en
établir les caractéristiques ;
■ l’analyse qualitative des risques (11.3) : faire une analyse qualitative des risques et des cir-
constances afin de classer, par ordre de priorité, leurs effets sur les objectifs du projet ;
■ l’analyse quantitative des risques (11.4) : évaluer la probabilité et l’impact des risques, et
estimer leur portée sur les objectifs du projet ;
■ la planification des stratégies de réponse (11.5) : élaborer des procédures et des méthodes
pour améliorer les opportunités et atténuer les menaces pouvant avoir un impact sur les
objectifs du projet.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
34 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 3 — Processus de la gestion de projet

Figure 3-6 Relations entre les processus de réalisation

■ la planification des approvisionnements (12.1) : déterminer ce que l’on doit acheter, en


quelle quantité et à quel moment ;
■ la planification des appels d’offres (12.2) : documenter les spécifications du produit et éta-
blir la liste des fournisseurs potentiels.

3.3.3 Processus de réalisation


Les processus de réalisation comprennent des processus principaux et des processus de sup-
port. La figure 3-6 illustre l’interaction entre les processus principaux et les processus de sup-
port suivants :
■ la mise en œuvre du plan de projet (4.2) : exécuter le plan de projet en réalisant les acti-
vités qui en font partie ;
■ l’assurance de la qualité (8.2) : évaluer de façon systématique les performances de l’en-
semble du projet, afin de s’assurer qu’il respectera les normes de qualité applicables ;
■ le développement de l’équipe (9.3) : développer les compétences des personnes et des
groupes, afin d’améliorer les performances du projet ;
■ la diffusion de l’information (10.2) : mettre les informations nécessaires à la disposition des
acteurs, en temps voulu ;
■ les appels d’offres (12.3) : obtenir les devis, les soumissions, les offres ou les propositions,
selon le cas ;
■ le choix des fournisseurs (12.4) : choisir parmi les fournisseurs potentiels ;
■ l’administration des contrats (12.5) : gérer les relations avec le vendeur.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
35
Chapitre 3 — Processus de la gestion de projet

Figure 3–7 | 3.4

Figure 3-7 Relations entre les processus de contrôle

3.3.4 Processus de contrôle


Les performances du projet doivent être examinées et mesurées régulièrement, afin d’identifier
les écarts par rapport au plan. Ces écarts alimentent les processus de contrôle dans les diverses
disciplines. Lorsque des écarts importants sont relevés (à savoir ceux susceptibles de faire
échouer le projet), on modifie le plan en répétant les processus de planification nécessaires.
Par exemple, le dépassement de la date de fin d’une activité peut entraîner des réajustements
du plan des ressources humaines, des heures supplémentaires ou des compromis entre les
objectifs de coût et de délai. Le contrôle comprend également la réalisation d’actions préven-
tives pour parer à des problèmes éventuels.
Le groupe des processus de contrôle comprend des processus principaux et des processus
de support.
La figure 3-7 illustre les interactions entre les processus principaux et les processus de sup-
port suivants :
■ le contrôle intégré des changements (4.3) : coordonner les changements sur l’ensemble du
projet ;
■ la vérification du contenu (5.4) : officialiser l’acceptation du contenu du projet ;
■ le contrôle des changements du contenu (5.5) : contrôler les changements apportés au
contenu du projet ;
■ le contrôle du planning (6.5) : contrôler les changements apportés au planning du projet ;
■ le contrôle des coûts (7.4) : contrôler les changements apportés au budget du projet ;
■ le contrôle de la qualité (8.3) : surveiller les résultats particuliers du projet, afin de déter-
miner s’ils respectent les normes de qualité et d’identifier les moyens d’éliminer la cause de
performances insuffisantes ;
■ les rapports d’avancement (10.3) : rassembler et diffuser les informations concernant les
performances. Ceci comprend les rapports de situation, la mesure de l’avancement et les
prévisions ;

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
36 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 3 — Processus de la gestion de projet

Figure 3-8 Relations entre les processus de clôture

■ le suivi et le contrôle des risques (11.6) : suivre les risques identifiés, surveiller les risques
résiduels et identifier les nouveaux risques, en s’assurant que les plans concernant les
risques sont bien exécutés et en évaluant leur efficacité à réduire ces derniers.

3.3.5 Processus de clôture


La figure 3-8 illustre les interactions entre les processus principaux suivants :
■ la clôture du contrat (12.6) : clore le contrat, y compris résoudre tous les problèmes en sus-
pens ;
■ la clôture administrative (10.4) : générer, rassembler et diffuser l’information afin d’officia-
liser l’achèvement d’une phase ou du projet, y compris évaluer ce dernier et établir une liste
des « leçons retenues » pouvant être utilisée au cours de la planification de projets ou de
phases à venir.

3.4 PERSONNALISATION DES INTERACTIONS ENTRE PROCESSUS


Les processus et les interactions décrits à la section 3.3 sont généralement acceptés ; ils s’ap-
pliquent à la majorité des projets. Cependant, tous les processus ne sont pas nécessaires à tous
les projets, et toutes les interactions ne s’appliquent pas à tous les projets. Par exemple :
■ Une organisation qui utilise systématiquement des sous-traitants peut explicitement décrire
dans le processus de planification où intervient chaque processus d’approvisionnement.
■ L’absence d’un processus ne signifie pas qu’il ne doit pas avoir lieu. L’équipe de gestion de
projet doit identifier et gérer tous les processus nécessaires à la réussite du projet.
■ Les projets qui dépendent de ressources particulières (développement de logiciels com-
merciaux, produits biopharmaceutiques, etc.) peuvent définir les rôles et les responsabilités
avant de définir le contenu : ce qui doit être fait peut être fonction des disponibilités.
■ Certaines données de sortie de processus peuvent être prédéfinies comme des contraintes.
Par exemple, la direction peut fixer une date objective de fin de projet, plutôt que de laisser
cette tâche au processus de planification. Une date de fin de projet imposée peut entraîner
des risques plus importants, faire augmenter les coûts et compromettre la qualité.
■ Les projets de plus grande envergure nécessitent davantage de détails. Par exemple, l’iden-
tification des risques peut être divisée pour identifier séparément les risques concernant les
coûts, ceux concernant les délais, les risques d’ordre technique et ceux concernant la qua-
lité.
■ Dans les sous-projets et les projets plus petits, un effort relativement faible sera consacré
aux processus dont les données de sortie ont été définies au niveau du projet (par exemple,

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
37
Chapitre 3 — Processus de la gestion de projet

Figure 3–9 | Section II

Figure 3-9 Matrice de présentation des processus de gestion de projet répartis selon les groupes de
processus et les disciplines.

un sous-traitant peut ignorer les risques explicitement assumés par le maître d’œuvre), ou
aux processus qui n’offrent qu’une utilité marginale (par exemple, on peut se passer de
plan officiel de communication dans un projet de quatre personnes).

3.5 MATRICE DE PRÉSENTATION DES PROCESSUS DE


GESTION DE PROJET
La figure 3-9 est une matrice décrivant les trente-neuf processus de gestion de projet, répartis
entre les cinq groupes de processus appelés démarrage, planification, réalisation, contrôle et
clôture, et entre les neuf disciplines de la gestion de projet décrites dans les chapitres 4 à 12.
Ce diagramme n’est pas conçu pour être limitatif ; il indique plutôt la place des processus
de gestion de projet, à la fois dans les groupes de processus et les disciplines.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
38 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
SECTION II

DISCIPLINES DE LA GESTION DE PROJET

4. Gestion de l’intégration du projet

5. Gestion du contenu du projet

6. Gestion des délais du projet

7. Gestion des coûts du projet

8. Gestion de la qualité du projet

9. Gestion des ressources humaines du projet

10. Gestion des communications du projet

11. Gestion des risques du projet

12. Gestion des approvisionnements du projet


Chapitre 4

Gestion de l’intégration du
projet

La gestion de l’intégration du projet comprend les processus nécessaires à la bonne coordi-


nation de la réalisation des divers éléments du projet. Cela implique des compromis entre des
objectifs concurrents et divers choix possibles, afin de répondre aux besoins et aux attentes des
acteurs, ou même de les dépasser. Bien que tous les processus de gestion de projet soient plus
ou moins intégratifs, ceux décrits dans ce chapitre le sont par essence. La figure 4-1 offre une
vue générale des processus principaux suivants :
4.1 Élaboration du plan de projet : intégrer et coordonner tous les plans de projet afin d’en
faire un document logique et cohérent.
4.2 Mise en œuvre du plan de projet : concrétiser le plan de projet en accomplissant les
activités le composant.
4.3 Contrôle intégré des changements : coordonner les modifications sur l’ensemble du
projet.
Ces processus interagissent entre eux et avec les processus d’autres disciplines. Chaque pro-
cessus peut nécessiter la participation d’une ou plusieurs personnes ou d’un ou plusieurs
groupes, selon les besoins du projet. Habituellement, tous les processus sont exécutés au
moins une fois au cours de chaque phase du projet.
Bien que les processus soient présentés ici comme des éléments distincts avec des inter-
faces bien définies, ils peuvent dans la pratique se chevaucher et interagir d’une manière non
détaillée dans ce chapitre. Les interactions entre processus sont décrites au chapitre 3.
Ce chapitre se concentre sur les processus, outils et méthodes utilisés pour intégrer les pro-
cessus de gestion de projet. Par exemple, la gestion de l’intégration du projet entre en jeu lors
de l’estimation des coûts dans le cadre de l’élaboration de plans alternatifs, ou lors de l’iden-
tification des risques associés aux différentes options d’affectation des ressources humaines.
Cependant, pour assurer la réussite d’un projet, l’intégration doit également intervenir dans
d’autres secteurs. Par exemple :
■ les activités du projet doivent être coordonnées avec les opérations courantes de l’organi-
sation maîtresse d’œuvre ;
■ le contenu du produit et le contenu du projet doivent être intégrés (l’introduction du cha-
pitre 5 traite de la différence entre contenu du produit et contenu du projet) ;
Une des méthodes utilisées pour intégrer les divers processus et mesurer les performances
du projet au fur et à mesure de son avancement (du démarrage à l’achèvement), est la gestion
de la valeur acquise (EVM en anglais). La gestion de la valeur acquise est traitée dans ce cha-
pitre en tant que méthodologie d’intégration de projet, alors que la technique de la valeur

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
41
Chapitre 4 — Gestion de l’intégration du projet

Figure 4–1 | 4.1.1.5

Figure 4-1 Vue d’ensemble de la gestion de l’intégration du projet

acquise (VA) sera traitée dans d’autres chapitres en tant qu’outil de mesure des performances
par rapport au plan du projet.
Les logiciels de gestion de projet sont des outils qui facilitent l’intégration au sein d’un
projet. Ils peuvent couvrir tous les processus de gestion de projet.

4.1 ÉLABORATION DU PLAN DE PROJET


L’élaboration du plan de projet utilise les données de sortie des autres processus de planifi-
cation, comme la planification stratégique, pour créer un document logique et cohérent ser-
vant à guider à la fois la réalisation et le contrôle du projet. Ce processus est habituellement
répété plusieurs fois. Par exemple, la première version peut inclure des besoins généraux en
ressources et une succession d’activités sans date, alors que les versions suivantes du plan
seront plus explicites à ce sujet. L’ensemble des travaux du projet compose un processus ité-
ratif habituellement exécuté par l’équipe de projet à l’aide de l’organigramme des tâches (OT)
qui permet à l’équipe de répertorier tout le travail à réaliser dans le projet, puis de le décom-
poser. Tout le travail défini doit être planifié, estimé et programmé, puis approuvé à l’aide de
plans détaillés de contrôle de gestion intégré, parfois appelés plans des comptes de contrôle,
au sein du processus de gestion de la valeur acquise. L’ensemble de tous les plans de contrôle
de gestion intégré constitue alors le contenu de tout le projet.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
42 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 4 — Gestion de l’intégration du projet

Le plan de projet sert à :


■ guider la réalisation du projet ;
■ documenter les hypothèses de la planification ;
■ expliquer les choix de planification au vu des diverses solutions choisies ;
■ faciliter la communication entre les acteurs ;
■ définir les principales vérifications du projet en fonction du contenu, du niveau de détail et
de la fréquence ;
■ fournir une référence de base pour la mesure de l’avancement et le contrôle du projet.

4.1.1 Données d’entrée de l’élaboration du plan de projet


.1 Autres données de sortie de la planification. Toutes les données de sortie des processus de pla-
nification des autres disciplines (la section 3.3 en donne un résumé) sont des données d’entrée
pour le processus d’élaboration du plan de projet. Les autres données de sortie de la planifi-
cation comprennent les documents fondamentaux, comme l’OT, et les informations détaillées.
De nombreux projets ont besoin également de données d’entrée spécifiques au domaine d’ap-
plication (par exemple, la plupart des grands projets ont besoin d’un plan de trésorerie).
.2 Données historiques. L’historique disponible (par exemple, les bases de données des estima-
tions, les archives des performances des projets antérieurs) doit avoir été consulté au cours des
autres processus de planification du projet. Ces informations doivent également être dispo-
nibles pendant l’élaboration du plan de projet pour aider à la vérification des hypothèses et
pour déterminer les options à intégrer au processus.
.3 Règles d’organisation. Toute organisation impliquée dans le projet peut avoir des règles offi-
cielles et officieuses dont les effets doivent être pris en compte. Les règles d’organisation dont
on doit habituellement tenir compte incluent entre autres :
■ la gestion de la qualité : vérification (audit) des processus, objectifs d’amélioration
continue ;
■ la gestion du personnel : règles d’embauche et de licenciement, entretiens d’évaluation des
performances des salariés ;
■ les contrôles financiers : compte-rendu des temps passés, revues des dépenses requises,
codification des comptes, provisions contractuelles standard.
.4 Contraintes. Une contrainte est une restriction à appliquer et qui a un impact sur les perfor-
mances du projet. Par exemple, un budget prédéfini est une contrainte qui très probablement
limitera les options de l’équipe quant au contenu, aux ressources humaines et au planning. En
général, lorsqu’un projet est réalisé sous contrat, les conditions contractuelles sont des
contraintes.
.5 Hypothèses. Les hypothèses sont des facteurs qui en planification sont divisés en trois caté-
gories : vrais, réels ou certains. Les hypothèses ont un impact sur tous les aspects de la plani-
fication du projet et font partie de son élaboration progressive. Souvent, les équipes de projet
déterminent, documentent et confirment les hypothèses lors du processus de planification. Par

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
43
Chapitre 4 — Gestion de l’intégration du projet

exemple, si la date de disponibilité d’une personne clé est incertaine, l’équipe peut avancer
4.1.2 | 4.1.3.2

une date particulière hypothétique. Les hypothèses comportent en général un certain degré de
risque.

4.1.2 Outils et méthodes de l’élaboration du plan de projet


.1 Méthodologie de planification de projet. On peut considérer comme méthodologie de plani-
fication de projet toute approche structurée utilisée pour guider l’équipe de projet lors de l’éla-
boration du plan de projet. Il peut s’agir de simples formulaires ou modèles standard (sur
support papier ou informatique, formel ou non) ou sous une forme plus complexe d’une série
de simulations requises (par exemple, l’analyse des risques impactant les délais par la méthode
de Monte Carlo). La plupart des méthodologies de planification de projet associent des outils
« physiques », tels les logiciels de gestion de projet, à des méthodes, telles les réunions de lan-
cement.
.2 Compétences et connaissances des acteurs. Chaque acteur possède des connaissances et des
compétences pouvant s’avérer utiles lors de l’élaboration du plan de projet. L’équipe de ges-
tion de projet doit créer une ambiance permettant aux acteurs d’apporter leur contribution au
plan de projet (voir également la section 9.3, « Développement de l’équipe »). Qui peut y contri-
buer, dans quelle mesure et à quel moment ? Ceci va dépendre du projet. Par exemple :
■ Dans un projet de construction avec contrat à prix fixe, celui qui estime et contrôle les
coûts apporte une contribution majeure aux objectifs de profitabilité pendant la prépara-
tion de l’offre, une fois le montant du contrat fixé.
■ Dans un projet où les ressources humaines sont définies à l’avance, chaque intervenant
peut contribuer de manière significative au non-dépassement des objectifs de coût et de
délais, en vérifiant la plausibilité de l’estimation des durées et des charges.
.3 Système d’information de gestion de projet (PMIS en anglais). Un système d’information de
gestion de projet est constitué d’outils et de méthodes utilisés pour rassembler, intégrer et dis-
tribuer les données de sortie des processus de gestion de projet. Il englobe tous les aspects du
projet, du démarrage à la clôture, et peut comprendre à la fois des systèmes manuels et auto-
matisés.
.4 Gestion de la valeur acquise (EVM en anglais). Méthode d’intégration du contenu, du planning
et des ressources servant à mesurer et à rendre compte des performances d’un projet, de son
démarrage à sa clôture. La section 7.4.2.3 traite également de la gestion de la valeur acquise.

4.1.3 Données de sortie de l’élaboration du plan de projet


.1 Plan de projet. Document officiel et approuvé, utilisé pour gérer la réalisation du projet. Le plan
de projet liste les dates prévues de réalisation des activités et d’atteinte des étapes jalons défi-
nies dans le plan de projet (voir la section 6.4.3.1). La diffusion du plan et du planning du
projet doit se conformer au plan de communication du projet (par exemple, la direction de l’or-
ganisation maîtresse d’œuvre peut demander des informations d’ensemble peu détaillées,
tandis qu’un sous-traitant peut avoir besoin d’informations très détaillées sur un sujet précis).
Dans certains domaines d’application, le terme plan de projet intégré fait référence à ce docu-
ment.
Il faut bien faire la distinction entre le plan de projet et les références de base des perfor-
mances du projet. Le plan de projet est un document ou un ensemble de documents qui sera
probablement modifié au fur et à mesure de la disponibilité des informations concernant le
projet. Habituellement, les références de base ne changeront que rarement et seront générale-
ment effectuées suite à l’approbation d’un changement du contenu du travail ou d’un produit
livrable.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
44 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 4 — Gestion de l’intégration du projet

Il existe différentes façons d’organiser et de présenter le plan de projet, mais ce dernier


comprend habituellement tous les éléments suivants (décrits plus en détail dans une autre
partie de cet ouvrage) :
■ la charte du projet ;
■ une description de l’approche ou de la stratégie de gestion du projet (résumé des plans de
gestion des autres disciplines) ;
■ la description du contenu, comprenant les objectifs et les produits livrables du projet ;
■ l’organigramme des tâches (OT) décomposé jusqu’au niveau de contrôle, en tant que docu-
ment de référence du contenu ;
■ l’estimation des coûts, les dates de début et de fin prévues (planning) et l’attribution des
responsabilités pour chaque produit livrable inclus dans l’OT, jusqu’au niveau de contrôle ;
■ les références de base du contenu technique, des délais et des coûts — c’est-à-dire les
délais de référence (le planning du projet) et les coûts de référence (le budget du projet à
échéance) ;
■ les principales étapes jalons, avec leur objectif de date ;
■ le personnel clé ou nécessaire, avec son coût et/ou la charge prévue ;
■ le plan de gestion des risques, incluant : les principaux risques (y compris les contraintes
et les hypothèses), ainsi que les réponses et les provisions (le cas échéant) prévues pour
chacun d’entre eux ;
■ les plans de gestion annexes, à savoir :
◆ le plan de gestion du contenu (section 5.2.3.3) ;
◆ le plan de gestion des délais (section 6.4.3.3) ;
◆ le plan de gestion des coûts (section 7.2.3.3) ;
◆ le plan de gestion de la qualité (section 8.1.3.1) ;
◆ le plan de gestion des ressources humaines (section 9.1.3.2) ;
◆ le plan de gestion des communications (section 10.1.3.1) ;
◆ le plan des stratégies de réponse aux risques (section 11.5.3.1) ;
◆ le plan de gestion des approvisionnements (section 12.1.3.1).
Au besoin, chacun de ces plans peut être inclus, avec le niveau de détail nécessaire,
dans chaque projet particulier.
■ les problèmes en cours et les décisions en attente.
Selon les besoins particuliers du projet, d’autres données de sortie de planification doi-
vent faire partie du plan officiel. Par exemple, le plan d’un grand projet comporte généra-
lement l’organigramme de l’organisation.
.2 Informations détaillées. Les informations détaillées jointes au plan de projet comprennent :
■ des données de sortie en provenance d’autres processus de planification et non incluses
dans le plan de projet ;
■ des informations ou de la documentation complémentaires, générées au cours de l’élabo-
ration du plan de projet (par exemple, les contraintes et les hypothèses inconnues aupa-
ravant) ;
■ de la documentation technique, telle que l’historique de tous les besoins, de toutes les spé-
cifications et études conceptuelles ;
■ de la documentation concernant les normes applicables ;
■ les spécifications provenant d’une planification antérieure du projet.
Ces éléments doivent être organisés, selon les besoins, de façon à faciliter leur utilisation
dans la réalisation du projet.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
45
Chapitre 4 — Gestion de l’intégration du projet

4.2 | 4.3

4.2 MISE EN ŒUVRE DU PLAN DE PROJET


La mise en œuvre du plan de projet est le processus principal de réalisation de ce dernier ;
la majeure partie du budget du projet sera dépensée pendant son déroulement. Au cours de
cette étape, le chef de projet et l’équipe de gestion du projet doivent coordonner et diriger
les diverses relations techniques et organisationnelles existant au sein du projet. C’est le pro-
cessus qui dépend le plus du domaine d’application, le produit du projet y étant effectivement
créé. Les performances doivent en permanence être comparées à la référence du projet (per-
formances réelles par rapport au plan de projet), afin de prendre les mesures correctives néces-
saires. Périodiquement, des prévisions du coût final et des délais seront faites pour soutenir
l’analyse.

4.2.1 Données d’entrée de la mise en œuvre du plan de projet


.1 Plan de projet. Le plan de projet est décrit à la section 4.1.3.1. Les plans de gestion annexes
(plans de gestion du contenu, des risques, des approvisionnements, de la configuration, etc.)
et les références de base sont des données d’entrée clés pour la mise en œuvre du plan de
projet.
.2 Informations détaillées. Les informations détaillées sont décrites à la section 4.1.3.2.
.3 Règles d’organisation. Les règles d’organisation sont décrites à la section 4.1.1.3. Toute orga-
nisation impliquée dans le projet peut avoir des règles officielles et officieuses pouvant avoir
un impact sur la mise en œuvre du plan de projet.
.4 Action préventive. Tout ce qui diminue les conséquences des risques sur le projet.
.5 Action corrective. Toute action visant à réaligner toute performance future sur le plan de
projet. Une action corrective est une donnée de sortie des divers processus de contrôle ; ici,
en tant que donnée d’entrée, elle ferme la boucle de retour des informations nécessaires à une
gestion efficace du projet.

4.2.2 Outils et méthodes de mise en œuvre du plan de projet


.1 Compétences en gestion. Les compétences en gestion, telles que l’aptitude à diriger, la com-
munication et la négociation, sont essentielles à une mise en œuvre efficace du plan de projet.
Ces compétences sont décrites à la section 2.4.
.2 Connaissance du produit et compétences requises. L’équipe de projet doit posséder une
connaissance du produit et les compétences requises adéquates. Ces compétences requises
sont définies comme faisant partie de la planification (surtout de la planification des ressources,
section 7.1) ; elles sont fournies au cours du processus d’obtention des ressources humaines
(décrit à la section 9.2).

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
46 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 4 — Gestion de l’intégration du projet

.3 Système d’autorisation de travail. Procédure formelle par laquelle on approuve le travail, afin
qu’il soit exécuté au bon moment et dans le bon ordre. Habituellement, le mécanisme principal
est une autorisation écrite de début d’une activité ou d’un lot de travail spécifique.
La conception d’un système d’autorisation de travail doit arriver à une adéquation entre la
valeur du contrôle fourni et le coût de ce contrôle. Par exemple, dans de nombreux petits pro-
jets, une autorisation verbale est suffisante.
.4 Réunions de revue de projet. Réunions programmées régulièrement pour échanger des infor-
mations sur le projet. Dans la plupart des projets, ces réunions ont lieu à divers intervalles et à
des niveaux différents (par exemple, l’équipe de gestion de projet peut se réunir seule toutes
les semaines, et tous les mois avec le client).
.5 Système d’information de gestion de projet. Ce système (PMIS en anglais) est décrit à la sec-
tion 4.1.2.3.
.6 Procédures organisationnelles. Toute organisation impliquée dans le projet peut avoir des pro-
cédures officielles et officieuses, utiles au cours de la mise en œuvre du plan de projet.

4.2.3 Données de sortie de la mise en œuvre du plan de projet


.1 Travail réalisé. Le travail réalisé est le résultat des activités effectuées au cours de la mise en
œuvre du projet. Les informations relatives au travail réalisé (quels sont les produits livrables
qui ont été achevés et ceux qui ne le sont pas, dans quelle mesure les normes de qualité sont-
elles respectées, quels coûts ont été encourus ou engagés, etc.) sont rassemblées en tant qu’élé-
ments de la mise en œuvre du plan de projet et alimentent le rapport d’avancement (voir la
section 10.3 qui traite plus en détail des rapports d’avancement). Il faut noter que, bien que les
résultats soient fréquemment des produits livrables tangibles, tels que des immeubles, des
routes etc., ils sont aussi souvent intangibles, tels que des personnes qualifiées pouvant effi-
cacement utiliser leurs qualifications.
.2 Demandes de changements. Les demandes de changements (par exemple, pour augmenter ou
réduire le contenu du projet, pour modifier les coûts [budget] ou les estimations de délais
[dates, etc.]) sont souvent identifiées au cours de la réalisation du projet.

4.3 CONTRÔLE INTÉGRÉ DES CHANGEMENTS


Le contrôle intégré des changements consiste à : a) influencer les facteurs entraînant des chan-
gements pour s’assurer qu’ils seront acceptés, b) déterminer si un changement a eu lieu et c)
gérer les changements au fur et à mesure qu’ils ont lieu. Le contenu initial du projet et la réfé-
rence intégrée des performances doivent être maintenus, en gérant les changements apportés
à la référence de base de façon continue (soit en rejetant les nouveaux changements, soit en
les acceptant et en les incorporant dans une référence révisée). Le contrôle intégré des chan-
gements implique :
■ de conserver l’intégrité des références de mesure des performances ;
■ de s’assurer que les changements apportés au contenu du produit sont bien reportés dans
la définition du contenu du projet. (L’introduction du chapitre 5 traite de la différence entre
le contenu du produit et le contenu du projet.)
■ de coordonner les changements dans les divers domaines, comme illustré à la figure 4-2.
Par exemple, une demande de changement des délais va souvent affecter les coûts, les
risques, la qualité et les ressources humaines.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
47
Capítulo 4 — Gestión de la Integración del Proyecto

4.3.1 | 4.3.3.3

Figure 4-2 Coordination des changements sur l’ensemble du projet

4.3.1 Données d’entrée du contrôle intégré des changements


.1 Plan de projet. Le plan de projet fournit la référence par rapport à laquelle le contrôle des
changements sera effectué (voir la section 4.1.3.1).
.2 Rapports d’avancement. Les rapports d’avancement (décrits à la section 10.3) donnent des
informations sur les performances du projet. Ils peuvent aussi attirer l’attention de l’équipe de
projet sur des sujets pouvant à l’avenir poser problème.
.3 Demandes de changements. Les demandes de changements peuvent apparaître sous de nom-
breuses formes : orales ou écrites, directes ou indirectes, externes ou internes, et obligatoires
légalement ou facultatives.

4.3.2 Outils et méthodes du contrôle intégré des changements


.1 Système de contrôle des changements. Un système de contrôle des changements est un
ensemble de procédures officielles et documentées qui définissent comment les performances
du projet seront suivies et évaluées ; il comporte les dispositions selon lesquelles les documents
officiels du projet peuvent être modifiés. Il comprend les documents, les systèmes de suivi, les
processus et les niveaux d’approbation nécessaires à l’autorisation des changements.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
48 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 4 — Gestion de l’intégration du projet

Dans de nombreux cas, l’entreprise maîtresse d’œuvre dispose d’un système de contrôle
des changements qui peut être adopté « tel quel », et être utilisé dans le projet. Toutefois, si
aucun système adéquat n’est disponible, l’équipe de gestion de projet devra en élaborer un
dans le cadre du projet.
De nombreux systèmes de contrôle des changements comportent un groupe dont la res-
ponsabilité est d’approuver ou de rejeter les changements proposés. Les rôles et les respon-
sabilités de ces groupes sont clairement définis dans le système de contrôle des changements
et sont acceptés par tous les acteurs majeurs. Les organisations varient selon la définition du
comité ; on rencontre néanmoins communément des comités de contrôle de la configuration
(CCB en anglais), des comités de revue en ingénierie (ERB en anglais), des comités de suivi
technique (TRB en anglais), des commissions d’évaluation technique (TAB en anglais) et bien
d’autres types. Le système de contrôle des changements doit aussi comporter des procédures
de mise en œuvre des changements pouvant être approuvés sans évaluation préalable, par
exemple, en cas d’urgence. Habituellement, un système de contrôle des changements per-
mettra d’approuver « automatiquement » des catégories précises de changements. Ces derniers
doivent tout de même être répertoriés et documentés, afin que l’évolution de la référence
puisse être documentée.
.2 Gestion de la configuration. Toute procédure documentée, utilisée dans l’orientation et la sur-
veillance à la fois technique et administrative afin :
■ d’identifier et de documenter les caractéristiques fonctionnelles et physiques d’un élément
ou d’un système ;
■ de contrôler tout changement apporté à de telles caractéristiques ;
■ d’enregistrer et de rendre compte de ces changements et de l’état de leur application ;
■ de faire des audits des éléments et du système afin de vérifier qu’ils sont conformes aux
besoins.
Dans de nombreux domaines d’application, la gestion de la configuration est un sous-
ensemble du système de contrôle des changements utilisé pour s’assurer que la description du
produit du projet est correcte et complète. Dans d’autres domaines, le contrôle des change-
ments fait référence à tout effort systématique visant à gérer les changements du projet.
.3 Mesure des performances. Les méthodes de mesure des performances, telles que la VA (valeur
acquise, décrite à la section 10.3.2.4) permettent d’évaluer si les écarts par rapport au plan
nécessitent une action corrective.
.4 Planification complémentaire. Les projets se déroulent rarement selon le plan. Les changements
éventuels peuvent nécessiter de réviser ou de recommencer l’estimation des coûts, de modi-
fier la séquence des activités, les délais, les besoins en ressources, l’analyse des diverses
réponses aux risques ou, également, d’apporter d’autres ajustements au plan de projet.
.5 Système d’information de gestion de projet. Ce système (PMIS en anglais) est décrit à la sec-
tion 4.1.2.3.

4.3.3 Données de sortie du contrôle intégré des changements


.1 Mises à jour du plan de projet. Il s’agit de toutes les modifications apportées au contenu du
plan de projet ou aux pièces jointes (décrites respectivement aux sections 4.1.3.1 et 4.1.3.2). Le
cas échéant, il faut en avertir les acteurs concernés.
.2 Action corrective. Les actions correctives sont décrites à la section 4.2.1.5.
.3 Leçons retenues. La cause des écarts, la justification du choix de l’action corrective, ainsi que
les autres types de leçons retenues doivent être documentés et intégrés à la base de données
d’historique du projet et des autres projets de l’entreprise maîtresse d’œuvre. Cette base de
données est également le point de départ de la gestion du capital intellectuel.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
49
Chapitre 5

Gestion du contenu du projet

La gestion du contenu du projet comprend les processus nécessaires pour s’assurer que le
projet contient toutes les activités nécessaires à sa réalisation, et uniquement celles-ci, de
manière à s’assurer de sa réussite (1). Ceci implique principalement de définir et de contrôler
ce qui fait ou non partie du projet. La figure 5-1 offre une vue d’ensemble des principaux pro-
cessus de gestion du contenu du projet :
5.1 Démarrage : adopter officiellement le projet ou une phase.
5.2 Planification du contenu : élaborer par écrit un cahier des charges qui servira de réfé-
rence pour les décisions ultérieures.
5.3 Définition du contenu : décomposer les principaux produits livrables du projet en élé-
ments plus petits et plus faciles à gérer.
5.4 Vérification du contenu : officialiser l’acceptation du contenu du projet.
5.5 Contrôle des changements du contenu : contrôler les modifications apportées au
contenu du projet.
Ces processus interagissent entre eux et avec les processus d’autres disciplines. Chaque pro-
cessus peut nécessiter la participation d’une ou plusieurs personnes ou d’un ou plusieurs
groupes, selon les besoins du projet. Habituellement, tous les processus sont exécutés au
moins une fois au cours de chaque phase du projet.
Bien que les processus soient présentés ici comme des éléments distincts avec des inter-
faces bien définies, ils peuvent dans la pratique se chevaucher et interagir d’une manière non
détaillée dans ce chapitre. Les interactions entre processus sont décrites au chapitre 3.
Dans le contexte d’un projet, le terme contenu peut désigner :
■ les spécifications d’un produit : les caractéristiques et les fonctions d’un produit ou d’un ser-
vice ;
■ le contenu d’un projet : le travail qui doit être réalisé pour livrer un produit selon les carac-
téristiques et fonctions définies.
Les processus, outils et méthodes utilisés pour gérer le contenu du projet sont le sujet de
ce chapitre. Ceux utilisés pour gérer les spécifications du produit varient selon le domaine
d’application et sont habituellement définis dans le cadre du cycle de vie du projet (le cycle de
vie du projet est traité à la section 2.1).
Un projet aboutit généralement à un produit unique, mais ce produit peut comporter des
composants annexes, lesquels comportent leurs propres spécifications de produit, distinctes
bien qu’interdépendantes. Par exemple, un nouveau système téléphonique comportera géné-
ralement quatre composants annexes, le matériel, les logiciels, la formation et la mise en
œuvre.
La réalisation du contenu du projet se mesure par rapport au plan de projet, et la réalisa-
tion des spécifications du produit, par rapport aux besoins exprimés pour ce produit. La ges-
tion de ces deux types de contenus doit être convenablement intégrée pour garantir que le
travail accompli dans le cadre du projet aboutit à la livraison du produit spécifié.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA 51
Chapitre 5 — Gestion du contenu du projet

Figure 5–1 | 5.1.1.1|

Figure 5-1 Vue d’ensemble de la gestion du contenu

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
52 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 5 — Gestion du contenu du projet

5.1 DÉMARRAGE
Le démarrage est le processus par lequel on lance officiellement un nouveau projet ou qui
autorise officiellement, dans un projet, le passage à la phase suivante (voir la section 2.1 pour
plus de détails sur les phases de projet). Ce démarrage officiel relie le projet aux activités opé-
rationnelles de l’entreprise maîtresse d’œuvre. Dans certaines organisations, un projet ne
démarre officiellement qu’après l’achèvement d’une évaluation des besoins, d’une étude de fai-
sabilité, d’un plan préliminaire ou d’une autre forme d’analyse, elle-même entreprise séparé-
ment. Certains types de projets, notamment les projets internes et le développement de
nouveaux produits, commencent sans autorisation officielle et seules quelques actions limitées
sont menées pour obtenir les approbations nécessaires à un démarrage officiel. Les projets sont
habituellement adoptés officiellement suite à un ou plusieurs des faits suivants :
■ une demande du marché (par exemple, un constructeur automobile adopte un projet de
construction de voitures consommant moins, en réponse à une pénurie de carburant) ;
■ un besoin commercial (par exemple, une société de formation adopte un projet de création
d’un nouveau cours pour augmenter ses revenus) ;
■ une demande de la clientèle (par exemple, une compagnie d’électricité adopte le projet de
construction d’une nouvelle sous-station électrique qui desservira une nouvelle zone indus-
trielle) ;
■ une avancée technologique (par exemple, une société d’électronique adopte un nouveau
projet de développement d’un jeu vidéo, rendu possible par les progrès accomplis en
matière de mémoire informatique) ;
■ une exigence juridique (par exemple, un fabricant de peintures adopte un nouveau projet
pour l’élaboration de directives concernant la manipulation de produits toxiques) ;
■ un besoin d’ordre social (par exemple, un organisme privé travaillant dans un pays en voie
de développement adopte un nouveau projet pour desservir en eau potable et en sanitaires
des communautés à faibles revenus et touchées par un taux de choléra élevé, et pour les
éduquer en matière d’hygiène publique).
Ces stimuli peuvent également s’appeler des problèmes, des circonstances favorables ou
des nécessités commerciales. Le point commun à tous ces termes est que la direction doit en
général prendre une décision quant aux réponses à donner à ces stimuli.

5.1.1 Données d’entrée du démarrage


.1 Description du produit. La description du produit documente les caractéristiques du produit
ou du service, pour la création duquel le projet a été entrepris. Les caractéristiques du pro-
duit étant élaborées de façon progressive, cette description contiendra en général moins de
détails dans les premières phases du projet et plus de détails dans celles qui suivent.
La description du produit devrait aussi documenter la relation entre le produit ou service
en cours de création et le besoin commercial ou autre stimulus ayant donné naissance au projet
(voir la liste à la section 5.1). Même si le fond et la forme de la description du produit varient,
celle-ci doit toujours être suffisamment détaillée pour permettre la planification de la suite du
projet.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
53
Chapitre 5 — Gestion du contenu du projet

De nombreux projets impliquent une organisation (le vendeur) réalisant le travail en vertu
5.1.1.2 | 5.2.1.4

d’un contrat pour le compte d’une autre organisation (l’acheteur). Dans de telles circonstances,
la description d’origine du produit est habituellement fournie par l’acheteur.
.2 Plan stratégique. Tous les projets doivent correspondre aux objectifs stratégiques de l’orga-
nisation maîtresse d’œuvre ; le plan stratégique de l’organisation maîtresse d’œuvre doit tou-
jours être pris en compte dans la décision de la sélection de projets.
.3 Critères de sélection de projet. Les critères de sélection de projet sont habituellement définis
en termes d’avantages du produit faisant l’objet du projet et peuvent s’étendre à tous les pro-
blèmes de gestion possibles (rendement financier, part de marché, perception du public, etc.).
.4 Données historiques. L’historique des résultats des décisions de sélection des projets antérieurs
ainsi que de celles concernant les performances de ces projets doit être pris en compte s’il est
disponible. Lorsque le démarrage concerne l’acceptation d’une nouvelle phase d’un projet, les
informations concernant les résultats des phases précédentes sont souvent essentielles.

5.1.2 Outils et méthodes de démarrage


.1 Méthodes de sélection de projet. Les méthodes de sélection de projet consistent à évaluer la
valeur et l’attrait de ce dernier pour son propriétaire. Ces méthodes de sélection consistent à
envisager un critère de décision (les critères multiples, s’ils sont utilisés, doivent être regroupés
dans une fonction de valeur unique), ainsi qu’un mode de calcul de la valeur tenant compte
des incertitudes existantes. Ceux-ci sont appelés modèle décisionnel et méthode de calcul. La
sélection de projet s’applique également au choix des différentes modalités d’exécution de
celui-ci. Des outils d’optimisation peuvent être utilisés pour rechercher la meilleure combi-
naison de variables en matière de décisions. Les méthodes de sélection de projet font géné-
ralement partie de l’une des deux grandes catégories suivantes (2) :
■ méthodes d’évaluation du profit : approches comparatives, modèles d’évaluation par score,
avantages apportés ou modèles économiques ;
■ méthodes d’optimisation sous contrainte : modèles mathématiques utilisant des algorithmes
de programmation linéaires, non linéaires, dynamiques, intégraux et multi-objectifs.
Ces méthodes sont souvent désignées par le terme modèles décisionnels. Ces modèles déci-
sionnels comprennent des techniques très répandues (arbres de décision, choix forcé, entre
autres), ainsi que des techniques spécialisées (processus d’analyse hiérarchique, analyse du
cadre logique, entre autres). L’utilisation de critères complexes de sélection de projet dans un
modèle sophistiqué est souvent considérée comme une phase séparée du projet.
.2 Avis d’experts. L’avis d’experts s’avère souvent nécessaire au cours de l’évaluation des don-
nées d’entrée de ce processus. Cette expertise peut être apportée par un groupe ou une per-
sonne possédant des connaissances particulières ou une formation spécifique ; on peut
l’obtenir à partir de plusieurs sources, telles que :
■ d’autres services de l’organisation maîtresse d’œuvre ;
■ des consultants ;
■ des acteurs, clients compris ;
■ des associations professionnelles et techniques ;
■ des groupements industriels.

5.1.3 Données de sortie du démarrage


.1 Charte du projet. Une charte de projet est un document autorisant officiellement l’existence
d’un projet. Elle doit comporter, soit directement, soit par référence à d’autres documents :
■ le besoin commercial pour lequel le projet a été entrepris ;
■ la description du produit (décrite à la section 5.1.1.1).
La charte du projet doit être émise par un responsable extérieur au projet et situé à un
niveau hiérarchique adéquat quant aux besoins du projet. Elle confère au chef de projet l’au-
torité d’utiliser les ressources de l’organisation pour les activités du projet.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
54 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 5 — Gestion du contenu du projet

Lorsqu’un projet est réalisé sous contrat, le contrat signé fait en général office de charte du
projet pour le vendeur.
.2 Identification/désignation d’un chef de projet. De manière générale, le chef de projet doit
être identifié et désigné le plus tôt possible, toujours avant la mise en œuvre du plan de
projet (décrite à la section 4.2), et de préférence au tout début de la planification du projet
(les processus de planification du projet sont décrits à la section 3.3.2).
.3 Contraintes. Les contraintes sont des facteurs limitant les options de l’équipe de gestion de
projet. Par exemple, un budget prédéfini est une contrainte qui très probablement limitera les
options de l’équipe quant au contenu, aux ressources humaines et au planning.
Lorsqu’un projet est réalisé sous contrat, les dispositions contractuelles sont généralement
des contraintes. Un autre exemple est la nécessité d’avoir un produit viable des points de vue
social, économique et environnemental, ce qui se répercutera également sur le contenu, les
ressources humaines et les délais de réalisation du projet.
.4 Hypothèses. Voir la section 4.1.1.5.

5.2 PLANIFICATION DU CONTENU


La planification du contenu est le processus par lequel on élabore et on documente progres-
sivement le travail à réaliser dans le cadre du projet (contenu du projet) et qui aura pour
résultat le produit du projet. La planification du contenu du projet commence par les données
d’entrée de départ de la description du produit, la charte du projet et la définition initiale des
contraintes et des hypothèses. Il est à noter que la description du produit contient les spécifi-
cations du produit, lesquelles reflètent les besoins du client tels que convenus, ainsi que la
conception du produit en conformité avec ses spécifications. Les données de sortie de la pla-
nification du contenu sont le cahier des charges et le plan de gestion du contenu, avec les
informations détaillées correspondantes. Le cahier des charges constitue la base de l’accord
entre le projet et le client du projet, car il identifie à la fois les objectifs et les produits livrables
du projet. Les équipes de projet élaborent de nombreux cahiers des charges selon le niveau de
décomposition du travail.

5.2.1 Outils et méthodes de planification du contenu


.1 Description du produit. Voir la section 5.1.1.1.
.2 Charte du projet. Voir la section 5.1.3.1.
.3 Contraintes. Voir la section 5.1.3.3.
.4 Hypothèses. Voir la section 4.1.1.5.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
55
Chapitre 5 — Gestion du contenu du projet

5.2.2 | 5.3.2.1
5.2.2 Outils et méthodes de planification du contenu
.1 Analyse du produit. L’analyse du produit consiste à développer une connaissance plus appro-
fondie du produit du projet. Elle comprend des méthodes telles que l’analyse de la décom-
position du produit, les études de systèmes, l’ingénierie et l’analyse de la valeur, l’analyse
fonctionnelle et le déploiement fonctionnel de la qualité.
.2 Analyse coût/bénéfice. L’analyse coût/bénéfice consiste à estimer les coûts tangibles et intan-
gibles (dépenses) et les bénéfices des différentes variantes du projet et du produit, puis à uti-
liser des techniques financières, telles que le retour sur investissement ou la période de
récupération (« payback period » en anglais), pour évaluer l’intérêt relatif des différentes
variantes étudiées.
.3 Identification des variantes. Il s’agit d’un terme global désignant les techniques utilisées pour
définir les différentes approches possibles d’un projet. On utilise ici toute une série de tech-
niques de gestion générale, les plus courantes étant le remue-méninges et le raisonnement
parallèle.
.4 Avis d’experts. Les avis d’experts sont développés à la section 5.1.2.2.

5.2.3 Données de sortie de la planification du contenu


.1 Cahier des charges. Le cahier des charges constitue une base de référence écrite pour la prise
de décisions futures et pour la confirmation ou le développement d’une compréhension com-
mune du contenu du projet entre les acteurs. Au fur et à mesure de l’avancement du projet,
il devient nécessaire de réviser ou de préciser le cahier des charges pour y incorporer les modi-
fications approuvées. Le cahier des charges doit comprendre, soit directement, soit par réfé-
rence à d’autres documents :
■ la justification du projet : le besoin commercial ayant donné naissance au projet. La justi-
fication du projet constitue la base d’évaluation des compromis ultérieurs.
■ le produit issu du projet : un résumé succinct de la description du produit (la description
du produit est traitée à la section 5.1.1.1).
■ les produits livrables du projet : liste résumant les sous-ensembles dont la livraison com-
plète et satisfaisante marquera l’achèvement du projet. Par exemple, les principaux produits
livrables du projet de développement d’un logiciel peuvent comporter le code exécutable,
un manuel d’utilisation et un didacticiel interactif. Lorsqu’elles sont connues, les exclusions
doivent être précisées ; en règle générale, tout ce qui n’est pas explicitement inclus est
implicitement exclu.
■ les objectifs du projet : critères quantifiables devant être satisfaits pour réussir le projet. Les
objectifs du projet doivent inclure au moins les coûts, les délais et les indicateurs de qua-
lité. Les objectifs du projet doivent comporter un attribut (par exemple, le coût), une unité
de mesure (par exemple, l’euro) et une valeur absolue ou relative (par exemple, moins de
1,5 million). Les objectifs non quantifiés (par exemple, « satisfaction du client ») signifient
un risque plus important quant à la réussite du projet.
.2 Informations détaillées. Le cas échéant, les informations détaillées associées au cahier des
charges doivent être documentées et organisées de manière à faciliter leur utilisation par les
autres processus de gestion du projet. Elles doivent toujours définir toutes les contraintes et
hypothèses identifiées. Le volume des informations détaillées varie suivant le champ d’appli-
cation.
.3 Plan de gestion du contenu. Ce document décrit les modalités de gestion du projet et d’intégra-
tion des changements de contenu au projet. Il doit également comporter une évaluation de la sta-
bilité attendue du contenu du projet (c’est-à-dire, sa propension à être modifié, avec quelle
fréquence et dans quelle mesure). Le plan de gestion du contenu doit également décrire claire-
ment les modalités d’identification et de classement des modifications du contenu. (Ceci est par-
ticulièrement difficile, et par conséquent absolument essentiel, lorsque les caractéristiques du
produit sont en cours d’élaboration.)

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
56 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 5 — Gestion du contenu du projet

Selon les besoins du projet, le plan de gestion du contenu peut être formel ou non, très
détaillé ou formulé dans ses grandes lignes. C’est un élément annexe au plan de projet (décrit
à la section 4.1.3.1).

5.3 DÉFINITION DU CONTENU


La définition du contenu implique la décomposition des principaux produits livrables du projet
(tels que précisés dans l’énoncé du contenu selon sa définition à la section 5.2.3.1) en éléments
plus petits et plus faciles à gérer, pour :
■ améliorer la précision de l’estimation des coûts, des durées et des ressources ;
■ définir une référence de base pour mesurer et contrôler les performances ;
■ faciliter l’attribution claire des responsabilités.
Une bonne définition du contenu est essentielle à la réussite du projet. « Lorsque le contenu
est mal défini, on peut s’attendre à des coûts plus élevés, des modifications inévitables venant
perturber le rythme du projet, entraîner des reprises, allonger les délais, diminuer la productivité
et saper le moral du personnel » (3).

Données d'entrée Outils et méthodes Données de sortie


.1 Cahier des charges .1 Modèles d'organigramme .1 Organigramme des
.2 Contraintes des tâches tâches
.3 Hypothèses .2 Décomposition .2 Mises à jour du cahier
.4 Autres données de sortie des charges
de la planification
.5 Données historiques

5.3.1 Données d’entrée de la définition du contenu


.1 Cahier des charges. Le cahier des charges est décrit à la section 5.2.3.1.
.2 Contraintes. Les contraintes sont décrites à la section 5.1.3.3. Lorsqu’un projet est réalisé sous
contrat, les contraintes fixées par les dispositions contractuelles sont souvent un facteur impor-
tant à prendre en compte lors de la définition du contenu.
.3 Hypothèses. Voir la section 4.1.1.5.
.4 Autres données de sortie de la planification. Les données de sortie d’autres disciplines doivent
être prises en compte afin de déterminer leur impact éventuel sur la définition du contenu du
projet.
.5 Données historiques. L’historique des projets antérieurs doit être pris en compte dans la défi-
nition du contenu. Les informations concernant les erreurs et les omissions dans les projets pré-
cédents sont particulièrement utiles.

5.3.2 Outils et méthodes de la définition du contenu


.1 Modèles d’organigramme des tâches. Un organigramme des tâches ou OT (décrit à la section
5.3.3.1) issu d’un projet antérieur peut souvent servir de modèle à un nouveau projet. Chaque
projet est unique, mais la plupart se ressemblant plus ou moins, les OT peuvent donc être
«réutilisés ». Par exemple, les projets d’une entreprise donnée auront des cycles de vie iden-
tiques ou semblables, et par conséquent, des produits livrables identiques ou similaires pour
chaque phase.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
57
Chapitre 5 — Gestion du contenu du projet

Figure 5–2 | 5.3.3.1

Figure 5-2 Exemple d’organigramme des tâches pour du matériel de défense

De nombreux champs d’application ou organisations maîtresses d’œuvre possèdent des OT


standard ou plus ou moins standard, pouvant servir de modèles. Par exemple, le ministère de
la défense américaine dispose d’OT standard recommandés pour le matériel de défense (MIL-
HDBK- 881). Un extrait d’un de ces modèles est donné à la figure 5-2.
.2 Décomposition. La décomposition consiste à découper les principaux produits livrables ou
sous-produits livrables du projet en éléments plus petits et faciles à gérer, jusqu’à les détailler
suffisamment pour permettre une bonne définition de toutes les activités du projet (planifica-
tion, réalisation, contrôle et clôture). La décomposition comprend les étapes principales sui-
vantes :
(1) identifier les principaux produits livrables du projet, gestion du projet incluse. Les prin-
cipaux produits livrables devraient toujours être définis en termes de l’organisation réelle du
projet. Par exemple :
■ les phases du cycle de vie du projet peuvent servir de premier niveau de décomposition,
les produits livrables du projet étant répétés au second niveau, comme illustré à la figure
5-3.
■ les principes d’organisation peuvent varier dans chaque branche de l’OT, comme illustré
à la figure 5-4.
(2) décider si une estimation adéquate des coûts et des durées peut être effectuée à ce
niveau de détail pour chaque produit livrable. Le sens du terme adéquat peut évoluer au cours
du projet ; la décomposition d’un produit livrable, devant être réalisée beaucoup plus tard, peut
s’avérer impossible. Pour chaque produit livrable, on passera à l’étape 4 si l’obtention de détails
adéquats est possible, sinon on passera à l’étape 3. Des produits livrables différents peuvent
donc avoir des niveaux de découpage divers.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
58 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 5 — Gestion du contenu du projet

Figure 5-3 Exemple d’organigramme des tâches organisé par phases

(3) identifier les éléments constituant le produit livrable. Ceux-ci devraient être décrits en
termes de résultats tangibles et vérifiables pour faciliter la mesure des performances. Comme
pour les éléments principaux, les éléments constitutifs doivent être définis en termes de l’or-
ganisation réelle du projet et de l’accomplissement des activités. Les résultats tangibles et véri-
fiables peuvent inclure des services ou des produits (par exemple, le rapport d’avancement
peut être décrit dans les rapports d’avancement hebdomadaires ; pour un élément fabriqué, les
éléments constitutifs peuvent comprendre divers composants distincts plus l’assemblage final).
On répétera l’étape 2 pour chaque élément constitutif.
(4) vérifier l’adéquation de la décomposition :
■ les éléments du niveau inférieur sont-ils nécessaires et suffisants pour permettre de réaliser
l’élément décomposé ? Dans la négative, les éléments constitutifs doivent être modifiés
(ajoutés, supprimés ou redéfinis).
■ chaque élément est-il clairement et totalement défini ? Dans la négative, les descriptions
doivent être revues ou complétées.
■ chaque élément peut-il être convenablement programmé ? Budgété ? Affecté à une unité
précise de l’organisation (par exemple, service, équipe ou personne) acceptant la respon-
sabilité de mener à bien sa réalisation ? Dans la négative, des modifications sont nécessaires
pour permettre aux responsables d’exercer un contrôle adéquat.

5.3.3 Données de sortie de la définition du contenu


.1 Organigramme des tâches. Un OT est un regroupement orienté produits livrables des élé-
ments d’un projet, qui organise et définit le contenu total du projet ; les tâches ne figurant pas

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
59
Chapitre 5 — Gestion du contenu du projet

Figure 5–4 | 5.4

Figure 5-4 Exemple d’un organigramme des tâches pour une usine de traitement des eaux usées

sur l’OT se situent en dehors du contenu du projet. Comme le cahier des charges, l’OT est sou-
vent utilisé pour développer ou confirmer une compréhension commune du contenu du projet.
Chaque niveau décroissant représente une description de plus en plus détaillée des produits
livrables du projet. La section 5.3.2.2 décrit l’approche la plus couramment adoptée pour l’éla-
boration d’un OT. Celui-ci se présente habituellement sous forme de graphique, comme illustré
aux figures 5-2, 5-3 et 5-4. On ne doit cependant pas confondre l’OT avec son mode de pré-
sentation : le tracé sous forme de graphique d’une liste d’activités non structurée ne constitue
pas un OT.
En général, on attribue un identifiant unique à chaque élément de l’OT ; ces identifiants
peuvent fournir une structure pour le regroupement hiérarchique des coûts et des ressources.
Les éléments au niveau le plus bas de l’OT peuvent être désignés comme lots de travaux, sur-
tout dans le cas d’organisations pratiquant la gestion de la valeur acquise. Ces lots de travaux
peuvent à leur tour être décomposés pour créer une structure de découpage de sous-projets.
En général, on utilise ce type d’approche lorsque le chef de projet affecte certains travaux à
une autre organisation qui doit les planifier et les gérer à un niveau plus détaillé que celui

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
60 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 5 — Gestion du contenu du projet

adopté par le chef de projet dans le projet principal. Ces lots de travaux peuvent être décom-
posés à leur tour dans le plan et le planning du projet, comme décrit aux sections 5.3.2.2 et
6.1.2.1.
Les descriptions des activités élémentaires sont souvent regroupées dans un dictionnaire
de l’OT. En général, celui-ci comprend la description des lots de travaux, ainsi que d’autres
informations relatives à la planification, telles que les dates prévues, les coûts budgétés et
l’affectation du personnel.
On ne doit pas confondre l’OT avec d’autres structures « de décomposition » servant à pré-
senter les informations relatives au projet. Les autres structures couramment utilisées dans cer-
tains domaines d’application comprennent :
■ l’OT contractuel (CWBS en anglais), qui est utilisé pour définir le niveau de compte rendu
que le vendeur fournira à l’acheteur. En général, il inclut moins de détails que l’OT utilisé
par le vendeur pour gérer son travail ;
■ l’organigramme fonctionnel (OF), qui est utilisé pour identifier l’attribution de responsabi-
lités aux services fonctionnels concernant les divers lots de travaux ;
■ l’organigramme des ressources, qui est une variante de l’OF et que l’on utilise habituelle-
ment lorsque les lots de travaux sont affectés à des individus ;
■ la nomenclature, qui donne une vue hiérarchique des assemblages, des sous-assemblages
et des composants physiques nécessaires à la fabrication du produit fini ;
■ l’organigramme du projet (PBS en anglais), qui peut être défini comme un OT bien fait.
Le terme PBS est très utilisé dans les domaines d’application où l’on emploie le terme OT,
à tort, pour désigner la nomenclature.
.2 Mises à jour du cahier des charges. Elles incluent toutes les modifications apportées au
cahier des charges (décrites à la section 5.2.3.1). Le cas échéant, il faut avertir les acteurs
concernés de ces mises à jour.

5.4 VÉRIFICATION DU CONTENU


La vérification du contenu est le processus qui permet d’obtenir l’adoption officielle du contenu
du projet par les acteurs (commanditaire, client, etc.). Elle nécessite d’examiner les produits
livrables et le travail accompli, afin de s’assurer qu’ils ont été correctement réalisés. Si l’on met
fin au projet prématurément, le processus de vérification du contenu doit établir et documenter
le niveau et le degré d’achèvement du projet. La vérification du contenu est différente du
contrôle de la qualité (décrit à la section 8.3) en ce qu’elle concerne principalement l’accep-
tation du travail réalisé, tandis que le contrôle de la qualité concerne essentiellement la confor-
mité de ce dernier. En général, ces processus sont effectués en parallèle afin que l’acceptation
et la conformité soient obtenues au même moment.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
61
Chapitre 5 — Gestion du contenu du projet

5.4.1 Données d’entrée de la vérification du contenu


5.4.1 | 5.5.3.1

.1 Travail réalisé. Le travail réalisé, c’est-à-dire l’identification des produits livrables achevés ou
partiellement réalisés, est une donnée de sortie provenant de la mise en œuvre du plan de
projet (traitée à la section 4.2).
.2 Documentation du produit. Les documents émis pour décrire les produits issus du projet doi-
vent être disponibles pour être examinés. Les termes employés pour décrire ces documents
(plans, spécifications, documentation technique, dessins, etc.) varient suivant le champ d’ap-
plication.
.3 Organigramme des tâches. L’OT aide à définir le contenu. On devrait l’utiliser pour vérifier le
travail constituant le projet (voir la section 5.3.3.1).
.4 Cahier des charges. Le cahier des charges définit le contenu avec quelques détails. Il doit être
vérifié (voir la section 5.2.3.1).
.5 Plan de projet. Le plan de projet est décrit à la section 4.1.3.1.

5.4.2 Outils et méthodes de la vérification du contenu


.1 Inspection. L’inspection comprend des activités telles que les mesures, les examens et les tests
qui permettent de déterminer si les résultats sont conformes aux spécifications. Les inspections
sont également appelées revues, revues de produit et audits ; dans certains champs d’appli-
cation, ces différents termes ont un sens particulier et plus restreint.

5.4.3 Données de sortie de la vérification du contenu


.1 Acceptation officielle. Les documents qui démontrent que le client ou le commanditaire a
accepté le produit de la phase du projet ou les principaux produits livrables doivent être pré-
parés et diffusés. Cette acceptation peut être conditionnelle, particulièrement à la fin d’une
phase.

5.5 CONTRÔLE DES CHANGEMENTS DU CONTENU


Le contrôle des changements du contenu consiste à : a) influencer les facteurs entraînant des
modifications pour s’assurer qu’elles ne seront pas contestées, b) déterminer si une modifica-
tion a eu lieu et c) gérer les modifications effectives quand et si elles ont lieu. On doit minu-
tieusement intégrer le contrôle des changements du contenu au même titre que les autres
processus de contrôle (contrôle du planning, contrôle des coûts, contrôle de la qualité et
autres, tels que traités à la section 4.3).

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
62 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 5 — Gestion du contenu du projet

5.5.1 Données d’entrée du contrôle des changements du contenu


.1 Organigramme des tâches. L’OT est décrit à la section 5.3.3.1. Il définit la référence de base
du contenu du projet.
.2 Rapports d’avancement. Les rapports d’avancement, traités à la section 10.3.3.1, fournissent
des informations sur les performances du contenu (par exemple, quels sont les produits
livrables intermédiaires achevés et ceux qui ne le sont pas encore). Les rapports d’avancement
peuvent aussi attirer l’attention de l’équipe de projet sur des questions risquant de poser pro-
blème à l’avenir.
.3 Demandes de changements. Les demandes de changements peuvent apparaître sous de nom-
breuses formes : orales ou écrites, directes ou indirectes, externes ou internes, obligatoires léga-
lement ou facultatives. Ces modifications peuvent requérir d’étendre le contenu. Elles peuvent
également permettre de le réduire. La plupart des demandes de changements ont pour origine :
■ un événement extérieur (par exemple, un changement dans les dispositions réglemen-
taires) ;
■ une erreur ou une omission dans la définition du contenu du produit (par exemple, oublier
d’inclure une fonction nécessaire dans la conception d’un système de télécommunications) ;
■ une erreur ou une omission dans la définition du contenu du projet (par exemple, l’utili-
sation d’une nomenclature à la place d’un OT) ;
■ une amélioration (par exemple, un projet d’assainissement de l’environnement est en
mesure de réduire les coûts en tirant parti d’une technologie qui n’était pas disponible lors
de la définition initiale du contenu) ;
■ la mise en œuvre d’un plan ou d’une solution de rechange pour faire face à un risque,
comme décrit à la section 11.6.3.3.
.4 Plan de gestion du contenu. Le plan de gestion du contenu est décrit à la section 5.2.3.3.

5.5.2 Outils et méthodes de contrôle des changements du contenu


.1 Système de contrôle des changements du contenu. Un système de contrôle des changements
du contenu définit les procédures permettant de modifier le contenu du projet. Il comprend
les documents, les systèmes de suivi et les niveaux d’autorisation nécessaires à l’autorisation
des modifications. Le système de contrôle des changements du contenu doit être inclus dans
le contrôle intégré des changements décrit à la section 4.3 et, en particulier, dans tous les sys-
tèmes de contrôle du contenu du produit déjà en place. Lorsque le projet est réalisé sous
contrat, le système de contrôle des changements du contenu doit aussi respecter toutes les dis-
positions contractuelles applicables.
.2 Mesure des performances. Les méthodes de mesure des performances, décrites à la section
10.3.2, permettent d’évaluer l’ampleur des écarts effectifs. Rechercher l’origine des écarts de la
référence de base et décider si ces écarts nécessitent une action corrective sont des opérations
essentielles du contrôle des changements du contenu.
.3 Planification complémentaire. Les projets se déroulent rarement selon le programme prévu. Les
changements de contenu éventuels peuvent nécessiter la révision de l’OT ou l’analyse des
variantes (voir respectivement les sections 5.3.3.1 et 5.2.2.3).

5.5.3 Données de sortie du contrôle des changements du contenu


.1 Changements du contenu. Il s’agit de toutes les modifications apportées au contenu du projet
tel que convenu et défini par l’OT approuvé. Les changements du contenu nécessitent souvent
un ajustement des coûts, des délais, de la qualité ou d’autres objectifs du projet.
Les changements du contenu sont réintroduits dans le processus de planification, les docu-
ments techniques et de planification sont mis à jour si nécessaire et les acteurs concernés sont
avertis.
.2 Action corrective. Toute action visant à réaligner sur le plan de projet les performances futures
prévues.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
63
Chapitre 5 — Gestion du contenu du projet

.3 Leçons retenues. La cause des écarts, le raisonnement utilisé pour choisir les actions correc-
5.5.3.2 | 6.1

tives, ainsi que les autres leçons retenues du contrôle des changements du contenu, doivent
être documentés pour pouvoir faire partie de la base de données historiques de ce projet ainsi
que des autres projets de l’organisation maîtresse d’œuvre.
.4 Référence de base mise à jour. Selon la nature de la modification, le document de référence
correspondant doit être corrigé et rediffusé ; avec l’incorporation de la modification approuvée,
il servira de nouvelle référence de base pour les changements à venir.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
64 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 6

Gestion des délais du projet

La gestion des délais du projet comprend les processus nécessaires à l’achèvement du projet
en temps voulu. La figure 6-1 offre une vue d’ensemble des principaux processus suivants,
tels qu’utilisés lors de l’élaboration du planning du projet :
6.1 Définition des activités : identifier les activités spécifiques devant être accomplies afin
de produire les divers produits livrables du projet.
6.2 Jalonnement des activités : identifier et documenter les dépendances entre les acti-
vités.
6.3 Estimation de la durée des activités : estimer le nombre d’unités de temps ouvré qui
seront nécessaires pour réaliser chacune des activités.
6.4 Élaboration du planning : analyser les dépendances, les durées et les besoins en res-
sources des activités en vue d’élaborer le planning du projet.
6.5 Contrôle du planning : contrôler les modifications apportées au planning du projet.
Ces processus interagissent entre eux et avec les processus d’autres disciplines. Chaque
processus peut nécessiter la participation d’une ou plusieurs personnes ou d’un ou plusieurs
groupes, selon les besoins du projet. Habituellement, tous les processus sont exécutés au
moins une fois au cours de chaque phase du projet.
Bien que les processus soient présentés ici comme des éléments distincts avec des inter-
faces bien définies, ils peuvent dans la pratique se chevaucher et interagir d’une manière non
détaillée dans ce chapitre. Les interactions entre processus sont décrites au chapitre 3.
Dans certains projets, et surtout dans les plus petits, le jalonnement des activités, l’esti-
mation de la durée des activités et l’élaboration du planning sont tellement liés qu’ils sont
considérés comme un processus unique (par exemple, ils peuvent être réalisés par une seule
personne en un temps relativement court). Ils sont présentés ici comme des processus dis-
tincts, car les outils et méthodes utilisés sont différents pour chacun d’entre eux.

6.1 DÉFINITION DES ACTIVITÉS


La définition des activités implique d’identifier et de documenter les activités spécifiques à
exécuter pour produire les produits livrables et sous-livrables identifiés dans l’organigramme
des tâches (OT). Dans ce processus, la nécessité de définir les activités du projet de telle
manière que les objectifs de celui-ci soient atteints est implicite.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
65
Chapitre 6 — Gestion des délais du projet

Chapitre 6 — Gestion des délais du projet

Figure 6–1 | 6.1.3.1

Figure 6-1 Vue d’ensemble de la gestion des délais du projet

66 Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 6 — Gestion des délais du projet

6.1.1 Données d’entrée de la définition des activités


.1 Organigramme des tâches. L’OT est la principale donnée d’entrée pour la définition des acti-
vités (voir la section 5.3.3.1 qui traite de l’OT plus en détail).
.2 Cahier des charges. La justification et les objectifs du projet inclus dans le cahier des charges
doivent être pris en compte explicitement pour la définition des activités (voir la section
5.2.3.1 qui traite du cahier des charges plus en détail).
.3 Données historiques. Il est souhaitable de tenir compte des données historiques (quelles acti-
vités ont vraiment été nécessaires lors de projets antérieurs et similaires) lors de la définition
des activités du projet.
.4 Contraintes. Les contraintes sont des facteurs limitant les options de l’équipe de gestion de
projet ; par exemple, l’utilisation de durées maximales souhaitées pour les activités.
.5 Hypothèses. Voir la section 4.1.1.5.
.6 Avis d’experts. L’utilisation de l’avis d’experts est traitée dans les sections 5.1.2.2 et 6.3.2.1.

6.1.2 Outils et méthodes de définition des activités


.1 Décomposition. Dans le contexte du processus de définition des activités, la décomposition
consiste à découper les lots de travail du projet en éléments plus petits et plus faciles à gérer
afin d’arriver à un meilleur niveau de contrôle. La méthode de décomposition est décrite avec
plus de détails à la section 5.3.2.2. La principale différence entre le découpage utilisé ici et
celui décrit dans le processus de définition du contenu est qu’ici le résultat est exprimé en
termes d’activités plutôt qu’en termes de produits livrables. L’OT et la liste des activités s’éla-
borent habituellement l’une après l’autre, l’OT formant la base de l’élaboration de la liste finale
des activités. Dans certains champs d’application, l’OT et la liste des activités sont créées
simultanément.
.2 Modèles et formulaires. Une liste d’activités (décrite à la section 6.1.3.1), ou une partie de
la liste d’activités d’un projet antérieur, peut souvent servir de modèle à un nouveau projet.
Les activités dans les modèles peuvent aussi contenir une liste des compétences des res-
sources et les charges de travail (en heures) de ces dernières, l’identification des risques, les
produits livrables prévus, etc.

6.1.3 Données de sortie de l’identification des activités


.1 Liste des activités. La liste des activités doit inclure toutes les activités à accomplir pour le
projet. Elle doit être organisée comme un complément de l’OT pour s’assurer qu’elle est com-

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
67
Chapitre 6 — Gestion des délais du projet

plète et ne comprend pas d’activités ne faisant pas partie du contenu du projet. Comme pour
6.1.3.2 | 6.2.2.1

l’OT, la liste des activités doit inclure la description de chacune des activités pour permettre
aux membres de l’équipe de projet de comprendre les modalités de réalisation des travaux.
.2 Informations détaillées. Le cas échéant, des informations détaillées concernant la liste des acti-
vités doivent être documentées et organisées de façon à en faciliter l’utilisation par d’autres
processus de la gestion de projet. Elles doivent toujours inclure les informations concernant
toutes les contraintes et hypothèses identifiées. La quantité d’informations détaillées utilisées
peut varier suivant le champ d’application.
.3 Mises à jour de l’organigramme des tâches. Lors de l’utilisation de l’OT pour la définition des
activités requises, l’équipe de projet constate qu’il manque des produits livrables ou que la
description des produits livrables nécessite une clarification ou correction. Ce type de mise
à jour doit être répercuté dans l’OT et la documentation associée, telle que l’estimation des
coûts. Ces mises à jour sont souvent appelées perfectionnements ; elles surviennent en général
lorsque le projet comporte des technologies nouvelles ou émergentes.

6.2 JALONNEMENT DES ACTIVITÉS


Le jalonnement des activités consiste à identifier et à documenter les interactions logiques
entre les activités. L’ordre dans lequel les activités seront réalisées doit être établi avec soin
pour que l’on puisse par la suite préparer un planning réaliste. Le jalonnement peut être
effectué à l’aide d’outils informatiques (par exemple, à l’aide d’un logiciel en gestion de
projet) ou manuellement. Les méthodes manuelles sont souvent plus efficaces pour les petits
projets et dans les phases initiales des grands projets lorsque l’on ne dispose que de peu de
détails. On peut aussi utiliser les deux méthodes conjointement.

6.2.1 Données d’entrée du jalonnement des activités


.1 Liste des activités. La liste des activités est décrite à la section 6.1.3.1.
.2 Description du produit. La description du produit est traitée à la section 5.1.1.1. Les caracté-
ristiques du produit ont souvent un impact sur le jalonnement des activités (par exemple, le
plan d’une usine à construire, l’interface des sous-systèmes d’un projet de développement
logiciel). Bien que cet impact soit souvent apparent dans la liste des activités, la description
du produit doit généralement être revue pour s’assurer de son exactitude.
.3 Dépendances obligatoires. Il s’agit des dépendances logiques inhérentes à la nature du travail
à effectuer. Elles incluent souvent des limites physiques. (Dans un projet de construction, il
est impossible d’ériger la superstructure avant que les fondations ne soient terminées ; dans
un projet d’électronique, on doit construire un prototype avant de pouvoir le tester.) Les
dépendances logiques obligatoires sont aussi appelées liaisons logiques fortes.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
68 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 6 — Gestion des délais du projet

Figure 6-2 Diagramme réseau du projet selon la méthode des antécédents

.4 Dépendances logiques optionnelles. Il s’agit de dépendances logiques fixées par l’équipe de


projet. Il faut les utiliser avec précaution (et bien les documenter) car elles peuvent limiter les
options futures de planification. Les dépendances logiques optionnelles sont habituellement
fixées à partir :
■ des « meilleures pratiques » concernant un champ d’application donné ;
■ de certaines particularités d’un projet pour lequel une séquence particulière est souhaitée,
même si d’autres séquences sont envisageables.
Les dépendances logiques optionnelles s’appellent également liaisons logiques préférées,
liaisons logiques privilégiées ou liaisons logiques douces.
.5 Dépendances logiques externes. Il s’agit des dépendances logiques qui relient des activités
du projet à d’autres qui n’en font pas partie. Par exemple, les tests d’un projet de logiciel peu-
vent dépendre de la livraison d’un équipement provenant d’un fournisseur extérieur, ou dans
un projet de construction, des consultations sur l’environnement doivent être menées avant
de démarrer la préparation du site.
.6 Étapes jalons. Les étapes jalons doivent faire partie du jalonnement des activités pour assurer
que les exigences concernant leur franchissement seront satisfaites.

6.2.2 Outils et méthodes de jalonnement des activités


.1 Méthode des antécédents (PDM en anglais). Méthode de représentation du projet dans
laquelle les activités sont identifiées par des cases ou des rectangles (nœuds) et sont reliées
par des flèches représentant les dépendances logiques (voir également la section 6.2.3.1). La
figure 6-2 représente un diagramme de projet simple selon la méthode PDM. Cette technique
est aussi appelée activités sur nœuds (AON en anglais) ; il s’agit de la méthode utilisée par
la plupart des logiciels de gestion de projet. La méthode PDM peut être mise en œuvre
manuellement ou sur ordinateur.
Elle comprend quatre types de liens logiques ou dépendances :
■ liaison Fin-Début : le démarrage du successeur dépend de l’achèvement de l’antécédent ;
■ liaison Fin-Fin : l’achèvement du successeur dépend de l’antécédent ;
■ liaison Début-Début : le démarrage du successeur dépend de l’antécédent ;
■ Liaison Début-Fin : l’achèvement du successeur dépend du démarrage de l’antécédent.
Dans la méthode des antécédents, la liaison Fin-Début est le type de liaison logique le plus
couramment utilisé. Les liaisons Début-Fin sont rarement utilisées et uniquement par certains
professionnels de la planification. L’utilisation des liaisons logiques Début-Début, Fin-Fin ou
Début-Fin avec des logiciels de gestion de projet peut produire des résultats inattendus, ces
types de liaisons n’ayant pas été mis en œuvre de façon cohérente.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
69
Chapitre 6 — Gestion des délais du projet

Figure 6–3 | 6.3.1.4

Figure 6-3 Diagramme réseau du projet selon la méthode du diagramme fléché

.2 Méthode du diagramme fléché (ADM en anglais). Méthode de représentation du projet dans


laquelle les activités sont identifiées par des flèches reliées entre elles par des points appelés
nœuds représentant les liaisons logiques (voir également la section 6.2.3.1). La figure 6-3
représente un diagramme réseau simple selon la méthode ADM. Cette technique est aussi
appelée activités sur flèches (AOA en anglais) et, bien qu’elle soit moins répandue que la
méthode PDM, elle reste la méthode de prédilection dans certains champs d’application. La
méthode ADM permet uniquement l’utilisation de liaisons Fin-Début ; elle peut nécessiter l’uti-
lisation d’activités fictives pour définir toutes les dépendances logiques de façon adéquate. La
méthode ADM peut être mise en œuvre manuellement ou sur ordinateur.
.3 Méthodes de représentation conditionnelle. Les méthodes de représentation telles que la tech-
nique d’évaluation et de suivi graphique ou GERT (« Graphical Evaluation and Review Tech-
nique » en anglais) et les modèles de la dynamique du système (« System Dynamics » en
anglais) permettent la modélisation d’activités qui ne se suivent pas, telles que les boucles (par
exemple, un test que l’on doit faire plusieurs fois), ou de ramifications conditionnelles (par
exemple, la mise à jour d’une tâche de conception qui n’est nécessaire que si l’inspection a
décelé des erreurs). Ni la méthode des antécédents (PDM), ni la méthode du diagramme
fléché (ADM) n’autorisent les boucles ou les ramifications conditionnelles.
.4 Diagrammes réseaux types. Des diagrammes réseaux standard peuvent être utilisés pour accé-
lérer la préparation des diagrammes réseaux de projet. Ils peuvent représenter la totalité d’un
projet ou seulement une partie de celui-ci. Une partie d’un réseau est souvent désignée par
le terme sous-réseau. Les sous-réseaux sont particulièrement utiles lorsqu’un projet comprend
plusieurs fonctions identiques ou quasiment identiques, telles que les différents étages d’un
immeuble de bureaux, les essais cliniques d’un projet pharmaceutique, les modules logiciels
d’un projet informatique ou la phase de mise en route d’un projet de développement.

6.2.3 Données de sortie du jalonnement des activités


.1 Diagrammes réseaux du projet. Les diagrammes réseaux du projet sont une représentation
schématique des activités du projet et de leurs enchaînements logiques (dépendances
logiques). Les figures 6-2 et 6-3 illustrent deux approches différentes de représentation d’un
diagramme réseau. Le diagramme réseau du projet peut être développé manuellement ou sur
ordinateur. Il peut comporter tous les détails du projet ou seulement un ou plusieurs groupes
d’activités. Le réseau doit toujours être accompagné d’une description sommaire de l’approche
de jalonnement. Toute séquence inhabituelle doit être décrite de manière détaillée.
Le diagramme réseau du projet est souvent appelé diagramme PERT (« Program Evalua-
tion and Review Technique » en anglais). À l’origine, le PERT était un type précis de dia-
gramme en réseau (voir également la section 6.4.2.1).

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
70 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 6 — Gestion des délais du projet

.2 Mises à jour de la liste des activités. Tout comme le processus de définition des activités peut
conduire à des mises à jour de l’OT, la préparation du diagramme réseau du projet peut
mettre en évidence des cas où une activité doit être fractionnée ou redéfinie afin de permettre
la représentation correcte des dépendances logiques.

6.3 ESTIMATION DE LA DURÉE DES ACTIVITÉS


L’estimation de la durée des activités est le processus menant à la définition des durées à
incorporer dans le planning à partir des informations sur le contenu du projet et ses res-
sources. Les données d’entrée de l’estimation de la durée des activités émanent habituellement
de la personne ou du groupe de l’équipe projet spécialiste du type d’activité considéré. L’es-
timation est souvent élaborée progressivement et le processus tient compte de la qualité et de
la disponibilité des données d’entrée. Par conséquent, on peut partir du principe que l’esti-
mation est de plus en plus précise, et son niveau de qualité meilleur. La personne ou le
groupe de l’équipe projet spécialiste du type d’activité envisagé doit effectuer l’estimation, ou
du moins l’approuver.
L’estimation du nombre d’unités de temps ouvré nécessaires à l’achèvement d’une activité
demande souvent que la durée calendaire soit également prise en compte. Par exemple, si
la durée de durcissement du béton est de quatre jours, il faudra compter entre deux à quatre
unités de temps ouvré : a) selon le jour de la semaine de début de l’activité et b) selon que
les week-ends sont considérés comme jours ouvrés ou non. La plupart des logiciels de pla-
nification traitent ce problème en utilisant différents calendriers contenant chacun différentes
unités de temps ouvré.
La durée totale du projet peut être également estimée à l’aide des outils et des méthodes
présentés ici, mais celle-ci est calculée de manière plus précise en tant que donnée de sortie
de l’élaboration du planning (décrite à la section 6.4). L’équipe projet peut considérer que la
durée du projet est une distribution de probabilités (si les techniques probabilistes sont uti-
lisées) ou une estimation mono valeur (si les techniques déterministes sont utilisées).

Données d'entrée Outils et méthodes Données de sortie


.1 Liste des activités .1 Avis d'expert .1 Estimation de la durée
.2 Contraintes .2 Estimation par analogie des activités
.3 Hypothèses .3 Durées sur base .2 Bases d'estimation
.4 Besoins en ressources quantitative .3 Mises à jour de la liste
.5 Disponibilités des .4 Réserve de durée des activités
ressources (contingence)
.6 Données historiques
.7 Risques identifiés

6.3.1 Données d’entrée pour l’estimation de la durée des activités


.1 Liste des activités. La liste des activités est décrite à la section 6.1.3.1.
.2 Contraintes. Les contraintes sont décrites à la section 6.1.1.4.
.3 Hypothèses. Les hypothèses sont décrites à la section 4.1.1.5. On peut citer l’exemple de la
fréquence des révisions de projet qui pourrait dicter la durée maximale des activités, par
exemple une durée au plus égale à l’intervalle entre deux révisions du projet.
.4 Besoins en ressources. Les besoins en ressources sont décrits à la section 7.1.3.1. La durée
de la plupart des activités dépend en grande partie des ressources qui leur sont affectées. Par
exemple, deux personnes travaillant ensemble peuvent terminer la conception d’un produit

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
71
Chapitre 6 — Gestion des délais du projet

6.3.1.5 | 6.4
en deux fois moins de temps que si elles travaillaient seules, tandis qu’une personne qui tra-
vaille à mi-temps sur une activité prendra en général deux fois plus de temps que si elle y tra-
vaillait à plein temps. Cependant, au fur et à mesure que l’on ajoute des ressources, on peut
rencontrer des problèmes de surcharge au niveau de la communication, ce qui diminue la
productivité et a pour résultat une réduction de la productivité proportionnelle à l’augmen-
tation des ressources.
.5 Disponibilités des ressources. La durée des activités dépend en grande partie des aptitudes
des ressources matérielles et humaines qui leur sont affectées. Par exemple, si deux membres
de l’équipe sont affectés à plein temps à une activité donnée, un spécialiste devrait norma-
lement l’achever plus rapidement qu’un débutant.
.6 Données historiques. Des données historiques concernant les durées probables de nombreux
types d’activités proviennent souvent de l’une des sources suivantes :
■ dossiers de projet : une ou plusieurs organisations impliquées dans le projet peuvent avoir
conservé des archives de projets précédents suffisamment détaillées pour servir à l’esti-
mation de la durée des activités. Dans certains champs d’application, les membres de
l’équipe de projet peuvent avoir conservé ce type d’informations ;
■ bases de données d’estimation des durées commercialisées : des données historiques sont
souvent disponibles commercialement. Ces bases de données sont particulièrement utiles
lorsque la durée des activités ne dépend pas du contenu réel du travail (par exemple,
temps de durcissement du béton, durée de réponse d’une administration à certains types
de demandes) ;
■ expérience de l’équipe de projet : les membres de l’équipe de projet peuvent se rappeler
des durées réelles ou estimées de projets précédents. Bien que de tels souvenirs soient
utiles, ils sont en général bien moins fiables que des résultats documentés.
.7 Risques identifiés. L’équipe de projet tient compte des risques identifiés (voir la section 11.2)
lorsqu’elle élabore l’estimation de la durée des activités, les risques (qu’ils constituent des
menaces ou des opportunités) pouvant avoir un impact considérable sur les durées. L’équipe
de projet tient compte de l’importance accordée à l’impact des risques dans l’estimation de la
durée de référence pour chaque activité, en prenant en compte les risques à probabilité forte
et à impact important.

6.3.2 Outils et méthodes d’estimation de la durée des activités


.1 Avis d’experts. Les avis d’experts sont décrits à la section 5.1.2.2. Les durées sont souvent dif-
ficiles à évaluer en raison du nombre de facteurs pouvant les influencer (par exemple, niveau
et productivité des ressources). La méthode à avis d’experts, appuyée par des données his-
toriques, doit être utilisée aussi souvent que possible. Si une telle expertise n’est pas dispo-
nible, les estimations sont par nature incertaines et risquées (voir le chapitre 11, « Gestion des
risques du projet »).
.2 Estimation par analogie. Également appelée estimation descendante, l’estimation par analogie
utilise la durée réelle d’une activité semblable effectuée par le passé comme base d’estimation
d’une activité future. On l’utilise fréquemment pour estimer la durée d’un projet lorsqu’il
existe peu d’informations détaillées sur celui-ci. (par exemple, dans les phases initiales). L’es-
timation par analogie est une forme d’avis d’experts (décrit à la section 6.3.2.1).
L’estimation par analogie est la plus fiable lorsque : a) les activités précédentes sont réel-
lement semblables et pas seulement en apparence et b) les individus préparant l’estimation
ont l’expérience nécessaire.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
72 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 6 — Gestion des délais du projet

.3 Durées sur base quantitative. On peut utiliser les quantités à réaliser pour chaque catégorie
spécifique de travail (c’est-à-dire le nombre de plans, les mètres de câble, les tonnes d’acier,
etc.) définies au stade de l’étude/conception, multipliées par le taux de productivité de l’unité
(c’est-à-dire le nombre d’heures par plan, de mètres de câble par heure, etc.) pour estimer
la durée des activités.
.4 Réserve de durée (contingence). Les équipes de projet peuvent choisir d’inclure une durée
supplémentaire, appelée réserve, contingence ou tampon, qui vient s’ajouter à la durée de l’ac-
tivité envisagée ou ailleurs dans le planning, pour pallier les risques le menaçant. Cette
réserve peut être un pourcentage de la durée estimée ou un nombre fixe d’unités de temps
ouvré. Cette réserve peut par la suite être réduite ou éliminée, au fur et à mesure de la dis-
ponibilité d’informations plus précises sur le projet. Ce type de réserve doit être documenté
avec les autres données et hypothèses.

6.3.3 Données de sortie de l’estimation de la durée des activités


.1 Estimation de la durée des activités. L’estimation de la durée des activités est une évaluation
quantitative du nombre probable d’unités de temps ouvré nécessaires à l’achèvement d’une
activité.
L’estimation de la durée des activités doit toujours être associée à une marge d’erreur pos-
sible. Par exemple :
■ 2 semaines ± 2 jours pour indiquer que l’activité demandera au moins huit jours mais pas
plus de douze jours (pour une semaine ouvrée de cinq jours).
■ Probabilité de 15 % de dépasser les trois semaines pour indiquer la forte probabilité, 85
pour cent, que l’activité demandera au plus trois semaines.
Le chapitre 11, « Gestion des risques du projet », développe plus en détail l’évaluation des
incertitudes.
.2 Bases d’estimation. Les hypothèses émises lors de l’élaboration des estimations doivent être
documentées.
.3 Mises à jour de la liste des activités. Les mises à jour de la liste des activités sont décrites à
la section 6.2.3.2.

6.4 ÉLABORATION DU PLANNING


Élaborer le planning signifie fixer les dates de début et de fin des activités du projet. Si ces
dates ne sont pas réalistes, il est alors peu probable que le projet sera terminé à la date
prévue. Le processus d’élaboration du planning doit être répété fréquemment (de même que
les processus dont découlent les données d’entrée, notamment pour les processus d’estima-
tion de la durée des activités et des coûts), avant d’établir le planning du projet.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
73
Chapitre 6 — Gestion des délais du projet

6.4.1 Données d’entrée pour l’élaboration du planning


6.4.1 | 6.4.2.3

.1 Diagrammes réseaux de projet. Les diagrammes réseaux de projet sont décrits à la section
6.2.3.1.
.2 Estimation de la durée des activités. L’estimation de la durée des activités est décrite à la sec-
tion 6.3.3.1.
.3 Besoins en ressources. Les besoins en ressources sont décrits à la section 6.3.1.4.
.4 Description des ressources disponibles. Pour établir le planning du projet, il faut savoir
quelles ressources seront disponibles, à quel moment et sous quelle forme. Par exemple, il
est parfois difficile de planifier des ressources partagées ou clés, leur disponibilité pouvant
varier ; le niveau de détail et de précision de la description des disponibilités des ressources
varieront également. Par exemple, pour établir le planning préliminaire d’un projet de consul-
tation, savoir que deux consultants seront disponibles sur un certain laps de temps peut suf-
fire. Par contre, le planning final du même projet identifiera les consultants disponibles.
.5 Calendriers. Les calendriers du projet et des ressources indiquent les périodes pendant les-
quelles il est possible de travailler. Les calendriers de projet affectent toutes les ressources (par
exemple, dans certains projets, le travail sera effectué uniquement pendant les heures nor-
males de travail, tandis que dans d’autres on fera les 3 x 8). Une semaine de travail de cinq
jours est un exemple d’utilisation de calendrier. Les calendriers des ressources affectent une
ressource ou une catégorie de ressources particulière (par exemple, un membre de l’équipe
peut être en vacances ou suivre une formation ; un contrat de travail peut limiter les dispo-
nibilités d’une certaine catégorie de personnel à certains jours de la semaine).
.6 Contraintes. Les contraintes sont des facteurs limitant les options de l’équipe de projet. Lors
de l’élaboration du planning, deux contraintes de temps principales doivent être prises en
compte :
■ les dates imposées : faire débuter ou terminer une activité à une date imposée peut per-
mettre d’empêcher une activité de démarrer avant une date donnée ou après une date
donnée. Bien que les quatre contraintes de date soient habituellement disponibles dans
les logiciels de gestion de projet, les contraintes « démarrer au plus tôt le » et « finir au plus
tard le » sont les plus couramment utilisées. Habituellement, on utilise les contraintes de
date dans des situations telles que : un créneau du marché pour un projet technologique,
des restrictions météorologiques pour des activités à l’extérieur, le respect de réglemen-
tations gouvernementales sur l’assainissement de l’environnement, la livraison de matériel
en provenance de parties non représentées dans le planning du projet, etc.
■ les événements clés ou jalons principaux : l’achèvement de certains produits livrables à
une date fixée peut être exigé par le commanditaire, le client ou les autres parties pre-
nantes du projet. Une fois planifiées, ces dates deviennent des dates attendues et, souvent,
ne peuvent être déplacées qu’avec beaucoup de difficulté. Les étapes jalons peuvent éga-
lement servir à indiquer les interfaces existantes avec le travail extérieur au projet. Ce tra-
vail ne figure habituellement pas dans la base de données du projet, mais les étapes jalons
associées à des contraintes de date peuvent fournir une interface de planning adéquate.
.7 Hypothèses. Se reporter à la section 4.1.1.5.
.8 Avances et retards (dépendances). Toutes les dépendances logiques pourraient impliquer l’in-
dication d’une avance ou d’un retard pour être définies avec précision. Exemple de retard :
on souhaite peut-être planifier un retard de deux semaines (décalage positif) entre une com-
mande de matériel et l’installation ou l’utilisation de celui-ci. Exemple d’avance dans une
liaison Fin-Début avec un décalage négatif de dix jours : le successeur commence dix jours
avant l’achèvement de l’antécédent.
.9 Plan de gestion des risques. Le plan de gestion des risques est développé à la section 11.1.3.
.10 Attributs des activités. Les attributs des activités, y compris la responsabilité (c’est-à-dire qui
effectuera le travail), l’emplacement géographique ou le bâtiment (où le travail doit être
effectué) et le type d’activité (d’ensemble ou détaillé), sont très importants pour permettre par

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
74 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 6 — Gestion des délais du projet

la suite aux utilisateurs de sélectionner et trier avec facilité les activités planifiées. La classifi-
cation OT est également un attribut important permettant de classer et de trier efficacement
les activités.

6.4.2 Outils et méthodes d’élaboration du planning


.1 Analyse mathématique. Il s’agit de calculer les dates théoriques de début et de fin, au plus
tôt et au plus tard, de toutes les activités du projet, sans tenir compte des limites au niveau de
l’ensemble des ressources. Les dates obtenues ne constituent pas le planning ; elles indiquent
plutôt les périodes durant lesquelles l’activité envisagée pourrait être planifiée, compte tenu
des limites de ressources et autres contraintes connues. Les techniques d’analyse mathéma-
tique les plus connues sont les suivantes :
■ méthode du chemin critique (CPM en anglais). Il s’agit de calculer de façon déterministe
une seule date de début et une seule date de fin, au plus tôt et au plus tard, pour chaque
activité en se basant sur la logique séquentielle du réseau, et sur une seule estimation de
durée pour chaque activité. La méthode CPM cherche surtout à calculer une marge afin
d’identifier les activités disposant d’une flexibilité moindre du point vue du planning. Les
algorithmes sous-jacents à cette méthode sont souvent utilisés dans d’autres types d’ana-
lyse mathématique.
■ technique d’évaluation et de suivi graphique (GERT). Il s’agit d’utiliser des probabilités
pour traiter les liaisons logiques et l’estimation de la durée des activités (c’est-à-dire que
certaines activités peuvent ne pas être réalisées du tout, d’autres peuvent l’être en partie
et d’autres encore, plus d’une fois).
■ technique d’évaluation et de suivi des projets (PERT). Il s’agit de calculer la durée des acti-
vités en utilisant une moyenne pondérée des estimations de durée. Bien qu’il existe des
différences superficielles entre la méthode CPM et la technique PERT, cette dernière dif-
fère principalement de la première parce qu’elle utilise la moyenne de la distribution
(valeur attendue) plutôt que l’estimation la plus probable utilisée initialement dans la
méthode CPM (voir la figure 6-4). De nos jours, la technique PERT est rarement utilisée.
.2 Compression des durées. La compression des durées est un cas particulier d’analyse mathé-
matique visant à réduire le délai de réalisation du projet sans en modifier le contenu (par
exemple, pour respecter des dates imposées ou d’autres objectifs de délais). La compression
des durées est réalisée à l’aide de méthodes telles que :
■ le compactage. Il s’agit d’analyser les compromis possibles au niveau des coûts et des
délais pour déterminer s’il est possible, et de quelle manière, d’obtenir le maximum de
compression de durée pour un surcoût minimum. La compression des délais n’est pas tou-
jours viable et entraîne souvent une augmentation des coûts.
■ la construction en régime accéléré. Il s’agit d’effectuer en parallèle des activités qui
devraient normalement se succéder (par exemple, commencer à développer le code d’un
projet logiciel avant d’avoir terminé la conception de ce dernier, ou commencer les fon-
dations d’une raffinerie de pétrole avant que 25 % des études ne soient achevées). La
construction en régime accéléré conduit souvent à des reprises et augmente généralement
le niveau de risques.
.3 Simulation. La simulation consiste à calculer plusieurs valeurs de la durée du projet, à l’aide
de différents jeux d’hypothèses concernant les activités. La méthode la plus courante est celle
de Monte Carlo par laquelle une distribution des résultats probables pour chaque activité est
définie, puis utilisée pour calculer une distribution des résultats probables de l’ensemble du
projet (voir également la section 11.4.2.4). En outre, on peut effectuer des analyses condi-
tionnelles (« what if »), en se servant du réseau logique pour simuler divers scénarios, comme
retarder la livraison d’un composant essentiel, allonger certains délais d’études ou incorporer
des facteurs externes (tels une grève ou un changement dans un processus d’obtention de
permis). Le résultat des simulations conditionnelles peut servir à évaluer la faisabilité des
délais en cas de circonstances défavorables et à préparer des plans de remplacement pour sur-
monter ou faire face à des situations inattendues.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
75
Chapitre 6 — Gestion des délais du projet

Figure 6–4 | 6.4.3.1

Figure 6-4 Calcul de la durée d’une seule activité à l’aide de la méthode PERT

.4 Heuristique de lissage des ressources. L’analyse mathématique conduit souvent à un planning


préliminaire avec début au plus tôt, nécessitant à certaines périodes plus de ressources que
celles disponibles ou des variations des besoins en ressources impossibles à gérer. Des heu-
ristiques, telles que « l’attribution prioritaire des ressources rares aux activités du chemin cri-
tique », peuvent être appliquées pour élaborer un planning reflétant de telles contraintes. Le
lissage des ressources conduit souvent à une durée de projet plus longue que celle envisagée
dans le planning préliminaire. Cette méthode est parfois appelée planification par les res-
sources, en particulier lorsqu’elle s’appuie sur un processus d’optimisation informatisé. La réaf-
fectation des ressources des activités non essentielles aux activités critiques est un moyen
couramment utilisé pour ramener, autant que possible, la durée du projet à sa durée totale ini-
tiale. On peut également envisager l’utilisation des heures supplémentaires, des week-ends
ou du travail en équipes pour réduire la durée des activités critiques. Augmenter la produc-
tivité en utilisant des technologies et/ou des machines différentes (par exemple soudure auto-
matique, coupe-tuyaux électriques, etc.) permet aussi de réduire des activités qui allongent la
durée du planning initial. La construction en régime accéléré, si elle est envisageable (comme
décrite à la section 6.4.2.2), est une autre méthode employée pour réduire la durée totale du
projet. Certains projets peuvent disposer d’une ressource essentielle et limitée imposant la pla-
nification à rebours de cette dernière à partir de la date de fin du projet ; c’est ce l’on appelle
la planification avec affectation à rebours des ressources. La chaîne critique est une technique
qui modifie l’échéancier du projet pour tenir compte de ressources limitées.
.5 Logiciels de gestion de projet. Les logiciels en gestion de projet sont largement utilisés pour
aider à l’élaboration des plannings. D’autres logiciels sont capables d’interagir directement ou
indirectement entre eux ou avec d’autres outils informatiques, pour satisfaire aux exigences
d’autres disciplines. Ils effectuent automatiquement le calcul de l’analyse mathématique et du

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
76 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 6 — Gestion des délais du projet

Figure 6-5 Diagramme réseau du projet avec dates

lissage des ressources ; ils permettent donc d’analyser rapidement les diverses possibilités en
matière de délais. Ils sont également très utiles pour imprimer ou visualiser les données de
sortie de l’élaboration du planning.
.6 Structure de codification. Les activités doivent être codifiées de manière à permettre le tri
et/ou la sélection par extraction suivant leurs différents attributs, tels que la responsabilité,
l’emplacement géographique ou le bâtiment, la phase du projet, le niveau de détail du plan-
ning, le type d’activité ou la classification OT.

6.4.3 Données de sortie de l’élaboration du planning


.1 Planning du projet. Le planning du projet comprend pour chaque activité au moins la date de
début planifiée et celle de fin attendue. (Remarque : le planning du projet reste préliminaire
tant que les affectations de ressources ne sont pas confirmées. En principe, cette confirmation
devrait se produire au plus tard une fois l’élaboration du plan de projet (à la section 4.1) ter-
minée.)
Le planning du projet peut se présenter sous forme synthétique (échéancier directeur) ou
détaillée. Bien qu’il puisse être présenté sous forme de tableau, on utilise le plus souvent la
forme graphique et un ou plusieurs des formats suivants :
■ diagrammes réseau du projet avec affichage de dates (voir la figure 6-5). Cette représen-
tation fait habituellement apparaître à la fois les liaisons logiques et les activités du chemin
critique du projet (voir la section 6.2.3.1 pour de plus amples informations sur les dia-
grammes réseau).

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
77
Chapitre 6 — Gestion des délais du projet

Figure 6–6 | 6.5.1.1

Figure 6-6 Diagramme à barres (Gantt)

■ diagrammes à barres, appelés également diagrammes de Gantt (voir la figure 6-6). Ils
représentent les dates de début et de fin des activités, ainsi que leur durée prévue et par-
fois leurs dépendances logiques. Ils sont relativement faciles à lire et ou les utilise souvent
dans les exposés de gestion.
■ échéanciers (voir la figure 6-7). Ils ressemblent aux diagrammes à barres, mais n’identi-
fient que le début ou l’achèvement planifié des principaux produits livrables et des inter-
faces externes clés.
.2 Informations détaillées. Les informations détaillées associées au planning du projet compren-
nent au moins les documents concernant toutes les contraintes et hypothèses identifiées. Le
volume des informations détaillées peut varier suivant le champ d’application. Par exemple :
■ Dans un projet de construction, des documents comme les histogrammes de charge, le
plan de trésorerie et l’échéancier des commandes et des livraisons seront vraisemblable-
ment inclus.
■ Dans un projet d’électronique, seuls les histogrammes de charge seront inclus.
Les informations qui font le plus souvent partie des informations détaillées sont, entre
autres :
■ Les besoins en ressources par unité de temps, souvent sous forme d’histogramme de
charge.
■ Les plannings de remplacement (par exemple, dans le meilleur ou dans le pire des cas,
avec ou sans lissage des ressources, avec ou sans dates imposées).
■ Provisions pour aléas de délais (voir la section 11.4).
.3 Plan de gestion du planning. Ce plan définit les modalités de gestion des modifications appor-
tées au planning. Selon les besoins du projet, il peut être formel ou non, très détaillé ou for-
mulé dans ses grandes lignes. C’est un élément annexe au plan de l’ensemble du projet (voir
la section 4.1).
.4 Mises à jour des besoins en ressources. Les mises à jour du lissage des ressources peuvent
avoir d’importantes répercussions sur l’estimation préliminaire des besoins en ressources.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
78 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 6 — Gestion des délais du projet

Figure 6-7 Echéancier

6.5 CONTRÔLE DU PLANNING


Le contrôle du planning consiste à : a) influencer les facteurs entraînant des modifications
au niveau du planning de manière à s’assurer que les changements font l’objet d’un accord
des parties impliquées, b) constater que le planning a changé et c) gérer les modifications
effectives quand elles ont lieu. L’intégration du contrôle du planning avec les autres processus
de contrôle doit être faite minutieusement, comme décrit à la section 4.3, « Contrôle intégré
des changements ».

Données d'entrée Outils et méthodes Données de sortie


.1 Planning du projet .1 Système de contrôle des .1 Mises à jour du planning
.2 Rapports d'avancement changements du .2 Action corrective
.3 Demandes de planning .3 Leçons retenues
changements .2 Mesure des
.4 Plan de gestion du performances
planning .3 Planification
complémentaire
.4 Logiciels de gestion de
projet
.5 Analyse des écarts

6.5.1 Données d’entrée pour le contrôle du planning


.1 Planning du projet. Le planning du projet est décrit à la section 6.4.3.1. Le planning officiel du
projet, appelé planning de référence (qui doit être réalisable techniquement et en termes de
ressources), est une composante du plan de projet décrit à la section 4.1.3.1. Il sert de base
de mesure et de suivi des performances du point de vue des délais.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
79
Chapitre 6 — Gestion des délais du projet

6.5.5.2 | 6.5.3.3
.2 Rapports d’avancement. Les rapports d’avancement, traités à la section 10.3.3.1, fournissent
des informations sur les performances du point de vue des délais (par exemple, les dates pla-
nifiées qui ont été respectées et celles qui ne l’ont pas été). Les rapports d’avancement peu-
vent aussi attirer l’attention de l’équipe de projet sur des questions pouvant, à l’avenir, être
à la source de problèmes.
.3 Demandes de changements. Les demandes de changements peuvent apparaître sous de nom-
breuses formes : orales ou écrites, directes ou indirectes, externes ou internes et imposées par
la loi ou facultatives. Après les modifications, il peut s’avérer nécessaire d’allonger les délais.
Ces changements peuvent aussi permettre d’accélérer l’exécution (voir la section 4.3.1.3).
.4 Plan de gestion du planning. Le plan de gestion du planning est décrit à la section 6.4.3.3.

6.5.2 Outils et méthodes du contrôle du planning


.1 Système de contrôle des changements du planning. Le système de contrôle du planning
définit les procédures permettant la modification du planning du projet. Il comprend les docu-
ments, les systèmes de suivi et les niveaux d’autorisation nécessaires pour autoriser les modi-
fications. Le contrôle des changements du planning doit être incorporé au système de contrôle
intégré des changements décrit à la section 4.3.
.2 Mesure des performances. Les méthodes de mesure des performances, telles que celles
décrites à la section 10.3.2, permettent d’évaluer l’ampleur des écarts effectifs. Décider si les
écarts de délai nécessitent une action corrective est une partie essentielle du contrôle des
changements du planning. Par exemple, le retard important d’une activité non essentielle peut
n’avoir qu’un faible impact sur l’ensemble du projet, tandis que le retard moins important
d’une activité critique ou sous-critique peut nécessiter une action immédiate.
.3 Planification complémentaire. Les projets se déroulent rarement comme prévu. Les modifica-
tions à venir peuvent nécessiter de revoir entièrement l’estimation de la durée des activités,
de modifier l’ordre de réalisation des activités ou d’envisager des plannings de remplacement.
.4 Logiciels en gestion de projet. Les logiciels en gestion de projet sont décrits à la section 6.4.2.5.
Ce sont des outils utiles pour le contrôle du planning car ils permettent d’effectuer le suivi des
dates planifiées par rapport aux dates réelles et à faire des prévisions quant à l’impact (effectif
ou potentiel) des modifications du planning.
.5 Analyse des écarts. L’efficacité de l’analyse des écarts durant le processus de contrôle du plan-
ning est un élément clé du contrôle des délais. La comparaison entre les dates cibles et les
dates de début et de fin réelles/prévues permet d’obtenir des informations utiles pour déceler
les écarts et mettre en œuvre des mesures correctives en cas de retard. La marge d’écart est
également un élément essentiel de la planification lors de l’évaluation des performances des
délais du projet. On doit particulièrement tenir compte des activités critiques et sous-critiques
(c’est-à-dire analyser les dix chemins sous-critiques, par ordre de marge croissante).

6.5.3 Données de sortie du contrôle du planning


.1 Mises à jour du planning. Il s’agit de toutes les modifications apportées au planning utilisé
pour gérer le projet. Le cas échéant, il y a lieu d’avertir les parties concernées. Ces mises à
jour peuvent ou non nécessiter la révision d’autres aspects du plan de projet.
Les révisions sont une catégorie particulière de mises à jour du planning. Il s’agit de modi-
fications apportées aux dates de début et de fin dans le planning officiel du projet. Ces modi-
fications sont généralement incorporées à cause des changements apportés au contenu ou aux
estimations. Dans certains cas, les retards sont tellement importants que l’on doit redéfinir
la référence de base pour obtenir des données réalistes pour la mesure des performances.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
80 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 6 — Gestion des délais du projet

Toutefois, il convient de faire attention avant de redéfinir la référence de base car l’historique
du planning du projet sera alors perdu. Cette redéfinition ne doit être utilisée qu’en dernier
ressort pour contrôler le planning ; de nouvelles dates cibles devraient être le mode normal
de révision du planning.
.2 Action corrective. Il s’agit de toute action visant à réaligner les dates de réalisation futures sur
celles prévues dans le plan de projet. Les actions correctives au niveau de la gestion des délais
consistent souvent à accélérer : mettre en œuvre des actions spéciales effectuées pour assurer
l’achèvement d’une activité sans retard ou avec un minimum de retard. Une action correc-
tive nécessite souvent l’analyse des causes ou de l’origine des écarts ; la planification et la réa-
lisation d’un rétablissement des délais peuvent s’effectuer non seulement pour l’activité à
l’origine de l’écart, mais aussi pour les activités délimitées se situant en aval dans le planning.
.3 Leçons retenues. La cause des écarts, la justification du choix de l’action corrective, ainsi que
les autres types de leçons retenues doivent être documentés et intégrés à la base de données
historiques du projet et des autres projets de l’entreprise maîtresse d’œuvre.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
81
Chapitre 7

Gestion des coûts du projet

La gestion des coûts du projet comprend les processus nécessaires à la réalisation du projet
dans les limites budgétaires approuvées. La figure 7-1 présente les processus principaux sui-
vants :
7.1 Planification des ressources : déterminer quelles ressources (personnes, équipement,
matériel) doivent être utilisées pour réaliser les activités du projet et en quelle quantité.
7.2 Estimation des coûts : établir une approximation (estimation) du coût des ressources
nécessaires à l’achèvement des activités du projet.
7.3 Budgétisation : attribuer à chaque activité sa quote-part de l’estimation du coût total.
7.4 Contrôle des coûts : contrôler les modifications apportées au budget du projet.
Ces processus interagissent entre eux et avec les processus d’autres disciplines. Chaque
processus peut nécessiter la participation d’une ou plusieurs personnes ou d’un ou plusieurs
groupes, selon les besoins du projet. Habituellement, tous les processus sont exécutés au
moins une fois au cours de chaque phase du projet.
Bien que les processus soient présentés ici comme des éléments distincts avec des inter-
faces bien définies, ils peuvent dans la pratique se chevaucher et interagir d’une manière non
détaillée dans ce chapitre. Les interactions entre processus sont décrites au chapitre 3.
La gestion des coûts du projet s’intéresse principalement au coût des ressources néces-
saires à la réalisation des activités du projet. Toutefois, la gestion des coûts du projet devrait
également prendre en compte les effets des décisions prises dans le cadre du projet sur le
coût d’utilisation du produit issu du projet. Par exemple, la décision de limiter le nombre de
revues d’études peut réduire le coût du projet au détriment du client qui voit le coût d’ex-
ploitation augmenter. Cette conception plus large de la gestion des coûts est souvent appelée
évaluation du coût du cycle de vie. Cette évaluation, associée aux techniques de l’ingénierie
de la valeur, permet de réduire les coûts et les durées, d’améliorer la qualité et les perfor-
mances et d’optimiser la prise de décision.
Dans de nombreux champs d’application, la prédiction et l’analyse des futures perfor-
mances financières du produit issu du projet ont lieu en dehors du projet. Dans d’autres
domaines (par exemple, les projets d’investissement), la gestion des coûts inclut également ce
processus. Lorsque de telles prédictions et analyses sont prises en compte, la gestion des coûts
du projet comprend alors des processus supplémentaires et de nombreuses techniques de
gestion générale, comme le retour sur investissement, les flux monétaires actualisés et l’ana-
lyse de la durée de récupération (en anglais « payback period »), entre autres.
La gestion des coûts du projet doit tenir compte du besoin en informations des acteurs :
des acteurs différents peuvent mesurer les coûts d’un projet différemment et à des moments
différents. Par exemple, le coût d’un approvisionnement peut être mesuré lorsqu’il est engagé,
commandé, livré, encouru ou enregistré par la comptabilité.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
83
Chapitre 7 — Gestion des coûts du projet

Figure 7–1 | 7.1.1.2

Figure 7-1 Vue d’ensemble de la gestion des coûts du projet

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
84 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 7 — Gestion des coûts du projet

Lorsque les coûts du projet sont utilisés dans le cadre d’un système d’appréciation du
mérite et de récompense du personnel (traité à la section 9.3.2.3), les coûts contrôlables et
incontrôlables doivent être estimés et budgétés séparément pour s’assurer que les récom-
penses octroyées reflètent les performances réelles.
Dans certains projets, et surtout dans les petits projets, les processus de planification des
ressources, d’estimation des coûts et de budgétisation sont tellement liés qu’ils sont considérés
comme un processus unique (par exemple, ils peuvent être réalisés par une seule personne
en un temps relativement court). Ils sont présentés ici comme des processus distincts car les
outils et méthodes utilisés sont différents pour chacun d’entre eux. La possibilité d’influencer
les coûts est plus importante durant les phases initiales du projet, et c’est pourquoi il est
essentiel de définir le contenu du projet le plus tôt possible, ainsi que d’identifier les spéci-
fications de façon approfondie et d’exécuter un plan viable.

7.1 PLANIFICATION DES RESSOURCES


La planification des ressources consiste à déterminer les ressources physiques (personnes,
équipement, matériel) devant être utilisées et les quantités correspondantes, ainsi que le
moment où celles-ci seront requises pour réaliser les activités du projet. Ce processus doit être
minutieusement coordonné avec celui de l’estimation des coûts (décrite à la section 7.2). Par
exemple :
■ L’équipe chargée d’un projet de construction doit connaître le code du bâtiment local. Une
telle expertise est disponible aisément lorsque l’on s’adresse à des fournisseurs locaux.
Néanmoins, si la main-d’œuvre locale ne connaît pas des techniques de construction par-
ticulières ou inhabituelles, le coût additionnel d’emploi d’un consultant peut constituer le
moyen le plus efficace de garantir la prise en compte du code du bâtiment local.
■ L’équipe d’un projet de conception automobile doit maîtriser les toutes dernières tech-
niques de montage automatisé. L’expérience requise peut être obtenue en ayant recours
à un consultant, en faisant participer un concepteur à un séminaire sur la robotique ou en
incluant une personne de la production dans l’équipe de projet.

7.1.1 Données d’entrée pour la planification des ressources


.1 Organigramme des tâches. L’organigramme des tâches (OT), décrit à la section 5.3.3.1) iden-
tifie les livrables et les processus du projet nécessitant des ressources, et constitue par consé-
quent la principale donnée d’entrée de la planification des ressources. Toutes les données de
sortie pertinentes en provenance d’autres processus de planification doivent être obtenues par
le biais de l’OT afin d’assurer un contrôle efficace.
.2 Données historiques. Dans la mesure du possible, l’utilisation de données historiques indi-
quant les types de ressources requis pour effectuer des travaux similaires lors de projets pré-
cédents est recommandée.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
85
Chapitre 7 — Gestion des coûts du projet

.3 Cahier des charges. Le cahier des charges (décrit à la section 5.2.3.1) contient la justification
7.1.1.3 | 7.2.1.8

et les objectifs du projet, deux aspects devant être explicitement pris en compte au cours de
la planification des ressources.
.4 Description des ressources disponibles. Pour planifier les ressources, il faut savoir lesquelles
(personnes, équipement, matériel) seraient disponibles. Le niveau de détail et de précision de
la description de l’ensemble des ressources varie. Par exemple, durant les phases initiales d’un
projet d’ingénierie, l’équipe peut comprendre un grand nombre d’ingénieurs débutants et
confirmés. Mais, au cours des phases suivantes du même projet, l’ensemble des ressources
pourra se limiter aux personnes le connaissant bien pour y avoir travaillé durant les phases
antérieures.
.5 Politique organisationnelle. Durant la planification des ressources, on doit tenir compte de la
politique de l’organisation maîtresse d’œuvre en matière de personnel et de location ou
d’achat des fournitures et des équipements.
.6 Estimation de la durée des activités. Durée des activités (décrite à la section 6.3.3.1).

7.1.2 Outils et méthodes de la planification des ressources


.1 Avis d’experts. Pour ce processus, l’opinion d’experts s’avère souvent nécessaire au cours de
l’évaluation des données d’entrée. Cette expertise peut être apportée par tout groupe ou toute
personne possédant des connaissances ou une formation particulières ; on peut l’obtenir de
plusieurs sources, comme :
■ des autres services de l’organisation maîtresse d’œuvre ;
■ de consultants ;
■ d’associations professionnelles et techniques ;
■ de groupements industriels.
.2 Identification des variantes. L’identification des variantes est traitée à la section 5.2.2.3.
.3 Logiciels de gestion de projet. Les logiciels de gestion de projet servent à organiser l’ensemble
des ressources. Suivant la sophistication du logiciel utilisé, on peut définir la disponibilité et
le taux des ressources, ainsi que leurs calendriers.

7.1.3 Données de sortie de la planification des ressources


.1 Besoins en ressources. Les données de sortie du processus de planification des ressources
consistent en une description des types et de la quantité des ressources nécessaires pour
chaque élément du niveau le plus bas de l’OT. Les besoins en ressources pour les autres
niveaux de l’OT peuvent se calculer sur la base des valeurs des niveaux plus bas. Ces res-
sources s’obtiendront soit par le processus d’obtention des ressources humaines (décrit à la
section 9.2), soit par le processus d’approvisionnement (décrit au chapitre 12).

7.2 ESTIMATION DES COÛTS


L’estimation des coûts consiste à formuler une approximation (estimation) du coût des res-
sources nécessaires à l’achèvement des activités du projet. Au cours de cette approximation
des coûts, l’estimateur doit tenir compte des causes d’écarts de l’estimation finale afin de
mieux gérer le projet.
Lorsqu’un projet est réalisé sous contrat, on doit bien faire la distinction entre l’estimation
des coûts et la détermination du prix. L’estimation des coûts consiste à évaluer un résultat
quantitatif probable (à savoir, combien la fourniture du produit ou du service envisagé coû-
tera-t-elle à l’organisation maîtresse d’œuvre ?) La détermination du prix est une décision
d’ordre commercial (à savoir, combien l’organisation maîtresse d’œuvre facturera-t-elle pour
le produit ou service ?) dans laquelle l’estimation des coûts n’est qu’une des considérations
prise en compte parmi tant d’autres.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
86 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 7 — Gestion des coûts du projet

L’estimation des coûts comprend l’identification et l’évaluation de diverses variantes en


matière de coûts. Par exemple, dans la plupart des domaines d’application, on admet géné-
ralement qu’un travail plus important lors de la phase d’étude est susceptible de réduire les
coûts de la phase de production. Le processus d’estimation des coûts doit déterminer si le
coût du travail d’étude supplémentaire est compensé par les économies anticipées.

7.2.1 Données d’entrée pour l’estimation des coûts


.1 Organigramme des tâches. L’OT est décrit à la section 5.3.3.1. Il sert à organiser les estima-
tions de coûts et à assurer que tous les travaux identifiés ont été estimés.
.2 Besoins en ressources. Les besoins en ressources sont décrits à la section 7.1.3.1.
.3 Taux des ressources. Afin de calculer le coût du projet, la personne ou le groupe qui pré-
pare l’estimation doit connaître le taux unitaire (par exemple, coût horaire du personnel, coût
en vrac du mètre cube de matériau) de chaque ressource. Si les taux réels ne sont pas connus,
ceux-ci doivent être estimés.
.4 Estimation de la durée des activités. L’estimation de la durée des activités (décrite à la section
6.3.3.1) a une influence sur l’estimation des coûts dans tous les projets dont le budget inclut
le coût du financement (c’est-à-dire les intérêts d’emprunt).
.5 Ouvrages sur l’estimation. Données sur l’estimation des coûts disponibles dans le commerce.
.6 Données historiques. Les données historiques concernant le coût de nombreuses catégories
de ressources peut souvent provenir de l’une ou de plusieurs sources des suivantes :
■ dossiers de projet : une ou plusieurs organisations impliquées dans le projet peuvent avoir
conservé des archives suffisamment détaillées sur des projets précédents pour aider à l’es-
timation des coûts. Dans certains domaines d’application, il est courant que certains
membres de l’équipe archivent ce type de données historiques.
■ bases de données commerciales d’estimation des coûts : on peut souvent trouver des don-
nées historiques sur le marché.
■ expérience de l’équipe de projet : les membres de l’équipe de projet peuvent se rappeler
des coûts réels ou estimés des précédents projets. Bien que de tels souvenirs soient utiles,
ils sont en général bien moins fiables que des résultats documentés.
.7 Plan comptable. Le plan comptable décrit la structure de codification utilisée par l’organisa-
tion maîtresse d’œuvre, pour enregistrer des informations d’ordre financier dans sa compta-
bilité. Les coûts estimés du projet doivent être associés au poste comptable correspondant.
.8 Risques. L’équipe de projet tient compte des informations sur les risques (voir la section
11.2.3.1) lorsqu’elle élabore l’estimation des coûts, puisque les risques (qu’ils constituent des
menaces ou des opportunités) peuvent avoir un impact considérable sur les coûts. Pour
chaque activité, l’équipe de projet tient compte de l’importance accordée à l’impact des
risques dans l’estimation des coûts.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
87
Chapitre 7 — Gestion des coûts du projet

7.2.2 Outils et méthodes de l’estimation des coûts


7.2.2 | 7.3.1.2

.1 Estimation par analogie. Également appelée estimation descendante (« top-down estimating »


en anglais), l’estimation par analogie utilise les coûts réels d’un projet semblable réalisé par
le passé comme base d’estimation des coûts du projet en cours. On l’utilise fréquemment pour
estimer le coût total d’un projet lorsqu’il existe peu d’informations détaillées sur celui-ci (par
exemple, dans les phases initiales). L’estimation par analogie est une forme de méthode basée
sur l’avis d’experts (décrite à la section 7.1.2.1).
L’estimation par analogie est en général moins coûteuse que les autres méthodes, mais elle
est également moins précise. Elle est plus fiable lorsque : a) les projets précédents sont réel-
lement semblables et non seulement semblables en apparence et b) les individus ou les
groupes préparant l’estimation ont l’expérience nécessaire.
.2 Modélisation paramétrique. La modélisation paramétrique consiste à utiliser les caractéris-
tiques (paramètres) du projet dans un modèle mathématique pour en prédire les coûts. Les
modèles peuvent être simples (la construction d’une maison coûtera un certain prix au mètre
carré habitable) ou complexes (une modélisation du coût du développement d’un logiciel uti-
lisera treize paramètres différents, chacun variant sur une échelle de cinq à sept points).
Le coût et la fiabilité des modélisations paramétriques sont très variables. Ils sont plus
fiables lorsque : a) l’historique utilisé pour élaborer le modèle est fiable, b) les paramètres uti-
lisés dans le modèle sont facilement quantifiables et c) le modèle est évolutif (c’est-à-dire qu’il
s’applique aussi bien aux très grands projets qu’aux très petits).
.3 Estimation ascendante. Cette technique commence par l’estimation du coût de chaque acti-
vité ou lot de travail, puis additionne et consolide chaque estimation pour arriver au total du
projet.
Le coût et la fiabilité de l’estimation ascendante dépendent de l’importance et de la com-
plexité des activités ou des lots de travail : des activités plus petites augmentent à la fois le
coût et le degré de précision du processus d’estimation. L’équipe de gestion de projet doit
optimiser le rapport entre une précision accrue et le surcoût qui en découle.
.4 Outils informatiques. Les outils informatiques, tels que les logiciels de gestion de projet, les
tableurs et les outils de simulation et de statistiques sont largement mis à contribution dans
l’estimation des coûts. Ils peuvent simplifier l’utilisation des méthodes décrites précédemment,
permettant ainsi d’étudier rapidement de nombreuses solutions du point de vue des coûts.
.5 Autres méthodes d’estimation des coûts. Par exemple, l’analyse de devis provenant de four-
nisseurs potentiels.

7.2.3 Données de sortie de l’estimation des coûts


.1 Estimation des coûts. L’estimation des coûts est une évaluation quantitative du coût probable
des ressources nécessaires à l’achèvement des activités du projet. Elle peut être présentée sous
forme abrégée ou détaillée.
Le coût de toutes les ressources affectées au projet doit être estimé. Ceci comprend, entre
autres, la main-d’œuvre, les matériaux, les fournitures et des catégories spéciales telles que
des provisions pour inflation ou des réserves financières.
Une estimation de coût s’exprime en principe en unités monétaires (dollars, euros, yen,
etc.) afin de faciliter les comparaisons au sein d’un projet et entre projets. Dans certains cas,
pour l’estimation des coûts, l’estimateur peut utiliser des unités de mesure, telles que les capa-
cités horaires ou journalières par employé, accompagnées de leur coût estimé pour faciliter
un contrôle adéquat. En général, l’estimation des coûts implique de tenir compte des mesures
de réduction prévues, telles que les plans de remplacement.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
88 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 7 — Gestion des coûts du projet

Au cours du projet, on aura intérêt à affiner les estimations de coût pour qu’elles reflètent
les informations supplémentaires disponibles. Dans certains domaines d’application, il existe
des directives indiquant les moments opportuns à la réalisation de telles modifications, ainsi
que le degré de fiabilité prévu. Par exemple, l’AACE (Association for the Advancement of Cost
Engineering) International a identifié cinq types d’estimations progressives des coûts de
construction durant la phase d’ingénierie d’un projet : ordre de grandeur, conceptuel, préli-
minaire, définitif et de contrôle.
.2 Informations détaillées. Les informations détaillées associées à l’estimation des coûts doivent
comprendre :
■ une description du contenu du travail estimé. Il s’agit souvent d’une référence à l’OT ;
■ la documentation de la base de l’estimation ; c’est-à-dire comment elle a été élaborée ;
■ la documentation de toutes les hypothèses émises ;
■ une indication de l’éventail des résultats possibles ; par exemple, 10 000 € ± 1 000 €, pour
indiquer qu’un élément donné devrait coûter entre 9 000 € et 11 000 €. Le volume et le
type des informations détaillées varient suivant le domaine d’application.
La prise de notes, même en brouillon, peut se révéler très utile pour une meilleure com-
préhension du processus d’élaboration de l’estimation.
.3 Plan de gestion des coûts. Le plan de gestion des coûts décrit comment gérer les écarts de
coûts (par exemple, les mesures à prendre pour les problèmes importants sont différentes de
celles destinées aux problèmes mineurs). Selon les besoins des acteurs du projet, il peut être
formel ou non, très détaillé ou formulé dans ses grandes lignes. C’est un élément annexe au
plan de projet (traité à la section 4.1.3.1).

7.3 BUDGÉTISATION
La budgétisation consiste à attribuer à chaque activité ou lot de travail élémentaire sa quote-
part de l’estimation globale afin d’établir un budget (Référence de coûts) pour mesurer les
performances du projet. La réalité peut dicter que l’estimation soit faite après l’accord bud-
gétaire, mais dans la mesure du possible, elle doit être effectuée avant la demande de budget.

7.3.1 Données d’entrée de la budgétisation


.1 Estimation des coûts. L’estimation des coûts est décrite à la section 7.2.3.1.
.2 Organigramme des tâches. L’OT (décrit à la section 5.3.3.1) identifie les éléments du projet
auxquels les coûts sont attribués.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
89
Chapitre 7 — Gestion des coûts du projet

Figure 7–2 | 7.4.2.2

Figure 7-2 Courbe illustrant la référence de coûts (budget)

.3 Planning du projet. Le planning du projet (décrit à la section 6.4.3.1) comprend les dates de
début prévues et les dates de fin attendues pour les éléments du projet auxquels des coûts
sont attribués. Ces informations sont nécessaires pour attribuer les coûts à l’unité de temps
durant laquelle ils seront encourus.
.4 Plan de gestion des risques. Le plan de gestion des risques est développé à la section 11.1.3.
En outre, il comprend souvent une provision qui peut être déterminée sur la base de la fia-
bilité attendue de l’estimation.

7.3.2 Outils et méthodes de budgétisation


.1 Outils et méthodes de budgétisation. Les outils et les méthodes décrits à la section 7.2.2 et
utilisés pour l’élaboration de l’estimation des coûts servent également à l’élaboration du
budget en ce qui concerne les activités ou les lots de travail.

7.3.3 Données de sortie de la budgétisation


.1 Référence de coûts (budget). La référence de coûts est un budget réparti dans le temps et uti-
lisé pour mesurer et effectuer le suivi des performances des coûts du projet. Il s’élabore en
additionnant les coûts estimés par période et se présente habituellement sous la forme d’une
courbe en S, tel qu’illustré à la figure 7-2.
Nombre de projets, particulièrement ceux de grande envergure, peuvent comporter plu-
sieurs références de coûts afin de mesurer les divers aspects de leurs performances de coûts.
Par exemple, un plan de décaissement ou une prévision de flux de trésorerie constitue une
référence de coûts pour la mesure des dépenses.

7.4 CONTRÔLE DES COÛTS


Le contrôle des coûts consiste à : a) agir sur les facteurs entraînant des modifications de la
référence de coûts afin de s’assurer que ces modifications sont consensuelles, b) déterminer
si la référence de coûts a changé et c) gérer les modifications au fur et à mesure qu’elles sur-
viennent. Le contrôle des coûts comprend :

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
90 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 7 — Gestion des coûts du projet

■ le suivi des performances des coûts, pour déceler et comprendre les écarts par rapport au
plan ;
■ la vérification de la prise en compte de toutes les modifications applicables, dans la réfé-
rence de coûts ;
■ la prévention de la prise en compte de modifications inappropriées ou non autorisées,
dans la référence de coûts ;
■ l’annonce aux parties prenantes concernées des modifications autorisées ;
■ les actions entreprises en vue de contenir les coûts prévus dans des limites acceptables.
Le contrôle des coûts implique de rechercher le « pourquoi » des écarts positifs et négatifs.
On doit l’intégrer minutieusement aux autres processus de contrôle (contrôle des change-
ments du contenu, contrôle du planning, contrôle de la qualité, entre autres, tels que traités
à la section 4.3). Par exemple, des mesures inadéquates en réponse à des écarts de coûts peu-
vent entraîner des problèmes de qualité ou de délais, ou conduire à un niveau de risque inac-
ceptable en aval du projet.

7.4.1 Données d’entrée du contrôle des coûts


.1 Référence de coûts (budget). La référence de coûts (ou budget) est décrite à la section
7.3.3.1.
.2 Rapports d’avancement. Les rapports d’avancement (traités à la section 10.3.3.1) donnent des
informations sur les performances de réalisation et des coûts du projet (par exemple, quels
sont les budgets respectés et ceux qui sont dépassés). Les rapports d’avancement peuvent
aussi attirer l’attention de l’équipe de projet sur des questions pouvant, à l’avenir, poser pro-
blème.
.3 Demandes de changements. Les demandes de changements peuvent apparaître sous de nom-
breuses formes : orales ou écrites, directes ou indirectes, externes ou internes, imposées par
la loi ou facultatives. Suite aux modifications, il peut s’avérer nécessaire d’augmenter le
budget, ou au contraire de le réduire.
.4 Plan de gestion des coûts. Le plan de gestion des coûts est décrit à la section 7.2.3.3.

7.4.2 Outils et méthodes de contrôle des coûts


.1 Système de contrôle des changements des coûts. Le système de contrôle des changements
des coûts définit les procédures selon lesquelles la référence de coûts peut être modifiée. Il
comprend les documents, les systèmes de suivi et les niveaux d’autorisation nécessaires pour
autoriser les modifications. Le système de contrôle des changements des coûts doit être incor-
poré au système de contrôle intégré des changements, traité à la section 4.3.
.2 Mesure des performances. Les méthodes de mesure des performances, décrites à la section
10.3.2, permettent d’évaluer l’ampleur des écarts effectifs. La gestion de la valeur acquise

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
91
Chapitre 7 — Gestion des coûts du projet

(EVM en anglais), décrite aux sections 7.4.2.3 et 10.3.2.4, est particulièrement utile pour le
7.4.2.3 | 7.4.3.6

contrôle des coûts. Déterminer l’origine des écarts et décider si ceux-ci nécessitent une action
corrective sont une partie essentielle du contrôle des coûts.
.3 Gestion de la valeur acquise. Tous les plans de contrôle des comptes utilisant la méthode de
la valeur acquise (EVM) doivent mesurer les performances du projet de façon continue en
mettant en rapport trois variables indépendantes : 1) la valeur prévue (VP), c’est-à-dire le tra-
vail effectif dont la réalisation a été programmée, y compris l’estimation de la valeur de ce tra-
vail (appelée auparavant Coût budgété du travail prévu, CBTP), par rapport à 2) la valeur
acquise (VA), c’est-à-dire le travail effectif réellement accompli, y compris l’estimation de la
valeur de ce travail (appelée auparavant Coût budgété du travail réalisé, CBTR ) et par rap-
port aux 3) coûts réels encourus pour produire la valeur acquise. L’opération : 2) valeur
acquise moins 1) valeur prévue constitue l’écart de prévision (EP). L’opération : 2) valeur
acquise moins 3) coût réel constitue l’écart de coût pour le projet. Voir également la section
10.3.2.4.
.4 Planification complémentaire. Les projets se déroulent rarement selon le programme prévu.
Les modifications éventuelles peuvent nécessiter de revoir l’estimation des coûts, voire de la
refaire complètement, ou d’analyser les différentes approches possibles.
.5 Outils informatiques. Des outils informatiques, tels que les logiciels en gestion de projet et les
tableurs, sont souvent utilisés pour effectuer le suivi des coûts planifiés par rapport aux coûts
réels et pour faire des prévisions quant à l’impact des modifications de coûts.

7.4.3 Données de sortie du contrôle des coûts


.1 Estimation corrigée des coûts. Il s’agit des modifications apportées aux informations sur les
coûts utilisées pour la gestion du projet. Le cas échéant, les acteurs et concernés doivent être
avertis. L’estimation corrigée des coûts peut nécessiter ou non l’ajustement d’autres aspects du
plan de projet.
.2 Mises à jour du budget. Il s’agit d’une catégorie spéciale d’estimation corrigée des coûts. Les
mises à jour du budget sont des modifications de la référence de coûts approuvée. Ces
chiffres ne sont généralement révisés qu’à la suite de modifications du contenu. Dans certains
cas, les écarts de coûts sont tellement importants que l’on doit redéfinir la référence de coûts
pour obtenir des données réalistes pour la mesure des performances.
.3 Action corrective. Il s’agit de toute action visant à réaligner le plan de projet et les perfor-
mances futures attendues du projet.
.4 Prévision à l’achèvement. La prévision à l’achèvement (PAA) est une prévision du coût total
le plus probable du projet, basée sur les performances et la quantification des risques du
projet, décrite à la section 11.4.3. Les techniques de prévision les plus courantes sont une
variante de :
■ PAA = Coûts réels à ce jour plus une nouvelle estimation pour le travail restant. Cette
approche est utilisée le plus souvent lorsque les performances passées ont démontré que
les hypothèses émises dans l’estimation initiale étaient fondamentalement imparfaites ou
qu’elles ne sont plus appropriées à un changement de conditions. Formule : PAA = CR + CEA.
■ PAA = Coûts réels à ce jour plus le budget restant (Coût budgété à l’achèvement – VA).
Cette approche est utilisée le plus souvent lorsque les écarts en cours sont jugés atypiques
et que l’équipe de gestion de projet s’attend à ce que des écarts semblables ne se repro-
duisent plus. Formule : PAA = CR + Coût budgété à l’achèvement – VA.
■ PAA = Coûts réels à ce jour plus le budget restant du projet (Coût budgété à l’achèvement – VA)
corrigé par un facteur de performances ; souvent il s’agit de l’indice de performance des coûts
(IPC) cumulé. Cette approche s’utilise le plus souvent lorsque les écarts en cours sont jugés repré-
sentatifs des écarts futurs. Formule : PAA = (CR + (Coût budgété à l’achèvement – VA)/IPC),
où IPC représente l’IPC cumulé.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
92 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 7 — Gestion des coûts du projet

Chacune de ces approches peut s’adapter parfaitement à un projet donné et peut signaler
à l’équipe de gestion de projet que les prévisions à l’achèvement dépassent les tolérances
acceptables.
.5 Clôture du projet. Des processus et procédures de clôture ou d’annulation de projet doivent
être établies. Par exemple, l’Énoncé de principes (SOP 98-1 émis par l’American Institute of
Certified Public Accountants, AICPA) exige que tous les coûts d’un projet non réussi en tech-
nologie de l’information soient passés aux pertes et profits du trimestre pendant lequel ce der-
nier a été annulé.
.6 Leçons retenues. La cause des écarts, la justification du choix de l’action corrective, ainsi que
les autres types de leçons retenues doivent être documentés et intégrés à la base de données
historiques du projet et des autres projets de l’entreprise maîtresse d’œuvre (voir la section
4.3.3.3).

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
93
Chapitre 8

Gestion de la qualité du
projet

La gestion de la qualité du projet comprend les processus nécessaires pour que le projet
réponde aux besoins pour lesquels il a été mis en œuvre. Elle comprend « toutes les activités
de l’ensemble de la gestion qui déterminent la politique, les responsabilités et les objectifs à
atteindre en matière de qualité, et qui les mettent en œuvre à l’aide de moyens tels que la pla-
nification, l’assurance, le contrôle et l’amélioration de la qualité dans le cadre du système qua-
lité » (1). La figure 8-1 offre une vue d’ensemble des principaux processus de gestion de la
qualité du projet ci-après :
8.1 Planification de la qualité : identifier les normes de qualité applicables au projet et
déterminer les modalités de leur respect.
8.2 Assurance de la qualité : évaluer régulièrement les performances de l’ensemble du
projet, afin de s’assurer de la conformité du projet aux normes de qualité applicables.
8.3 Contrôle de la qualité : effectuer le suivi des résultats spécifiques du projet, afin d’éva-
luer leur conformité aux normes de qualité applicables et d’identifier comment éliminer les
causes de performances insuffisantes.
Ces processus interagissent entre eux et avec les processus d’autres disciplines. Chaque
processus peut nécessiter la participation d’une ou plusieurs personnes ou d’un ou plusieurs
groupes, selon les besoins du projet. Habituellement, tous les processus sont exécutés au
moins une fois au cours de chaque phase du projet.
Bien que les processus soient présentés ici comme des éléments distincts avec des inter-
faces bien définies, ils peuvent dans la pratique se chevaucher et interagir d’une manière non
détaillée dans ce chapitre. Les interactions entre processus sont décrites au chapitre 3.
L’approche de base de la gestion de la qualité décrite dans cette section doit être compa-
tible avec celle de l’organisation internationale de normalisation (ISO), présentée en détail
dans les normes et directives ISO 9000 et 10000. Cette approche généralisée doit également
être compatible avec : a) les approches de la gestion de la qualité propriétaires, telles que pré-
conisées par Deming, Juran, Crosby, et autres et, b) les approches non propriétaires, telles
que la gestion intégrale de la qualité (TQM en anglais) et l’amélioration continue, entre autres.
La gestion de la qualité doit tenir compte à la fois de la gestion du projet et du produit issu
de ce dernier. Le terme générique produit est quelquefois employé dans les ouvrages consa-
crés à la qualité pour désigner à la fois des biens et des services. Ne pas répondre aux impé-
ratifs de qualité de l’un ou de l’autre peut avoir de graves conséquences pour certains ou tous
les acteurs du projet. Par exemple :

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
95
Chapitre 8 — Gestion de la qualité du projet

Figure 8–1 | 8.1

Figure 8-1 Vue d’ensemble de la gestion de la qualité du projet

■ satisfaire aux exigences du client en surchargeant de travail l’équipe de projet peut avoir
des conséquences néfastes, notamment une attrition accrue du personnel ;
■ atteindre les objectifs de délais du projet en effectuant à la hâte les inspections de qua-
lité programmées peut avoir des conséquences néfastes lorsque les erreurs ne sont pas
décelées.
La qualité est « l’ensemble des caractéristiques d’une entité se rapportant à sa capacité à
répondre à des besoins explicites ou implicites » (2). Les besoins explicites et implicites sont
les données d’entrée de l’élaboration détaillée des besoins du projet. Dans le contexte d’un
projet, un des aspects essentiels de la gestion de la qualité est la nécessité d’exprimer les
besoins implicites sous forme de besoins confirmés par le biais de la gestion du contenu du
projet, décrite au chapitre 5.
L’équipe de gestion de projet doit éviter de confondre qualité et classe. La classe est « une
catégorie ou un rang donné(e) à des entités ayant un usage fonctionnel identique mais des
caractéristiques techniques différentes » (3). Une qualité médiocre est toujours un problème,
tandis qu’une classe inférieure n’en est pas forcément un. Par exemple, un logiciel peut être
de très bonne qualité (pas de bogues manifestes, manuel lisible) tout en étant d’une classe
inférieure (nombre limité de fonctions). Inversement, il peut être d’une qualité médiocre
(nombreux bogues, manuel d’utilisation mal organisé) tout en étant d’une classe supérieure
(nombreuses fonctions). Définir et fournir le niveau requis en matière de qualité et de classe
relèvent de la responsabilité du chef de projet et de l’équipe de gestion.
L’équipe de gestion de projet doit aussi être consciente du fait que la gestion moderne de
la qualité et la gestion de projet sont complémentaires. Par exemple, ces deux disciplines
reconnaissent l’importance de :

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
96 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 8 — Gestion de la qualité du projet

■ la satisfaction du client : comprendre, gérer et infléchir les besoins de façon à répondre


aux attentes du client. Ceci nécessite d’associer conformité aux besoins (le projet doit pro-
duire les résultats annoncés) et adaptation à l’utilisation (le produit ou le service réalisé
doit répondre à des besoins réels).
■ la prévention vaut mieux que l’inspection : éviter les erreurs coûte toujours moins cher
que de les réparer lorsqu’elles sont décelées à l’inspection.
■ la responsabilité de la direction : pour réussir, il faut la participation de tous les membres
de l’équipe ; cela dit, la disponibilité des ressources nécessaires à la réussite demeure la
responsabilité de la direction.
■ les processus par phases : la répétition du cycle planifier-réaliser-vérifier-agir décrit par
Deming et autres ressemble beaucoup à l’organisation par phases et par processus traitée
au chapitre 3, « Processus de la gestion de projet ».
De plus, les initiatives de l’entreprise réalisatrice visant à l’amélioration de la qualité (par
ex : TQM, amélioration continue, etc.) peuvent accroître la qualité de la gestion du projet
autant que celle du produit issu du projet.
Cependant, il existe une importante différence dont l’équipe de gestion de projet doit avoir
clairement conscience : la nature temporaire d’un projet signifie que les investissements pour
l’amélioration de la qualité du produit, surtout en matière de prévention et d’évaluation des
défauts, doivent souvent être pris en charge par l’entreprise réalisatrice, le projet ne durant
pas toujours assez longtemps pour qu’elle puisse en bénéficier.

8.1 PLANIFICATION DE LA QUALITÉ


La planification de la qualité consiste à identifier les normes de qualité applicables au projet
et à déterminer les modalités de leur respect. Il s’agit de l’un des processus majeurs de sou-
tien, lors de la planification du projet (voir la section 3.3.2, « Processus de planification ») ; il
doit être appliqué régulièrement et en parallèle avec les autres processus de planification du
projet. Par exemple, les changements apportés au produit résultant du projet et nécessaires
au respect des normes de qualité identifiées peuvent entraîner des ajustements au niveau des
coûts ou des délais ; ou encore, la qualité souhaitée pour le produit peut nécessiter une ana-
lyse détaillée des risques provenant d’un problème identifié. Avant l’élaboration des normes
ISO 9000, les activités décrites ici sous le nom de planification de la qualité étaient commu-
nément traitées dans le cadre de l’assurance de la qualité.
Les méthodes de planification de la qualité traitées ici sont le plus fréquemment utilisées
dans les projets. Il en existe de nombreuses autres pouvant être utiles pour certains projets ou
dans certains domaines d’application.
L’équipe de projet doit également avoir conscience de l’un des principes fondamentaux
de la gestion moderne de la qualité à savoir que la qualité doit être planifiée et non contrôlée
après coup.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
97
Chapitre 8 — Gestion de la qualité du projet

8.1.1 Données d’entrée de la planification de la qualité


8.1.1 | 8.1.3.1

.1 Politique de qualité. Il s’agit de « l’ensemble des intentions et des orientations d’une organi-
sation en matière de qualité, telles qu’officiellement exprimées par la direction » (4). La poli-
tique de qualité de l’entreprise réalisatrice peut souvent être adoptée « telle quelle » dans le
projet. Cependant, si l’organisation n’a pas de politique officielle en matière de qualité, ou
si le projet implique plusieurs organisations, comme c’est le cas dans les partenariats d’en-
treprises, l’équipe de gestion du projet devra alors mettre sur pied la politique de qualité à
suivre au cours du projet.
Quelle que soit l’origine de la politique de qualité, l’équipe de gestion du projet doit s’as-
surer que les acteurs du projet en sont pleinement conscients (par exemple, en diffusant l’in-
formation de façon adéquate, tel que décrit à la section 10.2).
.2 Cahier des charges. Le cahier des charges (décrit à la section 5.2.3.1) est une donnée d’en-
trée majeure pour la planification de la qualité, car il documente les principaux produits
livrables du projet, ainsi que les objectifs du projet servant à définir les exigences importantes
des acteurs.
.3 Description du produit. Bien que certains éléments de la description du produit (décrite à la
section 5.1.1.1) puissent faire partie de l’énoncé du contenu, celle-ci contient souvent des
détails techniques et d’autres aspects pouvant avoir un impact sur la planification de la qua-
lité.
.4 Normes et réglementations. L’équipe de gestion de projet doit tenir compte de toutes les
normes ou réglementations spécifiques à un domaine d’application, qui peuvent avoir un
impact sur le projet. La section 2.5.1 traite des normes et des réglementations.
.5 Données de sortie des autres processus. Outre le cahier des charges et la description du pro-
duit, les processus des autres disciplines peuvent fournir des données de sortie à considérer
comme faisant partie de la planification de la qualité. Par exemple, la planification des appro-
visionnements (décrite à la section 12.1) peut identifier des exigences de qualité d’un sous-
traitant à incorporer dans le plan de la gestion de la qualité de l’ensemble du projet.

8.1.2 Outils et méthodes de la planification de la qualité


.1 Analyse coût/bénéfice. L’analyse coût/bénéfice doit tenir compte des compromis consentis
entre le coût et les bénéfices, tels que décrits à la section 5.2.2.2. Le respect des exigences en
matière de qualité implique notamment moins de reprises, ce qui signifie une plus grande
productivité, des coûts moindres et une plus grande satisfaction des acteurs. Le coût principal
du respect des exigences en matière de qualité est celui associé aux activités de gestion de la
qualité du projet. Les bénéfices doivent être plus importants que les coûts : c’est un axiome
de la gestion de la qualité.
.2 Étalonnage. L’étalonnage implique de comparer les pratiques réelles ou prévues du projet
à celles d’autres projets, afin de déceler les améliorations possibles et de générer une norme
permettant de mesurer les performances. Les autres projets peuvent être, ou non, des pro-
jets de l’entreprise realisatrice ou peuvent faire partie, ou non, du même domaine d’applica-
tion.
.3 Modélisation. Un modèle est un diagramme représentant, au sein d’un système, les relations
entre ses divers composants. Les techniques de modélisation habituellement utilisées en ges-
tion de la qualité comprennent :
■ les diagrammes de causalité, également appelés diagrammes d’Ishikawa ou diagrammes
en arêtes de poisson, qui illustrent les relations possibles entre divers facteurs et des pro-
blèmes ou des effets potentiels. La figure 8-2 présente un diagramme de causalité géné-
rique ;
■ les logigrammes ou schémas de processus décrivent l’interaction entre les divers compo-
sants d’un système. La figure 8-3 présente un logigramme de révision de conception.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
98 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 8 — Gestion de la qualité du projet

Figure 8-2 Diagramme de causalité

La modélisation peut aider l’équipe de projet à anticiper la nature et l’emplacement des


éventuels problèmes de qualité ; elle peut, par conséquent, aider à élaborer des approches
pour les traiter.
.4 Prototypage. Le prototypage est une technique statistique aidant à identifier les facteurs ayant
un impact sur des variables spécifiques. Cette technique s’applique le plus fréquemment au
produit résultant du projet (par exemple, les concepteurs d’automobiles peuvent vouloir iden-
tifier la combinaison de suspension et de pneus produisant, à un coût raisonnable, la
meilleure tenue de route).
Toutefois, on peut aussi l’appliquer aux questions de gestion de projet, telles que les com-
promis entre les coûts et les délais. Par exemple, des ingénieurs confirmés coûteront plus cher
que des débutants, mais finiront sans doute leur travail en moins de temps. Une « expérience »
bien conçue (dans le cas présent, le calcul des coûts et des durées du projet selon les diverses
combinaisons d’ingénieurs confirmés et débutants) permettra souvent d’identifier la solution
optimale, à partir d’un nombre de cas relativement limité.
.5 Coût de la qualité. Le coût de la qualité fait référence au coût total de tous les efforts entre-
pris pour obtenir un produit ou un service de qualité ; il couvre tout le travail visant à assurer
la conformité aux spécifications, ainsi que celui résultant de la non-conformité aux spécifi-
cations. Il existe trois types de coûts encourus : les coûts de prévention, d’évaluation et des
défauts, ces derniers étant divisés en coûts internes et externes.

8.1.3 Données de sortie de la planification de la qualité


.1 Plan de gestion de la qualité. Le plan de gestion de la qualité décrit la mise en œuvre de la
politique de qualité de l’équipe de gestion de projet. La terminologie ISO 9000 stipule qu’il
doit décrire le système de qualité du projet, c’est-à-dire « la structure organisationnelle, les res-
ponsabilités, les procédures, les processus et les ressources nécessaires à la gestion de la qua-
lité » (5).
Le plan de gestion de la qualité constitue une donnée d’entrée du plan de l’ensemble du
projet (décrit à la section 4.1, « Élaboration du plan de projet ») et doit aborder le contrôle,
l’assurance et l’amélioration de la qualité du projet.
Selon les besoins du projet, le plan de gestion de la qualité peut être formel ou non, très
détaillé ou global.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
99
Chapitre 8 — Gestion de la qualité du projet

Figure 8-3 | 8.2.2.2

Figure 8-3 Exemple de schéma de processus

.2 Définitions opérationnelles. Une définition opérationnelle décrit, en termes très spécifiques,


une opération précise et la manière dont celle-ci est mesurée par le processus de contrôle de
la qualité. Par exemple, dire que le respect des dates programmées du planning est une
mesure de la qualité de la gestion n’est pas suffisant ; l’équipe de gestion du projet doit aussi
indiquer si chaque activité doit démarrer, ou simplement finir, dans les délais ; si chaque acti-
vité sera mesurée ou si simplement certains produits livrables le seront, et si oui, lesquels.
Dans certains domaines d’application, les définitions opérationnelles sont également appelées
indicateurs.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
100 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 8 — Gestion de la qualité du projet

.3 Listes de contrôle. Une liste de contrôle est un outil structuré, généralement spécifique à un
élément, que l’on utilise pour vérifier l’exécution d’une série d’étapes requises. Les listes de
contrôle peuvent être simples ou complexes. Elles sont généralement composées d’instruc-
tions (« Faites ceci ! ») ou de questions (« Avez-vous fait ceci ? »). De nombreuses organisations
disposent de listes de contrôle standard, garantissant l’homogénéité de tâches fréquentes.
Dans certains domaines d’application, les listes de contrôle sont également disponibles auprès
d’associations professionnelles ou de sociétés de services.
.4 Données d’entrée pour les autres processus. Le processus de planification de la qualité peut
permettre d’identifier le besoin d’une nouvelle activité dans un autre domaine.

8.2 ASSURANCE DE LA QUALITÉ


L’assurance de la qualité englobe toutes les activités programmées et systématiques mises en
œuvre dans le cadre du système de qualité pour s’assurer du respect par le projet de toutes
les normes de qualité applicables (6). Elle doit être présente tout au long du projet. Avant
l’élaboration des normes ISO 9000, les activités décrites dans la planification de la qualité fai-
saient communément partie de l’assurance de la qualité.
Celle-ci est souvent du ressort d’un service d’assurance de la qualité ou d’un service por-
tant un nom semblable ; cela n’est pas obligatoire.
Elle peut être fournie à l’équipe de gestion de projet et à la direction de l’entreprise rea-
lisatrice (assurance de la qualité interne) ou au client et à d’autres entités qui ne sont pas acti-
vement impliqués dans les activités du projet (assurance de la qualité externe).

8.2.1 Données d’entrée de l’assurance de la qualité


.1 Plan de gestion de la qualité. Le plan de gestion de la qualité est décrit à la section 8.1.3.1.
.2 Résultats des mesures du contrôle de la qualité. Les mesures du contrôle de la qualité sont
des données résultant des tests et des mesures du contrôle de la qualité, enregistrées dans un
format permettant la comparaison et l’analyse.
.3 Définitions opérationnelles. Les définitions opérationnelles sont décrites à la section 8.1.3.2.

8.2.2 Outils et méthodes de l’assurance de la qualité


.1 Outils et méthodes de planification de la qualité. Les outils et méthodes de planification de la
qualité décrits à la section 8.1.2 peuvent également servir à l’assurance de la qualité.
.2 Audits qualité. Un audit qualité est un examen structuré des autres activités de gestion de la
qualité. Il permet d’identifier les leçons retenues qui pourront améliorer les performances du

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
101
Chapitre 8 — Gestion de la qualité du projet

projet en cours ou des autres projets de l’entreprise. Les audits qualité peuvent être pro-
8.2.3 | 8.3.2.4

grammés ou aléatoires, et effectués par des auditeurs internes ayant reçu la formation adé-
quate ou par des tiers, tels que des agences d’audit qualité.

8.2.3 Données de sortie de l’assurance de la qualité


.1 Amélioration de la qualité. L’amélioration de la qualité consiste à améliorer l’efficacité du
projet afin que les acteurs en tirent davantage de bénéfices. Dans la plupart des cas, la mise
en œuvre des améliorations de la qualité nécessitera de préparer des demandes de change-
ments ou d’entreprendre des mesures correctives, et suivra les procédures de contrôle intégré
des changements décrites à la section 4.3.

8.3 CONTRÔLE DE LA QUALITÉ


Le contrôle de la qualité consiste à contrôler les résultats spécifiques du projet, afin de déter-
miner s’ils sont conformes aux normes de qualité applicables et d’identifier les causes de
résultats insatisfaisants. Il doit être effectué tout au long du projet. Les résultats du projet com-
prennent à la fois les résultats du produit, tels que les produits livrables, et les résultats de
la gestion de projet, tels que les performances de coûts et de délais. Le contrôle de la qualité
est souvent réalisé par un service de contrôle de la qualité ou par un service portant un nom
semblable ; cela n’est pas obligatoire.
L’équipe de gestion de projet doit avoir une connaissance pratique du contrôle statistique
de la qualité, notamment en ce qui concerne l’échantillonnage et les probabilités, afin d’être
en mesure d’évaluer les données de sortie du contrôle de la qualité. Il peut lui être utile de
connaître, entre autres choses, les différences entre :
■ la prévention (éviter les erreurs dans le processus) et l’inspection (éviter que les erreurs
ne soient découvertes par le client) ;
■ l’échantillonnage des attributs (le résultat est conforme, ou non) et l’échantillonnage des
variables (le résultat est évalué par rapport à une échelle continue de mesure du degré de
conformité) ;
■ les causes particulières (événements inhabituels) et les causes aléatoires (variations nor-
males du processus) ;
■ les tolérances (le résultat est acceptable s’il se situe dans la fourchette de tolérance fixée)
et les limites de contrôle (le processus est sous contrôle si le résultat se situe dans les
limites indiquées).

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
102 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 8 — Gestion de la qualité du projet

8.3.1 Données d’entrée du contrôle de la qualité


.1 Travail réalisé. Le travail réalisé (décrit à la section 4.2.3.1) comprend à la fois les résultats du
processus et ceux du produit. Des informations sur les résultats prévus ou attendus (extraites
du plan de projet), ainsi que celles sur les résultats réels, doivent être disponibles.
.2 Plan de gestion de la qualité. Le plan de gestion de la qualité est décrit à la section 8.1.3.1.
.3 Définitions opérationnelles. Les définitions opérationnelles sont décrites à la section 8.1.3.2.
.4 Listes de contrôle. Les listes de contrôle sont décrites à la section 8.1.3.3.

8.3.2 Outils et méthodes du contrôle de la qualité


.1 Inspection. L’inspection comprend des activités telles que les mesures, les examens et les
tests, permettant de déterminer la conformité des résultats aux spécifications. Des inspections
peuvent être effectuées à n’importe quel niveau (par exemple, on peut inspecter les résul-
tats d’une seule activité ou le produit final du projet). Les inspections ont des appellations
diverses : révisions, revues de produit, audits et révisions de projet ; dans certains domaines
d’application, ces termes ont un sens restreint et particulier.
.2 Fiches de contrôle. Les fiches de contrôle sont des représentations graphiques des résultats
d’un processus dans le temps. Elles servent à déterminer si le processus est « sous contrôle »
(par exemple, les différences de résultats ont-elles pour origine des variations aléatoires, ou
bien sont-elles dues à des événements inhabituels dont la cause doit être identifiée et cor-
rigée ?). Lorsqu’un processus est sous contrôle, il n’est pas besoin de l’ajuster. On peut tou-
tefois encore le modifier pour obtenir des améliorations.
Les fiches de contrôle aident à surveiller n’importe quel type de variable de sortie. Bien
que le plus souvent utilisées pour suivre des activités répétitives, telles que la fabrication par
lots, elles peuvent également servir à surveiller les écarts de coûts et de prévisions, le nombre
et la fréquence des changements du contenu, les erreurs dans les documents du projet ou
d’autres résultats de gestion, et permettre ainsi de déterminer si le processus de gestion de
projet est sous contrôle. La figure 8-4 est une fiche de contrôle des performances de délais
d’un projet.
.3 Diagrammes de Pareto. Un diagramme de Pareto est un histogramme, présenté par ordre de
fréquence d’occurrence, montrant combien de résultats ont été générés par type ou catégorie
de causes identifiées (voir la figure 8-5). Ce classement par ordre permet de guider l’action
corrective ; l’équipe de projet doit agir en premier lieu pour éliminer les problèmes à l’origine
du plus grand nombre de défauts. Les diagrammes de Pareto sont conceptuellement liés à la
loi de Pareto qui stipule qu’un nombre relativement faible de causes est à l’origine de la
grande majorité des problèmes ou défauts. Ceci est communément désigné par l’expression
principe 80/20, où 80 % des problèmes sont dus à 20 % des causes.
.4 Échantillonnage statistique. L’échantillonnage statistique implique de choisir une partie de la
population intéressée pour l’inspecter (par exemple, sélectionner dix dessins techniques au
hasard dans une liste en comportant soixante-quinze). Un échantillonnage adéquat peut sou-
vent réduire les coûts du contrôle de la qualité. Il existe un corpus de connaissances sub-
stantiel en matière d’échantillonnage statistique ; dans certains domaines d’application, il est
nécessaire que l’équipe de gestion de projet connaisse l’éventail des méthodes d’échantillon-
nage.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
103
Chapitre 8 — Gestion de la qualité du projet

Figure 8–4 | Figure 8–5

Figure 8-4 Fiche de contrôle des performances de délais du projet

.5 Modélisation. La modélisation est décrite à la section 8.1.2.3. Elle est utilisée dans le contrôle
de la qualité pour aider à analyser l’origine des problèmes.
.6 Analyse des tendances. L’analyse des tendances consiste à utiliser des techniques mathéma-
tiques pour prévoir les résultats futurs, en se basant sur l’historique des résultats. On l’utilise
souvent pour surveiller :
■ les performances techniques : combien d’erreurs ou de défauts identifiés, combien qui ne
sont pas corrigés ;
■ les performances de coûts et de délais : combien d’activités achevées par période avec des
écarts significatifs.

8.3.3 Données de sortie du contrôle de la qualité


.1 Amélioration de la qualité. L’amélioration de la qualité est décrite à la section 8.2.3.1.
.2 Décisions d’acceptation. Les éléments inspectés sont soit acceptés, soit rejetés. Ces derniers
peuvent nécessiter des reprises (décrites à la section 8.3.3.3).
.3 Reprises. Une reprise est une action visant à rendre conforme aux besoins ou aux spécifi-
cations un élément non conforme ou défectueux. Dans la plupart des domaines d’application,
une reprise, plus particulièrement une reprise imprévue, entraîne fréquemment un dépasse-
ment des objectifs du projet. L’équipe de projet devra s’efforcer de limiter les reprises.
.4 Listes de contrôle remplies. Voir la section 8.1.3.3. Si des listes de contrôle sont utilisées, elles
doivent être mises dans le dossier du projet une fois remplies.
.5 Corrections de processus. Les corrections de processus impliquent de prendre des mesures
correctives ou préventives immédiates, consécutives aux mesures du contrôle de la qualité.
Dans certains cas, la correction doit être effectuée selon les procédures du contrôle intégré
des changements, décrites à la section 4.3.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
104 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 8 — Gestion de la qualité du projet

Figure 8-5 Diagramme de Pareto

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
105
Chapitre 9

Gestion des ressources


humaines du projet

La gestion des ressources humaines du projet comprend les processus nécessaires à l’opti-
misation de l’utilisation des personnes impliquées dans le projet. Elle englobe tous les acteurs
du projet : commanditaires, clients, partenaires, participants individuels, etc., décrits à la sec-
tion 2.2. La figure 9-1 présente les processus principaux suivants :
9.1 Planification de l’organisation : identifier, documenter et attribuer les rôles, les res-
ponsabilités et les relations hiérarchiques des intervenants du projet.
9.2 Obtention des ressources humaines : faire en sorte que les ressources nécessaires
soient affectées au projet et y travaillent.
9.3 Développement de l’équipe : développer les compétences individuelles et de groupe
afin d’améliorer les performances du projet.
Ces processus interagissent entre eux et avec les processus d’autres disciplines. Chaque
processus peut nécessiter la participation d’une ou plusieurs personnes ou d’un ou plusieurs
groupes, selon les besoins du projet. Habituellement, tous les processus sont exécutés au
moins une fois au cours de chaque phase du projet.
Bien que les processus soient présentés ici comme des éléments distincts avec des inter-
faces bien définies, ils peuvent dans la pratique se chevaucher et interagir d’une manière non
détaillée dans ce chapitre. Les interactions entre processus sont décrites au chapitre 3.
Il existe de nombreux ouvrages sur l’interaction entre personnes dans un contexte opé-
rationnel évolutif. Parmi les nombreux thèmes abordés :
■ entraîner, communiquer, négocier et autres sujets, traités à la section 2.4, « Compétences
majeures en gestion » ;
■ déléguer, motiver, encadrer, guider et autres sujets ayant trait aux relations entre les indi-
vidus ;
■ construire une équipe, gérer les conflits et autres sujets ayant trait aux relations entre les
groupes d’individus ;
■ évaluation des performances, recrutement, maintien de l’effectif, relations avec le per-
sonnel, normes d’hygiène et de sécurité et autres sujets ayant trait à l’administration des
ressources humaines.
La plupart de ces matières sont directement applicables à la direction et à la gestion du
personnel dans un projet, et le chef de projet et l’équipe de gestion de projet doivent les
connaître. Cependant, ils doivent également être attentifs à la manière d’appliquer ces
connaissances dans le projet. Par exemple :

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
107
Chapitre 9 — Gestion des ressources humaines du projet

Figure 9–1 | 9.1.1.2

Figure 9-1 Vue d’ensemble de la gestion des ressources humaines du projet

■ les projets étant par nature temporaires, les relations personnelles et structurelles seront
généralement à la fois temporaires et nouvelles. L’équipe de gestion du projet doit choisir
soigneusement les méthodes convenant aux relations transitoires de ce type ;
■ la nature et le nombre des acteurs du projet évoluent souvent au fur et à mesure que le
projet change de phase de cycle de vie. Il en résulte que les méthodes adaptées à une
phase ne le sont pas nécessairement à une autre. L’équipe de gestion de projet doit veiller
à utiliser les méthodes qui conviennent aux besoins du moment ;
■ les activités liées à l’administration des ressources humaines relèvent rarement de la res-
ponsabilité directe de l’équipe de gestion du projet. Toutefois, celle-ci doit avoir une
connaissance suffisante des exigences administratives pour s’assurer de leur respect.
Remarque : selon le type de secteur d’activité ou d’organisation auquel ils appartiennent,
les chefs de projet peuvent aussi être responsables du redéploiement et de la disponibilité des
ressources humaines.

9.1 PLANIFICATION DE L’ORGANISATION


La planification de l’organisation consiste à identifier, documenter et attribuer les rôles, les res-
ponsabilités et les relations hiérarchiques au sein du projet. Ces attributions peuvent se faire

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
108 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 9 — Gestion des ressources humaines du projet

au profit d’individus ou de groupes. Les individus et les groupes peuvent faire partie de l’or-
ganisation en charge du projet ou venir de l’extérieur. Les groupes internes sont souvent asso-
ciés à un service fonctionnel spécifique, tel que l’ingénierie, le marketing ou la comptabilité.
Dans la plupart des projets, l’essentiel de la planification de l’organisation est effectué
durant les phases initiales du projet. Néanmoins, les résultats de ce processus doivent être
examinés régulièrement, tout au long du projet, afin de s’assurer qu’ils conviennent toujours.
Si l’organisation initiale ne convient plus, il faut alors la réviser rapidement.
Vu l’importance de l’impact qu’aura la structure organisationnelle du projet sur les besoins
en communication du projet, la planification de l’organisation est souvent étroitement liée à
la planification des communications (décrite à la section 10.1).

9.1.1 Données d’entrée de la planification de l’organisation


.1 Interfaces du projet. Les interfaces du projet appartiennent généralement à l’une des trois
catégories suivantes :
■ les interfaces organisationnelles : relations hiérarchiques formelles ou non entre les dif-
férents services de l’organisation. Ces interfaces peuvent être très complexes ou très
simples. Par exemple, l’élaboration d’un système de télécommunication complexe peut
demander la coordination de nombreux sous-traitants pendant plusieurs années, tandis
que l’élimination d’une erreur de programmation dans un système installé sur un seul site
ne demandera guère plus que d’avertir l’utilisateur et le personnel en charge du fonction-
nement, une fois l’activité achevée.
■ les interfaces techniques : relations hiérarchiques formelles ou non entre les différentes
disciplines techniques. Ces interfaces se produisent aussi bien pendant les phases du
projet (par exemple, la conception du site par les ingénieurs en génie civil doit être com-
patible avec la superstructure élaborée par les ingénieurs en structure) qu’entre les phases
du projet (par exemple, lorsqu’une équipe de conception automobile transmet les résul-
tats de son travail à l’équipe responsable de la création du nouvel outillage nécessaire à
la fabrication du véhicule).
■ les interfaces interpersonnelles : relations hiérarchiques formelles ou non entre les diffé-
rentes personnes affectées au projet.
Toutes ces interfaces ont souvent lieu simultanément comme, par exemple, lorsqu’un
architecte employé par une société de design explique les principales préoccupations en
matière de conception à l’équipe de gestion de projet d’un sous-traitant avec laquelle il n’a
aucun lien hiérarchique.
.2 Besoins en personnel. Les besoins en personnel établissent le type de compétences et de pro-
fils d’individus ou de groupes nécessaires, et la durée du travail nécessaire. Les besoins en
personnel constituent un sous-ensemble des besoins globaux en ressources identifiés au cours
de la planification des ressources (décrite à la section 7.1).

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
109
Chapitre 9 — Gestion des ressources humaines du projet

.3 Contraintes. Les contraintes sont des facteurs limitant les options de l’équipe de projet. Les
9.1.1.3 | 9.1.3.4

options organisationnelles d’un projet peuvent être soumises à des contraintes de différentes
façons. Le plus souvent, les facteurs qui restreignent l’organisation de l’équipe sont, entre
autres :
■ la structure de l’entreprise réalisatrice : une organisation dont la structure de base est une
matrice forte implique que le rôle du chef de projet sera relativement plus important que
celui du même poste dans une organisation dont la structure de base est une matrice
faible (voir la section 2.3.3 pour plus de détails sur les structures organisationnelles) ;
■ les conventions collectives : les accords contractuels passés avec des syndicats ou d’autres
groupements de salariés peuvent imposer certains rôles ou certaines relations hiérar-
chiques (le groupement de salariés est, par essence, un acteur) ;
■ les préférences de l’équipe de gestion de projet : si des membres de cette équipe ont eu
du succès avec certaines structures par le passé, ils favoriseront probablement des struc-
tures semblables à l’avenir ;
■ les affectations de personnel escomptées : la façon dont le projet est organisé dépend sou-
vent des compétences spécifiques de certaines personnes.

9.1.2 Outils et méthodes de la planification de l’organisation


.1 Modèles et formulaires. Bien que chaque projet soit unique, la plupart se ressemblent plus ou
moins. Le processus de planification de l’organisation peut être plus rapide si l’on utilise la
définition des rôles et des responsabilités ou les relations hiérarchiques d’un projet semblable.
.2 Pratiques en ressources humaines. Beaucoup d’organisations ont une politique, des lignes
directrices et des procédures diverses pouvant aider l’équipe de gestion de projet dans de
nombreux aspects de la planification de l’organisation. Par exemple, une organisation consi-
dérant le chef comme un « mentor » disposera probablement d’une documentation décrivant
la façon dont ce rôle doit être rempli.
.3 Théorie des organisations. Il existe de nombreux ouvrages décrivant comment les organisa-
tions peuvent et doivent être structurées. Bien qu’une minorité de ceux-ci aborde tout parti-
culièrement les structures de projet, l’équipe de gestion de projet doit connaître la théorie des
organisations de façon à mieux répondre aux exigences du projet.
.4 Analyse des acteurs. L’identification des acteurs et les besoins des différents acteurs doivent
être analysés pour en assurer la satisfaction. La section 10.1.2.1 traite de l’analyse des acteurs
avec plus de détails.

9.1.3 Données de sortie de la planification de l’organisation


.1 Attribution des rôles et des responsabilités. Au sein du projet, les rôles (qui fait quoi) et les
responsabilités (qui décide quoi) doivent être attribués aux acteurs appropriés. Les rôles et les
responsabilités peuvent évoluer au fil du temps. La plupart des rôles et des responsabilités
seront attribués aux acteurs activement impliqués dans les activités du projet, tels que le chef
de projet, les autres membres de l’équipe de gestion du projet et les différents participants.
Dans la plupart des projets, le rôle et les responsabilités du chef de projet sont en général
essentiels, mais ils varient grandement selon le domaine d’application.
Les rôles et les responsabilités au sein du projet doivent être étroitement liés à la défini-
tion du contenu du projet. Une matrice des responsabilités (voir la figure 9-2) est souvent uti-

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
110 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 9 — Gestion des ressources humaines du projet

Figure 9-2 Matrice des responsabilités

lisée pour cela. Les projets de plus grande envergure peuvent contenir une matrice des res-
ponsabilités sur plusieurs niveaux. Par exemple, une matrice des responsabilités à haut niveau
peut définir quel groupe ou quel service est responsable de chaque élément de l’organi-
gramme des tâches, alors que les matrices des responsabilités de niveau inférieur sont utili-
sées au sein du groupe pour attribuer aux diverses personnes les rôles et les responsabilités
correspondant à des activités spécifiques.
.2 Plan de gestion du personnel. Ce plan décrit quand et comment les ressources humaines
seront affectées et retirées de l’équipe de projet. Selon les besoins, le plan de gestion du per-
sonnel peut être formel ou non, très détaillé ou formulé dans ses grandes lignes. C’est un élé-
ment annexe au plan de projet (voir la section 4.1, « Élaboration du plan de projet »).
Le plan de gestion du personnel comporte souvent des histogrammes de ressources,
comme à la figure 9-3.
On doit veiller particulièrement à la manière dont les membres de l’équipe de projet (per-
sonnes ou groupes) sont dessaisis de leurs responsabilités une fois qu’ils ne sont plus néces-
saires au projet. Des procédures de réaffectation adéquates peuvent :
■ faire baisser les coûts en réduisant ou en éliminant la tendance au « bricolage » pour meu-
bler le temps entre deux affectations ;
■ améliorer le moral en réduisant ou en éliminant l’incertitude quant aux futures possibilités
d’emploi.
.3 Organigramme. Un organigramme est une représentation graphique des liens hiérarchiques
au sein d’un projet. Selon les besoins du projet, il peut être formel ou non, très détaillé ou for-
mulé dans ses grandes lignes. Par exemple, l’organigramme d’un projet impliquant un service
interne de trois à quatre personnes ne sera probablement pas aussi rigoureux et détaillé que
celui d’une équipe d’intervention en cas de catastrophe de 3000 personnes.
Un organigramme fonctionnel (OF) est un type particulier d’organigramme identifiant, au
sein de l’organisation, les services responsables des différents lots de travail.
.4 Informations détaillées. Les informations détaillées associées à la planification de l’organisa-
tion dépendent du champ d’application et de la taille du projet. Les informations le plus sou-
vent trouvées dans les pièces jointes sont, entre autres :

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
111
Capítulo 9 — Gestión de los Recursos Humanos del Proyecto

Figure 9–3 | 9.2.2.1

Figure 9-3 Histogramme des ressources

■ l’impact de l’organisation : possibilités exclues d’office par le type d’organisation choisi ;


■ les descriptions de postes : descriptions générales par postes des compétences, responsa-
bilités, autorité conférée, environnement physique et autres caractéristiques attachées à
l’exécution d’un travail donné. Également appelées descriptions de fonctions ;
■ les besoins en formation : si le personnel à affecter ne possède pas les compétences
requises par le projet, l’acquisition de ces compétences devra faire partie du projet.

9.2 OBTENTION DES RESSOURCES HUMAINES


L’obtention des ressources humaines consiste à s’assurer que le personnel nécessaire (indi-
vidus ou groupes) soit affecté au projet et y travaille. Dans la plupart des environnements, il
se peut que les « meilleures » ressources ne soient pas disponibles. L’équipe de gestion du
projet doit alors veiller à ce que les ressources qui le sont répondent aux exigences du projet.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
112 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 9 — Gestion des ressources humaines du projet

9.2.1 Données d’entrée de l’obtention des ressources humaines


.1 Plan de gestion du personnel. Ce plan est décrit à la section 9.1.3.2. Il comprend les besoins
en ressources humaines du projet, décrits à la section 9.1.1.2.
.2 Description de l’ensemble du personnel. Lorsque l’équipe de gestion du projet est en mesure
d’infléchir ou de diriger les affectations de personnel, elle doit prendre en compte les carac-
téristiques du personnel éventuellement disponible. Ceci comprend, entre autres :
■ l’expérience acquise : les personnes ou les groupes ont-ils déjà effectué un travail simi-
laire ? L’ont-ils fait convenablement ?
■ les intérêts personnels : les personnes ou les groupes souhaitent-ils travailler sur ce projet ?
■ les caractéristiques personnelles : les personnes ou les groupes pourront-ils travailler
ensemble au sein d’une équipe ?
■ la disponibilité : les personnes ou les groupes les plus réclamés seront-ils disponibles pen-
dant les périodes nécessaires ?
■ les compétences : quelles sont les compétences requises et à quel niveau le sont-elles ?
.3 Pratiques de recrutement. Il se peut que l’une ou plusieurs organisations impliquées dans
le projet aient une politique, des lignes directrices ou des procédures régissant l’affectation du
personnel. Dans ce cas, de telles pratiques constituent des restrictions au processus d’obten-
tion des ressources humaines.

9.2.2 Outils et méthodes d’obtention des ressources humaines


.1 Négociations. Dans la plupart des projets, les affectations de personnel doivent être négo-
ciées. Par exemple, l’équipe de gestion de projet peut avoir à négocier avec :
■ les responsables fonctionnels pour s’assurer que le projet se verra attribuer du personnel
aux compétences adéquates pendant la période de temps nécessaire ;
■ d’autres équipes de gestion de projet au sein de l’entreprise réalisatrice pour affecter
convenablement les ressources rares ou spécialisées.
Les capacités de l’équipe à influencer l’organisation (voir la section 2.4.5, « Influencer l’or-
ganisation ») jouent un rôle important dans les négociations concernant les affectations du per-
sonnel, tout comme la politique des organisations impliquées dans le projet. Par exemple, un
responsable fonctionnel peut être récompensé en fonction de l’utilisation de son personnel.
Ceci l’incite à affecter du personnel disponible ne répondant pas forcément à toutes les exi-
gences du projet.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
113
Chapitre 9 — Gestion des ressources humaines du projet

.2 Préaffectations. Dans certains cas, du personnel peut être préaffecté au projet. Ceci se pro-
9.2.2.2 | 9.3.2.4

duit lorsque : a) le projet résulte d’un appel d’offres, et des ressources humaines particulières
ont été promises dans le cadre de l’offre ou, b) le projet est un projet de service interne, et
les affectations de personnel ont été définies dans la charte du projet.
.3 Recrutement à l’extérieur. La gestion des approvisionnements du projet (décrite au chapitre
12) peut permettre d’obtenir les services de personnes ou de groupes de personnes particu-
liers pour réaliser les activités du projet. Ceci est nécessaire lorsque l’entreprise ne dispose
pas du personnel interne dont elle a besoin pour réaliser le projet (par exemple, suite à la
décision délibérée de ne pas embaucher ces personnes comme salariés à plein temps, parce
que les employés aux compétences adéquates ont déjà été affectés à d’autres projets, ou suite
à d’autres circonstances).

9.2.3 Données de sortie de l’obtention des ressources humaines


.1 Personnel affecté au projet. Le projet est doté de personnel lorsqu’on est sûr que les per-
sonnes adéquates y ont été affectées. Le personnel peut être affecté à plein temps, à temps
partiel ou en fonction des besoins du projet.
.2 Répertoire de l’équipe de projet. Le répertoire de l’équipe de projet est une liste de tous les
membres de l’équipe de projet et des autres acteurs. Selon les besoins du projet, il peut être
formel ou non, très détaillé ou présenté dans ses grandes lignes.

9.3 DÉVELOPPEMENT DE L’ÉQUIPE


Le développement de l’équipe consiste aussi bien à renforcer l’aptitude des acteurs à contri-
buer au projet individuellement qu’à renforcer l’aptitude de l’équipe à fonctionner en tant que
telle. Le développement au niveau individuel (managérial et technique) est indispensable au
développement de l’équipe. Le développement de l’équipe est essentiel pour que le projet
puisse atteindre ses objectifs.
Le développement de l’équipe dans un projet se complique souvent lorsque les membres
de l’équipe sont sous les ordres, à la fois, d’un responsable fonctionnel et du chef de projet
(voir la section 2.3.3 qui traite des matrices organisationnelles). Bien gérer ces doubles liens
hiérarchiques est souvent un facteur essentiel à la réussite du projet, et dont la responsabi-
lité incombe en général au chef de projet.
Bien qu’au chapitre 3 le développement de l’équipe soit présenté comme l’un des pro-
cessus d’exécution, il a lieu tout au long du projet.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
114 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 9 — Gestion des ressources humaines du projet

9.3.1 Données d’entrée du développement de l’équipe


.1 Ressources humaines du projet. L’obtention des ressources humaines du projet est décrite
à la section 9.2.3.1. Les affectations de personnel définissent implicitement les compétences
des personnes et de l’équipe sur lesquelles on pourra s’appuyer.
.2 Plan de projet. Le plan de projet est décrit à la section 4.1.3.1. Il décrit le contexte technique
dans lequel l’équipe va travailler.
.3 Plan de gestion du personnel. Ce plan est décrit à la section 9.1.3.2.
.4 Rapports d’avancement. Les rapports d’avancement (décrits à la section 10.3.3.1) fournissent
à l’équipe de projet un retour d’information sur les performances, par rapport au plan du
projet.
.5 Retour d’informations de l’extérieur. L’équipe de projet doit périodiquement mesurer ses per-
formances par rapport aux attentes des tiers externes au projet.

9.3.2 Outils et méthodes de développement de l’équipe


.1 Activités de développement de l’esprit d’équipe. Ces activités englobent les actions de ges-
tion et les actions individuelles visant particulièrement et principalement à améliorer les per-
formances de l’équipe. De nombreuses actions, telles que faire participer au processus de
planification les membres de l’équipe n’appartenant pas à la direction ou établir des règles de
base pour aplanir et gérer les conflits, peuvent avoir comme effet secondaire d’améliorer les
performances de l’équipe. Les activités de développement de l’esprit d’équipe peuvent varier,
depuis un sujet abordé en cinq minutes au cours d’une réunion de projet normale, jusqu’à des
séminaires prolongés et organisés à l’extérieur par des professionnels, dont l’objectif est
d’améliorer les relations entre les acteurs majeurs.
Il existe de nombreux ouvrages traitant du développement de l’esprit d’équipe. En règle
générale, l’équipe de gestion de projet doit connaître les différentes activités de développe-
ment de l’esprit d’équipe.
.2 Compétences en gestion. Les compétences en gestion (traitées à la section 2.4) ont une
importance particulière pour le développement de l’équipe.
.3 Systèmes d’appréciation du personnel. Les systèmes d’appréciation du personnel sont des
actions formelles de gestion visant à promouvoir ou à renforcer le comportement souhaité.
Pour être efficaces, ces systèmes doivent établir un lien clair, explicite et réalisable entre les
performances du projet et les récompenses. Par exemple, si l’on souhaite récompenser un
chef de projet pour l’atteinte des objectifs de coût du projet, celui-ci doit bénéficier d’un
niveau de contrôle adéquat sur les décisions concernant les ressources humaines et les appro-
visionnements.
Il faut souvent que les projets aient leur propre système d’appréciation du personnel car
ceux de l’entreprise réalisatrice peuvent ne pas convenir. Par exemple, l’employé prêt à faire
des heures supplémentaires pour respecter un planning serré doit être récompensé, tandis
que celui qui doit faire des heures supplémentaires suite à une mauvaise planification ne doit
pas l’être.
Les systèmes d’appréciation du personnel doivent également prendre en compte les dif-
férences culturelles. Par exemple, il peut être très difficile de mettre sur pied un mécanisme
adapté d’appréciation de l’équipe dans une culture qui encourage l’individualisme.
.4 Regroupement. Le regroupement consiste à rassembler au même endroit tous, ou presque
tous, les membres les plus actifs de l’équipe de projet pour améliorer leur capacité à travailler
ensemble. Le regroupement est largement utilisé dans les grands projets et peut être aussi effi-
cace pour les petits projets (par exemple, établir un quartier général où l’équipe peut se
retrouver, afficher les plannings et les mises à jour, etc.). Dans certains projets, le regroupe-
ment n’est pas toujours possible ; on peut alors prévoir des réunions fréquentes afin d’en-
courager l’interaction entre les membres de l’équipe.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
115
Chapitre 9 — Gestion des ressources humaines du projet

.5 Formation. La formation englobe toutes les activités d’amélioration des compétences de


9.3.2.5 | Chapitre 10

l’équipe de projet. Certains auteurs font la distinction entre formation, éducation et dévelop-
pement, mais ces distinctions ne sont ni homogènes, ni reconnues par la majorité. La forma-
tion peut être formelle (par exemple, formation en salle, formation sur matériel informatique)
ou informelle (par exemple, retour d’informations des autres membres de l’équipe). Il existe
de nombreux ouvrages sur la formation continue.
Si les membres de l’équipe de projet n’ont pas les compétences techniques ou de gestion
nécessaires, l’acquisition de celles-ci devra faire partie du projet, ou des mesures devront être
prises pour affecter un personnel adéquat au projet. Les coûts directs et indirects issus de la
formation sont en général assumés par l’entreprise réalisatrice.

9.3.3 Données de sortie du développement de l’équipe


.1 Amélioration des performances. L’amélioration des performances de l’équipe peut avoir de
nombreuses origines et avoir un impact sur de nombreux aspects des performances du projet :
■ l’ amélioration des compétences individuelles peut permettre à une personne donnée d’ef-
fectuer avec plus d’efficacité les activités qui lui ont été attribuées ;
■ l’amélioration du comportement de l’équipe (par exemple, aplanissement et gestion des
conflits) peut permettre aux membres de l’équipe de concentrer leurs efforts sur les acti-
vités techniques ;
■ l’amélioration des compétences, soit individuelles, soit de l’équipe, peut aider à identifier
et à développer de meilleures manières de travailler.
.2 Éléments d’évaluation des performances. Les membres du projet doivent en principe fournir
des éléments d’évaluation des performances des autres membres de l’équipe de projet avec
lesquels ils sont amenés à travailler fréquemment.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
116 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 10

Gestion des communications


du projet

La gestion des communications du projet comprend les processus nécessaires à assurer, en


temps voulu et de façon adéquate, la rédaction, la collecte, la diffusion, l’archivage et le trai-
tement final des informations concernant le projet. Elle établit les liens critiques entre les per-
sonnes, les idées et les informations nécessaires au succès. Toute personne impliquée dans le
projet doit être prête à envoyer et à recevoir des communications et doit comprendre à quel
point celles dans lesquelles elle est impliquée en tant qu’individu affectent le projet dans son
ensemble. La figure 10-1 présente les processus principaux suivants :
10.1 Planification des communications : déterminer les besoins des acteurs en matière
d’information et de communication ; qui a besoin de quelles informations, quand et sous
quelle forme.
10.2 Diffusion de l’information : mettre les informations nécessaires à la disposition des
acteurs du projet en temps voulu.
10.3 Rapports d’avancement : rassembler et diffuser les informations sur les performances.
Ceci comprend les rapports sur l’état du projet, les mesures d’avancement et les prévi-
sions.
10.4 Clôture administrative : générer, rassembler et diffuser les informations permettant
d’officialiser l’achèvement du projet ou d’une de ses phases.
Ces processus interagissent entre eux et avec les processus d’autres disciplines. Chaque
processus peut nécessiter la participation d’une ou plusieurs personnes ou d’un ou plusieurs
groupes, selon les besoins du projet. Habituellement, tous les processus sont exécutés au
moins une fois au cours de chaque phase du projet.
Bien que les processus soient présentés ici comme des éléments distincts avec des inter-
faces bien définies, ils peuvent dans la pratique se chevaucher et interagir d’une manière non
détaillée dans ce chapitre. Les interactions entre processus sont décrites au chapitre 3.
Les compétences en gestion dans le domaine de la communication (traitées à la section
2.4.2) s’apparentent, sans être identiques, à la gestion des communications du projet. La com-
munication est un sujet plus vaste comportant un corpus important de connaissances qui ne
s’appliquent pas qu’au contexte d’un projet. Par exemple :
■ les modèles expéditeur-destinataire : boucles de retour d’informations, obstacles à la com-
munication, etc. ;
■ le choix des moyens de communication : quand communiquer par écrit ou oralement,
quand écrire un mémo informel ou un rapport en bonne et due forme, etc.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
117
Chapitre 10 — Gestion des communications du projet

Figure 10–1 | 10.1.1.1

Figure 10-1 Vue d’ensemble de la gestion des communications du projet

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
118 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 10 — Gestion des communications du projet

■ le style : voix active ou passive, structure des phrases, choix des mots, etc. ;
■ les techniques de présentation : langage du corps, conception des aides visuelles, etc. ;
■ les méthodes de conduite de réunion : préparation de l’ordre du jour, gestion des conflits,
etc.

10.1 PLANIFICATION DES COMMUNICATIONS


La planification des communications consiste à déterminer les besoins des acteurs en matière
d’information et de communication : qui a besoin de quelles informations, quand, sous quelle
forme et de qui. Bien que tous les projets requièrent la communication des informations les
concernant, les besoins en information et les méthodes de diffusion varient grandement. Iden-
tifier les besoins en information des acteurs et déterminer les moyens adéquats de répondre
à ces besoins est un facteur important à la réussite du projet.
Dans la plupart des projets, la majeure partie de la planification des communications est
intégrée aux toutes premières phases du projet. Néanmoins, les résultats de ce processus doi-
vent être systématiquement revus tout au long du projet et au besoin révisés afin de s’assurer
qu’ils sont toujours applicables.
La planification des communications est souvent étroitement liée à la planification de l’or-
ganisation (décrite à la section 9.1), car la structure organisationnelle du projet a un impact
très important sur les besoins en communications du projet.

10.1.1 Données d’entrée de la planification des communications


.1 Besoins en communications. Les besoins en communications sont la somme des besoins en
information des acteurs du projet. Ils sont définis en associant le type et le moyen de diffu-
sion des informations requises à une analyse de la valeur de ces informations. Les ressources
du projet doivent être utilisées uniquement pour la communication d’informations contribuant
à sa réussite ou lorsqu’un manque de communication peut entraîner un échec. Les informa-
tions habituellement nécessaires à l’évaluation des besoins en communication du projet com-
prennent :
■ les relations de responsabilité entre les acteurs et l’organisation du projet ;
■ les disciplines, les services et les spécialités impliqués dans le projet ;
■ la logistique concernant le nombre de personnes impliquées dans le projet et leur empla-
cement ;
■ les besoins en information externe (par exemple, la communication avec les médias).

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
119
Chapitre 10 — Gestion des communications du projet

.2 Technologie des communications. Les technologies ou les méthodes employées pour dissé-
10.1.1.2 | 10.2.2.2

miner les informations entre les acteurs du projet varient considérablement : elles peuvent
prendre la forme de conversations brèves ou de réunions prolongées, de simples documents
écrits ou de plannings et de bases de données directement accessibles en ligne.
Les facteurs technologiques des communications pouvant avoir un impact sur le projet
comprennent :
■ l’urgence du besoin en information : la réussite du projet dépend-elle de la disponibilité à
tout moment d’informations fréquemment mises à jour, ou des rapports écrits envoyés
régulièrement suffisent-ils ?
■ la technologie disponible : les systèmes déjà en place conviennent-ils, ou les besoins du
projet justifient-ils des changements ?
■ la composition prévue de l’équipe de projet : les systèmes de communication proposés
sont-ils compatibles avec l’expérience et la compétence des participants du projet, ou doit-
on prévoir une formation et un entraînement approfondis ?
■ la durée du projet : la technologie disponible est-elle susceptible de changer avant la fin
du projet ?
.3 Contraintes. Les contraintes sont des facteurs limitant les options de l’équipe de gestion de
projet. Par exemple, si le volume d’achat est important, une plus grande attention devra être
apportée au traitement des informations contractuelles.
Lorsqu’un projet est réalisé sous contrat, il existe souvent des dispositions contractuelles
spécifiques concernant la planification des communications.
.4 Hypothèses. Voir la section 4.1.1.5.

10.1.2 Outils et méthodes de la planification des communications


.1 Analyse des acteurs. Les besoins en information des différents acteurs, ainsi que leurs sources
d’informations, doivent être analysés afin d’en avoir une vision méthodique et logique et de
pouvoir y répondre (la section 2.2 traite des acteurs plus en détail). L’analyse doit prendre en
compte les méthodes et les technologies, adaptées au projet, qui fourniront les informations
nécessaires. Il faut prendre soin d’éviter le gaspillage des ressources dû à des informations
inutiles ou à une technologie non appropriée.

10.1.3 Données de sortie de la planification des communications


.1 Plan de gestion des communications. Un plan de gestion des communications est un docu-
ment qui fournit :
■ une structure de collecte et de classement précisant les méthodes à utiliser pour rassem-
bler et stocker les différents types d’information. Les procédures doivent également pré-
ciser les modalités de collecte et de diffusion des mises à jour et des corrections ;
■ une structure de diffusion précisant les destinataires des informations (rapports d’état, don-
nées, planning, documentation technique, etc.) et le format de diffusion (rapports écrits,
réunions, etc.) des différents types d’information. Cette structure doit être compatible avec
les responsabilités et les relations hiérarchiques décrites par l’organigramme du projet ;
■ une description des informations à diffuser indiquant le format, le contenu, le degré de
détail et les conventions/définitions à utiliser ;
■ des calendriers d’émission précisant le moment d’émission de chaque type de communi-
cation ;
■ des méthodes d’accès aux informations entre les communications prévues ;
■ une méthode de mise à jour du plan de gestion des communications, au fur et à mesure
de la progression et de l’évolution du projet.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
120 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 10 — Gestion des communications du projet

Selon les besoins du projet, le plan de gestion des communications peut être formel ou
non, très détaillé ou formulé dans ses grandes lignes. C’est un élément annexe du plan de
projet global (décrit à la section 4.1).

10.2 DIFFUSION DE L’INFORMATION


La diffusion de l’information consiste à mettre, en temps voulu, les informations nécessaires
à la disposition des acteurs du projet. Elle comprend la mise en œuvre du plan de gestion des
communications, ainsi que la réponse aux demandes d’information imprévues.

10.2.1 Données d’entrée de la diffusion de l’information


.1 Travail réalisé. Le travail réalisé est décrit à la section 4.2.3.1.
.2 Plan de gestion des communications. Le plan de gestion des communications est décrit à la
section 10.1.3.1.
.3 Plan de projet. Le plan de projet est décrit à la section 4.1.3.1.

10.2.2 Outils et méthodes de diffusion de l’information


.1 Compétences en communication. Les compétences en communication favorisent l’échange
des informations. L’expéditeur a la responsabilité de communiquer des informations claires,
complètes et sans ambiguïté, pour que le destinataire les reçoive correctement et pour
confirmer qu’elles sont bien comprises. Le destinataire doit s’assurer qu’il a bien reçu toutes
les informations et qu’il les a bien comprises. La communication a de multiples dimensions :
■ écrite et orale, écouter et parler ;
■ interne (au sein du projet) et externe (à l’attention du client, des médias, du public, etc.) ;
■ formelle (rapports, briefings, etc.) et informelle (mémos, conversations ad hoc, etc.) ;
■ verticale (par les voies hiérarchiques de l’entreprise) et horizontale (entre collègues et avec
une entreprise partenaire).
.2 Systèmes d’extraction de l’information. Les membres de l’équipe et les acteurs peuvent par-
tager des informations en utilisant diverses méthodes, comme les systèmes de classement
manuels, les bases de données électroniques, les logiciels de gestion de projet et les systèmes
d’accès à la documentation technique telle que les dessins d’ingénierie, les spécifications de
conception, les plans d’essais, etc.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
121
Chapitre 10 — Gestion des communications du projet

.3 Méthodes de diffusion de l’information. Les informations sur le projet peuvent être diffusées
10.2.2.3 | 10.3.2.5

en utilisant de nombreuses méthodes : réunions de projet, diffusion de documents papier,


accès partagé à des bases de données électroniques mises en réseau, télécopie, courrier élec-
tronique, messagerie vocale, visioconférence et intranet du projet.

10.2.3 Données de sortie de la diffusion de l’information


.1 Dossiers du projet. Les dossiers du projet peuvent contenir de la correspondance, des mémos
et des documents le décrivant. Ces informations doivent, dans la mesure du possible et si cela
est justifié, être conservées de manière organisée. Souvent, les membres de l’équipe de projet
conservent des archives personnelles dans un carnet de projet.
.2 Rapports du projet. Rapports officiels sur l’état du projet et/ou sur les problèmes.
.3 Présentations du projet. L’équipe de projet donne des informations à un ou à tous les acteurs
du projet de façon officielle ou informelle. L’information correspond aux besoins de ceux qui
la reçoivent et la méthode de présentation est adaptée.

10.3 RAPPORTS D’AVANCEMENT


Les rapports d’avancement consistent à rassembler et à diffuser les informations concernant
les performances, afin de fournir aux acteurs des informations sur l’utilisation des ressources
pour atteindre les objectifs du projet. Ce processus comprend :
■ les rapports de situation décrivant où en est le projet ; par exemple, l’état des indicateurs
de planning et de budget ;
■ les rapports d’avancement décrivant les réalisations de l’équipe de projet ; par exemple,
le pourcentage d’achèvement par rapport au plan, ou ce qui est terminé par rapport à ce
qui est en cours ;
■ les prévisions de la situation et de l’avancement futurs du projet.
Les rapports d’avancement doivent en général présenter des informations sur le contenu,
les délais, les coûts et la qualité. De nombreux projets nécessitent également des informations
sur les risques et les approvisionnements. Les rapports peuvent être préparés globalement ou
dans des situations exceptionnelles.

10.3.1 Données d’entrée des rapports d’avancement


.1 Plan de projet. Le plan de projet est traité à la section 4.1.3.1. Il contient les diverses réfé-
rences utilisées pour l’évaluation des performances du projet.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
122 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 10 — Gestion des communications du projet

.2 Travail réalisé. Le travail réalisé (quels produits livrables ont été achevés, complètement ou
partiellement, quels coûts (et/ou ressources) ont été encourus ou engagés, etc.) est une
donnée de sortie de la mise en œuvre du plan de projet (traitée à la section 4.2.3.1). Il doit
être rapporté dans le cadre fourni par le plan de gestion des communications. Une informa-
tion précise et uniforme sur le travail réalisé est essentielle à la création de rapports d’avan-
cement utiles.
.3 Autres documents du projet. Les dossiers du projet sont traités à la section 10.2.3.1. En plus
du plan de projet et du travail réalisé, les autres documents du projet contiennent souvent des
informations relatives au contexte du projet, qui doivent être prises en compte dans l’éva-
luation des performances du projet.

10.3.2 Outils et méthodes des rapports d’avancement


.1 Examens du rendement. Les examens du rendement sont des réunions organisées pour éva-
luer l’état et/ou l’avancement du projet. Habituellement, ils sont utilisés conjointement à une
ou plusieurs techniques de compte rendu d’avancement décrites ci-dessous.
.2 Analyse des écarts. L’analyse des écarts consiste à comparer les résultats réels du projet aux
résultats planifiés ou prévus. Les écarts de coûts et de prévisions sont les plus fréquemment
analysés, mais souvent les écarts par rapport au plan sur le contenu, les ressources, la qualité
et les risques sont aussi importants ou plus importants.
.3 Analyse des tendances. L’analyse des tendances consiste en un examen des résultats du
projet au fil du temps pour déterminer si les performances s’améliorent ou se détériorent.
.4 Analyse de la valeur acquise. L’analyse de la valeur acquise, sous ses formes diverses, est la
méthode de mesure des performances la plus couramment employée. Elle intègre les mesures
du contenu, des coûts (ou des ressources) et des délais pour permettre à l’équipe de gestion
de projet d’évaluer les performances de ce dernier. L’analyse de la valeur acquise implique le
calcul de trois valeurs clés pour chaque activité :
■ la valeur planifiée (VP), appelée auparavant coût budgété du travail prévu (CBTP), cor-
respond à cette portion du budget approuvé que l’on a prévu de dépenser pour l’activité
pendant une période donnée ;
■ le coût réel (CR), appelé auparavant coût réel du travail effectué (CRTE), correspond à la
totalité des coûts encourus pour travailler sur l’activité pendant une période de temps
donnée. Ce coût réel doit correspondre à ce qui a été budgété (quel que soit ce budget)
pour la VP et la VA (exemple : heures directes uniquement, coûts directs uniquement ou
tous les coûts, y compris les coûts indirects) ;
■ la VA, appelée auparavant coût budgété du travail réalisé (CBTR), correspond à la valeur
du travail réellement achevé.
Ces trois valeurs sont combinées pour mesurer la réalisation du travail planifié. Les
mesures les plus couramment utilisées sont l’écart de coûts (EC = VA – CR) et l’écart de pré-
visions (EP = VA – VP). Ces deux valeurs, écart de coûts et écart de prévisions, peuvent être
converties en indicateurs d’efficacité afin de refléter les performances des coûts et des délais
de n’importe quel projet. L’indice de performance des coûts (IPC = VA/CR) est l’indicateur
d’efficacité des coûts le plus couramment utilisé. L’IPC cumulé (somme de tous les budgets
des VA individuelles divisée par la somme de tous les CR individuels) est largement utilisé
pour prévoir le coût du projet à son achèvement. En outre, l’indice de performance délais (IPD =
VA/VP) est parfois utilisé conjointement à l’IPC pour prévoir la date d’achèvement du projet.
.5 Outils et méthodes de diffusion de l’information. Les rapports d’avancement sont diffusés à
l’aide des outils et des méthodes décrits à la section 10.2.2.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
123
Chapitre 10 — Gestion des communications du projet

Figure 10–2 | 10.4.3.1

Figure 10-2 Rapport des performances sous forme de graphique

Figure 10-3 Rapport d’avancement sous forme de tableau

10.3.3 Données de sortie des rapports d’avancement


.1 Rapports d’avancement. Les rapports d’avancement organisent et résument les informations
obtenues et présentent le résultat des analyses. Ils doivent fournir le genre d’informations et
le degré de détail demandés par les différents acteurs, tels que décrits dans le plan de gestion
des communications.
Les formats courants des rapports d’avancement comprennent les diagrammes à barres
(appelés aussi diagrammes de Gantt), les courbes en S, les histogrammes et les tableaux. La
figure 10-2 utilise des courbes en S pour représenter les données cumulées de l’analyse de
la VA, tandis que la figure 10-3 représente un ensemble de données de VA différent sous
forme de tableau.
.2 Demandes de changements. L’analyse des performances du projet entraîne souvent des
demandes de changements pour certains aspects du projet. Ces demandes de changements
sont traitées de la façon décrite dans les divers processus de contrôle des changements (par
exemple, gestion des changements du contenu, contrôle du planning, etc.).

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
124 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 10 — Gestion des communications du projet

10.4 CLÔTURE ADMINISTRATIVE


Le projet ou une de ses phases doit être clos après avoir atteint ses objectifs ou après qu’on
y ait mis fin pour d’autres raisons. La clôture administrative consiste à documenter les résul-
tats du projet pour officialiser l’acceptation du produit du projet par le commanditaire ou le
client. Elle comprend la collecte des dossiers du projet (en s’assurant qu’ils reflètent bien les
spécifications finales) ; l’analyse du succès, de l’efficacité et des leçons retenues du projet ; et
l’archivage de ces informations pour utilisation ultérieure.
Les activités faisant partie de la clôture administrative ne doivent pas être repoussées à
l’achèvement du projet. Chaque phase du projet doit être convenablement conclue pour s’as-
surer qu’aucune information importante et utile ne se perde. En outre, les compétences des
employés, enregistrées dans la base de données de l’ensemble du personnel, doivent être
mises à jour pour refléter les nouvelles compétences et aptitudes.

10.4.1 Données d’entrée de la clôture administrative


.1 Documentation sur la mesure des performances. Toute la documentation produite pour enre-
gistrer et analyser les performances du projet, y compris les documents de planification ayant
établi la base de la mesure des performances, doit être disponible pour consultation pendant
la clôture administrative.
.2 Documentation du produit. Les documents produits pour décrire le produit du projet (plans,
spécifications, documentation technique, dessins, fichiers électroniques, etc. — la termino-
logie varie selon le champ d’application) doivent également être disponibles pour consul-
tation pendant la clôture administrative.
.3 Autres documents du projet. Les autres documents du projet sont traités à la section 10.2.3.1.

10.4.2 Outils et méthodes de la clôture administrative


.1 Outils et méthodes des rapports d’avancement. Les outils et méthodes des rapports d’avan-
cement sont traités à la section 10.3.2.
.2 Rapports du projet. Voir la section 10.2.3.2.
.3 Présentations du projet. Voir la section 10.3.3.3.

10.4.3 Données de sortie de la clôture administrative


.1 Archives du projet. Un jeu complet de dossiers du projet indexés doit être préparé pour archi-
vage par les acteurs concernés. Toutes les bases de données de l’historique du projet, spéci-
fiques au projet ou concernant tout le programme, doivent être mises à jour. Lorsque les
projets sont réalisés sous contrat ou lorsqu’ils impliquent des approvisionnements importants,
une attention particulière doit être apportée à l’archivage des documents financiers.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
125
Chapitre 10 — Gestion des communications du projet

.2 Clôture du projet. La confirmation que le projet répond à toutes les demandes du client
10.4.3.2 | Chapitre 11

concernant le produit du projet (le client a officiellement accepté les résultats et les produits
livrables du projet) et aux besoins de l’entreprise : par exemple, évaluations du personnel,
rapports sur le budget, leçons retenues, etc.
.3 Leçons retenues. Les leçons retenues sont traitées à la section 4.3.3.3.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
126 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 11

Gestion des risques du projet

La gestion des risques est le processus systématique d’identification, d’analyse et de réduction


des risques du projet. Elle implique d’optimiser la probabilité et les conséquences des évé-
nements favorables et de minimiser la probabilité et les conséquences des événements défa-
vorables aux objectifs du projet. La figure 11-1 donne une vue d’ensemble des principaux
processus suivants :
11.1 Planification de la gestion des risques : déterminer l’approche à suivre et la manière
de planifier les activités du projet liées à la gestion des risques.
11.2 Identification des risques : déterminer les risques susceptibles d’avoir des répercus-
sions sur le projet et documenter leurs caractéristiques.
11.3 Analyse qualitative des risques : analyser qualitativement les risques, afin de classer
leur effet sur les objectifs du projet par ordre de priorité.
11.4 Analyse quantitative des risques : mesurer la probabilité et les conséquences des
risques et évaluer leur impact sur les objectifs du projet.
11.5 Développement des stratégies de réponse : établir des procédures et des méthodes
destinées à augmenter les opportunités et à réduire les menaces affectant les objectifs
du projet.
11.6 Suivi et contrôle des risques : surveiller les risques résiduels, identifier de nouveaux
risques, mettre en œuvre les plans de réduction des risques et évaluer leur efficacité
durant le cycle de vie du projet.
Ces processus interagissent entre eux et avec les processus d’autres disciplines. Chaque
processus peut nécessiter la participation d’une ou plusieurs personnes ou d’un ou plusieurs
groupes, selon les besoins du projet. Habituellement, tous les processus sont exécutés au
moins une fois au cours de chaque phase du projet. Bien que les processus soient présentés
ici comme des éléments distincts avec des interfaces bien définies, ils peuvent dans la pra-
tique se chevaucher et interagir d’une manière non détaillée dans ce chapitre. Les interactions
entre processus sont décrites au chapitre 3.
Un risque est une condition ou un événement incertain qui, s’il se concrétise, a un impact
positif ou négatif sur un objectif du projet. Un risque a une cause et, s’il se produit, un impact.
Par exemple, obtenir un permis ou avoir peu de personnel affecté au projet peut constituer
une cause. La composante événement du risque réside dans le fait que l’obtention du permis
peut prendre plus longtemps que prévu ou que le personnel peut ne pas être à la hauteur de
la tâche. Si l’un ou l’autre de ces événements se produit, les coûts, les délais ou la qualité du
projet sont affectés. Les conditions liées à un risque peuvent comprendre certains aspects de
l’environnement du projet pouvant contribuer aux risques, tels que de mauvaises pratiques
de gestion de projet ou la dépendance par rapport à des participants externes que l’on ne
peut pas contrôler.
Les risques comprennent aussi bien ce qui menace les objectifs du projet que les oppor-
tunités d’améliorer ces objectifs. Ils ont pour origine l’incertitude présente dans tous les pro-
jets. Les risques connus sont ceux qui ont été identifiés et analysés et auxquels il est possible

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
127
Chapitre 11 — Gestion des risques du projet

Chapitre 11 — Gestion des risques du projet

Figure 11–1 | 11.1.1.6

Figure 11-1 Vue d’ensemble de la gestion des risques

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
128 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 11 — Gestion des risques du projet

de se préparer. Les risques inconnus ne sont pas gérables, bien que les chefs de projet puis-
sent les prendre en compte en établissant une provision générale basée sur l’expérience
acquise au cours de projets similaires.
Les organisations perçoivent le risque comme une menace à la réussite du projet. Les
risques constituant des menaces peuvent être acceptés s’ils sont compensés par les avantages
à tirer de cette acceptation. Par exemple, l’adoption d’un planning d’exécution accélérée, sus-
ceptible de ne pas être respecté, est un risque que l’on prend pour achever le projet plus tôt.
On peut prendre des risques pour tirer parti de certaines circonstances dans la mesure où
celles-ci sont favorables aux objectifs du projet.
Pour réussir, l’organisation doit être prête à étudier, tout au long du projet, la question de
la gestion des risques. On mesure l’engagement de l’organisation par les efforts entrepris pour
rassembler des données de bonne qualité sur les risques et leurs caractéristiques.

11.1 PLANIFICATION DE LA GESTION DES RISQUES


La planification de la gestion des risques consiste à décider de la marche à suivre et de la pla-
nification des activités de projet concernant la gestion des risques. Il est important de plani-
fier les processus de gestion des risques décrits ci-après pour s’assurer que l’importance, le
type et le niveau de visibilité de la gestion de risques sont proportionnels à la fois au niveau
de risque général et à l’importance du projet pour l’organisation.

11.1.1 Données d’entrée de la planification de la gestion des risques


.1 Charte du projet. La charte du projet est traitée à la section 5.1.3.1.
.2 Politique de l’organisation en matière de gestion des risques. Certaines organisations peuvent
avoir des approches déjà définies en matière d’analyse et de stratégies de réponse aux risques.
Celles-ci doivent être adaptées pour chaque projet.
.3 Rôles et responsabilités définis. Les rôles, les responsabilités et les niveaux d’autorité pré-
définis pour la prise de décision influenceront la planification.
.4 Tolérance au risque des acteurs du projet. Les organisations et les individus n’ont pas tous la
même tolérance au risque. Cette différence est visible dans la politique exprimée ou se révèle
dans les actions mises en place.
.5 Modèles et formulaires de plan de gestion des risque. Certaines organisations ont créé des
modèles (ou un formulaire standard) que l’équipe de projet peut utiliser. L’organisation conti-
nuera à améliorer le modèle et/ou le formulaire, en fonction de son adéquation et de son uti-
lité au projet.
.6 Organigramme des tâches (OT). L’OT est décrit à la section 5.3.3.1.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
129
Chapitre 11 — Gestion des risques du projet

11.1.2 Outils et méthodes de planification de la gestion des risques


11.1.2 | 11.2.1.3

.1 Réunions de planification. Les équipes de projet organisent des réunions de planification pour
élaborer le plan de gestion des risques. Les participants comprennent le chef de projet, les
responsables de chaque groupe de l’équipe de projet, tout membre de l’organisation dont la
responsabilité est de gérer la planification des risques et la mise en œuvre des activités, les
acteurs clés et d’autres, s’il y a lieu. Ils utilisent des modèles et formulaires de gestion des
risques et, au besoin, d’autres données d’entrée.

11.1.3 Données de sortie de la planification de la gestion des risques


.1 Plan de gestion des risques. Le plan de gestion des risques décrit la manière dont l’identifi-
cation, les analyses qualitative et quantitative, le développement des stratégies de réponse, le
suivi et le contrôle des risques seront organisés et réalisés durant le cycle de vie du projet.
Il ne s’intéresse pas aux stratégies de réponse à chaque risque ; ceci est accompli dans le plan
des stratégies de réponse, traité à la section 11.5.3.1. Le plan de gestion des risques peut
inclure :
■ la méthodologie. Elle définit les approches, les outils et les sources de données pouvant
être utilisés pour gérer les risques de ce projet. Divers types d’évaluations peuvent
convenir suivant la phase du projet, la quantité d’informations disponibles et la flexibi-
lité restante dans la gestion des risques ;
■ les rôles et les responsabilités. Ils définissent qui dirige, soutient et participe à chaque type
d’action décrit dans le plan de gestion des risques. Les équipes de gestion des risques
extérieures aux projets sont susceptibles d’effectuer des analyses des risques indépen-
dantes et plus impartiales que celles organisées par l’équipe de projet ;
■ l’élaboration d’un budget. Il s’agit du budget de gestion des risques du projet ;
■ la fréquence. Elle définit à quels intervalles le processus de gestion des risques devra être
appliqué tout au long du cycle de vie du projet. Les résultats doivent être obtenus assez
tôt pour influer sur les décisions. Les décisions prises doivent être revues et corrigées
périodiquement pendant l’exécution du projet ;
■ la notation et l’interprétation. Méthodes de notation et d’interprétation des résultats cor-
respondant au type et à la fréquence des analyses qualitative et quantitative des risques
effectuées. Pour pouvoir être cohérentes, ces méthodes doivent être fixées à l’avance ;
■ les seuils. Critères de seuil des risques au-delà desquels une action sera entreprise, par qui
et de quelle manière. Le responsable, le client ou le commanditaire du projet peuvent ne
pas avoir le même seuil de risque. Le seuil acceptable correspond à l’objectif par rapport
auquel l’équipe de projet mesurera l’efficacité de la mise en œuvre du plan des stratégies
de réponse ;
■ les éditions. Elles décrivent le contenu et le format du plan des stratégies de réponse décrit
à la section 11.5.3.1. Elles définissent la manière dont les résultats des processus de ges-
tion des risques devront être documentés, analysés et communiqués, entre autres, à
l’équipe de projet, aux acteurs internes et externes, et aux commanditaires ;
■ le suivi. Il documente le mode d’enregistrement de toutes les facettes des activités liées
aux risques qui pourraient être utiles au projet en cours ainsi qu’aux besoins futurs, et
contribuer aux leçons retenues. Il précise si les processus liés aux risques doivent faire
l’objet d’audits, et de quelle manière.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
130 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 11 — Gestion des risques du projet

11.2 IDENTIFICATION DES RISQUES


L’identification des risques consiste à déterminer ceux susceptibles d’affecter le projet et à
en répertorier les caractéristiques.
En général, les participants à l’identification des risques comprennent, dans la mesure du
possible : l’équipe de projet, l’équipe de gestion des risques, des experts sur le sujet appar-
tenant à d’autres services de l’entreprise, les clients, les utilisateurs finaux, d’autres chefs de
projet, les acteurs et des experts extérieurs.
L’identification des risques est un processus itératif. Elle peut être effectuée, la première
fois, par une partie de l’équipe de projet ou par l’équipe de gestion des risques. L’équipe de
projet au complet et les principaux acteurs peuvent effectuer une deuxième itération. Pour
obtenir une analyse impartiale, des personnes n’étant pas impliquées dans le projet peuvent
effectuer ce processus une dernière fois.
Il est souvent possible dès l’identification des risques d’élaborer et même de mettre en
œuvre des stratégies de réponse simples et efficaces.

11.2.1 Données d’entrée de l’identification des risques


.1 Plan de gestion des risques. Ce plan est décrit à la section 11.1.3.
.2 Données de sortie de la planification du projet. L’identification des risques nécessite une com-
préhension de la mission et du contenu du projet, ainsi que des objectifs du responsable, du
commanditaire ou des acteurs. Les données de sortie en provenance d’autres processus doi-
vent être examinées, afin d’identifier les risques éventuels sur l’ensemble du projet. Il peut
s’agir entre autres de :
■ la charte du projet ;
■ l’OT ;
■ la description du produit ;
■ l’estimation des coûts et des délais ;
■ le plan des ressources ;
■ le plan des approvisionnements ;
■ la liste des hypothèses et celle des contraintes.
.3 Catégories de risques. Les risques pouvant avoir un impact, positif ou négatif, sur le projet
peuvent être identifiés et organisés par catégories. Ces catégories doivent être bien définies et
refléter les origines courantes des risques pour le secteur d’activité ou le domaine d’applica-
tion concerné. Elles comprennent :
■ les risques liés à la technologie, à la qualité ou aux performances ; par exemple : miser
sur une technologie complexe ou qui n’a pas encore fait ses preuves, fixer des objectifs
de performance irréalistes, ou encore modifier la technologie utilisée ou les normes indus-
trielles en cours de projet ;

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
131
Chapitre 11 — Gestion des risques du projet

■ les risques liés à la gestion du projet : par exemple, une mauvaise répartition du temps
11.2.1.4 | 11.3

et des ressources, la qualité médiocre du plan de projet ou une mauvaise utilisation des
techniques de gestion de projet ;
■ les risques liés à l’organisation : par exemple, fixer des objectifs incohérents en matière de
coûts, de délais et de contenu, l’absence de classement des projets par ordre de priorité,
un financement inadéquat ou interrompu, ou des conflits d’allocation de ressources entre
les divers projets de l’organisation ;
■ les risques externes : par exemple, un changement d’environnement juridique ou régle-
mentaire, les questions relatives au travail, un changement de priorité au niveau du res-
ponsable, les risques inhérents au pays et les conditions climatiques. Les risques de type
force majeure, tels que les tremblements de terre, les inondations ou les guerres civiles,
nécessitent des actions de grande envergure plutôt qu’une gestion de risques.
.4 Données historiques. Les informations concernant les projets précédents peuvent être obte-
nues à partir des sources suivantes :
■ dossiers de projets : une ou plusieurs organisations impliquées dans le projet peuvent
avoir conservé des documents sur les résultats d’un projet précédent que l’on pourra uti-
liser pour l’identification des risques. Il peut s’agir des rapports finaux ou des plans de stra-
tégies de réponse du projet. L’historique peut contenir des leçons retenues organisées,
décrivant les problèmes et leur résolution, ou alors être tiré de l’expérience des acteurs du
projet ou d’autres personnes au sein de l’organisation.
■ des informations publiées : bases de données commerciales, études théoriques, étalonnage
et autres études publiées sont disponibles dans de nombreux domaines d’application.

11.2.2 Outils et méthodes d’identification des risques


.1 Revues de la documentation. Une consultation structurée des plans et des hypothèses du
projet (au niveau à la fois de l’ensemble du projet et du contenu détaillé de celui-ci), des dos-
siers de projets précédents ainsi que d’autres informations, constitue en général la première
tâche des équipes de projet.
.2 Méthodes de collecte des informations. Les exemples de méthodes employées pour rassem-
bler des informations au cours de l’identification des risques peuvent inclure le remue-
méninges, la méthode de Delphes, les entretiens et l’analyse des forces, faiblesses,
opportunités et menaces (analyse SWOT en anglais).
■ Le remue-méninges. Le remue-méninges est probablement la méthode d’identification des
risques la plus fréquemment utilisée. Il a pour objet d’obtenir une liste exhaustive des
risques pouvant être traités ultérieurement dans les processus d’analyse qualitative et
quantitative.
En principe, les séances de remue-méninges ont lieu au sein de l’équipe de projet,
mais elles peuvent également rassembler un ensemble d’experts pluridisciplinaires. Guidés
par un animateur, les participants font part de leurs idées concernant les risques du projet.
Les sources de risques sont identifiées dans leurs grandes lignes et affichées pour que tous
les participants les étudient durant la réunion. Les risques sont ensuite catégorisés par type
et détaillés.
■ La technique de Delphes. La technique de Delphes est un moyen d’obtenir un consensus
entre des experts sur un sujet tel que les risques du projet. Ces experts sur les risques des
projets sont connus, mais leur participation est anonyme.
À l’aide d’un questionnaire, un animateur sollicite des idées concernant les risques
importants du projet. Les réponses sont soumises, puis circulent entre les experts qui
feront d’autres commentaires. Après quelques séances de ce type, un consensus est
obtenu sur les risques principaux du projet. La technique de Delphes aide à limiter la par-
tialité lors de la consultation des données et évite qu’une personne particulière ait une trop
grande influence sur le résultat.
■ Les entretiens. On peut identifier les risques grâce à des entretiens menés avec des chefs
de projet expérimentés ou des experts sur le sujet. La personne en charge de l’identifica-
tion des risques recherche les individus compétents, leur présente le projet et leur donne

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
132 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 11 — Gestion des risques du projet

des informations telles que l’OT et la liste des hypothèses. Les personnes interrogées iden-
tifient les risques potentiels en se basant sur leur expérience, sur les données du projet
et sur d’autres sources jugées utiles.
■ L’analyse des forces, faiblesses, opportunités et menaces (analyse SWOT en anglais). Il s’agit
de l’examen du projet du point de vue des forces, faiblesses, opportunités et menaces
visant à étendre le périmètre des risques considérés.
.3 Listes de contrôle. Les listes de contrôle pour l’identification des risques peuvent être éla-
borées à partir des historiques et des connaissances accumulés au cours de projets précédents
semblables et d’autres sources d’informations. Un des avantages inhérents à une liste de
contrôle est la rapidité et la simplicité de l’identification des risques. Un de ses inconvénients
est qu’il est impossible d’établir une liste de contrôle des risques exhaustive et, de ce fait, l’uti-
lisateur peut être limité aux catégories figurant sur la liste. Il faut prendre soin de prendre en
compte des éléments absents d’une liste standard s’ils se rapportent au projet concerné. La
liste de contrôle doit détailler tous les types de risques envisageables pour le projet. Il est
important de l’examiner comme une étape formelle de toute procédure de clôture de projet
pour améliorer la liste des risques potentiels et leur description.
.4 Analyse des hypothèses. Chaque projet est conçu et élaboré en se basant sur un ensemble de
suppositions, de scénarios ou d’hypothèses. L’analyse des hypothèses est une méthode qui en
explore la validité. Elle identifie les risques dus à l’inexactitude, au manque de cohérence ou
au caractère incomplet des hypothèses.
.5 Techniques de construction de diagrammes. Les techniques de construction de diagrammes
peuvent comprendre :
■ les diagrammes de causalité (également appelés diagrammes d’Ishikawa ou en arêtes de
poisson) : utiles pour identifier les causes des risques (décrits à la section 8.1.2.3) ;
■ les logigrammes ou schémas de processus : représentent l’interaction entre les diverses
composantes d’un système et le mécanisme de relation de cause à effet (décrits à la sec-
tion 8.1.2.3) ;
■ les diagrammes d’influence : la représentation graphique d’un problème indiquant les
influences causales, l’ordre des événements dans le temps et les autres relations entre les
variables et les résultats.

11.2.3 Données de sortie de l’identification des risques


.1 Risques. Un risque est une circonstance ou un événement incertain qui, s’il se concrétise, a
un impact positif ou négatif sur un objectif du projet.
.2 Symptômes annonciateurs. Les symptômes annonciateurs, parfois appelés déclencheurs ou
signes d’avertissement, sont une indication de la présence ou de l’imminence d’un risque. Par
exemple, le manque d’étapes jalons intermédiaires peut être le premier signe avertissant d’un
retard imminent sur le planning.
.3 Données d’entrée pour les autres processus. L’identification des risques peut déterminer le
besoin d’une nouvelle activité dans un autre domaine. Par exemple, l’OT ne contient pas suf-
fisamment de détails pour permettre une bonne identification des risques ou le planning est
incomplet ou manque de logique.

11.3 ANALYSE QUALITATIVE DES RISQUES


L’analyse qualitative des risques est le processus consistant à évaluer l’impact et la probabilité
des risques identifiés. Elle classe les risques par ordre d’importance de leur effet possible sur
les objectifs du projet. Il s’agit d’un des moyens utilisés pour déterminer l’attention à accorder
à des risques particuliers et guider les stratégies de réponse. L’urgence des actions liées aux
risques peut exagérer l’importance d’un risque. Une évaluation de la qualité des informations
disponibles aide également à modifier l’évaluation du risque envisagé. L’analyse qualitative
des risques implique que la probabilité et l’impact des risques seront évalués à l’aide de
méthodes et d’outils d’analyse qualitative reconnus. La présence de tendances dans les résul-

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
133
Chapitre 11 — Gestion des risques du projet

tats, lorsque l’analyse qualitative est effectuée de manière répétitive, peut nécessiter une ges-
11.3.1 | 11.3.2.4

tion des risques plus ou moins conséquente. L’utilisation de ces outils aide à corriger la par-
tialité souvent présente dans un plan de projet. L’analyse qualitative des risques doit être
revue et corrigée durant le cycle de vie du projet pour rester cohérente avec les changements
au niveau des risques du projet. Ce processus peut conduire à une analyse plus approfondie
à l’aide de l’analyse quantitative des risques (11.4) ou directement à la planification des stra-
tégies de réponse (11.5).

11.3.1 Données d’entrée de l’analyse qualitative des risques


.1 Plan de gestion des risques. Ce plan est décrit à la section 11.1.3.
.2 Risques identifiés. Les risques découverts au cours de l’identification des risques sont évalués,
ainsi que leur impact potentiel sur le projet.
.3 État du projet. L’incertitude quant à un risque dépend souvent de la progression du projet
durant son cycle de vie. Au début du projet, peu de risques ont déjà fait surface, la concep-
tion du projet n’est pas encore arrivée à maturité, et des modifications peuvent avoir lieu. La
découverte d’autres risques est donc possible.
.4 Type de projet. Il est plus facile de comprendre la probabilité de la concrétisation des évé-
nements à risque et leurs conséquences dans le cadre de projets courants ou récurrents. Les
projets qui utilisent une technologie de pointe ou novatrice, ou les projets très complexes,
comportent souvent un plus grand degré d’incertitude.
.5 Niveau de précision des données. La précision indique dans quelle mesure un risque est
connu et compris. Elle mesure l’étendue des données disponibles, ainsi que leur fiabilité.
L’origine des données utilisées pour identifier les risques doit être évaluée.
.6 Échelles de probabilité et d’impact. Ces échelles, décrites à la section 11.3.2.2, doivent
servir à l’évaluation des deux dimensions clés d’un risque, décrites à la section 11.3.2.1.
.7 Hypothèses. Les hypothèses identifiées lors du processus d’identification des risques sont
évaluées comme des risques potentiels (voir les sections 4.1.1.5 et 11.2.2.4).

11.3.2 Outils et méthodes d’analyse qualitative des risques


.1 Probabilité et impact des risques. La probabilité et les conséquences des risques peuvent être
décrites par des qualificatifs, tels que très élevé, élevé, moyen, faible ou très faible.
La probabilité d’un risque est la vraisemblance de son occurrence.
Les conséquences d’un risque correspondent aux répercussions sur les objectifs du projet,
en cas de concrétisation du risque.
Ces deux dimensions d’un risque sont appliquées à des événements spécifiques, et non
à l’ensemble du projet. L’analyse des risques à l’aide de la probabilité et des conséquences
aide à identifier les risques devant faire l’objet d’une gestion active.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
134 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 11 — Gestion des risques du projet

.2 Matrice de classification de la probabilité et de l’impact des risques. On peut créer une


matrice qui classifie les risques ou les circonstances en fonction d’échelles de probabilité et
d’impact conjuguées (très faible, faible, moyen, élevé et très élevé). Les risques dont la pro-
babilité et l’impact sont élevés nécessitent une analyse approfondie, telle que leur quantifi-
cation, et une gestion des risques très rigoureuse. La classification des risques s’accomplit pour
chaque risque à l’aide d’une matrice et d’échelles de risques.
L’échelle de probabilité d’un risque va de 0,0 (impossible) à 1,0 (certain). L’évaluation de
la probabilité d’un risque peut être difficile, la méthode à avis d’experts étant utilisée souvent
sans le bénéfice des données de l’historique. On peut utiliser une échelle ordinale, représen-
tant des valeurs de probabilité relatives allant de très peu probable à presque certain. On peut
encore attribuer des probabilités spécifiques à l’aide d’une échelle générale (par exemple, 0,1/
0,3/ 0,5/ 0,7/ 0,9).
L’échelle d’impact d’un risque reflète la gravité des répercussions qu’il aura sur l’objectif
du projet. L’impact peut être ordinal ou cardinal, selon la culture de l’organisation conduisant
l’analyse. Les échelles ordinales sont tout simplement des valeurs classées par ordre (très
faible, faible, moyen, élevé et très élevé). Les échelles cardinales attribuent une valeur à ces
impacts. Ces valeurs sont habituellement linéaires (par exemple, 0,1/0,3/0,5/0,7/0,9), mais
souvent non linéaires (par exemple, 0,05/0,1/0,2/0,4/0,8), ce qui reflète le souhait de l’orga-
nisation d’éviter les risques à impact élevé. L’objet des deux approches est d’attribuer une
valeur relative à l’impact du risque sur les objectifs du projet en cas de concrétisation. Des
échelles bien définies, qu’elles soient de type ordinal ou cardinal, peuvent être élaborées au
niveau de l’organisation. Ces définitions améliorent la qualité des données et facilitent une uti-
lisation répétée du processus.
La figure 11-2 est un exemple d’évaluation de l’impact des risques par objectif de projet.
Elle illustre son utilisation dans le cadre d’une approche soit ordinale, soit cardinale. Les des-
cripteurs de l’impact relatif doivent être préparés par l’organisation, avant le début du projet.
La figure 11-3 est une matrice Probabilité-Impact (P-I). Elle illustre la simple multiplica-
tion des valeurs de l’échelle attribuées aux estimations de probabilité et d’impact. L’associa-
tion de ces deux dimensions est couramment employée pour déterminer si un risque est
considéré faible, moyen ou élevé. Cet exemple utilise une échelle non linéaire pour illustrer
le rejet de risques à impact élevé, mais des échelles linéaires sont souvent utilisées. On peut
aussi élaborer une matrice P-I à l’aide d’échelles ordinales. L’organisation doit déterminer,
pour l’une et l’autre des approches, la probabilité et les impacts conjugués qui auront pour
résultat la classification du risque envisagé comme risque élevé (situation « rouge »), risque
modéré (situation « jaune ») ou risque faible (situation « verte »). La notation des risques aide
à les placer dans une catégorie permettant de déterminer les actions entreprises dans le cadre
des stratégies de réponse.
.3 Test des hypothèses du projet. Les hypothèses identifiées doivent être testées par rapport à
deux critères : la stabilité de l’hypothèse et les conséquences pour le projet si elle s’avère
fausse. Des hypothèses de remplacement pouvant s’avérer vraies devraient être identifiées, et
leurs conséquences sur les objectifs du projet testées lors du processus d’analyse qualitative
des risques.
.4 Niveau de précision des données. Si l’on souhaite qu’elle soit utile à la gestion du projet,
l’analyse qualitative des risques requiert des données précises et impartiales. Le niveau de pré-
cision des données est une méthode évaluant dans quelle mesure les données sur les risques
sont utiles à la gestion des risques. Elle consiste à examiner :
■ dans quelle mesure les risques sont compris ;
■ les données disponibles sur les risques ;
■ la qualité des données ;
■ la fiabilité et l’intégrité des données.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
135
Chapitre 11 — Gestion des risques du projet

Figure 11–2 | 11.4

Figure 11-2 Évaluation de l’impact des riques

L’utilisation de données peu précises, par exemple en cas de mauvaise compréhension


d’un risque, peut être à l’origine d’une analyse qualitative des risques inutilisable par le chef
de projet. Si le niveau de précision des données n’est pas acceptable, une collecte des don-
nées de meilleure qualité peut être envisagée.

11.3.3 Données de sortie de l’analyse qualitative des risques


.1 Niveau global de risque du projet. Le niveau global de risque peut indiquer la situation du
projet en matière de risques par rapport aux autres projets, par comparaison des notations des
risques. Il peut servir à affecter du personnel ou d’autres ressources aux projets sur la base de
niveaux de risques différents, à prendre une décision concernant le projet sur la base d’une
analyse coûts et bénéfices ou à appuyer la recommandation de démarrage, de poursuite ou
d’annulation d’un projet.
.2 Liste des risques par ordre de priorité. Les risques et les circonstances peuvent être triés par
ordre de priorité selon un certain nombre de critères. Ceux-ci comprennent le niveau (élevé,
moyen et faible) ou le niveau de l’OT. On peut également regrouper les risques selon qu’ils
nécessitent des stratégies de réponse immédiates ou qu’ils peuvent être traités ultérieurement.
Les risques affectant les coûts, les délais, les fonctionnalités et la qualité peuvent être évalués
séparément avec des classifications différentes. Les risques importants doivent comporter une
description des raisons sur lesquelles est basée l’évaluation de leur probabilité et de leur
impact.
.3 Liste des risques nécessitant une analyse et une gestion plus approfondies. Les risques classés
comme élevés ou moyens sont de parfaits candidats pour une analyse plus approfondie, y
compris pour l’analyse quantitative des risques et pour la gestion des risques.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
136 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 11 — Gestion des risques du projet

Figure 11-3 Matrice Probabilité-Impact

.4 Tendances exprimées par les résultats de l’analyse qualitative des risques. Une tendance dans
les résultats peut apparaître au fur et à mesure de la répétition de l’analyse. La mise en œuvre
de stratégies de réponse ou une analyse plus approfondie peut alors se révéler plus ou moins
urgente et importante.

11.4 ANALYSE QUANTITATIVE DES RISQUES


Le processus d’analyse quantitative des risques vise à évaluer numériquement la probabilité
de chaque risque et ses conséquences sur les objectifs du projet, ainsi que l’ampleur du risque
en général pour le projet. Ce processus utilise des méthodes telles que la simulation de Monte
Carlo et l’analyse des décisions pour :
■ déterminer la probabilité d’atteindre un objectif particulier du projet ;
■ quantifier l’exposition au risque du projet et déterminer la quantité de provisions néces-
saires pour aléas de coûts et de délais ;
■ identifier les risques nécessitant le plus d’attention, en quantifiant dans quelle mesure ils
contribuent au risque du projet ;
■ identifier des objectifs de coûts, de délais ou de contenu réalistes et réalisables.
L’analyse quantitative des risques suit en général l’analyse qualitative des risques. Elle
implique l’identification de ces derniers. Les processus d’analyse qualitative et quantitative des
risques peuvent être utilisés séparément ou ensemble. Le temps et le budget disponibles et le
besoin de données qualitatives ou quantitatives sur les risques et leurs impacts dicteront les
méthodes à utiliser. Les tendances discernées dans les résultats, lorsque l’analyse quantitative
est effectuée plusieurs fois, peuvent indiquer le besoin d’une gestion des risques plus ou
moins importante.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
137
Chapitre 11 — Gestion des risques du projet

11.4.1 | 11.4.3.4

11.4.1 Données d’entrée de l’analyse quantitative des risques


.1 Plan de gestion des risques. Voir la section 11.1.3.
.2 Risques identifiés. Voir la section 11.2.3.1.
.3 Liste des risques par ordre de priorité. Voir la section 11.3.3.2.
.4 Liste des risques nécessitant une analyse et une gestion plus approfondies. Voir la section
11.3.3.3.
.5 Données historiques. Des informations sur des projets précédents et semblables, des études
sur des projets semblables réalisées par des spécialistes du risque, ainsi que des bases de don-
nées de risques peuvent être disponibles sur le marché ou à partir de sources propriétaires
(voir la section 11.2.1.4).
.6 Avis d’experts. Les données d’entrée peuvent provenir de l’équipe de projet, d’experts sur le
sujet au sein de l’organisation et d’autres personnes extérieures. D’autres sources d’informa-
tions incluent les experts en ingénierie ou en statistique (voir la section 5.1.2.2).
.7 Autres données de sortie de la planification. Les données de sortie de la planification les plus
utiles sont : le diagramme réseau du projet et l’estimation des durées utilisée pour l’élabora-
tion du planning, la liste, associée à l’OT, de tous les coûts avec estimations, et les modèles
des objectifs techniques du projet.

11.4.2 Outils et méthodes d’analyse quantitative des risques


.1 Entretiens. Les techniques d’entretien sont utilisées pour quantifier la probabilité des risques
et leurs impacts sur les objectifs du projet. Un entretien sur les risques avec les acteurs du
projet et des experts du domaine peut constituer la première étape de la quantification des
risques. Les informations nécessaires dépendent du type de distribution des probabilités que
l’on va utiliser. Par exemple, en cas de distributions triangulaires, des informations seront ras-
semblées selon des scénarios optimistes (faibles), pessimistes (élevés) et des plus probables,
tandis que pour les distributions Gaussienne et log-normale, elles seront concentrées sur la
moyenne et sur l’écart-type. Des exemples d’estimations à trois points pour une estimation
des coûts sont représentés à la figure 11-4.
Des distributions continues de probabilités sont habituellement utilisées dans l’analyse
quantitative des risques. Elles représentent à la fois la probabilité et l’impact de la composante
étudiée du projet. Les types de distribution courants comprennent les distributions rectangu-
laire, Gaussienne, triangulaire, Bêta et log-normale. Deux exemples de ces distributions sont
représentés à la figure 11-5 (où l’axe vertical fait référence à la probabilité et l’axe horizontal
à l’impact).
La documentation de la logique de détermination de la fourchette des risques constitue un
aspect important des entretiens sur les risques, car cela peut conduire à des stratégies efficaces
pour faire face aux risques durant le processus de planification des stratégies de réponse
(décrit à la section 11.5).

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
138 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 11 — Gestion des risques du projet

Figure 11-4 Estimations et fourchette des coûts définis après des entretiens sur les risques

.2 Analyse de la sensibilité. Cette analyse aide à identifier les risques pouvant avoir le plus grand
impact sur le projet. Elle examine dans quelle mesure le caractère incertain de chaque élé-
ment du projet affecte l’objectif envisagé, en conservant à tous les autres éléments incertains
leurs valeurs de référence respectives.
.3 Méthode de l’arbre de décision. L’analyse d’une décision est habituellement structurée sous
forme d’un arbre de décision. Celui-ci est un diagramme représentant une décision retenue et
les implications du choix de telle ou telle solution de remplacement. Elle incorpore la pro-
babilité des risques, ainsi que le coût ou les gains associés à chaque choix logique d’événe-
ments et de décisions futures. La sélection d’une solution dans l’arbre de décision revient à
choisir la solution rapportant la valeur attendue la plus importante une fois que tous les coûts,
gains et implications des décisions ultérieures sont quantifiés. La figure 11-6 présente un
arbre de décision.
.4 Simulation. La simulation d’un projet utilise un modèle pour convertir les incertitudes spéci-
fiées à un niveau détaillé en impact potentiel sur les objectifs exprimés au niveau du projet
dans son ensemble. Les simulations de projet sont en principe effectuées à l’aide de la
méthode de Monte Carlo.
Pour une analyse des risques et des coûts, une simulation peut utiliser l’OT classique de
projet comme modèle. Pour une analyse des risques de délais, on utilisera le planning obtenu
à partir de la méthode des antécédents (PDM en anglais) (voir la section 6.2.2.1).
La figure 11-7 illustre le résultat obtenu après une simulation des risques et des coûts.

11.4.3 Données de sortie de l’analyse quantitative des risques


.1 Liste des risques quantifiés, classés par ordre de priorité. Cette liste de risques contient ceux
qui constituent la plus grande menace ou représentent l’opportunité la plus importante pour
le projet, ainsi que la mesure de leurs impacts.
.2 Analyse probabiliste du projet. Prévisions des résultats potentiels en matière de coûts et de
délais indiquant les dates de fin ou la durée du projet, et les coûts possibles, ainsi que leur
degré de certitude.
.3 Probabilité d’atteindre des objectifs de coûts et de délais. La probabilité d’atteinte des objec-
tifs du projet conformément au plan en cours et avec la connaissance actuelle des risques aux-
quels le projet doit faire face peut être estimée à l’aide de la quantification des risques.
.4 Tendances exprimées par les résultats de l’analyse quantitative des risques. Une tendance
dans les résultats obtenus peut apparaître au fur et à mesure de la répétition de l’analyse.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
139
Chapitre 11 — Gestion des risques du projet

Figure 11–5 | 11.5.2

Figure 11-5 Exemples de distributions des probabilités couramment utilisées

11.5 DÉVELOPPEMENT DES STRATÉGIES DE RÉPONSE


Le développement des stratégies de réponse est le processus qui consiste à élaborer des
options et à déterminer des actions visant à cultiver les opportunités et à réduire les menaces
affectant les objectifs du projet. Il implique l’identification des parties ou des individus aux-
quels sera confiée la responsabilité de chacune des stratégies de réponse approuvées. Ce pro-
cessus permet de s’assurer que les risques identifiés seront gérés de façon adéquate.
L’efficacité de la planification des stratégies de réponse aura une influence directe sur l’aug-
mentation ou la baisse du niveau global de risques du projet.
La planification des stratégies de réponse doit être adaptée à la gravité des risques, ren-
table par rapport au défi à relever, opportune pour réussir, réaliste par rapport au contexte du
projet, avoir reçu l’accord de toutes les parties impliquées et être assignée à une personne res-
ponsable. Il est souvent nécessaire de sélectionner la meilleure stratégie de réponse parmi
plusieurs options possibles.

11.5.1 Données d’entrée de la planification des stratégies de réponse


.1 Plan de gestion des risques. Voir la section 11.1.3.
.2 Liste des risques par ordre de priorité. Cette liste, issue de l’analyse qualitative des risques,
est décrite à la section 11.3.3.2.
.3 Niveau de risque du projet. Voir la section 11.3.3.1.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
140 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 11 — Gestion des risques du projet

Figure 11-6 Méthode de l’arbre de décision

.4 Liste des risques quantifiés, classés par ordre de priorité. Cette liste, issue de l’analyse quan-
titative des risques, est décrite à la section 11.4.3.1.
.5 Analyse probabiliste du projet. Voir la section 11.4.3.2.
.6 Probabilité d’atteindre des objectifs de coûts et de délais. Voir la section 11.4.3.3.
.7 Liste des stratégies de réponse potentielles. Dans le processus d’identification des risques, on
peut identifier des actions permettant de faire face à des risques particuliers ou à des caté-
gories de risques.
.8 Seuils de risque. Le niveau de risque acceptable pour l’organisation aura une influence sur
la planification des stratégies de réponse (voir la section 11.1.3).
.9 Personnes en charge des risques. Une liste des acteurs du projet pouvant être chargés des
stratégies de réponse. Les personnes en charge des risques doivent être impliquées dans l’éla-
boration des stratégies de réponse.
.10 Causes courantes de risques. Plusieurs risques peuvent avoir une même origine. Cette situa-
tion peut mettre en évidence la possibilité d’atténuer deux ou plusieurs risques grâce à une
stratégie de réponse commune.
.11 Tendances exprimées par les résultats des analyses qualitative et quantitative des risques. Ces
tendances sont décrites à la section 11.3.3.4 et 11.4.3.4. Des tendances apparaissant dans les
résultats peuvent rendre des stratégies de réponse ou des analyses plus approfondies plus ou
moins urgentes et importantes.

11.5.2 Outils et méthodes de planification des stratégies de réponse


Plusieurs stratégies de réponse sont envisageables. Le choix doit se porter, pour chaque
risque, sur la plus efficace. Un plan d’actions doit ensuite être élaboré afin de mettre en œuvre
cette stratégie. On peut choisir une stratégie principale et une stratégie de secours.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
141
Chapitre 11 — Gestion des risques du projet

Figure 11–7 | 11.5.3.3

Figure 11-7 Simulation des risques de coût

.1 Rejet. Le rejet d’un risque consiste à modifier le plan de projet afin d’éliminer ce risque ou la
circonstance, ou encore de protéger les objectifs du projet contre leur impact. Bien que
l’équipe de projet ne puisse jamais empêcher la concrétisation de tous les risques, il est pos-
sible d’en prévenir certains.
Certains risques, survenant tôt dans le projet, peuvent être traités en clarifiant les spécifi-
cations, en obtenant plus d’informations, en améliorant la communication ou en faisant appel
à un expert. Réduire le contenu pour éviter les activités à haut risque, ajouter des ressources
ou allonger les délais, adopter une approche familière au lieu d’une approche novatrice ou
éviter un sous-traitant inconnu, sont des exemples de rejet.
.2 Transfert. Le transfert des risques consiste à transférer à une tierce partie les conséquences
d’un risque et la responsabilité de la stratégie de réponse correspondante. Transférer le risque
donne simplement la responsabilité de sa gestion à une tierce partie ; cela ne l’élimine pas.
Le transfert de la responsabilité d’un risque est d’autant plus efficace qu’il s’agit d’un risque
de type financier. Le transfert implique presque toujours le paiement d’une prime de risque à
la partie s’en chargeant. Il comprend l’utilisation d’une assurance, de cautionnements de
bonne exécution et de garanties. Des contrats peuvent être utilisés pour transférer la respon-
sabilité de risques particuliers à une tierce partie. L’utilisation d’un contrat à prix forfaitaire
peut transférer le risque au vendeur si la conception du projet est stable. Bien qu’un contrat
à coûts remboursables laisse au client ou au commanditaire une plus grande partie du risque,
il peut contribuer à réduire les coûts en cas de modifications en milieu de projet.
.3 Réduction. La réduction a pour objet d’atténuer la probabilité et/ou les conséquences d’une
menace jusqu’à un seuil acceptable. Prendre tôt des mesures visant à réduire la probabilité de
la concrétisation d’un risque ou de son impact sur le projet est plus efficace que d’essayer d’en
réparer les conséquences une fois le risque concrétisé. Les coûts de la réduction doivent être
proportionnels à la probabilité du risque et à ses conséquences.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
142 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 11 — Gestion des risques du projet

La réduction des risques peut consister en la mise en œuvre d’un nouveau plan d’actions
visant à réduire le problème ; par exemple : adopter des processus moins complexes, effec-
tuer davantage de tests sismiques ou d’ingénierie, ou choisir un vendeur plus fiable. Cela
peut impliquer de modifier les circonstances de façon à réduire la probabilité de matéria-
lisation du risque ; par exemple : ajouter des ressources ou allonger les délais. Cela peut
nécessiter l’élaboration d’un prototype pour réduire le risque présenté par le passage d’un
modèle à petite échelle à un produit grandeur nature.
Dans les situations où réduire la probabilité est impossible, une mesure de réduction
peut s’intéresser à l’impact du risque en identifiant ses facteurs de gravité. Par exemple, inté-
grer de la redondance dans un sous-système au niveau de sa conception peut réduire l’im-
pact résultant d’une défaillance du composant initial.
.4 Acceptation. Cette méthode indique que l’équipe de projet a décidé de ne pas modifier le
plan de projet pour faire face au risque ou qu’elle n’est pas en mesure d’identifier d’autres
stratégies de réduction adéquates. L’acceptation active peut inclure l’élaboration d’un plan
alternatif, à mettre en œuvre au cas où un risque se réaliserait. L’acceptation passive ne néces-
site aucune action, l’équipe de projet devant faire face aux risques au fur et à mesure de leur
concrétisation.
Un plan alternatif est appliqué aux risques identifiés qui surviennent au cours du projet.
Au cas où le risque se réaliserait, l’élaboration anticipée d’un plan alternatif peut considéra-
blement réduire le coût d’une action. Les symptômes annonciateurs, tels que le fait de ne pas
atteindre les étapes jalons intermédiaires, doivent être définis et suivis. Un plan de secours est
élaboré si l’impact du risque est fort ou si la stratégie choisie n’est pas complètement efficace.
Ceci peut inclure l’allocation d’une provision, l’élaboration d’options de rechange ou la modi-
fication du contenu du projet.
La mesure d’acceptation des risques la plus courante est d’établir une provision pour aléas,
ou réserve, incluant le temps, l’argent et les ressources nécessaires pour faire face aux risques
connus. Pour les risques acceptés, la provision devrait être fixée par les impacts et calculée
à un niveau acceptable d’exposition aux risques.

11.5.3 Données de sortie de la planification des stratégies de réponse


.1 Plan des stratégies de réponse. Le plan des stratégies de réponse (parfois appelé registre des
risques) doit être rédigé au niveau de détail auquel les actions seront entreprises. Il doit com-
porter tout ou partie des éléments suivants :
■ les risques identifiés, leur description, les parties du projet (par exemple, éléments de
l’OT) affectées, leurs causes et la façon dont ils peuvent affecter les objectifs du projet ;
■ les personnes en charge des risques et les responsabilités attribuées ;
■ les résultats des processus d’analyse qualitative et quantitative des risques ;
■ les mesures approuvées, y compris le rejet, le transfert, la réduction ou l’acceptation, pour
chaque risque du plan des stratégies de réponse ;
■ le niveau de risque résiduel prévu une fois la stratégie mise en œuvre ;
■ les actions spécifiques de mise en œuvre de la stratégie choisie, pour faire face aux
risques ;
■ le budget et les délais des mesures à prendre ;
■ les plans alternatifs et les plans de secours.
.2 Risques résiduels. Les risques résiduels sont ceux qui persistent une fois prises les mesures
de rejet, de transfert ou de réduction. Ils comprennent aussi les risques mineurs acceptés et
traités, par exemple, en incorporant une provision pour aléas aux coûts et aux délais auto-
risés.
.3 Risques subordonnés. Les risques résultant directement de la mise en œuvre d’une mesure
de réduction sont appelés risques subordonnés. On doit les identifier et planifier des straté-
gies de réponse adéquates.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
143
Chapitre 11 — Gestion des risques du projet

.4 Accords contractuels. Des accords contractuels peuvent être signés afin de préciser la res-
11.5.3.4 | 11.6.2.5

ponsabilité de chacun en cas de concrétisation de risques spécifiques, ainsi que pour la mise
en place d’assurances, de services et d’autres postes, s’il y a lieu, destinés à éviter les menaces
ou à y parer.
.5 Provisions nécessaires pour aléas. Grâce à l’analyse probabiliste du projet (11.4.3.2) et aux
seuils de risque (11.1.3.1), le chef de projet peut déterminer l’importance du tampon ou des
provisions nécessaires pour réduire le risque de dépassement des objectifs du projet, à un
niveau acceptable pour l’organisation.
.6 Données d’entrée pour les autres processus. La plupart des mesures concernant les risques
impliquent une dépense de temps, d’argent ou de ressources supplémentaires et nécessitent
des modifications du plan de projet. Les organisations exigent que les dépenses soient justi-
fiées et en rapport avec le niveau de réduction des risques obtenu. Les stratégies alternatives
doivent être réintroduites dans les processus correspondants des autres disciplines.
.7 Données d’entrée pour un plan de projet révisé. Les résultats du processus de planification
des stratégies de réponse doivent être incorporés dans le plan de projet afin de s’assurer que
la mise en œuvre et le suivi des actions approuvées font bien partie du projet en cours.

11.6 SUIVI ET CONTRÔLE DES RISQUES


Le suivi et le contrôle des risques sont des processus qui consistent à suivre les risques iden-
tifiés, à surveiller les risques résiduels et à identifier des nouveaux risques, en s’assurant de la
mise en œuvre des plans de risque et en évaluant leur efficacité pour atténuer les risques. Ce
processus enregistre les indicateurs des risques associés à la mise en œuvre des plans alter-
natifs. Il s’agit d’un processus continu, étalé sur toute la vie du projet. Les risques évoluent au
fur et à mesure de la progression du projet ; de nouveaux risques apparaissent ou des risques
anticipés disparaissent.
Les bons processus de surveillance et de contrôle des risques permettent l’obtention d’in-
formations grâce auxquelles des décisions efficaces seront prises avant l’occurrence des
risques. La communication à tous les acteurs du projet est nécessaire pour évaluer périodi-
quement l’acceptabilité du niveau de risques du projet.
Le suivi des risques a pour objet de déterminer si :
■ les stratégies de réponse ont été mises en œuvre comme prévu ;
■ les actions visant à la réduction des risques sont aussi efficaces que prévu ou s’il faut en
élaborer de nouvelles ;
■ les hypothèses du projet sont toujours valables ;
■ l’exposition au risque a évolué, grâce à l’analyse des tendances ;
■ des symptômes annonciateurs sont apparus ;
■ les procédures adéquates sont suivies ;
■ des risques, non encore identifiés, se sont matérialisés ou sont apparus.
Le contrôle des risques peut impliquer le choix de stratégies possibles, l’élaboration d’un
plan alternatif, la prise de mesures correctives ou la replanification du projet. La personne res-
ponsable des stratégies de réponse doit faire un rapport périodique au chef de projet et au
chef de l’équipe de gestion des risques sur l’efficacité du plan, sur tous les effets non anticipés
et sur toutes les corrections nécessaires durant l’exécution du projet pour parer aux risques.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
144 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 11 — Gestion des risques du projet

11.6.1 Données d’entrée de la surveillance et du contrôle des risques


.1 Plan de gestion des risques. Voir la section 11.1.3.
.2 Plan des stratégies de réponse. Voir la section 11.5.3.1.
.3 Communications du projet. Le travail réalisé et les autres documents du projet, décrits à la
section 10.3.1, fournissent des informations sur les performances et les risques du projet. Les
rapports couramment utilisés dans le cadre de la surveillance et du contrôle des risques com-
prennent les listes de problèmes, les listes d’actions en cours, les rapports d’alarmes, ou les avis
d’escalade.
.4 Identification et analyse des risques supplémentaires. Tout au long de la mesure des per-
formances du projet et de l’élaboration de rapports les concernant, des risques potentiels non
encore identifiés peuvent apparaître. Pour ceux-ci, on doit mettre en œuvre le cycle des six
processus concernant les risques.
.5 Modifications du contenu. Les modifications apportées au contenu nécessitent souvent une
nouvelle analyse des risques et de nouveaux plans de réponse. Les modifications du contenu
sont décrites à la section 5.5.3.1.

11.6.2 Outils et méthodes de suivi et de contrôle des risques


.1 Audits des stratégies de réponse aux risques du projet. Les auditeurs de risque examinent
et documentent l’efficacité des stratégies de réponse mises en place pour prévenir et trans-
férer l’occurrence d’un risque ou y parer, ainsi que l’efficacité de la personne en charge. Ces
audits sont effectués durant le cycle de vie du projet pour contrôler les risques.
.2 Revues périodiques des risques du projet. Les revues périodiques des risques doivent être
programmées. Les risques du projet devraient figurer à l’ordre du jour de toutes les réunions
de l’équipe. La classification des risques et l’établissement de priorités correspondantes peu-
vent changer au cours de la vie du projet. Tout changement peut nécessiter une analyse qua-
litative ou quantitative approfondie.
.3 Analyse de la valeur acquise. La valeur acquise sert à contrôler les performances globales du
projet en les comparant à un plan de référence. Les résultats obtenus grâce à une analyse de
la valeur acquise peuvent indiquer un écart potentiel du projet à l’achèvement par rapport aux
coûts et aux délais cibles. Lorsqu’un projet s’écarte considérablement de la référence de base,
une mise à jour de l’identification et de l’analyse des risques est nécessaire. L’analyse de la
valeur acquise est décrite à la section 10.3.2.4.
.4 Mesure des performances techniques. La mesure des performances techniques compare les
accomplissements techniques au cours de l’exécution du projet, à l’accomplissement tech-
nique planifié dans le plan de projet. Un écart, tel que le fait de ne pas livrer une fonction-
nalité comme prévu lors du franchissement d’une étape jalon, peut constituer un risque pour
la réalisation du contenu du projet.
.5 Planification de stratégies de réponse complémentaires. Si un risque non identifié dans le
plan des stratégies de réponse fait surface ou si son impact sur les objectifs est plus important

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
145
Chapitre 11 — Gestion des risques du projet

que prévu, la mesure identifiée n’est peut-être pas adéquate. Il est alors nécessaire d’effectuer
11.6.3 | Chapitre. 12

une planification supplémentaire des stratégies de réponse, afin de maîtriser le risque en ques-
tion.

11.6.3 Données de sortie du suivi et du contrôle des risques


.1 Décisions à chaud. Les décisions à chaud sont des mesures non planifiées prises pour faire
face aux risques émergents, non encore identifiés ou acceptés. Ces décisions à chaud doivent
être convenablement documentées et incorporées au plan de projet et au plan des stratégies
de réponse.
.2 Action corrective. Une action corrective consiste à suivre le plan alternatif ou à prendre une
décision à chaud.
.3 Demandes de changements du projet. Mettre en œuvre des plans alternatifs ou prendre des
décisions à chaud conduit souvent à des changements du plan de projet pour faire face aux
risques. Une demande de changement, gérée par le contrôle intégré des changements, décrit
à la section 4.3, est alors émise.
.4 Mises à jour du plan des stratégies de réponse. Les risques peuvent ou non se matérialiser.
Ceux qui se matérialisent doivent être documentés et évalués. La mise en œuvre du contrôle
des risques peut réduire l’impact ou la probabilité des risques identifiés. Les niveaux de
risques doivent être réévalués de façon à permettre un contrôle convenable des nouveaux
risques importants. Les risques ne se matérialisant pas doivent être documentés et éliminés du
plan des stratégies de réponse.
.5 Base de données des risques. Référentiel permettant de recueillir, mettre à jour et analyser
les données obtenues et utilisées dans le cadre des processus de gestion des risques. Son uti-
lisation facilite la gestion des risques dans l’ensemble de l’organisation et, avec le temps, for-
mera la base d’un programme de leçons retenues en matière de risques.
.6 Mises à jour des listes de vérification de l’identification des risques. Des listes de vérification
mises à jour au fur et à mesure que l’on acquiert de l’expérience aideront à gérer les risques
dans les projets à venir.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®®), Édition 2000
146 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 12

Gestion des approvisionne-


ments du projet

La gestion des approvisionnements du projet comprend les processus nécessaires à l’acqui-


sition, en dehors de l’entreprise, de biens et de services afin de réaliser le contenu du projet.
Pour simplifier, on désignera les biens et services, au pluriel ou au singulier, par le terme
général de produit. La figure 12-1 offre une vue d’ensemble des principaux processus sui-
vants :
12.1 Planification des approvisionnements : déterminer ce qui doit être acquis et à quel
moment.
12.2 Planification des appels d’offres : documenter les spécifications du produit et iden-
tifier des sources possibles.
12.3 Appels d’offres : obtenir des devis, des soumissions, des offres ou des propositions,
selon le cas.
12.4 Choix des fournisseurs : choisir parmi les fournisseurs potentiels.
12.5 Administration des contrats : gérer les relations avec le vendeur.
12.6 Clôture du contrat : finir et clore le contrat, et résoudre tous les problèmes en suspens.
Ces processus interagissent entre eux et avec les processus d’autres disciplines. Chaque
processus peut nécessiter la participation d’une ou plusieurs personnes ou d’un ou plusieurs
groupes, selon les besoins du projet. Habituellement, tous les processus sont exécutés au
moins une fois au cours de chaque phase du projet. Bien que les processus soient présentés
ici comme des éléments distincts avec des interfaces bien définies, ils peuvent dans la pra-
tique se chevaucher et interagir d’une manière non détaillée dans ce chapitre. Les interactions
entre processus sont décrites au chapitre 3.
La gestion des approvisionnements du projet est traitée ici du point de vue de l’acheteur,
dans le cadre de la relation acheteur-vendeur. Dans un projet, la relation acheteur-vendeur
peut exister à divers niveaux. Selon le domaine d’application, le vendeur peut être désigné
par le terme de sous-traitant ou de fournisseur.
En principe, le vendeur va gérer son travail comme un projet. Dans ce cas :
■ l’acheteur devient le client et par conséquent, un acteur majeur pour le vendeur.
■ l’équipe de gestion de projet du vendeur doit se préoccuper de tous les processus de ges-
tion de projet, et non pas seulement de ceux de ce champ d’application.
■ les modalités du contrat deviennent des données d’entrée majeures pour de nombreux
processus du vendeur. Le contrat peut en fait contenir les données d’entrée (par exemple,
produits livrables, étapes jalons principales, objectifs de coût) ou il peut limiter les options
de l’équipe de projet (par exemple, l’accord de l’acheteur pour les décisions concernant
le personnel est souvent nécessaire dans les projets de conception).

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
147
Chapitre 12 — Gestion des approvisionnements du projet

Figure 12–1 | 12.1.1.2

Figure 12-1 Vue d’ensemble de la gestion des approvisionnements du projet

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
148 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 12 — Gestion des approvisionnements du projet

Ce chapitre part du principe que le vendeur ne fait pas partie l’entreprise réalisatrice.
Cependant, la majeure partie des sujets traités s’applique également aux accords formels
passés avec les autres services de l’entreprise réalisatrice. Lorsqu’il s’agit d’accords informels,
les processus décrits dans les chapitres 9, « Gestion des ressources humaines du projet », et 10,
« Gestion des communications du projet » sont mieux adaptés.

12.1 PLANIFICATION DES APPROVISIONNEMENTS


La planification des approvisionnements consiste à identifier les besoins du projet pouvant
être satisfaits au mieux par l’achat de produits ou services à l’extérieur de l’entreprise réali-
satrice. Ce processus doit avoir lieu durant la définition du contenu. Il implique de décider s’il
faut obtenir un produit ou un service, de quelle manière, en quelle quantité et à quel moment.
Lorsque le projet acquiert des produits et services (contenu du projet) en dehors de l’en-
treprise, les processus allant de la planification des appels d’offres (section 12.2) à la clôture
du contrat (section 12.6) doivent être recommencés pour chacun. L’équipe de gestion de
projet peut, si nécessaire, faire appel à des spécialistes en approvisionnement et en prépara-
tion et gestion de contrats, et les faire intégrer à l’équipe de projet dès le début du processus.
Lorsque le projet n’acquiert aucun produit ou service en dehors de l’entreprise, les pro-
cessus allant de la planification des appels d’offres (section 12.2) à la clôture du contrat (sec-
tion 12.6) n’ont pas lieu.
La planification des approvisionnements doit également intégrer les vendeurs potentiels,
notamment dans le cas où l’acheteur souhaite conserver une certaine influence ou un cer-
tain contrôle sur les décisions concernant les contrats.

12.1.1 Données d’entrée de la planification des approvisionnements


.1 Cahier des charges. Le cahier des charges (voir la section 5.2.3.1) indique les limites du
projet en cours. Il apporte des informations importantes sur les besoins du projet et les stra-
tégies à prendre en compte dans la planification des approvisionnements.
.2 Description du produit. La description du produit résultant du projet (décrite à la section
5.1.1.1) offre des informations importantes sur toute question ou tout problème technique à
prendre en compte dans la planification des approvisionnements.
La description du produit est généralement moins détaillée que la description des travaux.
Elle décrit le produit final résultant du projet ; la description des travaux (traitée à la section

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
149
Chapitre 12 — Gestion des approvisionnements du projet

12.1.3.2) décrit la partie de ce produit devant être fournie par le vendeur. Toutefois, si l’en-
12.1.1.3 | 12.1.3.2

treprise choisit d’acheter la totalité du produit, aucune distinction n’est à faire entre ces deux
termes.
.3 Structure d’approvisionnement. Si l’entreprise réalisatrice n’a aucun service formel chargé de
la passation des contrats, l’équipe de projet devra fournir les ressources et la compétence
nécessaires aux activités d’approvisionnement du projet.
.4 Conditions du marché. Le processus de planification des approvisionnements doit rechercher
les produits et services disponibles sur le marché, leurs fournisseurs et les conditions de vente.
.5 Autres données de sortie de la planification. Dans la mesure où elles sont disponibles, les
autres données de sortie de la planification doivent être prises en compte dans la planifica-
tion des approvisionnements. Les autres données de sortie de la planification à prendre en
compte comprennent les estimations préliminaires de coûts et de délais, les plans de gestion
de la qualité, les prévisions de trésorerie, l’organigramme des tâches, les risques identifiés et
les ressources humaines prévues.
.6 Contraintes. Les contraintes sont des facteurs limitant les options de l’acheteur. L’une des
contraintes les plus courantes dans de nombreux projets est la disponibilité de fonds.
.7 Hypothèses. Les hypothèses sont des facteurs qui, pour les besoins de la planification, sont
définis comme vrais, réels ou certains.

12.1.2 Outils et méthodes de planification des approvisionnements


.1 Analyse « Produire ou acheter ». Il s’agit d’une technique de gestion, et d’une partie du pro-
cessus de définition initiale du contenu à moindre coût, permettant de déterminer si un pro-
duit particulier peut être fabriqué à moindre coût par l’entreprise réalisatrice. L’analyse doit
prendre en compte les coûts indirects et directs. Par exemple, la partie « acheter » de l’analyse
doit définir le coût réel d’achat du produit, ainsi que les coûts indirects de gestion du pro-
cessus d’achat.
Une analyse « Produire ou acheter » doit également refléter le point de vue de l’entreprise
réalisatrice, ainsi que les besoins immédiats du projet. Par exemple, l’achat d’équipement (il
peut s’agir d’une grue comme d’un ordinateur), plutôt que sa location ou son leasing, n’est
pas nécessairement plus rentable. Cela dit, si l’organisation en a besoin à long terme, la part
du coût d’achat allouée au projet peut être inférieure au coût de la location.
.2 Avis d’experts. L’opinion d’experts s’avère souvent nécessaire à l’évaluation des données
d’entrée de ce processus. Cette expertise peut être apportée par un groupe ou une personne
possédant une formation ou des connaissances particulières ; on peut l’obtenir de plusieurs
sources :
■ des autres services de l’entreprise réalisatrice ;
■ de consultants ;
■ des associations professionnelles et techniques ;
■ des groupements industriels.
.3 Choix du type de contrat. Il existe différents types de contrats adaptés aux différents types
d’achat. On rencontre généralement trois grandes catégories de contrats :

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
150 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 12 — Gestion des approvisionnements du projet

■ les contrats à prix forfaitaire ou contrats à forfait : cette catégorie de contrats stipule un
prix total fixe pour un produit bien défini. Dans la mesure où le produit n’est pas bien
défini, l’acheteur comme le vendeur prennent un risque ; l’acheteur peut ne pas recevoir
le produit souhaité ou le vendeur peut encourir des coûts supplémentaires pour le livrer.
Les contrats à prix forfaitaire peuvent également comprendre des clauses d’intéressement
pour inciter la partie concernée à atteindre ou à dépasser certains objectifs choisis, tels que
les dates cibles ;
■ les contrats à coûts remboursables : cette catégorie de contrat prévoit le paiement (rem-
boursement) au vendeur des coûts réels encourus, habituellement majorés d’une com-
mission représentant le bénéfice du vendeur. Ces coûts sont généralement classés en coûts
directs ou coûts indirects. Les coûts directs sont ceux occasionnés exclusivement par le
projet (par exemple, le salaire du personnel affecté à plein temps au projet). Les coûts
indirects, également appelés frais généraux, sont ceux affectés au projet par l’entreprise
réalisatrice au titre des coûts de gestion (par exemple, le salaire des dirigeants de la
société). Les coûts indirects sont habituellement calculés à partir d’un pourcentage des
coûts directs. Les contrats à coûts remboursables comprennent souvent des clauses d’in-
téressement pour inciter la partie concernée à atteindre ou à dépasser certains objectifs
choisis, tels que des délais ou le coût total ;
■ les contrats pièces et main-d’œuvre : il s’agit d’un type de contrat hybride mêlant certains
aspects des contrats à prix forfaitaire et des contrats à coûts remboursables. Ces contrats
s’apparentent aux contrats à coûts remboursables en ce qu’ils ne sont pas plafonnés, la
valeur totale de l’accord n’étant pas précisée au moment de l’attribution. La valeur d’un
contrat pièces et main-d’œuvre peut augmenter comme s’il s’agissait d’un contrat à coûts
remboursables. Inversement, les contrats pièces et main-d’œuvre s’apparentent aussi aux
contrats à prix unitaire quand, par exemple, les taux unitaires sont fixés à l’avance par
l’acheteur et le vendeur, ou lorsque les deux parties s’entendent sur les tarifs payés à la
catégorie « ingénieurs confirmés ».

12.1.3 Données de sortie de la planification des approvisionnements


.1 Plan de gestion des approvisionnements. Le plan de gestion des approvisionnements doit
décrire la gestion des processus des approvisionnements restants (de la planification des
appels d’offres à la clôture du contrat). Par exemple :
■ Quels types de contrats utilisera-t-on ?
■ Si des estimations indépendantes sont nécessaires comme critères d’évaluation, qui les pré-
parera et quand ?
■ S’il existe un service des approvisionnements au sein de l’organisation maîtresse d’œuvre,
quelles actions l’équipe de gestion de projet peut-elle entreprendre seule ?
■ Si des documents d’approvisionnement standard sont nécessaires, où peut-on se les pro-
curer ?
■ Comment s’effectuera la gestion des différents prestataires ?
■ Comment assurer la coordination entre les approvisionnements et les autres aspects du
projet, tels que les rapports sur les délais et les performances ?
Selon les besoins du projet, le plan de gestion des approvisionnements peut être formel
ou non, et très détaillé ou présenté dans ses grandes lignes. C’est un élément annexe du plan
de projet décrit à la section 4.1, « Élaboration du plan de projet ».
.2 Description(s) des travaux. La description des travaux présente l’élément à acquérir de
manière suffisamment détaillée pour que les vendeurs potentiels puissent déterminer s’ils sont
capables de le fournir. Le degré de détail varie en fonction de la nature de l’élément, des
besoins de l’acheteur ou du type de contrat prévu.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
151
Chapitre 12 — Gestion des approvisionnements du projet

Certains domaines d’application reconnaissent différents types de description des travaux.


12.2 | 12.3

Par exemple, dans certaines administrations, le terme description des travaux est réservé à un
achat correspondant à un produit ou service bien précis et le terme description des objectifs
est employé pour un achat présenté comme un problème à résoudre.
La description des travaux peut être revue et corrigée au cours du processus d’approvi-
sionnement. Par exemple, un vendeur potentiel peut suggérer une approche plus efficace ou
un produit moins cher que celui initialement choisi. Chaque élément approvisionné nécessite
une description des travaux particulière. On peut toutefois regrouper plusieurs produits ou
services pour former un élément approvisionné unique associé à une seule description des
travaux.
Cette description doit être aussi claire, complète et concise que possible. Elle doit com-
porter une description de tous les services annexes requis, tels que les rapports d’avancement
ou le support opérationnel de l’élément approvisionné après la fin du projet. Dans certains
domaines d’application, les descriptions de travaux doivent se plier à des exigences spéci-
fiques quant au contenu et au format.

12.2 PLANIFICATION DES APPELS D’OFFRES


La planification des appels d’offres implique de préparer les documents nécessaires (le pro-
cessus des appels d’offres est décrit à la section 12.3).

12.2.1 Données d’entrée de la planification des appels d’offres


.1 Plan de gestion des approvisionnements. Le plan de gestion des approvisionnements est
décrit à la section 12.1.3.1.
.2 Description(s) des travaux. La description des travaux est décrite à la section 12.1.3.2.
.3 Autres données de sortie de la planification. Les autres données de sortie de la planification
(voir la section 12.1.1.5) qui ont éventuellement été modifiées depuis leur intégration à la pla-
nification des approvisionnements doivent être révisées encore une fois quand elles sont uti-
lisées dans l’appel d’offres. Spécifiquement, la planification des appels d’offres doit suivre
étroitement le planning du projet.

12.2.2 Outils et méthodes de planification des appels d’offres


.1 Documents standard. Les documents standard comprennent des contrats standard, des des-
criptions standard des produits et services à obtenir ou des versions normalisées de tout ou
partie des documents d’offres nécessaires (voir la section 12.2.3.1). Les organisations gérant
de gros volumes d’approvisionnement doivent établir une version normalisée de tous ces
documents.
.2 Avis d’experts. Les méthodes basées sur l’avis d’experts sont développées dans la section
5.1.2.2.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
152 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 12 — Gestion des approvisionnements du projet

12.2.3 Données de sortie de la planification des appels d’offres


.1 Documents d’approvisionnement. Ces documents servent à obtenir des offres auprès de ven-
deurs potentiels. Les termes soumission et devis sont généralement employés lorsque le choix
du vendeur est basé sur le prix (achat de produits commerciaux ou standard), tandis que le
terme offre est généralement employé lorsque d’autres considérations, telles que l’approche
ou les compétences techniques, priment. Dans la vie courante, ces termes sont souvent uti-
lisés indifféremment et il vaut mieux ne pas présumer, sans explication, du sens du terme
employé. On rencontre couramment les termes suivants pour désigner les différents types de
documents d’approvisionnement : appel à candidatures, appel d’offres, demande de prix,
appel à négociations et première réponse du fournisseur.
Les documents d’approvisionnement doivent être conçus de manière à obtenir des
réponses précises et complètes de la part des vendeurs potentiels. La description complète
des travaux doit toujours y figurer, ainsi qu’une description du format de réponse souhaité
et toutes les dispositions contractuelles demandées (par exemple, une copie du modèle de
contrat, des clauses de confidentialité). Dans le cas d’une passation de contrat avec l’admi-
nistration, tout ou partie du contenu et de la structure des documents d’approvisionnement
peut être défini par des règlements.
Les documents d’approvisionnement doivent être suffisamment précis pour que les
réponses soient homogènes et comparables, mais suffisamment souples pour permettre aux
vendeurs de proposer des améliorations.
.2 Critères d’évaluation. Les critères d’évaluation permettent de classer ou d’attribuer une note
aux offres. Ils peuvent être objectifs (par exemple, « Le chef de projet proposé doit être cer-
tifié PMP® ») ou subjectifs (par exemple, « Le chef de projet proposé doit avoir acquis une
expérience préalable documentée dans des projets similaires »). Les critères d’évaluation sont
souvent intégrés aux documents d’approvisionnement.
Ces critères peuvent se limiter au prix d’achat si l’élément à approvisionner est facilement
disponible auprès d’un certain nombre de sources acceptables (le prix d’achat dans ce
contexte comprend le coût de l’élément, ainsi que les dépenses annexes, telles que le coût de
la livraison). Sinon, il faut identifier et documenter d’autres critères de sélection :
■ compréhension du besoin, tel qu’il apparaît dans l’offre du vendeur ;
■ coût d’ensemble ou global : le vendeur retenu offrira-t-il le coût total le plus bas (coût
d’achat plus coût d’exploitation) ?
■ capacité technique : le vendeur possède-t-il, ou peut-on raisonnablement attendre de lui
qu’il acquière, les compétences et connaissances techniques requises ?
■ approche de gestion : le vendeur possède-t-il, ou peut-on raisonnablement attendre de lui
qu’il développe, des processus et procédures de gestion à même d’assurer le succès du
projet ?
■ capacité financière : le vendeur dispose-t-il, ou peut-on raisonnablement attendre de lui
qu’il obtienne, les ressources financières nécessaires ?
.3 Mises à jour de la description des travaux. La description des travaux est décrite à la section
12.1.3.2. Les modifications apportées à une ou plusieurs descriptions de travaux peuvent être
identifiées au cours de la planification des appels d’offres.

12.3 APPELS D’OFFRES


L’appel d’offres consiste à obtenir des réponses (soumissions et propositions) des vendeurs
potentiels quant à la solution à apporter aux besoins du projet. Dans le cadre de ce processus,
la majeure partie de l’effort est fournie par les vendeurs potentiels, sans frais pour le projet.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
153
Chapitre 12 — Gestion des approvisionnements du projet

12.3.1 | 12.4.2.1

12.3.1 Données d’entrée des appels d’offres


.1 Documents d’approvisionnement. Les documents d’approvisionnement sont décrits à la sec-
tion 12.2.3.1.
.2 Listes de vendeurs qualifiés. Certaines organisations conservent des listes ou des fichiers d’in-
formations sur les vendeurs potentiels. En général, ces listes comportent des informations rela-
tives à leur expérience passée dans le domaine en question et d’autres caractéristiques
importantes.
Si de telles listes ne sont pas disponibles, l’équipe de projet devra alors développer ses
propres sources. Des informations générales sont largement disponibles sur Internet, dans les
annuaires de bibliothèques, auprès d’associations locales, dans des catalogues commerciaux
et auprès d’autres sources similaires. L’obtention d’informations détaillées sur des sources spé-
cifiques peut demander plus d’efforts, comme des visites sur place ou des contacts avec d’an-
ciens clients.
Les documents d’approvisionnement doivent être envoyés à l’ensemble des vendeurs
potentiels ou seulement à quelques-uns.

12.3.2 Outils et méthodes d’appel d’offres


.1 Réunions de mise au point des offres. Les réunions de mise au point des offres (également
appelées conférences des soumissionnaires, conférences des entrepreneurs et conférences pré-
liminaires à l’offre) sont des réunions avec les vendeurs potentiels avant la préparation d’une
offre. Elles permettent de s’assurer que ceux-ci ont une compréhension claire et identique de
la prestation à fournir (spécifications techniques, exigences contractuelles, etc.). Les réponses
aux questions posées peuvent être incorporées aux documents d’approvisionnement sous
forme d’annexes. Durant ce processus, tous les vendeurs potentiels doivent être sur un même
pied d’égalité.
.2 Annonces. On peut souvent élargir les listes de vendeurs potentiels en passant des annonces
dans des publications à large diffusion, comme les journaux, ou dans des publications spé-
cialisées, comme les journaux professionnels. Certaines administrations doivent passer une
annonce publique pour certains types d’approvisionnement ; la plupart d’entre elles doivent
faire la même chose pour les contrats de sous-traitance du secteur public.

12.3.3 Données de sortie des appels d’offres


.1 Offres. Les offres (voir également la section 12.2.3.1 qui traite des soumissions, devis et
offres) sont des documents préparés par un vendeur décrivant son intention et sa capacité à
fournir le produit demandé. Elles sont préparées conformément aux instructions contenues
dans les documents d’approvisionnement. Les offres peuvent être accompagnées d’une pré-
sentation orale.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
154 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 12 — Gestion des approvisionnements du projet

12.4 CHOIX DES FOURNISSEURS


Le choix des fournisseurs implique la réception des soumissions ou offres, et l’application de
critères d’évaluation à la sélection d’un prestataire. Lors de la sélection des fournisseurs, de
nombreux facteurs doivent être évalués, en dehors du coût ou du prix.
■ Le prix peut être le facteur déterminant pour un produit commercial, mais le prix le plus
bas proposé n’est pas nécessairement le coût le plus bas, si le vendeur s’avère incapable
de livrer le produit en temps voulu.
■ Les offres sont souvent séparées en partie technique (approche) et commerciale (prix),
chacune étant évaluée séparément.
■ Plusieurs sources peuvent s’avérer nécessaires pour des produits critiques.
Les méthodes et les outils décrits ici peuvent s’employer séparément ou ensemble. Par
exemple, un système de pondération peut servir à :
■ sélectionner un fournisseur unique, à qui on demandera de signer un contrat type ;
■ classer dans l’ordre toutes les offres pour établir une séquence de négociation.
Dans le cas d’éléments approvisionnés importants, ce processus peut être répété. Une pré-
sélection de vendeurs qualifiés peut être effectuée en fonction d’une offre préliminaire ; une
évaluation plus approfondie sera ensuite effectuée, à partir d’une offre plus détaillée et plus
complète.

12.4.1 Données d’entrée du choix des fournisseurs


.1 Offres. Les offres sont décrites à la section 12.3.3.1.
.2 Critères d’évaluation. Les critères d’évaluation peuvent comprendre des échantillons de pro-
duits ou de services déjà fournis par les fournisseurs, comme moyen d’évaluer leurs capacités
et la qualité de leurs produits. Ils peuvent également comporter une consultation de l’histo-
rique du rapport du fournisseur avec l’organisation passant le contrat. Les critères d’évalua-
tion sont décrits à la section 12.2.3.2.
.3 Règles d’organisation. Les organisations impliquées dans les approvisionnements de projet
ont en principe des règles officielles qui vont affecter l’évaluation des offres.

12.4.2 Outils et méthodes de choix des fournisseurs


.1 Négociation du contrat. La négociation du contrat implique des clarifications et un accord
mutuel sur la structure et les exigences de celui-ci avant la signature. Dans la mesure du pos-
sible, la rédaction finale du contrat doit être le reflet de tous les accords conclus. En général,
les sujets couverts comprennent, entre autres, les responsabilités et les niveaux d’autorité, les
modalités et la loi applicables, les approches de gestion technique et commerciale, le finan-
cement du contrat et le prix.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
155
Chapitre 12 — Gestion des approvisionnements du projet

Dans le cas d’éléments d’approvisionnement complexes, la négociation du contrat peut


12.4.2.2 | 12.5.1.4

être un processus indépendant comportant des données d’entrée (par exemple, une liste de
problèmes ou de questions non résolus) et des données de sortie (par exemple, un protocole
d’accord) propres.
.2 Système de pondération. Un système de pondération est une méthode servant à quantifier
des donnés qualitatives pour minimiser les effets des préjugés individuels lors du choix du
vendeur. Ces types de systèmes impliquent pour la plupart : 1) d’attribuer un cœfficient à
chaque critère d’évaluation, 2) de classer les vendeurs potentiels selon chaque critère, 3) de
multiplier le cœfficient par le classement et 4) de faire le total des résultats obtenus pour
arriver à un score global.
.3 Système de sélection. Un système de sélection consiste à établir des exigences de perfor-
mance minimales pour un ou plusieurs critères d’évaluation. À savoir, un vendeur potentiel
peut se voir imposer de proposer un chef de projet ayant des qualifications particulières, par
exemple un diplômé PMP®, avant que le reste de son offre puisse être étudié.
.4 Estimations indépendantes. Dans de nombreux cas, l’organisation responsable des approvi-
sionnements peut développer ses propres estimations pour vérifier les prix proposés. Des dif-
férences significatives entre les estimations peuvent indiquer que la description des travaux
était inexacte ou que le vendeur potentiel ne l’a pas comprise, ou n’y a pas répondu com-
plètement. Les estimations indépendantes sont souvent appelées estimations du coût accep-
table.

12.4.3 Données de sortie du choix des fournisseurs


.1 Contrat. Un contrat est une obligation réciproque et irrévocable obligeant le vendeur à
fournir le produit spécifié et l’acheteur à en payer le prix. Un contrat établit une relation
légale et peut être porté devant les tribunaux. L’accord peut être simple ou complexe, reflétant
habituellement, mais pas toujours, la simplicité ou la complexité du produit. Les contrats,
entre autres désignations, peuvent être appelés contrat, accord, sous-contrat, bon de com-
mande ou protocole d’accord. La plupart des organisations ont des règles et des procédures
formelles (habituellement appelées délégation des pouvoirs d’approvisionnement) identifiant
spécifiquement la personne habilitée à signer de tels accords pour le compte de l’organisa-
tion.
Bien que tous les documents du projet soient sujets à une forme quelconque de révision
et d’approbation, l’obligation légale qu’implique un contrat signifie, en principe, qu’il sera
soumis à un processus d’approbation plus approfondi. Dans tous les cas, le processus de révi-
sion et d’approbation devra principalement assurer que le contrat a été rédigé de manière à
décrire le produit ou service répondant au besoin identifié. Dans le cas de projets importants
entrepris par des organismes publics, le processus de révision peut même inclure une révi-
sion publique de l’accord.

12.5 ADMINISTRATION DES CONTRATS


L’administration des contrats est le processus assurant que les performances du vendeur
répondent aux exigences contractuelles. Dans les projets de plus grande envergure, compor-
tant de nombreux fournisseurs de services ou de produits, l’aspect majeur de l’administration
des contrats consiste à gérer les interfaces entre les divers prestataires. Au vu de l’obligation
légale qu’implique la relation contractuelle, il est impératif que l’équipe de projet soit
consciente des conséquences juridiques des actions prises lors de l’administration des contrats.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
156 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 12 — Gestion des approvisionnements du projet

L’administration des contrats comprend l’application des processus de gestion de projet


convenant aux relations contractuelles, et l’intégration des données de sortie de ces processus
dans la gestion d’ensemble du projet. Lorsque plusieurs vendeurs et produits sont impliqués,
cette intégration et cette coordination ont souvent lieu à différents niveaux. Les processus de
gestion de projet à appliquer sont :
■ la réalisation du plan de projet, décrite à la section 4.2, pour autoriser le travail du contrac-
tant au moment opportun ;
■ les rapports d’avancement, décrits à la section 10.3, pour contrôler les coûts, les délais et
les performances techniques du contractant ;
■ le contrôle de la qualité, décrit à la section 8.3, pour inspecter le produit du contractant et
en vérifier la conformité ;
■ le contrôle des changements, décrit à la section 4.3, pour s’assurer que les changements
sont correctement approuvés et que tous ceux qui devaient en être informés l’ont bien été.
L’administration des contrats a également une composante financière. Les règles de paie-
ment doivent être précisées dans le contrat et établir une relation spécifique entre l’avance-
ment des travaux effectués par le vendeur et les compensations qui lui sont versées.

12.5.1 Données d’entrée de l’administration des contrats


.1 Contrat. Les contrats sont décrits à la section 12.4.3.1.
.2 Travail réalisé. Les résultats du travail réalisé par le vendeur (quels sont les produits livrables
achevés et ceux qui ne le sont pas, dans quelle mesure les normes de qualité sont-elles res-
pectées, quels ont été les coûts encourus ou engagés, etc.) sont rassemblés comme des élé-
ments de la mise en œuvre du plan de projet. (La section 4.2 donne plus de détails sur la mise
en œuvre du plan de projet.)
.3 Demandes de changements. Les demandes de changements peuvent porter sur la modifi-
cation des modalités du contrat ou de la description du produit ou du service à fournir. Si le
travail du vendeur n’est pas satisfaisant, la décision de résilier le contrat sera aussi traitée
comme une demande de changement. Les changements contestés, à savoir ceux pour lesquels
le vendeur et l’équipe de gestion de projet n’ont pas pu se mettre d’accord sur le payeur, sont
appelés, selon les cas, réclamations, différends ou appels.
.4 Factures des vendeurs. Le vendeur doit envoyer des factures au fur et à mesure pour
demander le paiement du travail effectué. Les conditions de facturation, documents justifica-
tifs nécessaires compris, sont définies dans le contrat.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
157
Chapitre 12 — Gestion des approvisionnements du projet

12.5.2 Outils et méthodes d’administration des contrats


12.5.2 | 12.6.3.2

.1 Système de contrôle des changements du contrat. Le système de contrôle des changements


du contrat définit le processus selon lequel le contrat peut être modifié. Il comprend les docu-
ments, les systèmes de suivi, les procédures de conciliation et les niveaux d’autorisation
nécessaires à l’autorisation des changements. Le système de contrôle des changements du
contrat doit être intégré au système de contrôle intégré des changements. (La section 4.3.
décrit ce système.)
.2 Rapports d’avancement. Les rapports d’avancement permettent à la hiérarchie de savoir dans
quelle mesure le vendeur atteint les objectifs contractuels. Les rapports d’avancement du
contrat doivent être intégrés aux rapports d’avancement intégrés du projet, décrits à la section
10.3.
.3 Système de règlement. Les règlements versés au vendeur sont habituellement gérés par le
système comptable de l’entreprise réalisatrice. Dans les projets de plus grande envergure, dans
le cas de gros volumes à approvisionner complexes, le projet peut développer son propre sys-
tème. Dans les deux cas, le système de règlement doit inclure des révisions et approbations
par l’équipe de gestion de projet.

12.5.3 Données de sortie de l’administration des contrats


.1 Correspondance. Les modalités du contrat nécessitent souvent la rédaction de documents
concernant certains aspects de la communication entre l’acheteur et le vendeur, tels que des
avertissements dans le cas de performances insuffisantes, et des modifications ou clarifications
apportées au contrat.
.2 Changements du contrat. Les changements (approuvés ou non) sont répercutés à l’aide des
processus correspondants de planification et d’approvisionnement du projet ; le cas échéant,
le plan de projet et toute la documentation s’y rapportant sont alors mis à jour.
.3 Demandes de règlement. Cela suppose que le projet utilise un système de règlement exté-
rieur. Si le projet possède son propre système interne, les donnés de sortie correspondent
alors aux « règlements ».

12.6 CLÔTURE DU CONTRAT


La clôture du contrat ressemble à la clôture administrative (décrite à la section 10.4) car elle
implique à la fois une vérification du produit (le travail a-t-il été effectué convenablement et
de manière satisfaisante ?) et une clôture administrative (mise à jour des dossiers pour y incor-
porer les résultats finaux et archivage de ces informations pour leur utilisation ultérieure). Les
modalités du contrat peuvent imposer des procédures spécifiques de clôture. La résiliation
d’un contrat constitue un cas particulier de clôture.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
158 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Chapitre 12 — Gestion des approvisionnements du projet

12.6.1 Données d’entrée de la clôture du contrat


.1 Documentation contractuelle. La documentation contractuelle comprend, entre autres, le
contrat proprement dit, ainsi que tous les plannings, les changements du contrat demandés et
approuvés, toute la documentation technique développée par le vendeur, les rapports d’avan-
cement du vendeur, les documents financiers (factures et justificatifs de paiement, par
exemple) et les résultats d’inspections liées au contrat.

12.6.2 Outils et méthodes de clôture du contrat


.1 Audits des approvisionnements. Un audit des approvisionnements est un passage en revue
structuré du processus d’approvisionnement, depuis la planification des approvisionnements
jusqu’à l’administration des contrats. L’objectif d’un audit des approvisionnements est d’iden-
tifier les succès et les échecs justifiant un transfert vers d’autres éléments d’approvisionnement
pour ce projet ou vers d’autres projets de l’entreprise réalisatrice.

12.6.3 Données de sortie de la clôture du contrat


.1 Dossier du contrat. Un ensemble complet de données indexées à inclure au dossier final du
contrat doit être préparé (voir la section 10.4 pour plus de détails sur la clôture administrative
et les archives du projet).
.2 Acceptation et clôture officielles. La personne ou l’organisation responsable de l’administra-
tion des contrats doit notifier officiellement le vendeur, par écrit, que le contrat a été rempli.
Les exigences en matière d’approbation et de clôture officielles sont habituellement précisées
dans le contrat.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
159
SECTION III

ANNEXES

A. Processus de normalisation du Projet Management Institute

B. Evolution du Guide du référentiel des connaissances en


gestion de projet du PMI (A Guide to the Project
Management Body of Knowledge)

C. Collaborateurs et réviseurs du Guide PMBOK® édition 2000

D. Notes

E. Extensions des champs d’application

F. Autres sources d’informations sur la gestion de projet

G. Résumé des domaines de compétence de la gestion de


projet
Annexe A

Processus de normalisation
du Project Management
Institute

À l’origine, le processus de normalisation du Project Management Institute (PMI) a été institué


en tant que politique de l’Institut par un vote du directoire du PMI lors de sa réunion d’oc-
tobre 1993. En mars 1998, le directoire du PMI a approuvé certaines modifications de ce pro-
cessus. Puis en mars 1999, de nouvelles modifications y ont été apportées afin d’intégrer les
modifications simultanées des procédures de gouvernance du PMI.

A.1 LES NORMES DU PMI


Les normes du PMI sont des documents élaborés ou publiés par le PMI, décrivant des pra-
tiques en gestion de projet d’un usage généralisé. Ces documents comprennent :
■ le Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®) ;
■ les manuels d’utilisation du référentiel des connaissances en gestion de projet.
D’autres documents peuvent être ajoutés à cette liste par le directeur de la normalisation
du PMI, avec l’avis et sous réserve de l’accord du Project Management Standards Program
Member Advisory Group et du directeur administratif du PMI. Les normes peuvent corres-
pondre à des ouvrages émanant du PMI et publiés par celui-ci ou encore à des publications
émanant d’autres organisations ou individus.
Les normes sont élaborées conformément au « Code de bonne conduite pour la normali-
sation » établi par l’Organisation internationale de normalisation (ISO) et aux directives concer-
nant la normalisation établies par l’American National Standards Institute (ANSI).

A.2 ÉLABORATION DES OUVRAGES ÉMANANT DU PMI


Les normes, établies par des textes élaborés par le PMI ou les révisions apportées à ces docu-
ments, sont publiées comme suit :
■ Le ou les auteurs potentiels soumettent une proposition au directeur de la normalisation
du PMI. Celui-ci peut également demander la soumission de telles propositions. Le direc-
teur soumet toutes les propositions reçues au PMI Standards Program Member Advisory
Group et décide avec lui de les accepter ou de les rejeter.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
163
Annexe A — Processus de normalisation du Projet Management Institute

■ Le directeur informe le ou les auteurs potentiels de sa décision et de la raison la motivant.


Annexe A

Si une proposition approuvée nécessite un financement dépassant le budget alloué pour


la normalisation, le directeur soumet la proposition au directeur administratif du PMI.
■ Pour toutes les propositions approuvées et financées, le directeur apporte son aide à l’au-
teur afin d’optimiser les chances d’acceptation du produit final. Le ou les auteurs doivent
signer le document de cession volontaire des copyrights au PMI (PMI Volunteer Assign-
ment of Copyright).
■ Lorsque le document proposé est terminé et convient à l’auteur ou aux auteurs de la pro-
position, ils le soumettent au directeur de la normalisation du PMI. Le PMI Standards Pro-
gram Member Advisory Group et le directeur passent en revue le document proposé et
décident de son transfert à des personnes compétentes pour un examen complémentaire
ou de son renvoi à l’auteur ou aux auteurs pour son amélioration.
■ Le directeur nomme, sous réserve de révision et d’approbation par le PMI Standards Pro-
gram Member Advisory Group, au moins trois personnes compétentes pour passer en
revue et commenter le document. En fonction des commentaires reçus, le Member Advi-
sory Group décide d’accepter ou non le document en tant que version pour commentaire.
■ Le directeur de la normalisation du PMI élabore un plan permettant au public d’étudier,
comme il se doit, chaque version pour commentaire. Ce plan comprend : a) une durée
d’étude d’un mois minimum à six mois maximum, b) l’avis de disponibilité pour étude de
la version pour commentaire dans le PM Network® (et/ou sur d’autres supports similaires
et adéquats) et c) le coût des copies pour étude. Le PMI Standards Program Member Advi-
sory Group doit approuver le plan d’étude publique du directeur. Chaque version pour
commentaire comprend une notice demandant l’envoi des commentaires au directeur de
la normalisation du PMI, au siège social du PMI et indiquant la durée et la date d’expira-
tion de la période d’étude.
■ Les versions pour commentaire sont publiées sous l’égide du Service d’édition du PMI et
doivent se conformer aux normes de celui-ci en matière de typographie et de style.
■ Pendant la période d’étude, le directeur sollicite l’avis officiel des directeurs des autres pro-
grammes du PMI (par exemple, certification, formation, composants et publication)
concernés par la future publication du document comme norme du PMI.
■ À la fin de la période d’étude, le directeur de la normalisation du PMI passe en revue les
commentaires reçus avec le PMI Standards Program Member Advisory Group et travaille
en collaboration avec le ou les auteurs, et d’autres personnes au besoin, à l’incorporation
des commentaires pertinents. En présence d’un grand nombre de commentaires, le PMI
Standards Program Member Advisory Group peut choisir de répéter le processus d’étude
de la version pour commentaire.
■ Lorsque le directeur de la normalisation du PMI et le PMI Standards Program Member
Advisory Group ont approuvé le document proposé, le directeur le soumet sans délai au
directeur administratif pour révision finale et accord. Le directeur administratif vérifie la
conformité du document aux procédures et s’assure que l’avis des membres a bien été pris
en compte. Il peut décider de : a) approuver le document tel que soumis, b) rejeter le
document ou c) demander la répétition du processus d’étude. Il motive sa décision.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
164 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Annexe A — Processus de normalisation du Projet Management Institute

A.3 ATTRIBUT DU STATUT DE NORME À DES OUVRAGES


EXTÉRIEURS
Les normes établies par des ouvrages émanant d’autres organisations ou individus sont
publiées comme suit :
■ Toute personne ou organisation peut adresser une demande au directeur de la normali-
sation du PMI pour lui demander d’étudier une publication extérieure afin de l’accepter
comme norme du PMI. Le directeur soumet toutes les propositions reçues au PMI Stan-
dards Program Member Advisory Group et décide avec lui de les accepter ou de les rejeter.
En cas d’acceptation, le directeur nomme, sous réserve de révision et d’approbation par le
PMI Standards Program Member Advisory Group, au moins trois personnes compétentes
pour passer en revue et commenter le document.
■ Durant la période d’étude, le directeur sollicite l’avis officiel des directeurs des autres pro-
grammes du PMI (par exemple, certification, formation, composants et publication)
concernés par la future publication du document comme norme du PMI.
■ En fonction des commentaires reçus, le Member Advisory Group et le directeur décident
de : a) accepter la proposition telle que rédigée comme norme du PMI, b) accepter la pro-
position avec des modifications et/ou un addendum comme norme du PMI, c) demander
une autre étude et d’autres commentaires sur la proposition (c’est-à-dire des réviseurs sup-
plémentaires et/ou l’émission d’une version pour commentaire) ou d) rejeter la proposi-
tion. Le directeur informe l’auteur de la proposition de la décision prise et de la raison la
motivant.
■ Lorsque le directeur de la normalisation du PMI et le PMI Standards Program Member
Advisory Group ont approuvé le document proposé, le directeur le soumet sans délai au
directeur administratif pour révision finale et accord. Le directeur prépare à l’attention du
directeur administratif une proposition de collaboration éventuelle avec le ou les auteurs
du document.
■ Le directeur administratif du PMI vérifie la conformité du document avec les procédures
et s’assure que l’avis d’un nombre suffisant de membres a été pris en compte. Il peut
décider de : a) approuver le document tel que soumis, b) rejeter le document ou c)
demander la répétition du processus d’étude. Il motive sa décision.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
165
Annexe B

Évolution du
Guide du référentiel des
connaissances en
gestion de projet
du PMI
B.1 LES PREMIERS PAS
Le Project Management Institute (PMI) est fondé en 1969 sur l’idée qu’il existe de nombreuses
pratiques communes de gestion dans des projets de domaines aussi divers que ceux du bâti-
ment ou de l’industrie pharmaceutique. L’idée d’établir des normes basées sur ces pratiques
commence à être largement débattue, en 1976, lors du Symposium du PMI à Montréal. La ges-
tion de projet est ensuite reconnue comme profession à part entière.
Il faut cependant attendre 1981 pour que le directoire du PMI approuve un projet d’éla-
boration de procédures et de concepts nécessaires à la profession de gestionnaire de projet.
La proposition de projet suggère trois axes de réflexion :
■ les caractéristiques distinctives du professionnel (éthique) ;
■ le contenu et la structure du référentiel des connaissances de la profession (normes) ;
■ la reconnaissance de la profession (accréditation).
L’équipe de projet devient ainsi connue sous le nom de « Ethics, Standards, and Accredi-
tation (ESA) Management Group ». Ce groupe est composé de :
Matthew H. Parry, président David C. Aird
Frederick R. Fisher David Haeney
Harvey Kolodney Charles E. Oliver
William H. Robinson Douglas J. Ronson
Paul Sims Eric W. Smythe
Ce groupe reçoit l’aide de plus de vingt-cinq bénévoles provenant de plusieurs branches
locales. La composante « éthique » est élaborée et soumise par un comité à Washington, D.C.,
présidé par Lew Ireland. La composante « gestion des délais » est élaborée à la suite de
longues réunions d’un groupe du sud de l’Ontario comprenant Dave MacDonald, Dave
Norman, Bob Spence, Bob Hall et Matt Parry. La composante « gestion des coûts » est élaborée

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
167
Annexe B — Evolution du Guide du référentiel des connaissances en gestion de projet du PMI

à la suite de longues réunions au sein du service des coûts de Stelco, sous la direction de
Annexe B

Dave Haeney et Larry Harrison. D’autres composantes sont élaborées par le groupe ESA. John
Adams et son groupe de Western Carolina University sont chargés des travaux d’accréditation.
Ces derniers conduisent à l’élaboration de lignes directrices pour l’accréditation et d’un pro-
gramme de certification des professionnels de la gestion de projet (les diplômés PMP) sous la
direction de M. Dean Martin.
Les résultats du projet de l’ESA sont publiés dans un rapport spécial du Project Manage-
ment Journal en août 1983. Ce rapport comprend :
■ un code de bonne conduite, accompagné d’une procédure de mise en application ;
■ une base de référence des normes composée de six disciplines principales : gestion du
contenu, gestion des coûts, gestion des délais, gestion de la qualité, gestion des ressources
humaines et gestion des communications ;
■ des lignes directrices pour l’accréditation (reconnaissance de la qualité des programmes
proposés par des structures d’enseignement) et pour la certification (reconnaissance de la
qualification professionnelle de certains individus).
Ce rapport sert par la suite de base aux premiers programmes d’accréditation et de certi-
fication du PMI. Le « Master » en gestion de projet délivré par Western Carolina University est
accrédité en 1983 et les premiers diplômés « Professionnels en gestion de projet » (PMP) sont
certifiés en 1984.

B.2 MISE À JOUR DES ANNÉES 1986–87


La publication du rapport de base de l’ESA entraîne de nombreuses discussions au sein du
PMI sur la pertinence des normes. En 1984, le directoire du PMI approuve un deuxième projet
de normalisation afin de « faire le tour des connaissances appliquées à la gestion de projet…
dans le cadre de l’ESA existant ». Six comités sont formés pour travailler sur les six disciplines
identifiées. De plus, en 1985, un atelier de travail est inscrit au calendrier des séminaires (Sym-
posiums) annuels du PMI.
Un document révisé, fruit de ces travaux, est approuvé dans son principe par le directoire
du PMI et publié pour commentaires dans le Project Management Journal d’août 1986. Les
principaux collaborateurs à cette version du document sont :
R. Max Wideman, président John R. Adams, président
(pendant l’élaboration) (après publication)
Joseph R. Beck Peter Bibbes
Jim Blethen Richard Cockfield
Peggy Day William Dixon
Peter C. Georgas Shirl Holingsworth
William Kane Colin Morris
Joe Muhlberger Philip Nunn
Pat Patrick David Pym
Linn C. Stuckenbruck George Vallance
Larry C. Woolslager Shakir Zuberi
En plus de l’expansion et de la restructuration du document d’origine, le document révisé
comprend trois nouvelles sections :
■ Le cadre de la gestion de projet est ajouté pour couvrir les relations entre le projet et son
environnement externe, et entre la gestion de projet et la gestion en général.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
168 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Annexe B — Evolution du Guide du référentiel des connaissances en gestion de projet du PMI

■ La gestion des risques est ajoutée comme discipline à part entière de façon à mieux cou-
vrir ce thème.
■ La gestion des contrats/approvisionnements est ajoutée comme discipline à part entière de
façon à mieux couvrir ce thème.
Par la suite, diverses modifications éditoriales et corrections sont incorporées au document,
et le directoire du PMI approuve ce dernier en mars 1987. Le manuscrit final est publié en
août 1987 sous le titre de The Project Management Body of Knowledge.

B.3 MISE À JOUR DE 1996


Le débat sur la forme, le contenu et la structure des normes clés du PMI continue après la
publication de la version de 1987. En août 1991, le directeur de la normalisation du PMI, Alan
Stretton, lance un projet de mise à jour du document sur la base des commentaires adressés
par les membres. L’élaboration du document révisé dure plusieurs années et découle d’une
série de documents de travail largement diffusés et d’ateliers durant les séminaires du PMI de
Dallas, Pittsburgh et San Diego.
En août 1994, le comité de normalisation du PMI émet une version pour commentaire du
document. Celle-ci est distribuée aux 10 000 membres du PMI et à plus de vingt autres asso-
ciations professionnelles et techniques.
La publication, en 1996, de l’ouvrage intitulé A Guide to the Project Management Body of
Knowledge (PMBOK® Guide) représente l’achèvement du projet lancé en 1991. Une liste des
collaborateurs et réviseurs impliqués figure plus loin dans cette section. Un résumé des dif-
férences entre le document de 1987 et celui de 1996, inclus dans la préface de l’édition 1996,
figure également plus loin dans cette section.
Ce document remplace le document du PMI intitulé Project Management Body of Know-
ledge (PMBOK®), publié en 1987. Pour aider les utilisateurs du document de 1996 qui ne
connaissent pas le document précédent, nous en avons résumé ici les principales différences.
1. Nous avons changé le titre pour souligner que ce document ne constitue pas en soi le
référentiel des connaissances en gestion de projet. Le document de 1987 définissait le réfé-
rentiel des connaissances en gestion de projet comme « l’ensemble des questions d’actualité,
domaines de réflexion et processus intellectuels impliqués dans la mise en œuvre de principes
solides de gestion… dans les projets ». Il est évident qu’un seul document ne peut constituer
à lui seul l’ensemble des connaissances en gestion de projet.
2. La section intitulée Framework (cadre) a été totalement réécrite. La nouvelle section
comporte trois chapitres :
■ « Introduction », qui définit l’objectif du document et explique en détail les termes projet
et gestion de projet.
■ « Contexte de la gestion de projet », qui traite du contexte dans lequel les projets se dérou-
lent : le cycle de vie du projet, le point de vue des acteurs, les influences extérieures et les
compétences clés en gestion en général.
■ « Processus de la gestion de projet », qui décrit les interactions entre les divers domaines
de la gestion de projet.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
169
Annexe B — Evolution du Guide du référentiel des connaissances en gestion de projet du PMI

3. Nous avons élaboré une définition revue et corrigée du projet. Nous souhaitions une défi-
Annexe B

nition qui soit à la fois exhaustive (il devait être impossible d’identifier comme projet une
entreprise généralement considérée comme telle mais ne répondant pas à la définition) et
exclusive (elle ne devait pas décrire une entreprise répondant à la définition mais n’étant pas
généralement considérée comme un projet). Nous avons trouvé de nombreuses définitions du
projet dans les ouvrages existants, et aucune ne nous a semblé complètement satisfaisante. La
nouvelle définition prend en compte les caractéristiques uniques d’un projet : un projet est
une entreprise temporaire mise en œuvre en vue de créer un produit ou service unique.
4. Le concept de cycle de vie du projet a été révisé. Le document de 1987 définissait les
phases du projet comme des subdivisions du cycle de vie du projet. Nous avons réorganisé
cette relation et défini le cycle de vie du projet comme un ensemble de phases dont le nombre
et les désignations sont déterminés par les besoins de contrôle de l’entreprise réalisatrice.
5. Les sections principales précédemment intitulées « fonctions » ont été rebaptisées « disci-
plines ». Le terme fonction étant souvent compris à tort comme signifiant un élément d’une
organisation fonctionnelle, le changement de nom devrait éliminer cette erreur de compré-
hension.
6. Nous avons officiellement reconnu l’existence d’une neuvième discipline. Il existait
depuis un certain temps un consensus, visant à reconnaître la gestion de projet comme un
processus intégratif. Le chapitre 4, « Gestion de l’intégration du projet », reconnaît l’importance
de ce sujet.
7. Nous avons ajouté le mot « projet » au titre de chaque discipline. Cela peut paraître redon-
dant, mais le but est de clarifier le contenu du document. Par exemple, la gestion des res-
sources humaines du projet ne couvre que les aspects de la gestion des ressources humaines
particuliers uniquement, ou presque, au contexte du projet.
8. Nous avons choisi de décrire les disciplines par les processus qui les composent. La
recherche d’une méthode homogène de présentation nous a conduits à restructurer entière-
ment le document de 1987 en trente-sept processus de gestion de projet. Chaque processus est
décrit en termes de données d’entrée, données de sortie et outils et méthodes. Les données
d’entrée et de sortie correspondent à des documents (par exemple, un cahier des charges) ou
à des éléments pouvant être documentés (par exemple, les dépendances entre activités). Les
outils et méthodes sont des mécanismes appliqués aux données d’entrée pour créer les don-
nées de sortie. Outre sa simplicité fondamentale, cette approche présente également plusieurs
autres avantages :
■ Elle met l’accent sur les interactions entre les disciplines. Les données de sortie d’un pro-
cessus deviennent les données d’entrée d’un autre processus.
■ Sa structure est souple et stable. Les changements en matière de disciplines et de pratiques
peuvent facilement être assimilés en ajoutant un nouveau processus, en modifiant l’ordre
des processus, en créant des subdivisions dans les processus ou en ajoutant des descrip-
tions à l’intérieur d’un processus.
■ Les processus sont au cœur d’autres normes. Par exemple, les normes de qualité de l’Or-
ganisation internationale de normalisation (la série ISO 9000) sont fondées sur l’identifi-
cation des processus commerciaux.
9. Nous avons ajouté quelques illustrations. Qu’il s’agisse d’un organigramme des tâches,
d’un diagramme réseau du projet et de courbes en S, un croquis vaut mieux qu’un long dis-
cours.
10. Nous avons réorganisé le document de façon significative. Le tableau suivant permet
de comparer les principaux titres de chapitres du document de 1987 à ceux du document de
1996 :

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
170 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Annexe B — Evolution du Guide du référentiel des connaissances en gestion de projet du PMI

Numérotation et désignation de 1987 Numérotation et désignation de 1996


0. Normes du PMBOK® B. Évolution du Guide du référentiel des
connaissances en gestion de projet (A
Guide to the Project Management Body of
Knowledge)
1. Cadre : logique 1. Introduction (définitions de base)
2. Contexte de la gestion de projet
(cycles de vie)
2. Cadre : vue d’ensemble 1. Diverses parties
2. Diverses parties
3. Diverses parties
3. Cadre : modèle intégratif 3. Processus de la gestion de projet
4. Gestion de l’intégration du projet
4. Glossaire de termes généraux IV. Glossaire
A. Gestion du contenu 5. Gestion du contenu du projet
B. Gestion de la qualité 8. Gestion de la qualité du projet
C. Gestion des délais 6. Gestion des délais du projet
D. Gestion des coûts 7. Gestion des coûts du projet
E. Gestion des risques 11. Gestion des risques du projet
F. Gestion des ressources humaines 9. Gestion des ressources humaines
du projet
G. Gestion des contrats/des approvisionne- 12. Gestion des approvisionnements du
ments du projet projet
H. Gestion des communications 10. Gestion des communications du projet
11. Nous avons éliminé « à classer » (to classify) de la liste des objectifs. Le document de
1996 et la version de 1987 offrent une structure à l’organisation des connaissances en ges-
tion de projet, mais ni l’un ni l’autre ne constituent des outils de classement particulièrement
utiles. En premier lieu, les sujets inclus ne sont pas exhaustifs, c’est-à-dire qu’ils n’incluent pas
de pratiques novatrices ou inhabituelles. En second lieu, de nombreux éléments étant utilisés
dans plusieurs disciplines ou plusieurs processus, les catégories ne sont donc pas uniques.
Les personnes suivantes, qui figurent à l’annexe C du document de 1996, ont contribué de
diverses manières aux différentes versions du document de 1996. Le PMI les remercie de leur
aide.

Comité de normalisation
Les personnes suivantes faisaient partie du comité de normalisation du PMI pendant la mise
à jour de 1996 du guide PMBOK® :
■ William R. Duncan, Duncan • Nevison, directeur de la normalisation du PMI
■ Frederick Ayer, Defense Systems Management College
■ Cynthia Berg, Medtronic Micro-Rel
■ Mark Burgess, KnowledgeWorks
■ Helen Cooke, Cooke & Cooke
■ Judy Doll, Searle
■ Drew Fetters, PECO Energy Company
■ Brian Fletcher, ABRINN Project Management Services
■ Earl Glenwright, A.S.S.I.S.T.
■ Eric Jenett, consultant
■ Deborah O’Bray, Manitoba Telephone System
■ Diane Quinn, Eastman Kodak Co.
■ Anthony Rizzotto, Miles Diagnostics
■ Alan Stretton, University of Technology, Sydney
■ Douglas E. Tryloff, TASC

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
171
Annexe B — Evolution du Guide du référentiel des connaissances en gestion de projet du PMI

Collaborateurs
Annexe B

En plus des membres du comité de normalisation, les personnes suivantes ont contribué par
des textes originaux ou des concepts clés à l’une ou plusieurs sections des chapitres indiqués :
■ John Adams, Western Carolina University (chapitre 3, « Processus de la gestion de projet »)
■ Keely Brunner, Ball Aerospace (chapitre 7, « Gestion des coûts du projet »)
■ Louis J. Cabano, Pathfinder, Inc. (chapitre 5, « Gestion du contenu du projet »)
■ David Curling, Loday Systems (chapitre 12, « Gestion des approvisionnements du projet »)
■ Douglas Gordon, Special Projects Coordinations (chapitre 7, « Gestion des coûts du
projet »)
■ David T. Hulett, D. T. Hulett & Associates (chapitre 11, « Gestion des risques du projet »)
■ Edward Ionata, Bechtel/Parsons Brinckerhoff (chapitre 10, « Gestion des communications
du projet »)
■ John M. Nevison, Duncan•Nevison (chapitre 9, « Gestion des ressources humaines du
projet »)
■ Hadley Reynolds, Reynolds Associates (chapitre 2, « Contexte de la gestion de projet »)
■ Agnes Salvo, CUNA Mutual Insurance (chapitre 11, « Gestion des risques du projet »)
■ W. Stephen Sawle, Consultants to Management, Inc. (chapitre 5, « Gestion du contenu du
projet »)
■ Leonard Stolba, Parsons, Brinckerhoff, Douglas & Quade (chapitre 8, « Gestion de la qua-
lité du projet »)
■ Ahmet Taspinar, MBP Network (chapitre 6, « Gestion des délais du projet »)
■ Francis M. Webster Jr. (chapitre 1, sur la définition de projet)

Réviseurs
En plus du comité de normalisation et des collaborateurs, les personnes suivantes ont adressé
des commentaires sur les diverses versions du document de 1996 :
■ Edward L. Averill, Edward Averill & Associates
■ A. C. (Fred) Baker, Baker, Barnes Associates, Inc.
■ F. J. (Bud) Baker, Wright State University
■ Tom Belanger, The Sterling Planning Group
■ John A. Bing, Coastline Community College
■ Brian Bock, Ziff Desktop Information
■ Paul Bosakowski, Fluor Daniel
■ Dorothy J. Burton, Management Systems Associates, Ltd.
■ Cohort ‘93, University of Technology, Sydney
■ Cohort ‘94, University of Technology, Sydney
■ Kim Colenso, Applied Business Technologies
■ Samuel K. Collier, Mead Corporation
■ Karen Condos-Alfonsi, bureau de la direction du PMI
■ E. J. Coyle, VDO Yazaki
■ Darlene Crane, Crane Consulting
■ Russ Darnall, Fluor Daniel
■ Maureen Dougherty, GPS Technologies
■ John J. Downing, Digital Equipment Corporation
■ Daniel D. Dudek, Optimum Technologies, Inc.
■ Lawrence East, Westinghouse

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
172 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Annexe B — Evolution du Guide du référentiel des connaissances en gestion de projet du PMI

■ Quentin W. Fleming, Primavera Systems, Inc.


■ Rick Fletcher, Acres
■ Greg Githens, Maxicomm Project Services, Inc.
■ Leo Giulianeti, Keane Inc.
■ Martha D. Hammonds, AMEX TSG Systems
■ Abdulrazak Hajibrahim, Bombardier
■ G. Alan Hellawell, Eastman Kodak
■ Paul Hinkley, Meta Consultants
■ Wayne L. Hinthorn, PMI du comté d’Orange, CA
■ Mark E. Hodson, Eli Lilly & Company
■ Lew Ireland, L. R. Ireland Associates
■ Elvin Isgrig, North Dakota State University
■ Murray Janzen, Procter & Gamble
■ Frank Jenes
■ Walter Karpowski, Management Assoc.
■ William F. Kerrigan, Bechtel International, Inc.
■ Harold Kerzner, Baldwin-Wallace College
■ Robert L. Kimmons, Kimmons-Asaro Group Ltd., Inc.
■ Richard King, AT&T
■ J. D. “Kaay” Koch, Koch Associates
■ Lauri Koskela, VTT Building Technology
■ Richard E. Little, Project Performance Management
■ Lyle W. Lockwood, Universal Technology Inc.
■ Lawrence Mack, PMI Pittsburgh
■ Christopher Madigan, Sandia National Laboratories
■ Michael L. McCauley, Integrated Project Systems
■ Hugh McLaughlin, Broadstar Inc.
■ Frank McNeely, National Contract Management Association
■ Pierre Ménard, Université du Québec à Montréal
■ Rick Michaels
■ Raymond Miller, AT&T
■ Alan Minson, A&R Minson
■ Colin Morris, Delcan Hatch
■ R. Bruce Morris
■ David J. Mueller, Westinghouse
■ Gary Nelson, Athena Consulting Inc.
■ John P. Nolan, AACE International
■ Louise C. Novakowski, Cominco Engineering Services, Ltd.
■ James O’Brien, O’Brien-Kreitzberg
■ JoAnn C. Osmer, Arbella Mutual Insurance Co.
■ Jon V. Palmquist, Allstate Insurance
■ Matthew Parry, Target Consultants
■ John G. Phippen, JGP Quality Services
■ Hans E. Picard, P&A Consultants Corporation
■ Serge Y. Piotte, Groupe Cartier
■ PMI, bureau de Houston
■ PMI, bureau du Manitoba
■ PMI, bureau de Nouvelle-Zélande
■ Charles J. Pospisil, Procon, Inc.
■ Janice Y. Preston, Pacifica Companies
■ Mark T. Price, GE Nuclear Energy

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
173
Annexe B — Evolution du Guide du référentiel des connaissances en gestion de projet du PMI


Annexe B | Annexe C
Christopher Quaife, Symmetric Resources
■ Peter E. Quinn, Canadian Air Force
■ Steven F. Ritter, Mead Corporation
■ William S. Ruggles, Ruggles & Associates
■ Ralph B. Sackman, Levi Strauss & Co.
■ Alice Sapienza, Simmons College
■ Darryl M. Selleck
■ Melvin Silverman, Atrium Associates, Inc.
■ Roy Smith, Decision Planning Corp.
■ Craig T. Stone, Management Counseling Corp.
■ Hiroshi Tanaka, JGC Corporation
■ Robert Templeton, MW Kellogg
■ Dick Thiel, King County (État de Washington) DPW
■ Saul Thomashow, Andersen Consulting
■ J. Tidhar, Oranatech Management Systems, Ltd.
■ Vijay K. Verma, TRIUMF
■ Janet Toepfer, Business Office Systems
■ Alex Walton, Harris Corporation
■ Jack Way, Simetra, Inc.
■ R. Max Wideman, AEW Services
■ Rebecca Winston, EG&G Idaho Inc.
■ Hugh M. Woodward, Proctor & Gamble
■ Robert Youker, Management Planning & Control Systems
■ Shakir H. Zuberi, ICF Kaiser Engineers Hanford
■ Dirk Zwart, Computer Sciences Corp.

Personnel de production
Mention spéciale aux employés suivants de PMI Communications :
■ Jeannette M. Cabanis, rédactrice en chef (Book Division)
■ Misty N. Dillard, assistante administrative
■ Linda V. Gillman, responsable du secrétariat
■ Bobby R. Hensley, coordinateur des publications
■ Jonathan Hicks, administrateur systèmes
■ Sandy Jenkins, rédactrice adjointe
■ Mark S. Parker, coordinateur de production
■ Dewey L. Messer, directeur-rédacteur en chef
■ Danell Moses, coordinateur Promotion et marketing
■ Shirley B. Parker, directeur commercial et du marketing
■ Melissa Pendergast, coordinateur des services de l’information
■ James S. Pennypacker, éditeur/directeur de la rédaction
■ Michelle Triggs, infographiste
■ Lisa Woodring, assistante administrative

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
174 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Annexe C

Collaborateurs et réviseurs
du Guide PMBOK®
Édition 2000

Les personnes ci-dessous ont collaboré de diverses manières aux différentes versions de ce
document. Le Project Management Institute (PMI) les remercie de leur aide et de leur contri-
bution.

C.1 PMI PROJECT MANAGEMENT STANDARDS PROGRAM MEMBER


ADVISORY GROUP
Les personnes suivantes étaient membres du PMI Standards Program Member Advisory Group
pendant l’élaboration de la présente édition du Guide du référentiel des connaissances en ges-
tion de projet (Guide PMBOK®) :
■ George Belev, KAPL, Inc. - A Lockheed Martin Company
■ Cynthia A. Berg, PMP, Medtronic Microelectronics Center
■ Sergio Coronado Arrechedera, MicroStrategy
■ Judith A. Doll, PMP, Monsanto
■ J. Brian Hobbs, PMP, Université du Québec à Montréal
■ David Hotchkiss, PMP, Nexgenix

C.2 ÉQUIPE DE PROJET DE LA MISE À JOUR DU GUIDE PMBOK®


Les personnes suivantes faisaient partie de l’équipe de projet de la présente édition 2000 du
Guide PMBOK®, sous la direction de Cynthia A. Berg, PMP, directeur de projet :
■ Cynthia A. Berg, PMP, Medtronic Microelectronics Center
■ Judith A. Doll, PMP, Monsanto
■ Daniel Dudek, PMP, PlanView, Inc.
■ Quentin Fleming, Primavera Systems, Inc.
■ Earl Glenwright, ASSIST
■ David T. Hulett, Ph.D., International Institute for Learning Inc.
■ Gregory J. Skulmoski, University of Calgary
■ Greg Githens, PMP, Catalyst Management Consulting

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
175
Annexe C — Collaborateurs et réviseurs du Guide PMBOK®, Édition 2000

C.3 COLLABORATEURS
Annexe C

En plus des membres du PMI Standards Program Member Advisory Group et de l’équipe de
projet du Guide PMBOK®, les personnes suivantes ont contribué par des textes originaux ou
des concepts clés à une ou plusieurs sections des chapitres indiqués. De plus, le « Risk Mana-
gement Specific Interest Group » du PMI a dirigé la rédaction du nouveau chapitre 11, « Ges-
tion des risques du projet ».
■ Quentin Fleming (chapitre 4, « Gestion de l’intégration du projet » et chapitre 12, « Gestion
des approvisionnements du projet »)
■ David Shuster (chapitre 8, « Gestion de la qualité du projet »)
■ David Hulett (chapitre 11, « Gestion des risques du projet »)
■ Sam Lane (chapitre 11, « Gestion des risques du projet »)
■ Ed Smith (chapitre 11, « Gestion des risques du projet »)
■ Alfredo del Caño (chapitre 11, « Gestion des risques du projet »)
■ Roger Graves (chapitre 11, « Gestion des risques du projet »)
■ David Hillson (chapitre 11, « Gestion des risques du projet »)
■ Stephen Reed (chapitre 11, « Gestion des risques du projet »)
■ Janice Preston (chapitre 11, « Gestion des risques du projet » - révision)
■ Mike Wakshull (chapitre 11, « Gestion des risques du projet » - révision)
■ Robert Youker (diverses sections dans tout le document)

C.4 RÉVISEURS
En plus des membres du PMI Standards Program Member Advisory Group et de l’équipe de
projet du Guide PMBOK® et des collaborateurs, les personnes suivantes ont adressé des
remarques concernant la version pour commentaire du présent document :
Muhamed Abdomerovic, PMP, D. Eng. Yassir Afaneh
Fabrizio Agnesi, PMP Frank Allen, PMP
Jon D. Allen, PMP MaryGrace Allenchey, PMP
Robert A. Andrejko, PMP Ichizo Aoki
Paul C. Aspinwall Ronald Auffrédou, PMP
Edward Averill, PMP Frederick L. Ayer, PMP
William W. Bahnmaier, PMP A. C. (Fred) Baker, PMP
Carole J. Bass, PMP Berndt Bellman
Sally Bernstein, PMP Nigel Blampied, PE, PMP
John Blatta Patrick Brown, PMP
Chris Cartwright, PMP Bruce C. Chadbourne, PMP
Raymond C. Clark, PE Michael T. Clark, PMP
Elizabeth Clarke David Coates, PMP
Kim Colenso, PMP Edmund H. Conrow, PMP
Kenneth G. Cooper John Cornman, PMP
Richard F. Cowan, PMP Kevin Daly, PMP
Mario Damiani, PMP Thomas Diethelm, PMP
David M. Drevinsky, PMP Frank D. Einhorn, PMP
Edward Fern, PMP Christian Frankenberg, PMP
Scott D. Freauf, PMP Jean-Luc Frere, PMP
Ichiro Fujita, PMP Chikako Futamura, PMP
Serge Garon, PEng, PMP Brian L. Garrison, PMP
Eric Glover Peter Bryan Goldsbury
Michael Goodman, PMP Jean Gouix, PMP
Alexander Grassi Sr., PMP Franz X. Hake

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
176 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Annexe C — Collaborateurs et réviseurs du Guide PMBOK®, Édition 2000

Peter Heffron Chris Herbert, PMP


Dr. David Hillson, PMP, FAPM J. Brian Hobbs, PMP
Marion Diane Holbrook Robin Hornby
Bill Hubbard Charles L. Hunt
Thomas P. Hurley, PMP George Jackelen
Angyan P. Jagathnarayanan Elden F. Jones II, PMP, CMII
Sada Joshi, PMP Ronald L. Kempf, PMP
Subramaniam Kandaswamy, Ph.D., PMP Kurt V. Kloecker
Robert Dohn Kissinger, Ph.D, PMP Blase Kwok, PMP
Jan Kristrom Philip A. Lindeman
Lawrence P. Leach Lyle W. Lockwood, PMP
Gábor Lipi Arif Mahmood, PMP
J. W. Lowthian, PMP Stephen S. Mattingly
James Martin (pour le compte d’INCOSE) Peter McCarthy
Glen Maxfield Krik D. McManus
Rob McCormack, PMP Mary F. Miekoski, PMP
David Michaud Gordon R. Miller, PMP
Oscar A. Mignone Jim Morris, PMP
Roy E. Morgan, PMP William A. Moylan, PMP
Bert Mosterd, PMP Wolfgang Obermeier
John D. Nelson, PMP Masato Ohori, PMP
Cathy Oest, PMP Edward Oliver
Kazuhiko Okubo, PE, PMP Fernando Romero Peñailillo
Jerry Partridge, PMP James M. Phillips, PMP
Francisco Perez-Polo, PMP George Pitagorsky, PMP
Crispin (Kik) Piney, PMP Bradford S. Price, PMP
David L. Prater, PMP Naga Rajan
Samuel L. Raisch, PMP Bill Righter, PMP
G. Ramachandran, PMP Bernice L. Rocque, PMP
William Simon Vaughan Robinson Jon Rude
Wolfgang Theodore Roesch Fabian Sagristani, PMP
Linda Rust, PMP Seymour Samuels
James N. Salapatas, PMP H. Peter Schiller
Bradford N. Scales Maria Scott, PMP
John R. Schuyler, PMP Kazuo Shimizu, PMP
Shoukat Sheikh, MBA, PMP (pour le compte du bureau PMI de Tokyo,
Larry Sieck. Japon)
Melvin Silverman, Ph.D., P.E. Keith Skilling, P.E., PMP
Loren J. Simer Jr. Kenneth F. Smith, PMP
Greg Skulmoski Paul J. Solomon
Barry Smythe, PMP Christopher Wessley Sours, PMP
Joe Soto Sr., PMP Joyce Statz, PMP
Charlene Spoede, PMP Thangavel Subbu
Emmett Stine, PMP Ahmet N. Taspinar, PMP
Jim Szpakowski Alan D. Uren, PMP
John A. Thoren Jr., PMP S. Rao Vallabhaneni
Juan Luis Valero, PMP Ana Isabel Vazquez Urbina
Ricardo Viana Vargas, PMP William W. Wassel, PMP
Stephen E. Wall, PMP Robert Williford, PMP
Tammo T. Wilkens, PE, PMP Jean A. Yager
Rebecca A. Winston

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
177
Annexe C — Collaborateurs et réviseurs du Guide PMBOK®, Édition 2000

Annexe C | Annexe D
C.5 CONTRIBUTIONS AUX DOCUMENTS PRÉCÉDENTS
Certaines portions de l’édition de 1996 et d’autres documents antérieurs sont incluses dans
cette édition. Le PMI souhaite remercier les bénévoles suivants pour leur importante contri-
bution à ce document :
■ John R. Adams
■ William R. Duncan
■ Matthew H. Parry
■ Alan Stretton
■ R. Max Wideman
Le PMI souhaite également remercier les autres bénévoles figurant à l’annexe B pour leur
contribution.

C.6 PERSONNEL DE PRODUCTION


Nous remercions tout particulièrement les employés suivants du PMI :
■ Steven L. Fahrenkrog, directeur de la normalisation
■ Lisa Fisher, assistante de rédaction
■ Lewis M. Gedansky, responsable de la recherche
■ Linda V. Gillman, coordinatrice de la publicité/des autorisations de copyright du Guide
PMBOK®
■ Eva T. Goldman, associée Recherche technique et normalisation
■ Paul Grace, directeur de la certification
■ Sandy Jenkins, directrice-rédactrice en chef
■ Toni D. Knott, éditeur de livres
■ Mark S. Parker, coordinateur de production
■ Dewey L. Messer, directeur de la conception et de la production
■ Linda Cherry, éditeur
■ Michelle Triggs Owen, infographiste
■ Shirley B. Parker, responsable des publications Entreprises/Livres
■ Iesha D. Turner-Brown, administratrice - Normes

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
178 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Annexe D

Notes

CHAPITRE 1. INTRODUCTION
1. The American Heritage Dictionary of the English Language, 3ème édition,
1992, Boston, Massachusetts : Houghton Mifflin Company.
2. Turner, J. Rodney. 1992. The Handbook of Project-Based Management. New
York : McGraw-Hill.

CHAPITRE 2. CONTEXTE DE LA GESTION DE PROJET


1. Morris, Peter W. G. 1988. « Managing Project Interfaces: Key Points for Pro-
ject Success ». Dans Cleland and King, Project Management Handbook, 2ème édi-
tion. Englewood Cliffs, New Jersey : Prentice-Hall.
2. Murphy, Patrice L. 1989. « Pharmaceutical Project Management: Is It Dif-
ferent? », Project Management Journal (septembre).
3. Muench, Dean, et al. 1994. The Sybase Development Framework. Oakland,
Californie : Sybase Inc.
4. Kotter, John P. 1990. A Force for Change: How Leadership Differs from
Management. New York : The Free Press.
5. Pfeffer, Jeffrey. 1992. Managing with Power: Politics and Influence in
Organizations. HBS Press. Cité dans Eccles et al., Beyond the Hype.
6. Eccles, Robert, et al. 1992. Beyond the Hype. Cambridge, Massachusetts :
Harvard University Press.
7. Organisation internationale de normalisation (ISO). 1994. Code de bonne
pratique pour la normalisation. Genève, Suisse : ISO Press.
8. The American Heritage Dictionary of the English Language, 3ème édition.

CHAPITRE 3. PROCESSUS DE LA GESTION DE PROJET


1. The American Heritage Dictionary of the English Language, 3ème édition.

CHAPITRE 4. GESTION DE L’INTÉGRATION DU PROJET


Aucune note pour ce chapitre.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
179
Annexe
Annexe D
D—— Notes
Notes

Annexe D | Annexe E

CHAPITRE 5. GESTION DU CONTENU DU PROJET


1. Turner, J. Rodney. 1992. The Handbook of Project-Based Management.
2. Ïyigün, M. Güven. 1993. « A Decision Support System for R&D Project
Selection and Resource Allocation Under Uncertainty ». Project Management
Journal 3 (décembre).
3. « Scope Definition and Control », Publication 2-6. 1986 (Juillet). Austin,
Texas : Construction Industry Institute, p. 45.

CHAPITRE 6. GESTION DES DÉLAIS DU PROJET


Aucune note pour ce chapitre.

CHAPITRE 7. GESTION DES COÛTS DU PROJET


Aucune note pour ce chapitre.

CHAPITRE 8. GESTION DE LA QUALITÉ DU PROJET


1. Organisation internationale de normalisation (ISO). ISO 8402. 1994. Mana-
gement de la qualité et assurance de la qualité. Genève, Suisse : ISO Press.
2. Idem
3. Idem
4. Idem
5. Idem
6. Idem

CHAPITRE 9. GESTION DES RESSOURCES HUMAINES DU PROJET


Aucune note pour ce chapitre.

CHAPITRE 10. GESTION DES COMMUNICATIONS DU PROJET


Aucune note pour ce chapitre.

CHAPITRE 11. GESTION DES RISQUES DU PROJET


Aucune note pour ce chapitre.

CHAPITRE 12. GESTION DES APPROVISIONNEMENTS DU PROJET


Aucune note pour ce chapitre.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
180 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Annexe E

Extensions des champs


d’application

E.1 NÉCESSITÉ D’EXTENSIONS DES CHAMPS D’APPLICATION


Des extensions des champs d’application sont nécessaires lorsqu’elles représentent des pra-
tiques et connaissances d’usage généralisé pour une catégorie de projets d’un champ d’ap-
plication, mais d’usage encore restreint pour l’ensemble des divers types de projets dans la
plupart des champs d’application. Les extensions des champs d’application reflètent :
■ des aspects uniques ou inhabituels de l’environnement d’un projet, que l’équipe de projet
doit connaître pour pouvoir gérer le projet efficacement ;
■ des pratiques et connaissances courantes qui, lorsqu’elles sont appliquées, améliorent l’ef-
ficacité du projet (par exemple, modèles d’organigramme des tâches).
Les pratiques et connaissances spécifiques au champ d’application peuvent résulter de
nombreux facteurs, telles entre autres les différences de normes dictées par la culture, de ter-
minologie technique, de l’impact de la société ou des cycles de vie des projets. Par exemple :
■ Dans le bâtiment, où presque tout le travail est réalisé sous contrat, il existe des pratiques
et connaissances courantes associées aux approvisionnements qui ne s’appliquent pas à
toutes les catégories de projets.
■ Dans les sciences de la vie, il existe des pratiques et connaissances courantes découlant
de l’environnement réglementaire, qui ne s’appliquent pas à toutes les catégories de pro-
jets.
■ Dans la passation de contrats publics, il existe des pratiques et connaissances courantes
découlant des réglementations en matière de marchés publics qui ne s’appliquent pas à
toutes les catégories de projets.
■ Dans le domaine du conseil, il existe des pratiques et connaissances courantes dues aux
responsabilités du chef de projet au niveau des ventes et du marketing, qui ne s’appli-
quent pas à toutes les catégories de projets.
Les extensions des champs d’application sont :
■ des ajouts aux textes de base des chapitres 1 à 12 et non pas des remplacements ;

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
181
Annexe E — Extensions des champs d’application

■ organisées de la même manière que cet ouvrage, c’est-à-dire qu’elles identifient et décri-
Annexe E

vent les processus de gestion de projet spécifiques au dit champ d’application ;


■ des ajouts spécifiques au texte de base, tels que ;
◆ l’identification de nouveaux processus ou de processus modifiés ;
◆ la subdivision de processus existants ;
◆ la description de diverses séquences ou interactions de processus ;
◆ des éléments plus nombreux ou la modification des définitions des processus cou-
rants ;
◆ la définition de données d’entrée, outils et méthodes et/ou de données de sorties par-
ticuliers aux processus existants.
Les extensions des champs d’application ne sont pas :
■ des documents pratiques de type « mode d’emploi » ou des « lignes directrices en matière
d’application pratique » (de tels documents peuvent être émis comme normes du PMI,
mais ils ne correspondent pas à ce que l’on entend par « extensions ») ;
■ un niveau plus détaillé de ce qui est traité dans cet ouvrage (de tels détails peuvent être
abordés dans des manuels ou guides pouvant être émis comme normes du PMI, mais ils
ne correspondent pas à ce que l’on entend par « extensions »).

E.2 CRITÈRES D’ÉLABORATION DES EXTENSIONS DES CHAMPS


D’APPLICATION
Les extensions doivent être élaborées selon les critères suivants :
■ Il existe un référentiel des connaissances important, à la fois orienté projet et propre (ou
presque) à ce champ d’application.
■ Une unité identifiable du PMI (par exemple, un groupe d’intérêt particulier, une université
ou un bureau du PMI) ou une organisation externe identifiable est prête à, et capable de
mettre en œuvre les ressources nécessaires pour souscrire et apporter son soutien au pro-
gramme de normalisation au cours de l’élaboration et de la mise à jour d’une norme par-
ticulière du PMI. Ou encore, l’extension peut être élaborée par le PMI lui-même.
■ L’extension proposée doit pouvoir être approuvée après la même analyse rigoureuse du
processus de normalisation de gestion de projet du PMI à laquelle sont soumises toutes
les autres normes du PMI.

E.3 PUBLICATION ET FORMAT DES EXTENSIONS DES CHAMPS


D’APPLICATION
Les extensions des champs d’application sont élaborées et/ou publiées par le PMI, ou sont
élaborées et/ou publiées soit par une unité du PMI, soit par une organisation externe avec
l’accord officiel du PMI.
■ Les extensions suivent le style et le contenu de cet ouvrage. Elles utilisent une numéro-
tation de paragraphe et de sous-paragraphe identique à celle de cet ouvrage pour les
informations développées.
■ Les sections et les paragraphes de cet ouvrage qui ne sont pas développés ne sont pas
repris dans les extensions.
■ Les extensions contiennent la justification de leur nécessité et des informations les concer-
nant.
■ Les extensions indiquent les usages pour lesquels elles ne sont pas prévues.

E.4 PROCESSUS D’ÉLABORATION ET DE MISE À JOUR DES


EXTENSIONS DES CHAMPS D’APPLICATION
Lorsqu’elles sont approuvées conformément au processus de normalisation du PMI, les exten-
sions des champs d’application deviennent des normes du PMI. Elles seront donc élaborées
et mises à jour conformément au processus décrit ci-après.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
182 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Annexe E — Extensions des champs d’application

■ Une extension doit être parrainée par le PMI, une unité du PMI officiellement constituée
(par exemple, un groupe d’intérêt particulier, une université ou un bureau) ou par une
autre organisation externe au PMI, mais approuvée par le PMI Standards Program Member
Advisory Group et le directeur de la normalisation du PMI. On donnera la préférence à un
co-parrainage avec le PMI. Toutes les approbations devront prendre la forme d’un accord
officiel écrit entre le PMI et l’entité de parrainage, lequel accord devra inclure, entres
autres, l’accord des deux parties concernant les droits de propriété intellectuelle et les
droits de publication de l’extension.
■ Un projet d’élaboration, de publication et/ou de mise à jour d’une extension doit être
approuvé par le programme de normalisation du PMI. L’autorisation de lancer, élaborer et
mettre à jour une extension doit émaner du PMI ; celle-ci fera l’objet d’un accord entre ou
au sein des organisations. Si aucune autre organisation de parrainage n’est trouvée, le pro-
gramme de normalisation du PMI peut choisir de continuer seul.
■ Le groupe commanditaire notifiera le PMI Standards Program Member Advisory Group et
le directeur de la normalisation du PMI, leur demandera conseil et sollicitera leur appui
tout au long du processus d’élaboration et de mise à jour. Ils s’entendront quant à l’adé-
quation de l’organisation parrainant l’extension proposée et examineront l’extension au
cours de son élaboration, pour détecter tout conflit ou toute similitude avec des projets
semblables qui seraient en cours de réalisation.
■ Le groupe commanditaire préparera une proposition d’élaboration de l’extension. Cette
proposition devra inclure la justification du projet sous forme de grille de processus spé-
cifiques au champ d’application concerné, ainsi que les sections de cet ouvrage qui sont
affectées. Elle devra également contenir l’engagement d’un nombre suffisant de rédacteurs
et réviseurs qualifiés ; l’identification des besoins en financement, y compris les coûts de
reproduction, d’affranchissement, de téléphone, de mise en page, etc. ; l’engagement de
respecter les procédures d’élaboration et de mise à jour des extensions de normes du
PMI ; et un plan et un calendrier d’élaboration et de mise à jour de l’extension.
■ Suite à l’acceptation de la proposition, l’équipe de projet préparera une charte de projet
qui devra être approuvée par le groupe commanditaire et l’équipe du programme de nor-
malisation du PMI. La charte devra indiquer les sources de financement et tout finance-
ment que l’on souhaite obtenir du PMI. Elle devra inclure l’obligation de révisions
périodiques de l’extension avec des rapports à l’équipe du programme de normalisation
du PMI et une « mesure de temporisation » précisant quand et dans quelles conditions l’ex-
tension perdra son statut de norme PMI active.
■ La proposition sera soumise au directeur de la normalisation du PMI conformément au
processus de normalisation du PMI. Le directeur de la normalisation du PMI déterminera
si la proposition est en mesure de produire un document répondant aux exigences impo-
sées aux normes du PMI et si des ressources et un appui adéquats ont été trouvés. Lors de
ce processus de détermination, le directeur de la normalisation du PMI sollicitera l’aide du
PMI Standards Program Member Advisory Group et, s’il y a lieu, d’un groupe de personnes
qualifiées non-impliquées dans l’extension pour la révision et les commentaires.
■ Le directeur de la normalisation du PMI, avec l’appui du PMI Standards Program Member
Advisory Group, effectuera le suivi et apportera son aide à l’élaboration du projet
approuvé.
■ L’organisation commanditaire élaborera l’extension conformément à la charte du projet
approuvée, ce qui inclura également une coordination avec l’équipe de normalisation du
PMI pour ce qui est de l’aide, de la révision et des commentaires.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
183
Annexe E — Extensions des champs d’application

■ Une fois l’extension achevée à la convenance de l’organisation commanditaire, elle


Annexe E | Annexe F

sera soumise au directeur de la normalisation du PMI qui se chargera des processus


d’approbation finale et de publication, conformément au processus de normalisa-
tion du PMI. L’extension finale soumise devra mentionner que l’organisation com-
manditaire s’engage à effectuer la mise à jour de l’extension du PMI et devra
comporter une liste des processus et efforts de mise à jour.
■ Une fois l’extension approuvée comme norme du PMI, l’organisation commandi-
taire mettra en œuvre le processus de mise à jour de l’extension, conformément au
plan approuvé.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
184 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Annexe F

Autres sources
d’informations sur la
gestion de projet

La gestion de projet est un domaine dynamique en pleine expansion ; des livres et articles sur
le sujet sont publiés régulièrement. Les organismes listés ci-dessous offrent un large éventail
de produits et services pouvant être utiles à toutes les personnes intéressées par la gestion de
projet.

F.1 ORGANISMES TECHNIQUES ET PROFESSIONNELS


Cet ouvrage a été élaboré et publié par le Project Management Institute (PMI) dont voici les
coordonnées :

Project Management Institute


Four Campus Boulevard
Newtown Square, PA 19073-3299 États-Unis
Téléphone : +610/356-4600
Fax : +610/356-4647
Courriel : pmihq@pmi.org
Internet : http://www.pmi.org

Le PMI a signé des accords de coopération avec les organismes suivants :


■ Association for the Advancement of Cost Engineering (Association pour l’avancement de
l’ingénierie des coûts) (AACE International)
Téléphone : +304/296-8444 Fax : +304/291-5728
■ Asociacion Espanola de Ingenieria de Proyectos (Association espagnole de gestion de
projet) (AEIPRO)
Téléphone : +3476-976-761-910 Fax: +349-1447-3187
■ Australian Institute of Project Management (Institut australien de gestion de projet) (AIPM)
Téléphone : +61-2-9960-0058 Fax: +61-2-9960-0052
■ Construction & Economy Research Institute of Korea (Institut coréen de construction et
recherche économique) (CERIK)
Téléphone : +822-3441-0801 Fax: +822-544-6234
■ Defense Systems Management College Alumni Association (Association des anciens élèves
du Defense Systems Management College) (DSMCAA)
Téléphone : +703/960-6802 Fax: +703/960-6807
■ Engineering Advancement Association of Japan (Association japonaise d’avancement de
l’ingénierie) (ENAA)
Téléphone : +81-3-3502-4441 Fax: +81-3-3502-5500

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
185
Annexe F — Autres sources d’informations sur la gestion de projet

■ Institute of Project Management (Institut de gestion de projet) (IPM-Irlande)


Annexe F

Téléphone : +353-1-661-4677 Fax: +353-1-661-3588


■ International Project Management Association (Association internationale de gestion de
projet) (IPMA)
Téléphone : +44-1594-531-007 Fax: +44-1594-531-008
■ Korean Institute of Project Management & Technology (Institut coréen de gestion de projet
et de technologie) (PROMAT)
Téléphone : +822-522-0360 Fax: +822-523-1680
■ National Contract Management Association (Association nationale de gestion de contrats)
(NCMA)
Téléphone : 703/448-9231 Fax: +703/448-0939
■ The NORDNET National Associations (Les associations nationales NORDNET)
(Danemark, Finlande, Islande, Norvège et Suède)
Fax: +468-719-9316
■ Project Management Associates (Associés de la gestion de projet) (PMA-Inde)
Téléphone : +91-11-852-6673 Fax: +91-11-646-4481
■ Project Management Institute South Africa (Institut de gestion de projet d’Afrique du Sud)
Téléphone : +2711-706-6813
■ Projekt Management Austria (Gestion de projet – Autriche)
Téléphone : +43-1-1313-52-215 Fax: +43-1-319-78-55
■ Russian Project Management Association (Association russe de gestion de projet)
(SOVNET)
Téléphone : +7-095-133-26-11 Fax: +7-095-133-24-41
■ Ukrainian Project Management Association (Association ukrainienne de gestion de projet)
Téléphone : +38-044-272-9400 o +38-044-245-4857
■ Project Management Association of Slovakia (Association de gestion de projet de Slova-
quie) (SPPR)
Téléphone : +421-805-599-1806 Fax: +421-805-599-1-818
■ Slovenian Project Management Association (Association slovène de gestion de projet)
(ZPM)
Téléphone : +386-6117-667-134 Fax: +386-61217-431
De plus, il existe de nombreuses autres organisations dans les domaines connexes qui
peuvent être à même de fournir des informations supplémentaires sur la gestion de projet. Par
exemple :
■ Academy of Management (Académie de gestion)
■ American Management Association International (Association américaine internationale de
gestion)
■ American Society for Quality Control (Association américaine pour le contrôle de la qua-
lité)
■ Construction Industry Institute (Institut de l’industrie du bâtiment)
■ Construction Management Association of America (Association américaine de gestion dans
le bâtiment) (CMAA)
■ Institute of Electrical and Electronics Engineers (Institut des ingénieurs en électricité et
électronique) (IEEE)
■ Institute of Industrial Engineers (Institut des ingénieurs en génie industriel) (IIE)
■ International Council on Systems Engineering (Conseil international en ingénierie sys-
tèmes) (INCOSE)
■ National Association for Purchasing Management (Association nationale de gestion des
achats)
■ National Contract Management Association (Association nationale de gestion de contrats)
■ Society for Human Resource Management (Association de gestion des ressources
humaines)

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
186 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Annexe F — Autres sources d’informations sur la gestion de projet

■ American Society of Civil Engineers (Association américaine des ingénieurs en génie civil)
Les coordonnées des organisations ci-dessus et d’autres organisations professionnelles et
techniques du monde entier peuvent généralement être obtenues sur Internet.

F.2 MAISONS D’ÉDITION


Le PMI est le plus gros éditeur d’ouvrages sur la gestion de projet. De nombreuses maisons
d’édition publient des ouvrages sur la gestion de projet et les domaines connexes. Celles qui
publient de tels ouvrages de façon régulière sont :
■ Addison-Wesley
■ AMACOM
■ Gower Press
■ John Wiley & Sons
■ Marcel Dekker
■ McGraw-Hill
■ Prentice-Hall
■ Probus
■ Van Nostrand Reinhold
La plupart des livres sur la gestion de projet édités par ces maisons d’édition sont dispo-
nibles auprès du PMI. Nombre de ces livres disponibles auprès des sources ci-dessus incluent
une bibliographie ou une liste exhaustive d’ouvrages à consulter.

F.3 FOURNISSEURS DE PRODUITS ET PRESTATAIRES DE SERVICES


Les sociétés qui proposent des logiciels, des formations, du conseil et d’autres produits et ser-
vices aux professionnels de la gestion de projet offrent souvent des monographies ou des
tirages à part.
Le programme PMI Registered Education Provider (R.E.P.) Program encourage le déve-
loppement professionnel permanent des membres du PMI, des professionnels de la gestion
de projet (les diplômés PMP) et d’autres acteurs de la gestion de projet, en mettant en rapport
les acteurs et les coordinateurs de formation avec des prestataires de services de formation et
des fournisseurs de produits qualifiés. Une liste des prestataires de services de formation
agréés (les R.E.P.) et des services correspondants peut être obtenue sur le site
http://www.pmi.org/education/rep.

F.4 ORGANISMES D’ENSEIGNEMENT


De nombreuses universités et écoles d’enseignement supérieur offrent des programmes de
formation continue en gestion de projet et autres disciplines connexes. Nombre de ces orga-
nismes proposent également des programmes permettant d’obtenir un diplôme de niveau uni-
versitaire.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
187
Annexe G

Résumé des disciplines de la


gestion de projet

GESTION DE L’INTÉGRATION DU PROJET


Sous-ensemble de la gestion de projet englobant les processus nécessaires à la coordination
adéquate des divers éléments du projet, elle comporte :
■ l’élaboration du plan de projet : intégrer et coordonner tous les plans de projet et en tirer
un document logique et cohérent ;
■ la mise en œuvre du plan de projet : concrétiser le plan de projet en accomplissant les
activités le composant ;
■ le contrôle intégré des changements : coordonner les modifications sur l’ensemble du
projet.

GESTION DU CONTENU DU PROJET


Sous-ensemble de la gestion de projet englobant les processus nécessaires pour s’assurer que
toutes les activités nécessaires au succès du projet, et seulement celles-ci, sont incluses dans
le projet, elle comporte :
■ le démarrage : adopter officiellement le projet ou la phase ;
■ la planification du contenu : élaborer par écrit un cahier des charges qui servira de réfé-
rence aux décisions ultérieures ;
■ la définition du contenu : décomposer les principaux produits livrables du projet en élé-
ments plus petits et plus faciles à gérer ;
■ la vérification du contenu : officialiser l’acceptation du contenu du projet ;
■ le contrôle des changements du contenu : contrôler les modifications apportées au
contenu du projet.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
189
Annexe G — Résumé des domaines de compétence de la gestion de projet

Annexe G
GESTION DES DÉLAIS DU PROJET
Sous-ensemble de la gestion de projet englobant les processus nécessaires pour assurer l’achè-
vement du projet en temps voulu, elle comporte :
■ l’identification des activités : identifier les activités spécifiques à accomplir pour la pro-
duction des divers produits livrables du projet ;
■ le jalonnement des activités : identifier et documenter les liaisons logiques entre les acti-
vités ;
■ l’estimation de la durée des activités : estimer le nombre d’unités de temps ouvré néces-
saires à l’exécution de chacune des activités ;
■ l’élaboration du planning : analyser la séquence, la durée et les besoins en ressources des
activités afin d’élaborer le planning du projet ;
■ le contrôle du planning : contrôler les modifications apportées au planning du projet.

GESTION DES COÛTS DU PROJET


Sous-ensemble de la gestion de projet recouvrant les processus nécessaires à l’exécution du
projet dans les limites budgétaires approuvées, elle comporte :
■ la planification des ressources : déterminer la nature (personnes, équipement, matériel) et
la quantité des ressources à utiliser pour l’achèvement des activités du projet ;
■ l’estimation des coûts : établir une approximation (estimation) du coût des ressources
nécessaires à l’achèvement des activités du projet ;
■ la budgétisation : attribuer à chaque activité sa quote-part dans l’estimation du coût total ;
■ le contrôle des coûts : contrôler les modifications apportées au budget du projet.

GESTION DE LA QUALITÉ DU PROJET


Sous-ensemble de la gestion de projet recouvrant les processus nécessaires pour s’assurer que
le projet répondra aux besoins pour lesquels il a été mis en œuvre, elle comporte :
■ la planification de la qualité : identifier les normes de qualité applicables au projet et déter-
miner les modalités de leur respect ;
■ l’assurance de la qualité : évaluer systématiquement les performances de l’ensemble du
projet afin de vérifier la conformité du projet aux normes de qualité applicables ;
■ le contrôle de la qualité : effectuer le suivi des résultats spécifiques du projet afin de déter-
miner s’ils sont conformes aux normes de qualité applicables, et identifier comment éli-
miner les causes de performances insuffisantes.

GESTION DES RESSOURCES HUMAINES DU PROJET


Sous-ensemble de la gestion de projet recouvrant les processus nécessaires à la meilleure uti-
lisation possible des effectifs impliqués dans le projet, elle comporte :
■ la planification de l’organisation : identifier, documenter et attribuer les rôles, les respon-
sabilités et les relations hiérarchiques des intervenants du projet ;
■ l’obtention des ressources humaines : faire en sorte que les ressources nécessaires soient
affectées au projet et y travaillent ;
■ le développement de l’équipe : développer les compétences individuelles et de groupe
afin d’améliorer les performances du projet.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
190 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Annexe G — Résumé des domaines de compétence de la gestion de projet

GESTION DES COMMUNICATIONS DU PROJET


Sous-ensemble de la gestion de projet recouvrant les processus nécessaires à la rédaction, la
collecte, la diffusion, l’archivage et, par la suite, au traitement final des informations concer-
nant le projet, de façon adéquate et en temps voulu, elle comporte :
■ la planification des communications : déterminer les besoins des acteurs en matière d’in-
formations et de communications (qui a besoin de quelles informations, quand et sous
quelle forme) ;
■ la diffusion de l’information : s’assurer que les informations nécessaires sont mises, en
temps voulu, à la disposition des acteurs du projet ;
■ les rapports d’avancement : rassembler et diffuser les informations concernant les perfor-
mances ; ceci comprend les rapports sur l’état, la mesure des progrès et les prévisions ;
■ la clôture administrative : générer, rassembler et diffuser les informations permettant d’of-
ficialiser l’achèvement du projet ou d’une de ses phases.

GESTION DES RISQUES DU PROJET


La gestion des risques est le processus systématique d’identification, d’analyse et de déve-
loppement de stratégies de réponse pour le projet. Elle implique qu’on maximise la proba-
bilité et les conséquences des événements favorables aux objectifs du projet et qu’on minimise
la probabilité et les conséquences des événements défavorables à ceux-ci. Elle comporte :
■ la planification de la gestion des risques : décider de l’approche à suivre et de la planifi-
cation des activités de projet concernant la gestion des risques ;
■ l’identification des risques : déterminer les risques susceptibles d’avoir des répercussions
sur le projet et en établir les caractéristiques ;
■ l’analyse qualitative des risques : analyser qualitativement les risques et les circonstances
afin de classer leurs effets sur les objectifs du projet par ordre de priorité ;
■ l’analyse quantitative des risques : mesurer la probabilité et les conséquences des risques
et évaluer leurs implications pour les objectifs du projet ;
■ la planification des stratégies de réponse : établir des procédures et des méthodes per-
mettant d’augmenter les opportunités et de réduire les menaces pour les objectifs du
projet ;
■ le suivi et le contrôle des risques : surveiller les risques résiduels, identifier les nouveaux
risques, mettre en œuvre les plans d’atténuation des risques et évaluer l’efficacité de ces
derniers pendant le cycle de vie du projet.

GESTION DES APPROVISIONNEMENTS DU PROJET


Sous-ensemble de la gestion de projet recouvrant les processus nécessaires à l’obtention, en
dehors de l’entreprise réalisatrice, des produits et des services qui permettront de réaliser le
contenu du projet, elle comporte :
■ la planification des approvisionnements : déterminer la nature et le moment des acquisi-
tions ;
■ la planification des appels d’offres : documenter les spécifications du produit et identifier
des sources potentielles ;
■ les appels d’offres : obtenir devis, soumissions, offres ou propositions, selon le cas ;
■ la sélection des fournisseurs : choisir parmi les fournisseurs potentiels ;
■ l’administration des contrats : gérer les relations avec le fournisseur ;
■ la clôture du contrat : régler le contrat, et toutes les questions en suspens.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
191
SECTION IV

GLOSSAIRE ET INDEX

Glossaire

Index
GLOSSAIRE

1. INCLUSIONS ET EXCLUSIONS
Ce glossaire comprend des termes qui :
■ s’appliquent presque exclusivement à la gestion de projet (par exemple, cahier des
charges, lot de travaux, organigramme des tâches (OT), méthode du chemin critique) ;
■ ne s’appliquent pas exclusivement à la gestion de projet, mais qui ont une signification dif-
férente ou plus restreinte en gestion de projet, comparativement à l’usage courant (par
exemple, date de début au plus tôt, activité, tâche).

Il ne contient pas, en général :


■ de termes propres à un domaine d’application donné ;
■ de termes dont l’utilisation dans la gestion de projet ne diffère pas essentiellement de
l’usage courant (par exemple, calendrier),
■ de termes composés dont la signification correspond clairement à celle de chaque com-
posant ;
■ de variantes, lorsque la signification d’un terme dérivé peut être déduite de celle du terme
de référence (par exemple, « rapport des écarts majeurs » est défini alors que « rapporter
les écarts majeurs » ne l’est pas).

Il en résulte que ce glossaire présente :


■ surtout des termes relatifs à la gestion du contenu et des délais du projet, et à la gestion
des risques du projet, car de nombreux termes utilisés dans ces disciplines s’appliquent
presque exclusivement à la gestion de projet ;
■ de nombreux termes relatifs à la gestion de la qualité du projet, puisqu’ils y sont employés
avec un sens plus restreint que dans l’usage courant ;
■ relativement peu de termes concernant la gestion des ressources humaines et des com-
munications du projet, puisque la plupart des termes employés dans ces disciplines ne dif-
fèrent sensiblement pas de l’usage courant ;
■ relativement peu de termes concernant la gestion des coûts du projet et des approvision-
nements du projet, puisque de nombreux termes utilisés dans ces disciplines ont un sens
restreint et particulier aux différents champs d’application.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
195
Glossaire

Abbreviations courantes | Activité


2. ABRÉVIATIONS COURANTES
AC Actual Cost Coût réel (CR)
ACWP Actual Cost of Work Performed Coût réel du travail réalisé (CRTR)
AD Activity Description Description de l’activité
ADM Arrow Diagramming Method Méthode du diagramme fléché
AF Actual Finish Date Date de fin réelle
AOA Activity-on-Arrow Activités sur flèches
AON Activity-on-Node Activités sur nœuds
AS Actual start date Date de début réelle
BAC Budget at Completion Budget à l’achèvement
BCWP Budgeted Cost of Work Performed Coût budgété du travail réalisé (CBTR)
BCWS Budgeted Cost of Work Scheduled Coût budgété du travail prévu (CBTP)
CAP Control Account Plan Plan des comptes de contrôle
CCB Change Control Board Comité de contrôle des changements
CPFF Cost-Plus-Fixed-Fee Contrat à rétribution fixe
CPIF Cost-Plus-Incentive-Fee Contrat en dépenses contrôlées avec
intéressement
CPI Cost Performance Index Indice de performance des coûts (IPC)
CPM Critical Path Method Méthode du chemin critique
CV Cost Variance Écart de coûts (EC)
DD Data Date Date de mise à jour
DU Duration Durée
EAC Estimate At Completion Prévision à l’achèvement
EF Early Finish Date Date de fin au plus tôt
ES Early Start Date Date de début au plus tôt
ETC Estimate (or Estimated) to Coût estimé pour achèvement
Complete (or Completion)
EV Earned value Valeur acquise (VA)
EVM Earned Value Management Gestion de la valeur acquise (GVA)
FF Free Float or Finish-to-Finish Marge libre ou Liaison Fin-Fin
FFP Firm Fixed Price Contrat à prix forfaitaire
FPIF Fixed Price Incentive Fee Contrat à prix forfaitaire avec
intéressement
FS Finish-To-Start Liaison Fin-Début (FD)
GERT Graphical Evaluation and Review Technique d’évaluation et de suivi
Technique graphique
IFB Invitation For Bid Appel à candidatures
LF Late Finish Date Date de fin au plus tard
LOE Level Of Effort Niveau de charge
LS Late Start Date Date de début au plus tard
MPM Modern Project Management Gestion de projet moderne
OBS Organization(al) Breakdown Organigramme fonctionnel
Structure
PC Percent Complete Pourcentage d’avancement (physique)
PDM Precedence Diagramming Méthode des antécédents
Method
PERT Program Evaluation and Review Technique d’évaluation et de suivi des
Technique programmes
PF Planned Finish Date Date de fin prévue
PM (1) Project Management Gestion de projet
(2) Project Manager Chef de projet

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
196 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Glossaire

PMBOK® Project Management Body of Référentiel des connaissances en gestion


Knowledge de projet
®
PMP Project Management Professional Professionnel en gestion de projet
PS Planned Start Date Date de début planifiée
PV Planned Value Valeur prévue
QA Quality Assurance Assurance de la qualité (AQ)
QC Quality Control Contrôle de la qualité (CQ)
RAM Responsibility Assignment Matrix Matrice d’allocation des
responsabilités
RDU Remaining Duration Durée restante
RFP Request For Proposal Appel d’offres
RFQ Request For Quotation Demande de devis
SF (1) Scheduled Finish Date Date de fin planifiée
(2) Start-To-Finish Lien Début-Fin
SOW Statement Of Work Cahier des charges (détaillé)
SPI Schedule Performance Index Indice de performance des délais
SS Scheduled Start Date Date de début prévue
SV Schedule Variance Écart de prévisions (EP)
TC Target Completion Date Date cible de fin de projet
TF (1)Total Float Marge totale
(2) Target Finish Date Date de fin cible
TS Target Start Date Date de début cible
TQM Total Quality Management Gestion intégrale de la qualité
VE Value Engineering Ingénierie de la valeur
WBS Work Breakdown Structure Organigramme des tâches (OT)

3. DÉFINITIONS
Un assez grand nombre de mots, définis ci-dessous ont, dans les dictionnaires une définition
plus large et quelquefois différente.
Les conventions suivantes sont utilisées :
■ lorsqu’un terme utilisé dans une définition est également défini dans le glossaire, il est
en italique ;
■ lorsqu’un synonyme est indiqué, aucune définition n’est donnée et le lecteur est renvoyé
au terme de préférence (voir terme préféré) ;
■ les termes connexes, mais non synonymes, sont rappelés en fin de définition (voir aussi
terme connexe).

Acceptation des risques / Risk Acceptance. L’utilisation de cette technique du processus


de planification des stratégies de réponse indique que l’équipe de projet a décidé de ne pas
modifier le plan de projet pour pallier à un risque, ou n’est pas en mesure de déterminer une
autre stratégie de réponse adéquate.
Acteur / Stakeholder. Personnes ou organisations activement impliquées dans le projet, ou
dont les intérêts peuvent être affectés positivement ou négativement en raison de l’exécu-
tion ou de l’achèvement du projet. Les acteurs peuvent également influencer le projet et ses
résultats.
Action corrective / Corrective Action. Modification apportée pour aligner les performances
futures du projet sur le plan du projet.
Activité / Activity. Élément de travail réalisé dans le cadre d’un projet. Habituellement, une
durée prévue, un coût prévu et des besoins prévus en ressources sont définis pour chaque
activité. Les activités peuvent être décomposées en tâches.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
197
Glossaire

Activité critique / Critical Activity. Activité située sur le chemin critique. Généralement
| Chevauchement

déterminée par la méthode du chemin critique. Bien que certaines activités puissent être
« critiques », au sens littéral du terme, sans être sur le chemin critique, ce sens est rarement
utilisé dans le contexte d’un projet.
Activité fictive / Dummy Activity. Activité de durée nulle utilisée pour figurer un lien logique
dans la méthode du diagramme fléché. L’activité fictive est utilisée lorsqu’un lien logique ne
peut pas être complètement ou correctement représenté par une flèche d’activité normale.
Les activités fictives sont représentées graphiquement par des flèches tracées en pointillés.
Activité critique

Activité sous-critique / Near-Critical Activity. Activité dont la marge totale est de faible
valeur.
Activités sur flèches / Activity-on-Arrow. Voir Méthode du diagramme fléché.
Activités sur nœuds /Activity-on-Node. Voir Méthode des antécédents.
Analyse de la valeur acquise / Earned Value Analysis. Voir la première définition dans
Valeur acquise.
Analyse de réseau / Network Analysis. Processus d’identification des dates de début et
de fin au plus tôt et au plus tard pour les parties inachevées des activités d’un projet. Voir
aussi Méthode du chemin critique, Technique d’évaluation et de suivi des projets (PERT),
Technique d’évaluation et de suivi graphique (GERT).
Analyse des hypothèses / Assumptions Analysis. Technique qui explore l’exactitude des
hypothèses et détermine les facteurs de risque pour le projet dus à l’inexactitude, à l’in-
cohérence ou au caractère incomplet des hypothèses.
Analyse du planning / Schedule Analysis. Voir Analyse de réseau.
Analyse mathématique / Mathematical Analysis. Voir Analyse de réseau.
Analyse par arbre de décision / Decision-Tree Analysis. Diagramme décrivant une déci-
sion à l’étude et les conséquences de l’une ou de l’autre des possibilités. Il prend en
compte les probabilités ou les risques, ainsi que le coût ou les avantages de chaque
chemin logique d’événements et de décisions futures.
Analyse qualitative des risques / Qualitative Risk Analysis. Analyse qualitative des
risques et des conditions permettant d’établir la priorité de leurs effets sur les objectifs du
projet. Elle comprend l’évaluation de la probabilité et de l’impact des risques du projet et
l’utilisation de méthodes telles que la matrice des probabilités et des impacts pour classer
les risques par catégorie (risque élevé, moyen ou faible). Ce classement est ensuite utilisé
dans le cadre de la planification des stratégies de réponse par ordre de priorité.
Analyse quantitative des risques / Quantitative Risk Analysis. Mesure quantitative de la
probabilité et des conséquences des risques et évaluation de leur incidence sur les objec-
tifs du projet. Les risques sont caractérisés par la distribution de probabilités et les consé-
quences possibles. Ce processus utilise des techniques quantitatives telles que les
simulations et l’analyse par arbre de décision.
Antécédent / Predecessor Activity. (1) Dans la méthode du diagramme fléché, activité d’en-
trée d’un nœud. (2) Dans la méthode des antécédents, activité de départ de la relation.
Appel à candidatures / Invitation for Bid (IFB). Généralement, ce terme équivaut au terme
appel d’offres. Cependant, dans certains domaines d’application, il peut avoir une significa-
tion plus restreinte ou plus spécifique.
Appel d’offres / Request for Proposal (RFP). Type de document utilisé pour solliciter des
offres de la part de fournisseurs potentiels de produits ou de services. Dans certains
domaines d’application, il peut avoir une signification plus restreinte ou spécifique.
Appel d’offres / Solicitation. Obtention de devis, soumissions, offres ou propositions, selon
le cas.
Assurance de la qualité / Quality Assurance (QA). (1) Processus d’évaluation systématique
des performances d’un projet, afin de s’assurer que le projet sera conforme aux normes de
qualité appropriés (2) Service responsable de l’assurance de la qualité.
Avance / Lead. Modification d’un lien logique permettant d’accélérer la tâche successeur. Par
exemple, dans une liaison Fin-Début avec une avance de 10 jours, le successeur peut
débuter au plus tôt 10 jours avant l’achèvement de l’antécédent. Voir aussi Retard.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
198 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Glossaire

Base de données de risques / Risk Database. Référentiel permettant de recueillir, mettre


à jour et analyser les données obtenues et utilisées dans le cadre du processus de gestion
des risques. Les programmes de « leçons retenues » utilisent une base de données de
risques. Celle-ci est produite par le processus de suivi et contrôle des risques.
Boucle / Loop. Chemin de réseau passant deux fois par le même nœud. Les boucles ne peu-
vent pas être analysées par les méthodes classiques d’analyse de réseau, telles que la
méthode du chemin critique, et la technique d’évaluation et de suivi des projets (PERT). Les
boucles sont permises dans la technique d’évaluation et de suivi graphique (GERT).
Budget à l’achèvement / Budget at Completion (BAC). Coût total budgété pour la réali-
sation d’un projet.
Budgétisation / Cost Budgeting. Répartition des coûts globaux estimés au niveau de
chaque activité.
Cadre hiérarchique / Line Manager. (1) Responsable de tout groupe fabriquant un produit
ou rendant un service. (2) Responsable fonctionnel.
Cahier des charges / Scope Statement. Le cahier des charges forme la base servant à
prendre les décisions futures dans un projet et à confirmer ou élaborer une interprétation
commune du contenu du projet entre les acteurs. Au fur et à mesure de l’avancement du
projet, il peut s’avérer nécessaire de revoir ou de peaufiner le cahier des charges, afin de
refléter les changements du contenu du projet approuvés.
Calcul à rebours / Backward Pass. Calcul des dates de fin et de début au plus tard de
toutes les activités inachevées d’un réseau. Ces dates sont calculées à l’aide de la logique
du réseau, en partant de la date de fin du projet. Cette date de fin peut avoir été calculée
au moyen d’un calcul au plus tôt ou avoir été imposée par le client ou le commanditaire.
Voir aussi Analyse de réseau.
Calcul au plus tôt / Forward Pass. Calcul des dates de début et de fin au plus tôt des par-
ties inachevées de toutes les activités d’un réseau. Voir aussi Analyse de réseau et Calcul
à rebours.
Catégorie de risques / Risk Category. Source de risques potentiels émanant de causes
techniques, de la gestion du projet, du mode d’organisation, ou de sources externes.
Changement du contenu / Scope Change. Modification du contenu du projet. Un change-
ment du contenu entraîne presque toujours un réajustement du coût ou du planning.
Champ d’application / Application Area. Catégorie de projets partageant des points com-
muns qui n’existent pas dans tous les projets. Les domaines d’application sont générale-
ment définis soit en termes de produits de projet (par exemple, des technologies ou des
secteurs industriels similaires), soit en fonction du type de client (par exemple, interne ou
externe, public ou privé). Les champs d’application se chevauchent souvent.
Charge / Effort. Nombre d’unités de travail nécessaires à l’achèvement d’une activité ou d’un
autre élément du projet. Généralement exprimée en capacités horaire, journalière ou heb-
domadaire par employé. À ne pas confondre avec durée.
Charte / Charter. Voir Charte du projet.
Charte du projet / Project Charter. Document émis par la direction d’une entreprise, et qui
autorise officiellement l’existence d’un projet. Il donne également au chef de projet les pou-
voirs nécessaires pour affecter des ressources de l’entreprise aux activités du projet.
Chef de projet / Project Manager (PM). Responsable de la gestion d’un projet.
Chemin / Path. Ensemble d’activités reliées séquentiellement dans un diagramme réseau du
projet.
Chemin critique / Critical Path. Série d’activités qui détermine la durée d’un projet. Dans un
modèle déterministe, le chemin critique est habituellement défini comme l’ensemble des
activités dont la marge est inférieure ou égale à une valeur donnée souvent nulle. Il s’agit
du chemin le plus long du projet. Voir Méthode du chemin critique.
Chemin du réseau / Network Path. Tout ensemble continu d’activités reliées entre elles dans
un diagramme réseau du projet.
Chevauchement / Overlap. Voir Avance.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
199
Glossaire

Choix des fournisseurs / Source Selection. Sélection parmi les fournisseurs potentiels.
Choix des fournisseurs | Coût budgété du travail prévu (CBTP)

Classe / Grade. Catégorie ou rang utilisé pour distinguer des entités ayant le même usage
fonctionnel (par exemple, « marteau »), mais soumises à des exigences de qualité diffé-
rentes (par exemple, on peut différencier différents marteaux par leur solidité).
Clôture administrative / Administrative Closure. Génération, collecte et diffusion des infor-
mations officialisant l’achèvement d’une phase ou d’un projet.
Clôture du contrat / Contract Close-out. Achèvement et règlement d’un contrat, résolution
de toutes les questions en suspens comprise.
Comité de contrôle des changements / Change Control Board (CCB). Groupe formelle-
ment constitué d’acteurs du projet, responsable de l’approbation ou du refus des modifi-
cations des références du projet.
Compactage / Crashing. Action entreprise pour diminuer la durée totale d’un projet après
analyse d’un certain nombre de possibilités pour déterminer comment obtenir une réduc-
tion de durée maximum à un coût minimum.
Composant / Component. Une partie constituante, un élément.
Compression de durée / Duration Compression. Réduction de la durée du planning d’un
projet, sans réduction de son contenu. Cela n’est pas toujours possible et implique sou-
vent une augmentation des coûts du projet.
Construction en régime accéléré / Fast Tracking. Réduction de la durée d’un projet par
chevauchement d’activités normalement effectuées en séquence, telles que la conception
et la construction. Quelquefois confondue avec ingénierie simultanée.
Contenu / Scope. Ensemble des produits et services devant résulter d’un projet. Voir aussi
Contenu du projet et Contenu du produit.
Contenu du produit / Product Scope. Caractéristiques et fonctions d’un produit ou d’un
service.
Contenu du projet / Project Scope. Ensemble des travaux devant être réalisés afin de livrer
un produit répondant aux caractéristiques et aux fonctions définies.
Contingences / Contingencies. Voir Réserve et Développement de plans alternatifs.
Contrainte / Constraint. Restriction applicable qui aura un impact sur les performances du
projet. Tout facteur ayant un impact sur la date à laquelle une activité peut être réalisée.
Contrat / Contract. Engagement mutuel qui oblige un vendeur à fournir un produit défini, et
un acheteur à en payer le prix. On rencontre généralement trois grandes catégories de
contrats :
■ Les contrats à prix forfaitaire ou contrats à forfait : cette catégorie de contrat stipule un
prix total fixe pour un produit bien défini. Dans la mesure où le produit n’est pas bien
défini, l’acheteur comme le vendeur prennent un risque ; l’acheteur peut ne pas rece-
voir le produit souhaité ou le vendeur peut encourir des coûts supplémentaires pour le
livrer. Les contrats à prix forfaitaire peuvent également comprendre des clauses d’in-
téressement pour inciter la partie concernée à atteindre ou à dépasser certains objec-
tifs choisis, tels que les dates cibles.
■ Les contrats à coûts remboursables : cette catégorie de contrat prévoit le paiement
(remboursement) au vendeur des coûts réels encourus, habituellement majorés d’une
commission représentant le bénéfice du vendeur. Ces coûts sont généralement classés
en coûts directs ou coûts indirects. Les coûts directs sont ceux occasionnés exclusi-
vement par le projet (par exemple, le salaire du personnel affecté à plein temps au
projet). Les coûts indirects, également appelés frais généraux, sont ceux affectés au
projet par l’entreprise réalisatrice au titre de coûts de gestion (par exemple, le salaire des
dirigeants de la société). Les coûts indirects sont habituellement calculés à partir d’un
pourcentage des coûts directs. Les contrats à coûts remboursables comprennent sou-
vent des clauses d’intéressement pour inciter la partie concernée à atteindre ou à
dépasser certains objectifs choisis, tels que les délais ou le coût total.
■ Les contrats pièces et main-d’œuvre : il s’agit d’un type de contrat hybride mêlant cer-
tains aspects des contrats à prix forfaitaire et des contrats à coûts remboursables. Ces
contrats s’apparentent aux contrats à coûts remboursables en ce qu’ils ne sont pas pla-

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
200 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Glossaire

fonnés, la valeur totale de l’accord n’étant pas précisée au moment de l’attribution. La


valeur d’un contrat pièces et main-d’œuvre peut augmenter comme s’il s’agissait d’un
contrat à coûts remboursables. Inversement, les contrats pièces et main d’œuvre s’ap-
parentent aussi aux contrats à prix unitaire quand, par exemple, les taux unitaires sont
fixés à l’avance par l’acheteur et le vendeur, ou lorsque les deux parties s’entendent sur
les tarifs payés à la catégorie « ingénieurs confirmés ».
Contrat à prix fixe / Fixed Price Contract. Voir Contrat à prix forfaitaire.
Contrat à prix forfaitaire / Firm Fixed Price Contract. Type de contrat où l’acheteur paye
au vendeur un montant déterminé (fixé par le contrat) quelles que soient les dépenses du
vendeur.
Contrat à prix forfaitaire avec intéressement / Fixed Price Incentive Fee Contract
(FPIF). Type de contrat par lequel l’acheteur paie au vendeur un montant déterminé (fixé
par le contrat) et le vendeur peut obtenir un gain supplémentaire s’il atteint des critères de
performance définis à l’avance.
Contrat à rétribution fixe / Cost Plus Fixed Fee Contract (CPFF). Type de contrat par
lequel l’acheteur rembourse au vendeur les coûts réels autorisés (tels que définis aux
termes du contrat) plus un bénéfice fixé à l’avance (honoraires).
Contrat en dépenses contrôlées avec intéressement / Cost Plus Incentive Fee
Contract (CPIF). Type de contrat par lequel l’acheteur rembourse au vendeur les coûts réels
autorisés (tels que définis aux termes du contrat) et lui paye un bénéfice s’il atteint certains
critères, indexé sur la réalisation d’objectifs de performance déterminés à l’avance.
Contrôle / Control. Processus consistant à comparer des résultats réels à ceux prévus, à
analyser les écarts, à évaluer plusieurs possibilités et à adopter des actions correctives
appropriées, si nécessaire.
Contrôle de la qualité / Quality Control (QC). (1) Processus de suivi de certains résultats
d’un projet afin de déterminer s’ils sont conformes aux normes de qualités applicables et
d’identifier des moyens nécessaires à l’élimination des causes de performances non satis-
faisantes. (2) Service responsable du contrôle de la qualité.
Contrôle des changements du contenu / Scope Change Control. Contrôle des modifi-
cations apportées au contenu du projet.
Contrôle des coûts / Cost Control. Contrôle des modifications apportées au budget d’un
projet.
Contrôle des stratégies de réponse / Risk Response Control. Suivi de la mise en place
et de l’efficacité des stratégies de réponse au cours du projet.
Contrôle du planning / Schedule Control. Contrôle des modifications apportées au plan-
ning du projet.
Contrôle intégré des changements / Integrated Change Control. Coordination des modi-
fications de l’ensemble du projet.
Convergence des chemins / Path Convergence. Dans un planning, nœud où plusieurs
chemins parallèles convergent ou se rejoignent. À cet endroit, tout retard ou toute prolon-
gation d’un chemin convergent peut retarder le projet. Au cours de l’analyse quantitative
des risques d’un planning, des risques significatifs peuvent se produire à cet endroit.
Correction à chaud / Workaround. Réponse à une menace. Se distingue du développement
des stratégies de réponse en ce sens qu’elle n’est pas prévue avant l’occurrence du risque
en question.
Courbe en S / S-Curve. Représentation graphique du cumul des coûts, des heures de tra-
vail, du pourcentage de travail ou d’autres paramètres, en fonction du temps. Le nom pro-
vient de la forme en S de la courbe (dont la pente est faible au début et à la fin, et plus forte
au milieu) provenant d’un projet qui débute lentement, accélère, avant de ralentir et de s’ar-
rêter. Terme désignant également le cumul de la distribution des probabilités résultant d’une
simulation, outil de l’analyse quantitative des risques.
Coût budgété du travail prévu (CBTP) / Budgeted Cost of Work Scheduled (BCWS). Ce
terme a été remplacé par le terme Valeur prévue.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
201
Glossaire

Coût budgété du travail réalisé (CBTR) / Budgeted Cost of Work Performed (BCWP).
| Diagramme réseau chronologique

Ce terme a été remplacé par le terme Valeur acquise.


Coût de la qualité / Cost of Quality. Coûts encourus pour assurer la qualité. Le coût de la
qualité comprend la planification, le contrôle et l’assurance de la qualité, ainsi que les
reprises.
Coût estimé pour achèvement (CEA) / Estimate to Complete (ETC). Coût estimé restant
à engager pour achever une activité, un groupe d’activités ou un projet. La plupart des
techniques de prévision du CEA comportent des réajustements de l’estimation initiale, en
fonction des performances obtenues à ce jour. Voir aussi Valeur acquise et Prévision à
l’achèvement.
Coût final prévu / Forecast Final Cost. Voir Prévision à l’achèvement.
Coût réel (CR) / Actual Cost. Total des coûts encourus devant être en conformité avec les
coûts budgétés dans la valeur prévue et dans la valeur acquise, pour les travaux accomplis
durant une période définie (il peut inclure soit des heures de travail directes ou des coûts
Coût budgété du travail réalisé (CBTR)

directs uniquement, soit l’ensemble des coûts y compris les coûts indirects). Voir aussi
valeur acquise.
Coût réel du travail réalisé (CRTR) / Actual Cost of Work Performed (ACWP). Ce terme
a été remplacé par le terme coût réel.
Cycle de vie du projet / Project Life Cycle. Ensemble généralement séquentiel des phases
du projet, dont le nom et le nombre sont déterminés en fonction des besoins de suivi par
l’organisation ou les organisations impliquées dans le projet.
Date cible de fin de projet / Target Completion Date (TC). Date imposée qui contraint ou
influence l’analyse du réseau.
Date d’avancement / As-of Date. Voir Date de mise à jour.
Date de début / Start Date. Date à laquelle une activité débute. Normalement associée à l’un
des qualificatifs suivants : réelle, planifiée, estimée, prévue, au plus tôt, au plus tard, cible,
de référence ou actuelle.
Date de début au plus tard / Late Start Date (LS). Dans la méthode du chemin critique,
date la plus tardive à laquelle une activité peut commencer sans retarder une étape jalon
donnée (généralement la fin du projet).
Date de début au plus tôt / Early Start Date. Dans la méthode du chemin critique, la pre-
mière date possible à laquelle les parties inachevées d’une activité (ou d’un projet) peuvent
démarrer, compte tenu de la logique du réseau et des contraintes de délai. Une date de
début au plus tôt peut changer lorsque le projet avance et que des modifications sont
apportées au plan de projet.
Date de début cible / Target Start Date (TS). Date à laquelle le démarrage d’une activité est
requis.
Date de début de référence / Baseline Start Date. Voir Date de début prévue.
Date de début planifiée / Planned Start Date (PS). Voir Date de début prévue.
Date de début actuelle / Current Start Date. Estimation à ce jour de la date de début d’une
activité.
Date de début prévue / Scheduled Start Date (SS). Date à laquelle le début d’une activité
est prévu. Cette date se situe normalement entre la date de début au plus tôt et la date
de début au plus tard. Elle peut tenir compte du lissage de ressources très limitées.
Date de début réelle / Actual Start Date (AS). Date à laquelle une activité a réellement
commencé.
Date de fin / Finish Date. Date à laquelle une activité est complètement terminée. Souvent
associée à l’un des qualificatifs suivants : réelle, prévue, estimée, planifiée, au plus tôt, au
plus tard, de référence, cible, ou actuelle.
Date de fin au plus tard / Late Finish Date (LF). Dans la méthode du chemin critique, date
la plus tardive à laquelle une activité peut se terminer sans retarder une étape jalon donnée
(généralement la fin du projet).

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
202 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Glossaire

Date de fin au plus tôt / Early Finish Date (EF). Dans la méthode du chemin critique, pre-
mière date possible à laquelle les parties inachevées d’une activité (ou d’un projet) peuvent
être terminées, compte tenu de la logique du réseau et des contraintes de délai. Une date
de fin au plus tôt peut changer lorsque le projet avance et que des modifications sont
apportées au plan de projet.
Date de fin cible / Target Finish Date (TF). Date à laquelle l’achèvement d’une activité est
requise.
Date de fin de référence / Baseline Finish Date. Voir Date de fin prévue.
Date de fin planifiée / Planned Finish Date (PF). Voir Date de fin prévue.
Date de fin prévue / Current Finish Date. Estimation à ce jour de la date d’achèvement
d’une activité.
Date de fin prévue / Scheduled Finish Date (SF). Date à laquelle la fin d’une activité est
prévue. Cette date se situe normalement entre la date de fin au plus tôt et la date de fin
au plus tard. Elle peut tenir compte du lissage de ressources très limitées.
Date de fin réelle / Actual Finish Date (AF). Date à laquelle une activité a réellement été
achevée. (Remarque : dans certains champs d’application, il peut arriver que l’activité soit
considérée comme « terminée » lorsque le travail est « substantiellement avancé ».)
Date de mise à jour / Data Date (DD). Date à laquelle ou jusqu’à laquelle le système de rap-
ports du projet a généré l’état et les réalisations du projet. Également appelée Date d’avan-
cement.
Définition des activités / Activity Definition. Définition des activités précises devant être
effectuées pour produire les différents produits livrables du projet.
Définition du contenu / Scope Definition. Décomposition des principaux produits livrables
en éléments plus petits, plus simples à gérer, afin de mieux les contrôler.
Demande de devis / Request for Quotation (RFQ). Généralement, ce terme est équivalent
à appel d’offres. Cependant, dans certains domaines d’application, il peut avoir une signi-
fication plus restreinte ou spécifique.
Démarrage / Initiation. Lancement d’un projet ou d’une phase.
Dépendance / Dependency. Voir Lien logique.
Descriptif des travaux / Statement of Work (SOW). Description détaillée des produits ou
services à fournir dans le cadre d’un contrat.
Description de l’activité /Activity Description (AD) . Courte phrase, ou légende, utilisée
dans le diagramme réseau du projet et décrivant généralement le contenu de l’activité.
Développement de l’équipe / Team Development. Développement des compétences des
membres de l’équipe, ainsi que de celles du groupe, afin d’améliorer les performances du
projet.
Développement de plans alternatifs / Contingency Planning. Élaboration d’un plan de
gestion déterminant les stratégies alternatives à utiliser pour assurer le succès du projet,
dans l’éventualité où les événements de risque identifiés se produiraient.
Diagramme à barres / Bar Chart. Représentation graphique des informations relatives à la
planification des activités d’un projet. Dans le diagramme à barres classique, les activités
ou d’autres éléments du projet sont listés sur la partie gauche du diagramme, l’échelle de
temps apparaît horizontalement en haut, et la durée des activités est représentée par des
barres horizontales parallèles à l’axe des dates. On parle aussi de Diagramme de Gantt.
Diagramme de Gantt / Gantt Chart. Voir diagramme à barres.
Diagramme de Pareto / Pareto Diagram. Histogramme, classé par fréquence d’occur-
rence, montrant le nombre de résultats produits par chacune des causes identifiées.
Diagramme PERT / PERT Chart. Ce terme est couramment utilisé pour désigner le dia-
gramme réseau du projet. Voir Technique d’évaluation et de suivi des projets (PERT) pour
la définition classique du PERT.
Diagramme réseau / Logic Diagram. Voir Diagramme réseau du projet.
Diagramme réseau chronologique / Time-Scaled Network Diagram. Diagramme réseau
du projet tracé de telle manière que la position et la longueur d’une activité en représentent
la durée. Essentiellement, il s’agit d’un diagramme à barres dans lequel est incluse la
logique du réseau.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
203
Glossaire

Diagramme réseau du projet / Project Network Diagram. Représentation graphique des


| Gestion des délais du projet

liens logiques entre les activités d’un projet. Toujours tracé de la gauche vers la droite pour
refléter la chronologie du projet. Souvent appelé « diagramme PERT ».
Diffusion de l’information / Information Distribution. Diffusion, en temps voulu, des infor-
mations nécessaires aux acteurs d’un projet.
Durée / Duration (DU). Nombre d’unités de temps de travail (excluant les jours fériés et autres
périodes non ouvrées) nécessaires à l’exécution d’une activité ou de tout autre partie du
projet. Généralement exprimée en jours ouvrés ou semaines ouvrées. Quelquefois
confondue à tort avec le temps écoulé. Voir aussi Charge.
Durée restante / Remaining Duration (RDU). Durée nécessaire pour achever une activité.
Écart de coûts (EC) / Cost Variance (CV). (1) Toute différence entre le coût budgété d’une
activité et son coût réel. (2) En valeur acquise, VA - CR = EC.
Diagramme réseau du projet

Écart de prévisions (EP) / Schedule Variance (SV). (1) Toute différence entre la date
d’achèvement planifiée d’une activité et sa date réelle d’achèvement. (2) Dans la méthode
de la valeur acquise, VA – VP = EP.
Échéancier / Milestone Schedule. Calendrier résumé dans lequel figurent les principales
étapes jalons du projet. Voir aussi Échéancier directeur.
Échéancier principal / Key Event Schedule. Voir Planning directeur.
Élaboration des stratégies de réponse / Risk Response Development. Élaboration des
mesures à mettre en œuvre pour profiter de circonstances favorables ou atténuer les élé-
ments menaçants.
Élaboration du plan de projet / Project Plan Development. Intégration et coordination de
tous les plans du projet afin de créer un document uniforme et cohérent.
Élaboration du planning / Schedule Development. Analyse de l’ordre de réalisation logique
des activités, de leurs durées et des ressources nécessaires afin d’élaborer le planning du
projet.
Élément / Element. Partie, substance ou principe d’un ensemble ou d’un tout complexe.
Entreprise réalisatrice / Performing Organization. Entreprise dont le personnel est le plus
directement impliqué dans l’exécution du projet.
Équipe de gestion de projet / Project Management Team. Membres de l’équipe de projet
directement impliqués dans les activités de gestion du projet. Pour certains petits projets,
l’équipe de gestion de projet peut éventuellement inclure tous les membres de l’équipe de
projet.
Estimation / Estimate. Évaluation d’un résultat quantitatif probable. Habituellement appliquée
aux coûts et aux durées du projet et devant toujours comporter une indication de son degré
de précision (par exemple, ± x pour cent). Généralement employée avec un qualificatif (par
exemple, préliminaire, conceptuelle, de faisabilité). Dans certains domaines d’application,
le qualificatif utilisé implique des degrés de précision particuliers (par exemple, pour les pro-
jets d’ingénierie et de construction : ordre de grandeur, estimation budgétaire et estimation
détaillée).
Estimation de la durée des activités /Activity Duration Estimating. Estimation du nombre
d’unités de temps ouvré nécessaires à l’achèvement de chaque activité.
Estimation de type ordre de grandeur / Order of Magnitute Estimate. Voir Estimation.
Estimation des coûts / Cost Estimating. Evaluation du coût des ressources nécessaires
pour réaliser les activités d’un projet.
Estimation détaillée / Definitive Estimate. Voir Estimation.
Estimation du coût acceptable / Should-Cost Estimate. Estimation du coût d’un produit
ou d’un service utilisée pour évaluer si le coût proposé par un sous-traitant possible est rai-
sonnable.
Estimation paramétrique / Parametric Estimating. Technique d’estimation utilisant les rela-
tions statistiques entre des données historiques et d’autres variables (par exemple, la sur-
face en génie civil, ou les lignes de code dans le développement logiciel) pour produire une
estimation.
Étape jalon / Milestone. Événement significatif d’un projet, généralement la disponibilité d’un
produit livrable principal.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
204 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Glossaire

Évaluation du coût du cycle de vie / Life-Cycle Costing. Concept consistant à inclure les
coûts d’acquisition, de fonctionnement et d’élimination lors de l’évaluation de possibilités
diverses.
Événement à risque / Risk Event. Événement ponctuel pouvant affecter le projet de façon
positive ou négative.
Événements sur nœuds / Event-on-Node. Technique de représentation graphique par
réseau dans laquelle les événements sont représentés par des rectangles (ou nœuds) reliés
entre eux par des flèches indiquant l’ordre dans lequel ils doivent se succéder. Utilisée dans
la technique d’évaluation et de suivi des projets (PERT).
Fiches de contrôle / Control Charts. Graphiques représentant les résultats d’un processus
sur une période de temps donnée et par rapport à des limites de contrôle établies. Ces
fiches permettant de déterminer si le processus remplit son rôle de contrôle, ou s’il doit être
ajusté.
Flèche / Arrow. Représentation graphique d’une activité. Voir aussi Méthode du diagramme
fléché.
Flottement / Slack. Terme utilisé dans la méthode du diagramme fléché comme équivalent
de marge.
Gestion de la qualité du projet / Project Quality Management. Domaine de compétence
de la gestion de projet regroupant les processus nécessaires pour s’assurer que le projet
répondra aux besoins pour lesquels il a été entrepris. Il comporte la planification, l’assu-
rance et le contrôle de la qualité.
Gestion de la qualité totale / Total Quality Management (TQM). Approche couramment
utilisée pour mettre sur pied un programme d’amélioration de la qualité, au sein d’une orga-
nisation.
Gestion de l’intégration du projet / Project Integration Management. Domaine de com-
pétence de la gestion de projet comprenant les processus nécessaires à la coordination
adéquate des divers éléments du projet. Il comporte l’élaboration du plan de projet, la mise
en œuvre du plan de projet et le contrôle intégré des changements.
Gestion de projet / Project Management. Application des connaissances, des compé-
tences, des outils et des méthodes nécessaires, aux activités du projet pour répondre aux
besoins du projet.
Gestion d’ensemble des changements / Overall Change Control. Coordination des
changements pour l’ensemble du projet.
Gestion des approvisionnements du projet / Project Procurement Management.
Domaine de compétence de la gestion de projet regroupant les processus nécessaires à
l’obtention, à l’extérieur de l’entreprise réalisatrice, des produits et des services qui per-
mettront de réaliser le contenu du projet. Il comporte la planification des approvisionne-
ments, la préparation des appels d’offres, les appel d’offres, le choix des fournisseurs, la
gestion administrative des contrats et la clôture des contrats.
Gestion des communications du projet / Project Communications Management.
Domaine de compétence de la gestion de projet comprenant les processus nécessaires
à la génération, la collecte, la diffusion, l’archivage et, par la suite, au traitement final des
informations concernant le projet, de façon adéquate et en temps voulu. Il est constitué de
la planification de la communication, la diffusion de l’information, les rapports d’avancement
et la clôture administrative.
Gestion des contrats / Contract Administration. Gestion des relations avec le vendeur.
Gestion des coûts du projet / Project Cost Management. Domaine de compétence de la
gestion de projet comprenant les processus nécessaires à la réalisation du projet dans les
limites budgétaires approuvées. Il est constitué de la planification des ressources, l’esti-
mation des coûts, la budgétisation et le contrôle des coûts.
Gestion des délais du projet / Project Time Management. Domaine de compétence de
la gestion de projet regroupant les processus nécessaires pour assurer l’achèvement du
projet en temps voulu. Il comporte l’identification et l’ordonnancement des activités, l’esti-
mation de la durée des activités, l’élaboration et le contrôle du planning.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
205
Glossaire

Gestion des ressources humaines du projet / Project Human Resource Management.


| Matrice d’attribution des responsabilités

Domaine de compétence de la gestion de projet comprenant les processus permettant


l’utilisation la plus efficace possible des ressources dans le projet. Il comporte la planifica-
tion de l’organisation, l’obtention des ressources humaines et le développement de
l’équipe.
Gestion des risques du projet / Project Risk Management. Processus systématique
d’identification, d’analyse et de réponse aux risques du projet. Il implique qu’on maximise
la probabilité et les conséquences des événements favorables et qu’on minimise la pro-
babilité et les conséquences des événements défavorables. Il comporte la planification de
la gestion des risques, l’identification, l’analyse qualitative et l’analyse quantitative des
risques, la planification des stratégies de réponse, et le suivi et le contrôle des risques.
Gestion du contenu du projet / Project Scope Management. Domaine de compétence
de la gestion de projet recouvrant les processus nécessaires pour s’assurer que toutes les
activités nécessaires au succès du projet, et seulement celles-ci, font partie du projet. Il
comporte le démarrage, la planification du contenu, la définition, la vérification du contenu,
et le contrôle des modifications du contenu.
Gestion des ressources humaines du projet

Gestion par la valeur acquise / Earned Value Management. Méthode permettant d’inté-
grer le contenu, le planning et les ressources et de mesurer les performances d’un projet.
Elle permet de comparer la somme de travail qui a été planifiée à ce qui a réellement été
effectué et à ce qui a été dépensé, afin de déterminer si les performances planifiées en
matière de coûts et de délais sont respectées.
Graphe des responsabilités / Responsibility Chart. Voir Matrice d’allocation des respon-
sabilités.
Groupe d’activités / Hammock. Activité globale ou de synthèse (un groupe d’activités
connexes est représenté comme une activité unique et suivi globalement). Un groupe d’ac-
tivités peut présenter ou non un découpage interne. Voir aussi Sous-projet, Sous-réseau.
Hypothèses / Assumptions. Les hypothèses sont des facteurs qui, à des fins de
planification, sont considérés comme vrais, réels ou certains. Elles ont un impact sur tous
les aspects de la planification du projet et font partie de son élaboration progressive. Les
équipes de projet font, documentent et confirment habituellement des hypothèses lors du
processus de planification. Les hypothèses comportent en général un degré de risque.
Identification des risques / Risk Identification. Détermination des risques pouvant avoir
un impact sur le projet et documentation de leurs caractéristiques. Les outils utilisés à cette
fin comprennent le remue-méninges et les listes de contrôle.
Indice de performance des coûts (IPC) / Cost Performance Index (CPI). Rapport de la
valeur acquise aux coûts réels. On utilise souvent l’IPC pour prévoir l’amplitude d’un dépas-
sement de coût éventuel, à l’aide de la formule suivante : BAC/ IPC = coût prévisionnel à
l’achèvement. IPC = VA divisée par CR.
Indice de performance des délais (IPD) / Schedule Performance Index (SPI). Rapport
de performance des délais (valeur acquise réelle par rapport à la valeur planifiée). L’IPD se
rapporte à la portion du planning ayant réellement été accomplie. IPD = VA divisée par VP.
Ingénierie de la valeur / Value Engineering (VE). L’ingénierie de la valeur est une approche
créative utilisée pour optimiser les coûts, économiser du temps, accroître les profits, amé-
liorer la qualité, augmenter les parts de marché, résoudre les problèmes et/ou utiliser les
ressources plus efficacement.
Jalonnement des activités / Activity Sequencing. Détermination et documentation de
l’ordre d’enchaînement des activités dans le temps en fonction des liaisons logiques entre
elles.
Leçons retenues / Lessons Learned. Enseignement profitable tiré de l’exécution du projet.
On peut identifier les leçons retenues à tout moment dans le projet. Également identifiées
à un dossier du projet.
Liaison Début-Début / Start-to-Start (SS). Voir Lien logique.
Liaison Début-Fin / Start-to-Finish (SF). Voir Lien logique.
Liaison Fin-Début / Finish-to-Start. Voir Lien logique.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
206 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Glossaire

Liaison Fin-Fin / Finish-to-Finish. Voir Lien logique.


Lien / Link. Voir Lien logique.
Lien logique / Logical Relationship. Relation de dépendance entre deux activités du projet,
ou entre une activité et une étape jalon. Voir aussi Relation d’antériorité. Les quatre types
de liens logiques possibles sont :
■ Début-Début : le démarrage du successeur n’est pas possible tant que le prédécesseur
n’a pas démarré.
■ Début-Fin : l’achèvement du successeur n’est pas possible tant que le prédécesseur
n’est pas terminé.
■ Fin-Début : le démarrage du successeur n’est pas possible tant que le prédécesseur
n’est pas terminé.
■ Fin-Fin : l’achèvement du successeur n’est pas possible tant que le prédécesseur n’est
pas terminé.
Lissage / Leveling. Voir Lissage des ressources.
Lissage des ressources / Resource Leveling. Forme d’analyse de réseau dans laquelle les
décisions concernant le planning (dates de début et de fin prévues) découlent des impéra-
tifs de ressources (par exemple, disponibilité limitée de ressources ou modifications des
niveaux de ressources difficiles à gérer).
Liste de contrôle / Checklist. Liste des nombreux risques pouvant survenir au cours d’un
projet. On s’en sert comme outil dans le processus d’identification des risques. Les listes
de contrôle sont exhaustives ; on y trouve divers types de risques rencontrés au cours des
projets antérieurs.
Livrable / Deliverable. Article, produit ou résultat mesurable, tangible et vérifiable devant être
produit pour mener à bien un projet ou une partie d’un projet. Terme souvent employé dans
un sens plus restreint quand il désigne un produit livrable externe, qui est un produit livrable
soumis à l’approbation du commanditaire ou du client.
Logiciels de gestion de projet / Project Management Software. Catégorie d’applications
logicielles spécialement conçues pour faciliter la planification et le suivi des coûts et des
délais d’un projet.
Logique / Logic. Voir Logique du réseau.
Logique du réseau / Network Logic. Ensemble des liens logiques entre activités constituant
le diagramme réseau du projet.
Lot de travaux / Work Package. Produit livrable défini au plus bas niveau de l’organigramme
des tâches qui peut être attribué à un autre chef de projet pour planification et exécution.
Ceci peut être accompli par le biais d’un sous-projet dans lequel le lot de travaux sera lui-
même divisé en activités.
Marge / Float. Nombre maximum d’unités de temps dont une activité peut être retardée, au-
delà de sa date de début au plus tôt, sans retarder la date de fin du projet. La marge est le
résultat d’un calcul arithmétique, et peut varier au fur et à mesure de l’avancement du projet
si des modifications sont apportées au plan de projet. Également appelée flottement,
marge totale ou marge d’un chemin. Voir aussi Marge libre.
Marge d’un chemin / Path Float. Voir Marge.
Marge libre / Free Float. Nombre maximum d’unités de temps dont une activité peut être
retardée au-delà de sa date de début au plus tôt, sans retarder la date de début au plus tôt
de l’un de ses successeurs. Voir aussi Marge.
Marge totale / Total Float. Voir Marge.
Matrice d’allocation des responsabilités / Responsibility Assignment Matrix (RAM).
Tableau dans lequel la structure de l’organisation du projet est liée à l’organigramme des
tâches, et qui permet de vérifier que la responsabilité de chacun des éléments de travail du
contenu du projet est attribuée.
Matrice d’attribution des responsabilités / Accountability Matrix. Voir Matrice d’alloca-
tion des responsabilités.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
207
Glossaire

Matrice de probabilité et d’impact / Probability and Impact Matrix. Manière courante de


Matrice de probabilité et d’impact | Planification des communications

déterminer si un risque est considéré comme faible, moyen ou élevé, en combinant ses
deux dimensions : sa probabilité d’occurrence et son impact sur les objectifs s’il se concré-
tise.
Matrice des responsabilités / Responsibility Matrix. Voir Matrice d’allocation des res-
ponsabilités.
Membres de l’équipe / Team Members. Voir Membres de l’équipe de projet.
Membres de l’équipe de projet / Project Team Members. Personnes directement ou indi-
rectement sous la responsabilité du chef de projet.
Mesure des performances techniques / Technical Performance Measurement. La
mesure des performances techniques compare les réalisations techniques durant l’exécu-
tion du projet au planning des réalisations techniques décrites dans le plan de projet.
Méthode de Monte Carlo / Monte Carlo Analysis. Technique effectuant plusieurs simula-
tions du projet pour calculer la distribution des résultats probables. Voir Simulation.
Méthode des antécédents / Precedence Diagramming Method (PDM). Technique de
représentation de réseaux dans laquelle les activités sont représentées par des rectangles
(ou nœuds). Les activités sont liées par des relations d’antériorité indiquant leur ordre d’exé-
cution.
Méthode du chemin critique / Critical Path Method (CPM). Technique d’analyse de
réseau utilisée pour estimer la durée d’un projet, consistant à analyser la séquence d’acti-
vités (chemin) qui présente le moins de souplesse (marge la plus faible). Les dates au plus
tôt sont obtenues par un calcul au plus tôt à partir d’une date de début de projet spécifiée.
Les dates au plus tard sont obtenues par un calcul à rebours, à partir d’une date d’achè-
vement spécifiée (généralement, la date de fin au plus tôt du projet obtenue par le calcul au
plus tôt).
Méthode du diagramme fléché / Arrow Diagramming Method (ADM). Technique de
représentation schématique d’un projet dans laquelle les activités sont représentées par
des flèches. La base de la flèche représente le début de l’activité, et la pointe sa fin (la lon-
gueur de la flèche ne représente pas la durée prévue de l’activité). Les activités sont reliées
à des points appelés nœuds (représentés généralement par de petits cercles), pour illustrer
l’ordre dans lequel elles doivent se succéder. Voir aussi Méthode des antécédents.
Mise en œuvre du plan de projet / Project Plan Execution. Application du plan de projet,
par la réalisation des activités qui le composent.
Niveau de charge / Level of Effort (LOE). Activité de support (par exemple, relation avec
le vendeur ou le client) dont l’avancement ne se prête pas à une évaluation par rapport à
des réalisations précises. Le niveau de charge est en général caractérisé par un taux de
charge uniforme pendant un laps de temps correspondant à la réalisation des activités qu’il
gère.
Nœud / Node. Point constituant d’un réseau ; point de jonction d’un certain nombre de lieus,
voire de tous les liens. Voir aussi Méthode du diagramme fléché et Méthode des antécé-
dents.
Obtention de ressources humaines / Staff Acquisition. Sélection et mise en place des
ressources humaines à affecter et à employer pendant le projet.
Organigramme des tâches (OT) / Work Breakdown Structure (WBS). Décomposition
orienté produits livrables des éléments d’un projet, qui organise et définit le contenu inté-
gral des travaux du projet. Chaque niveau représente une définition des travaux du projet
plus détaillée que le niveau précédent.
Organigramme fonctionnel (OF) / Organizational Breakdown Structure (OBS). Repré-
sentation de l’organisation à laquelle appartient un projet, structurée de façon à relier des
lots de travaux à des unités organisationnelles.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
208 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Glossaire

Organisation fonctionnelle / Functional Organization. Type de structure organisationnelle


dans laquelle le personnel est regroupé hiérarchiquement par spécialités (par exemple, pro-
duction, marketing, ingénierie, et comptabilité au premier niveau ; l’ingénierie est elle-même
divisée en mécanique, électricité, etc.).
Organisation matricielle / Matrix Organization. Structure organisationnelle dans laquelle
le chef de projet partage, avec les responsables fonctionnels, la responsabilité de définir les
priorités et de diriger le travail du personnel affecté à un projet.
Organisation par projets / Projectized Organization. Structure organisationnelle dans
laquelle le chef de projet a toute autorité pour définir les priorités et diriger le travail du per-
sonnel affecté à un projet.
Partie d’un réseau / Fragnet. Voir Sous-réseau.
Phase / Phase. Voir Phase du projet.
Phase du projet / Project Phase. Ensemble d’activités d’un projet liées logiquement et
aboutissant généralement à l’achèvement d’un produit livrable important.
Plan comptable / Chart of Accounts. Système de codification utilisé pour assurer le suivi
des coûts d’un projet par catégorie (par exemple, heures, fournitures, matériaux et équi-
pements). Le plan comptable est habituellement calqué sur celui de l’entreprise réalisatrice
du projet. Voir aussi Plan des comptes.
Plan de gestion des risques / Risk Management Plan. Document décrivant comment
seront exécutés les processus de gestion des risques durant le projet. Il s’agit du résultat
de la planification de la gestion des risques.
Plan de projet / Project Plan. Document formel et approuvé, utilisé pour mener à bien à la
fois l’exécution et le contrôle du projet. Le plan de projet sert principalement à documenter
les hypothèses de travail et les décisions relatives à la planification, à faciliter la communi-
cation entre les acteurs et à documenter les références approuvées de contenu, le coût et
le planning. Un plan de projet peut être détaillé ou global.
Plan des comptes / Code of Accounts. Système de codification utilisé pour identifier
chaque élément de l’organigramme des tâches de manière unique. Voir aussi Plan comp-
table.
Plan des comptes de contrôle (PCC) / Control Account Plan (CAP). Appelé auparavant
« plan des postes de coûts ». Le PCC est un point de contrôle de gestion où se fait l’inté-
gration du contenu, du budget et des délais, et où les performances sont évaluées. Les
PCC sont placés à des points de gestion déterminés de l’organigramme des tâches.
Plan des stratégies de réponse / Risk Response Plan. Document détaillant tous les
risques identifiés, y compris leurs descriptions, leurs causes, leurs probabilités d’occur-
rence, leur impact sur les objectifs, les stratégies de réponse proposées, le nom des per-
sonnes faisant ces propositions et du responsable, et l’état actuel du risque. Également
appelé Registre des risques.
Planification de la gestion des risques / Risk Management Planning. Décisions relatives
à l’approche à prendre et à la façon de planifier les activités de gestion des risques dans un
projet.
Planification de la qualité / Quality Planning. Détermination des normes de qualité appli-
cables à un projet, et des moyens à mettre en œuvre pour les respecter.
Planification de l’organisation / Organizational Planning. Identification, documentation et
attribution des rôles, des responsabilités et des liens hiérarchiques dans un projet.
Planification des appels d’offres / Solicitation Planning. Établissement des spécifications
relatives aux produits à acquérir et identification des fournisseurs potentiels.
Planification des approvisionnements / Procurement Planning. Définition des éléments
à obtenir et à quel moment.
Planification des communications / Communications Planning. Évaluation des besoins
des acteurs d’un projet en matière d’information et de communication(s) : qui a besoin de
quelles informations, quand, et sous quelle forme ces informations seront transmises.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
209
Glossaire

Planification des ressources / Resource Planning. Détermination des moyens (en per-
| Sous-projet

sonnel, équipement, matériaux) et des quantités nécessaires à la réalisation des activités


du projet.
Planification des stratégies de réponse / Risk Response Planning. Établissement des
procédures et des techniques visant à améliorer les opportunités et à réduire les menaces
concernant les objectifs du projet. Les outils comprennent le rejet, la modification, le trans-
Planification de ressources

fert et l’acceptation.
Planification du contenu / Scope Planning. Processus consistant à élaborer progressive-
ment le travail nécessaire à la réalisation d’un projet, y compris la rédaction d’un cahier des
charges où figurent la justification du projet, les principaux livrables et ses objectifs.
Planification du projet / Project Planning. Élaboration et mise à jour du plan de projet.
Planning / Schedule. Voir Planning du projet.
Planning cible / Target Schedule. Voir Référence.
Planning directeur / Master Schedule. Planning de synthèse où figurent les activités prin-
cipales et les étapes jalons principales. Voir aussi Planning.
Planning du projet / Project Schedule. Ensemble des dates prévues pour exécuter les acti-
vités et franchir les étapes jalons.
Planning piloté par les ressources / Resource-Limited Schedule. Planning de projet dont
les dates de début et de fin tiennent compte de la disponibilité des ressources. Le planning
final d’un projet doit toujours être piloté par les ressources.
Pourcentage d’avancement (physique) / Percent Complete (PC). Estimation, exprimée
en pourcentage, de la quantité de travail achevée, pour une activité ou un groupe d’acti-
vités.
Prévision à l’achèvement / Estimate at Completion (EAC). Coût total estimé d’une acti-
vité, d’un groupe d’activités ou d’un projet, une fois réalisé le contenu défini. La plupart des
méthodes d’estimation de la prévision à l’achèvement comportent des réajustements de
l’estimation initiale en fonction des résultats obtenus à ce jour.
Prévisions budgétaires / Budget Estimate. Voir Estimation.
Professionnel en gestion de projet (PMP®) / Project Management Professional (PMP®).
Personne certifiée par le Project Management Institute (PMI®).
Programme / Program. Groupe de projets connexes, gérés de façon coordonnée. Les pro-
grammes comportent généralement un élément de travail en cours.
Projet / Project. Entreprise temporaire initiée dans le but de fournir un produit, un service ou
un résultat unique.
Provision pour aléas / Contingency Reserve. Somme d’argent ou quantité de temps sup-
plémentaire (par rapport à l’estimation) nécessaire à la réduction du risque de dépassement
des objectifs du projet jusqu’à un niveau acceptable pour l’organisation.
Provision pour contingences / Contingency Allowance. Voir Réserve.
Quantification des risques / Risk Quantification. Évaluation quantitative de la probabilité
d’occurrence des événements à risque et de leurs conséquences.
Rapport des écarts majeurs / Exception Report. Document ne contenant que les princi-
paux écarts par rapport au plan (plutôt que l’ensemble des écarts).
Rapports coût-délai intégrés / Integrated Cost/ Schedule Reporting. Voir Valeur
acquise.
Rapports d’avancement / Performance Reporting. Collecte et diffusion des informations
concernant l’avancement. Ceci englobe la préparation de rapports, la mesure de l’avan-
cement et les prévisions.
Réduction / Mitigation. Voir Réduction des risques.
Réduction des délais / Schedule Compression. Voir Compression de durée.
Réduction des risques / Risk Mitigation. A pour objet d’atténuer la probabilité et/ou l’im-
pact d’un risque en dessous d’un seuil acceptable.
Référence / Baseline. Plan initial approuvé (d’un projet, d’un lot de travaux ou d’une activité),
plus ou moins les modifications de contenu approuvées. Habituellement utilisé avec un
modificateur (par ex., référence de coûts, de temps, de mesure des performances).

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
210 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Glossaire

Référence de contenu / Scope Baseline. Voir Référence.


Référence de mesure des performances / Performance Measurement Baseline. Plan
approuvé par rapport auquel on compare les écarts pour le contrôle du projet.
Référentiel des connaissances en gestion de projet ou PMBOK®/ Project Manage-
ment Body of Knowledge (PMBOK®) . Terme global qui désigne l’ensemble des connais-
sances nécessaires à l’exercice de la gestion de projet. Comme pour d’autres professions,
telles que le droit, la médecine ou la comptabilité, ce référentiel de connaissances dépend
des enseignants et des praticiens qui l’appliquent et le font progresser. Le PMBOK® com-
prend des méthodes classiques et éprouvées, largement utilisées, aussi bien que des pra-
tiques nouvelles et originales dont l’usage est plus limité.
Retard / Lag. Modification d’un lien logique entraînant un retard au niveau de la tâche suc-
cesseur. Par exemple, dans une liaison Fin-Début avec un retard de 10 jours, le successeur
ne peut commencer au plus tôt que 10 jours après l’achèvement de l’antécédent. Voir aussi
Avance.
Registre des risques / Risk Register. Voir Plan des stratégies de réponse.
Rejet d’un risque / Risk Avoidance. Le rejet de risque implique la modification du plan de
projet afin d’éliminer un risque ou de protéger les objectifs du projet contre son impact. Il
s’agit d’un outil du processus de planification des stratégies de réponse.
Relation d’antériorité / Precedence Relationship. Terme utilisé dans la méthode des anté-
cédents pour désigner un lien logique. Toutefois, dans l’usage courant, les termes « rela-
tion d’antériorité », « lien logique » et « dépendance » sont employés indiféremment, quelle
que soit la méthode de représentation graphique utilisée.
Remue-méninges / Brainstorming. Technique de créativité générale qui peut servir à iden-
tifier les risques grâce à l’aide d’un groupe de membres de l’équipe ou d’experts dans un
domaine particulier. Généralement, ce type de session est organisé de façon à enregistrer
les idées de chacun des participants afin de les analyser ultérieurement. Cet outil est décrit
dans le processus d’identification des risques.
Reprise / Rework. Action entreprise pour corriger un élément défectueux ou non conforme,
afin de le rendre conforme aux exigences ou aux spécifications.
Réseau / Network. Voir Diagramme réseau du projet.
Réserve / Reserve. Provision incluse dans le plan de projet pour faire face aux risques ayant
un impact sur les coûts et/ou les délais. Souvent utilisé avec un déterminant (par exemple,
réserve pour imprévus, réserve pour aléas) pour préciser le genre des risques qui sont
censés être couverts. La signification précise du terme caractérisé varie en fonction du
domaine d’application.
Responsable fonctionnel / Functional Manager. Responsable chargé des activités d’un
service particulier de l’entreprise ou d’une fonction (par exemple, ingénierie, fabrication,
marketing).
Retenue de garantie / Retainage. Portion du prix total d’un contrat qui n’est pas réglée
avant l’achèvement de celui-ci, afin de s’assurer du respect total des termes du contrat.
Risque / Risk. Événement ou condition incertaine qui, s’il survient ou si elle se présente, peut
avoir un impact positif ou négatif sur les objectifs d’un projet.
Risque résiduel / Residual Risk. Risque qui persiste après la mise en œuvre des stratégies
de réponse.
Risque subordonné / Secondary Risk. Risque résultant directement de la mise en œuvre
d’une stratégie de réponse.
Rupture / Hanger. Rupture non intentionnelle dans un chemin de réseau. Une rupture est
généralement le résultat d’activités ou de liens logiques manquants.
Simulation / Simulation. Une simulation utilise un modèle de projet qui convertit les incerti-
tudes définies à un niveau détaillé, en l’impact qu’elles pourraient avoir sur les objectifs
exprimés au niveau de la totalité du projet. Les simulations de projet se servent d’estima-
tions et de modèles informatisés des risques à un niveau détaillé. Elles sont habituellement
effectuées à l’aide de la méthode de Monte Carlo.
Sous-projet / Subproject. Partie du projet global.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
211
Glossaire

Sous-réseau / Subnet. Partie du diagramme réseau du projet représentant en général une


| Index

sorte de sous-projet.
Sous-réseau / Subnetwork. Voir Sous-réseau.
Successeur / Successor Activity. (1) Dans la méthode du diagramme fléché, activité débu-
Sous-réseau

tant à partir d’un nœud. (2) Dans la méthode des antécédents, activité à laquelle aboutit un
lien logique.
Suivi / Monitoring. Collecte, analyse et préparation de rapports sur les performances du
projet, en général par comparaison avec le plan.
Suivi et contrôle des risques / Risk Monitoring and Control. Suivi des risques résiduels,
identification des nouveaux risques, mise en œuvre des stratégies de réponse aux risques
et évaluation de l’efficacité de ces dernières tout au long du cycle de vie du projet.
Symptômes annonciateurs / Triggers. Les symptômes annonciateurs, parfois appelés
déclencheurs ou signes d’avertissements, sont une indication de l’occurrence de risques
ou de leur imminence. Les symptômes annonciateurs peuvent être découverts lors du pro-
cessus d’identification des risques et contrôlés dans le cadre du suivi et contrôle des
risques.
Tâche / Task. Terme générique désignant tout travail non inclus dans l’organigramme des
tâches, mais qui pourrait représenter une décomposition plus précise du travail par les indi-
vidus en ayant la responsabilité. Il s’agit également du niveau de charge le plus bas d’un
projet.
Tâche élémentaire / Work Item. Ce terme n’est plus usité. Voir Activité.
Tampon / Buffer. Voir Réserve.
Technique d’évaluation et de suivi des projets (PERT) / Program Evaluation and
Review Technique. Technique d’analyse de réseau orientée événement, utilisée pour
estimer la durée d’un projet lorsque l’estimation de la durée des activités individuelles com-
porte un certain degré d’incertitude. La méthode PERT applique la méthode du chemin cri-
tique en utilisant pour chaque activité une durée calculée par une moyenne pondérée des
estimations de durée optimiste, pessimiste et des plus probables. Elle calcule l’écart type
de la date d’achèvement à partir de ceux des durées du chemin critique. Également
appelée Analyse de la méthode des moments.
Technique d’évaluation et de suivi graphique (GERT) / Graphical Evaluation and
Review Technique. Technique d’analyse de réseau qui permet le traitement conditionnel
et probabiliste des liaisons logiques (c’est-à-dire que certaines activités peuvent ne pas se
réaliser).
Transfert / Transference. Voir Transfert des risques.
Transfert des risques / Risk Transference. Le transfert des risques consiste à transférer à
un tiers l’impact d’un risque, ainsi que la responsabilité de mise en œuvre des stratégies de
réponse.
Unité calendaire / Calendar Unit. La plus petite unité de temps utilisée dans l’ordonnan-
cement d’un projet. Les unités calendaires sont généralement des heures, des jours ou des
semaines. Elles peuvent aussi correspondre à des équipes, voire à des minutes. Ce terme
est principalement utilisé par les logiciels de gestion de projet.
Valeur acquise / Earned Value (EV). Le travail physique accompli plus le budget qui lui est
imparti. La somme des coûts estimés approuvés (peut inclure des frais généraux) pour les
activités (ou portions d’activités) accomplies durant un certain laps de temps (habituelle-
ment du début du projet à la date de mise à jour). Appelée auparavant « coût budgété du
travail réalisé (CBTR) d’une activité ou d’un groupe d’activités.
Valeur prévue (VP) / Planned Value (PV). Le travail physique prévu additionné du budget
autorisé pour son accomplissement. Ce terme remplace l’ancien terme « Coût budgété du
travail prévu (CBTP) ».
Vendeur / Seller. Fournisseur de biens ou prestataire de services pour une organisation.
Vérification du contenu / Scope Verification. Acceptation formelle du contenu du projet.

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
212 © 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
INDEX
A AON Voir activités sur nœuds
appel à candidature 153, 198
AC/CR Voir Coût réel (CR) appel d’offres (AO) 153, 198
acteur(s) 6, 11–12, 16–18, 24, 32, 34–35, 41, AQ Voir assurance de la qualité
43–44, 49, 54, 56, 61, 63, 74, 80, 91–92,
107–08, 114–15, 119–22, 124, 129–32, 147, AS Voir date de début réelle
169, 197 assurance de la qualité (AQ) 7, 35, 95, 97,
Voir aussi acteur(s) du projet 99, 101–02, 190, 198
acteur(s) du projet 4, 11, 16, 35, 83, 89, 95,
98, 102, 107–08, 110, 117, 119–22, 132, 138,
141, 144, 191 B
Voir aussi acteur(s)
BAC Voir Budget à l’achèvement
action corrective 30, 46, 49, 63-64, 80-81, 91-
93, 102-03, 144, 146, 197 BCWP/VBTR Voir Coût budgété du travail réalisé
activité(s) 14, 36, 47, 68-69, 71-75, 77-78, 80- (CBTR)
81, 87- 88, 100- 01, 103, 123, 170, 197 BCWS/ VBTP Voir Coût budgété du travail prévu
critique 76, 80, 198 (CBTP)
description de l’ 203 boucle 46, 199
durées 34, 65, 67, 72-73, 75, 190 Budget à l’achèvement (BAC) 92, 199
fictive 198 budgétisation 7, 34, 83, 85, 89-90, 190, 199
identification des 7, 34, 65, 67, 71, 190
jalonnement des 7, 34, 49, 65, 68-70, 190,
206 C
liste 60, 67-68, 71, 73 cahier des charges 150–53, 156, 199
successeur 74 calcul à rebours 199
estimation 7, 34, 65, 71-73, 73-75, 80, 86- calcul au plus tôt 199
87, 190 CAP Voir plan des comptes
activité critique Voir activité, critique CCB Voir Comité de contrôle des changements
activité fictive Voir activité, fictive charte du projet 45, 54-55, 114, 129, 131,
activité sous-critique 80, 198 183, 199
activités sur flèches (AOA) 70, 198 charte Voir charte du projet
activités sur nœuds (AON) 69, 198 chef de projet 4, 16, 19-21, 24, 46, 54-55, 60-
61, 96, 107, 110, 114-15, 130, 136, 144, 153,
ACWP/CRTE Voir Coût réel du travail réalisé 156, 181, 199
(CRTR)
chemin critique 9, 76-77, 80, 200
AD/DA Voir description de l’activité
méthode du 26, 75, 208
ADM Voir Méthode du diagramme fléché
chemin(s) 139, 199
AF Voir date de fin réelle
convergence des 201
aléas 45
marge d’un 207
analyse mathématique 75-77, 198
chevauchement 4, 9, 16, 30, 41, 51, 65, 83,
analyse qualitative des risques 8, 34, 127, 95, 107, 117, 127, 147, 199
133–37, 140, 191, 198
choix de fournisseurs 8, 35, 147, 153,
analyse quantitative des risques 8, 34, 155–56, 191, 200
127, 130, 132, 134, 136–39, 141, 143, 191,
198 classe 96, 200
antécédent Voir activité, antécédent clôture administrative 8, 37, 117, 125, 158-
59, 191, 200
AOA Voir activités sur flèches

Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®), Édition 2000
© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
213
Index

Comité de contrôle des changements | gestion de projet


Comité de contrôle des changements 49, modifications du 158-59
200 négociation du 155-56
compression de durée 75, 200 pièces et main-d’œuvre 200
construction en régime accéléré 12, 75, contrôle 11-12, 36, 42-43, 45-47, 49, 57, 59,
200 62-63, 67, 79-80, 85, 88-89, 91, 102-03, 115,
contenu 19, 25, 27, 30, 32–33, 43–45, 59–63, 124, 130, 144-45, 149, 157, 170, 201
68, 89, 123, 131–32, 137, 142, 170–71, 200 Voir aussi Comité de contrôle des changements,
Voir aussi contenu du produit, contenu du projet, système de contrôle des changements,
gestion du contenu du projet et plan de contrôle des coûts, contrôle intégré des
gestion du contenu du projet changements, contrôle de la qualité, suivi et
modification du 29, 56, 62–63, 80, 92, 103, 124, contrôle des risques, contrôle du planning et
145 contrôle du contenu
Référence de 63, 210 plan des comptes de contrôle 42, 92, 209
contrôle des changements du projet 7, fiches de 103, 205
36, 51, 62–64, 91, 189, 201 contrôle de la qualité 7, 36, 61–62, 91, 95,
définition du 6–7, 34, 37, 51, 57, 59, 67, 85, 99–104, 157, 190, 201
110, 149–50, 189 contrôle des coûts 7, 36, 62, 83, 90-93, 190,
énoncé du 34, 45, 51, 55–57, 60–62, 67, 86, 201
98, 149, 170, 189 contrôle intégré des changements 7, 36,
planification du 7, 34, 51, 55–56, 189 41, 47-49, 63, 79-80, 91, 102, 104, 146, 158,
189, 201
vérification du 7, 36, 51, 61–62, 189
courbe en S 90, 124, 170, 201
contenu du produit 6, 41, 47, 51, 63, 200
Coût budgété du travail prévu (CBTP) 92,
contenu du projet 6, 32, 36, 41–42, 47, 51, 123, 196, 198, 201
55–56, 60–61, 63, 71, 75, 91, 96, 143, 147,
149,189, 191, 200 Coût budgété du travail réalisé (CBTR)
92, 123, 202
Contingences ou aléas 73, 75, 88, 90, 129,
143-44 coût de la qualité 99, 202
développement de plans alternatifs 203 Coût réel (CR) 88, 92, 123, 202
plans alternatifs 41, 63, 88, 143-44, 146 Coût réel du travail réalisé (CRTR) 123,
202
provision pour aléas 78, 137, 144, 210
CPFF Voir contrat, à rétribution fixe
contrat à coûts remboursables Voir contrat,
à coûts remboursables CPI/IPC Voir indice de performance des coûts
(IPC)
contrat à forfait Voir contrat, à forfait
CPIF Voir contrat, en dépenses contrôlées avec
contrat à prix fixe Voir contrat, à prix fixe intéressement
contrat à prix forfaitaire (FFP) Voir contrat, à CPM Voir méthode du chemin critique
prix forfaitaire
CV Voir écart de coûts
contrat à prix forfaitaire avec
intéressement (FPIF) Voir contrat, à prix cycle de vie du projet 6, 11-14, 30, 51, 57-58,
forfaitaire avec intéressement 127, 130, 145, 169-70, 181, 191, 202
contrat à rétribution fixe (CPFF) Voir
contrat, à rétribution fixe