Pmi fr

Le Guide PMBOK®

Édition 2000

PROJECT MANAGEMENT INSTITUTELe Guide officiel du Project Management Body of Knowledge

Guide du référentieldes connaissances en

gestion de projet

Guide duRéférentiel desconnaissances en gestion deprojet (Guide PMBOK®)

An American National StandardANSI/PMI 99-001 2000

Guide duRéférentiel desconnaissances en gestion deprojet (Guide PMBOK®)

Édition 2000

Project Management InstituteNewtown Square, Pennsylvania, États-Unis

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 BoulevardNewtown Square, Pennsylvania 19073-3299 USATéléphone : 610-356-4600 ou visitez notre site Internet : www.pmi.orgCourriel : [email protected]

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

Le service de publication du PMI accepte volontiers les corrections et les commentaires concernant sesdocuments. N’hésitez pas à nous envoyer vos commentaires concernant la typographie, la mise en page oud’autres erreurs éventuellement identifiées, ainsi que tous vos commentaires destinés au PMI et portant sur lecontenu du Guide du référentiel des connaissances en gestion de projet. Faites simplement une copie despages en question dans le Guide PMBOK®, indiquez les erreurs et envoyez le tout à : Book Editor, PMIPublications, 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 : [email protected].

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

« PMBOK », « PM Network » et « PMI Today » sont des marques déposées aux États-Unis ainsi que dansd’autres pays ; « Project Management Journal » et « Building professionalism in project management » sont desmarques 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éspromotionnelles, ou pour inclusion dans des programmes de formation d’entreprises ou d’un autre type. Pour plusd’informations, merci d’écrire à Bookstore Administrator, PMI Publications, Four Campus Boulevard, NewtownSquare, 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èreque ce soit ou par quelque moyen que ce soit, électronique, manuel, photocopie, enregistrement, ou parl’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 InformationStandards 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

ISBN: 1-930699-68-9

SOMMAIRE

AVANT-PROPOSSOMMAIRE ----------------------------------------------------------------- vLISTE DES FIGURES ----------------------------------------------------- viiPRÉFACE À L’ÉDITION 2000 ---------------------------------------------- ix

SECTION I — CADRE DE LA GESTION DE PROJET --------------------- 1Chapitre 1 — Introduction ------------------------------------------------- 3

1.1 Objectif de ce guide -------------------------------------------------------- 31.2 Qu’est-ce qu’un projet ? -------------------------------------------------- 41.3 Qu’est-ce que la gestion de projet ? ------------------------------------- 61.4 Relations avec les autres disciplines de gestion ------------------------- 91.5 Activités connexes --------------------------------------------------------- 10

Chapitre 2 — Contexte de la gestion de projet ------------------------- 112.1 Phases et cycle de vie du projet ------------------------------------------ 112.2 Acteurs du projet ----------------------------------------------------------- 162.3 Influences organisationnelles ---------------------------------------------- 182.4 Compétences majeures en gestion -------------------------------------- 212.5 Influences socio-économiques et environnementales ------------------ 26

Chapitre 3 — Processus de la gestion de projet ----------------------- 293.1 Processus du projet -------------------------------------------------------- 293.2 Groupes de processus ---------------------------------------------------- 303.3 Interactions entre processus ---------------------------------------------- 323.4 Personnalisation des interactions entre processus --------------------- 373.5 Matrice de présentation des processus de gestion de projet ---------- 38

SECTION II — DISCIPLINES DE LA GESTION DE PROJET-------------- 39Chapitre 4 — Gestion de l’intégration du projet ----------------------- 41

4.1 Élaboration du plan de projet --------------------------------------------- 424.2 Mise en œuvre du plan de projet ----------------------------------------- 464.3 Contrôle intégré des changements --------------------------------------- 47

Chapitre 5 — Gestion du contenu du projet ---------------------------- 515.1 Démarrage ------------------------------------------------------------------ 535.2 Planification du contenu --------------------------------------------------- 555.3 Définition du contenu ------------------------------------------------------ 575.4 Vérification du contenu ---------------------------------------------------- 615.5 Contrôle des changements du contenu --------------------------------- 62

Chapitre 6 — Gestion des délais du projet ----------------------------- 656.1 Définition des activités ----------------------------------------------------- 656.2 Jalonnement des activités ------------------------------------------------- 686.3 Estimation de la durée des activités -------------------------------------- 716.4 Élaboration du planning ---------------------------------------------------- 736.5 Contrôle du planning ------------------------------------------------------- 79

Chapitre 7 — Gestion des coûts du projet ------------------------------ 837.1 Planification des ressources ----------------------------------------------- 857.2 Estimation des coûts ------------------------------------------------------- 867.3 Budgétisation --------------------------------------------------------------- 897.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 --------------------------- 958.1 Planification de la qualité -------------------------------------------------- 978.2 Assurance de la qualité ---------------------------------------------------- 1018.3 Contrôle de la qualité ------------------------------------------------------ 102

Chapitre 9 — Gestion des ressources humaines du projet ----------- 1079.1 Planification de l’organisation --------------------------------------------- 1089.2 Obtention des ressources humaines ------------------------------------- 1129.3 Développement de l’équipe ----------------------------------------------- 114

Chapitre 10 — Gestion des communications du projet --------------- 11710.1 Planification des communications ---------------------------------------- 11910.2 Diffusion de l’information -------------------------------------------------- 12110.3 Rapports d’avancement --------------------------------------------------- 12210.4 Clôture administrative ------------------------------------------------------ 125

Chapitre 11 — Gestion des risques du projet -------------------------- 12711.1 Planification de la gestion des risques ----------------------------------- 12911.2 Identification des risques -------------------------------------------------- 13111.3 Analyse qualitative des risques ------------------------------------------- 13311.4 Analyse quantitative des risques ------------------------------------------ 13711.5 Développement des stratégies de réponse ------------------------------ 14011.6 Suivi et contrôle des risques ---------------------------------------------- 144

Chapitre 12 — Gestion des approvisionnements du projet ----------- 14712.1 Planification des approvisionnements ------------------------------------ 14912.2 Planification des appels d’offres ------------------------------------------ 15212.3 Appels d’offres ------------------------------------------------------------- 15312.4 Choix des fournisseurs ---------------------------------------------------- 15512.5 Administration des contrats ----------------------------------------------- 15612.6 Clôture du contrat ---------------------------------------------------------- 158

SECTION III—ANNEXES ------------------------------------------------------ 161Annexe A — Processus de normalisation du Project Management

Institute - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 163Annexe B — Évolution du Guide du référentiel des connaissances en

gestion de projet du PMI - - - - - - - - - - - - - - - - - - - - - - - - - - - 167Annexe C — Collaborateurs et réviseurs du Guide PMBOK®,

Édition 2000 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 175Annexe D — Notes - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 179Annexe E — Extensions des champs d’application - - - - - - - - - - - 181Annexe F — Autres sources d’information sur la gestion de

projet - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 185Annexe G — Résumé des domaines de compétence de la gestion

de projet - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 189

SECTION IV — GLOSSAIRE ET INDEX ------------------------------------- 193Glossaire -------------------------------------------------------------------- 195Index ------------------------------------------------------------------------- 215

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 USAvi

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

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

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© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USAviii

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 etpratiques 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 dutemps, 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 pourles 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 chapitres4 (Gestion de l’intégration du projet), 7 (Gestion des coûts du projet) et 10 (Gestion descommunications 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, analysequantitative des risques, planification des stratégies de réponse, et suivi et contrôle desrisques.

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ôleintégré des changements », pour souligner l’importance du contrôle des changementstout au long du projet.

10. Nous avons ajouté un tableau (figure 3-9), pour représenter le rapport entre lestrente-neuf processus de la gestion de projet, les cinq groupes de processus de gestion deprojet 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 enconstante évolution. Le PMI a l’intention de mettre le Guide PMBOK® à jour régulièrement. Parconséquent, si vous souhaitez faire des commentaires sur cet ouvrage ou suggérer des amé-liorations, veuillez les envoyer à :

PMI Project Management Standards ProgramProject Management InstituteFour Campus BoulevardNewtown Square, PA 19073-3299 USATéléphone : + 1 (610) 356-4600Télécopie : + 1 (610) 356-4647Courriel : [email protected] : http://www.pmi.org

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 USAx

SECTION I

CADRE DE LA GESTION DE PROJET

1. Introduction

2. Contexte de la gestion de projet

3. Processus 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 3

Chapitre 1

Introduction

Le Guide du référentiel des connaissances en gestion de projet (Guide PMBOK®) est un termeglobal qui décrit l’ensemble des connaissances au sein du domaine professionnel de la gestionde 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 projetrecense des méthodes classiques, éprouvées et largement utilisées, ainsi que des méthodesnouvelles 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 dureste de l’ouvrage. Il comprend les sections principales suivantes :1.1 Objectif de ce guide1.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 gestion1.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 cetouvrage 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écritessont applicables à la majorité des projets, la plupart du temps, et qu’il s’est établi un consensusgénéral sur leur valeur et leur utilité. Cela ne signifie pas que les connaissances et les méthodesdécrites sont ou doivent être appliquées à tous les projets sans distinction ; l’équipe de gestionde 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 desmé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.

Cet ouvrage fournit une référence de base pour toutes les personnes intéressées par la pro-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 lesprojets ;

■ 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 sesdétails. L’annexe E traite de l’extension des champs d’application, alors que l’annexe F proposeune 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 debase en matière de connaissances et méthodes de gestion de projet pour ses programmes dedé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érationsou 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 continueset répétitives, alors que les seconds sont temporaires et uniques. On peut donc définir unprojet par les caractéristiques distinctives suivantes : un projet est une entreprise temporairemise en œuvre en vue de créer un produit ou un service unique. Temporaire signifie que toutprojet 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 nombreusesorganisations, les projets sont un moyen de répondre aux demandes qui ne peuvent pas êtretraitées dans le fonctionnement normal de l’organisation.

Des projets sont entrepris à tous les niveaux d’une organisation. Ils peuvent occuper uneseule personne ou plusieurs milliers. Leur durée peut aller de quelques semaines à plus de cinqans. Les projets peuvent impliquer un seul service d’une entreprise ou dépasser les limites del’organisation, comme dans le cas de groupements d’entreprises et de partenariats. Ils sontessentiels à la réalisation de la stratégie de l’organisation maîtresse d’œuvre car ils constituentle 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 voiede 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© 2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA

Chapitre 1 — Introduction

4

1.2

|1.

2.3



1.2.1 TemporaireTemporaire signifie que tout projet a un début et une fin bien déterminés. La fin arrive lorsqueles objectifs du projet ont été atteints ou lorsqu’il devient évident que ces objectifs ne serontou 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 pasdes entreprises continues.

En outre, temporaire ne s’applique généralement pas au produit ou au service créé par leprojet. 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ésultatdurable. Par exemple, le projet de construction d’un monument national aboutira à un résultatqui, on l’espère, durera des siècles. Une série de projets et/ou des projets complémentairesmené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’unprojet est d’atteindre un but et de mettre un terme au projet. L’objectif d’une opération continuese 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 lesopé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 sontré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 uniqueLes 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 milliersd’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 sontfondamentalement 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éparationde 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 progressiveL’é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èresdu produit ou service doivent être élaborées progressivement. Progressivement signifie « pro-

céder par étapes ; continuer sans interruption par incréments », tandis qu’élaboré signifie « pré-paré soigneusement et dans les détails ; développé complètement » (1). Ces caractéristiquesparticulières seront définies dans leurs grandes lignes au tout début du projet et de façon plusexplicite et détaillée au fur et à mesure que l’équipe de projet acquerra une connaissance plusapprofondie 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é souscontrat. Une fois que le contenu du projet (le travail à réaliser) est correctement défini, il nedoit 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 etle contenu du projet.

Les deux exemples suivants illustrent cette élaboration progressive dans deux différentschamps d’application.

Exemple 1. La construction d’une usine de produits chimiques commence à l’ingénierie desprocédés pour définir les caractéristiques du processus. Ces caractéristiques sont utilisées pourconcevoir les principales unités de traitement. Ces informations deviennent la base des étudesde 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 tiredes plans détaillés conduisant aux plans de fabrication (isométriques de construction). Pendantla 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éepar des plans conformes à l’exécution. Durant les essais et la mise en service, l’élaboration descaractéristiques se poursuit souvent sous forme d’ultimes ajustements de fonctionnement.

Exemple 2. Le produit d’un projet de développement économique peut initialement êtredéfini comme suit : « Améliorer la qualité de vie des résidents aux revenus les plus faibles dela communauté X ». Au fur et à mesure que le projet avance, on peut décrire les produits plusspécifiquement comme, par exemple : « Offrir, dans la communauté X, l’accès à l’eau et à lanourriture à 500 résidents à faibles revenus ». L’étape suivante de l’élaboration progressive peutse concentrer exclusivement sur l’augmentation de la production agricole et du marketing, alorsque le ravitaillement en eau devient une priorité secondaire, et sera entrepris une fois que laré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éthodesaux activités d’un projet afin de répondre à ses besoins. La gestion de projet est accompliegrâce à l’utilisation de processus tels que le démarrage, la planification, l’exécution, le contrôleet la clôture. L’équipe de projet gère les travaux composant les projets, lesquels comprennenten 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, mieuxvous êtes capable de le gérer.

Le terme gestion de projet est parfois employé pour décrire une approche organisationnellede la gestion des opérations courantes. Cette approche, mieux définie par l’expression gestionpar projets, traite de nombreux aspects des opérations courantes comme des projets afin de



6

1.3

|1.

3.2

leur appliquer des méthodes de gestion de projet. Bien que la compréhension de la gestion deprojet soit essentielle pour une organisation qui gère par projets, l’étude détaillée de cetteapproche est hors du propos de cet ouvrage.

On peut organiser les connaissances en gestion de projet de différentes façons. Cet ouvragecomporte deux sections principales réparties sur douze chapitres, tel que décrit ci-dessous.

1.3.1 Le cadre de la gestion de projetLa section I, intitulée « Cadre de la gestion de projet », présente une base à la compréhensionde la gestion de projet.

Le chapitre 1, Introduction, définit les termes clés et offre une vue d’ensemble du restedu livre.

Le chapitre 2, Contexte de la gestion de projet, décrit l’environnement dans lequel lesprojets 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 projetLa 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 enneuf 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 pourassurer une bonne coordination des divers éléments du projet. Il comprend l’élaboration duplan 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, lavé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 assurerla 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’assurerque 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écessairespour 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



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 desrisques, 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. Cecicomprend la planification des approvisionnements, la planification des appels d’offres, lesappels d’offres, le choix des fournisseurs, l’administration et la clôture des contrats.



8

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

Figu

re 1

–1|

1.4

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, lePMBOK® 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 desressources 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émentsimportants du projet, mais qui ne sont pas nécessaires ou présentes dans tous les projets. Leschamps 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 servicesfinanciers.

L’annexe E traite plus en détail des champs d’application de la gestion de projet.



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

1.5 ACTIVITÉS CONNEXESCertains 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 programmecomprenant 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’enretirer des avantages que ne permettrait pas une gestion individuelle (2). De nombreux pro-grammes comprennent aussi des éléments appartenant à des opérations courantes. Parexemple :

■ 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 plusieurslancements sur une certaine période (opération continue).

Les programmes peuvent également comporter un certain nombre d’activités répétitives oucycliques, 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ésrégulièrement afin d’obtenir des subsides et comportant souvent une série de projets derecherche 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 projetsont 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écisde 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 à uneentreprise externe ou à un autre service fonctionnel de l’entreprise réalisatrice. Onpeut 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étencedes ressources humaines, tels que la plomberie ou l’installation électrique dans un projetde 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 del’organisation.



10

1.5

|2.

1.1


Chapitre 2

Contexte de la gestion deprojet

Les projets et la gestion de projet se déroulent dans un environnement plus vaste que celui duprojet lui-même. L’équipe de gestion de projet doit maîtriser ce contexte plus large. La gestionau jour le jour des activités du projet est nécessaire à sa réussite, mais n’est pas suffisante. Cechapitre décrit les aspects majeurs du contexte de la gestion de projet, qui ne sont pas traitésailleurs dans cet ouvrage. Les sujets abordés sont :2.1 Phases et cycle de vie du projet2.2 Acteurs du projet2.3 Influences organisationnelles2.4 Compétences majeures en gestion2.5 Influences socio-économiques et environnementales

2.1 PHASES ET CYCLE DE VIE DU PROJETLes projets étant des entreprises uniques, ils comportent un certain degré d’incertitude. Lesorganisations maîtresses d’œuvre les décomposent généralement en plusieurs phases de projetpour assurer une meilleure gestion et les relier à leurs opérations courantes. L’ensemble desphases du projet est appelé cycle de vie du projet.

2.1.1 Caractéristiques des phases du projetChaque 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équentles 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 revuedes principaux produits livrables et des performances du projet à ce jour, afin de a) décidersi 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 pointsde contrôle.

Chaque phase de projet comprend normalement une série de produits livrables précis,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 leurnom 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 projetLa 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 projetest viable. La définition du cycle de vie du projet déterminera si l’étude de faisabilité est traitéecomme 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 viedu 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 desbesoins à la conception, de la construction à l’exploitation ou des études à la fabrication. Lesproduits 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ésacceptables. Cette pratique de chevauchement des phases est souvent appelée construction enré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’architectefait-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 quidoivent 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 listesde 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é versla fin pour baisser rapidement au fur et à mesure que le projet arrive à son terme. Cemodè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 projetavec 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 projetest 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 deserreurs 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 bureaun’est qu’une phase ou étape du cycle de vie du produit.


Chapitre 2 — Contexte de la gestion de projet

12

2.1.

2|

2.1.

3

Bien que de nombreux cycles de vie de projet utilisent des noms de phases similaires, avecdes produits livrables demandés semblables, peu sont identiques. La plupart comportent quatreou 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 uneautre, 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 debureaux, 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êmedé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 phaseset 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 enphase de révision finale, avril 2000, décrit une série de jalons d’approvisionnement et dephases, comme illustré à la figure 2-2.

■ Développement conceptuel et technologique : études sur papier des différents conceptspossibles pour répondre aux besoins d’une mission ; développement de sous-systèmes/composants et démonstration de concept/technologie des concepts du nouveausystème. S’achève par le choix de l’architecture de système et de la technologie maturedevant être utilisées.

■ Développement et démonstration du système : intégration du système ; réduction desrisques ; démonstration des modèles d’études techniques ; développement et premier testopé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.



Figure 2-1 Exemple type de cycle de vie

■ 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, commeillustré à 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éveloppementd’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 lasé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émentairesdemandés pour l’examen de la demande d’homologation (NDA) par la fédération de lasanté publique américaine (FDA).



14

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

Figu

re 2

–2|

Figu

re 2

–3

Développement de logiciels. Il existe divers modèles de cycle de vie d’un logiciel, tels quele 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 lesobjectifs de premier niveau, faire l’étude logique du système, étudier et produire le premierniveau, 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 lesobjectifs du second niveau, réaliser l’étude physique, produire le second niveau, faire desplans 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 niveaufinal et effectuer les essais unitaires, de sous-systèmes, de système et de réception.



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

2.2 ACTEURS DU PROJETLes acteurs d’un projet sont les personnes et les sociétés activement impliquées dans le projetou dont les intérêts peuvent être affectés positivement ou négativement par l’exécution oul’achèvement du projet. Les acteurs peuvent aussi influencer le projet et ses résultats. L’équipede gestion de projet doit identifier les acteurs, déterminer leurs besoins, puis gérer et infléchirces 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’unnouveau 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. Plusieursniveaux 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 lasé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 commede 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 ouexterne à 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 etexternes, propriétaires et bailleurs de fonds, vendeurs et fournisseurs, membres de l’équipeet leurs familles, agences gouvernementales et réseaux de média, simples citoyens, groupesd’influence temporaires ou permanents, et la société dans son ensemble. Nommer ouregrouper les acteurs sert surtout à déterminer les personnes ou organisations se définissantcomme 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.



16

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

Figu

re 2

-4|

Figu

re 2

–5

Gérer les attentes des acteurs peut s’avérer difficile, parce qu’ils ont souvent desobjectifs divergents et parfois conflictuels. Par exemple :

■ Le chef de service qui a demandé un nouveau système d’information souhaite unprogramme bon marché, l’architecte du système vise l’excellence technique et lefournisseur chargé de la programmation cherche à optimiser ses bénéfices.



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

■ Le vice-président de la recherche d’une société d’électronique définira la réussite d’un nou-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 lapré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 minimiserles effets nuisibles sur l’environnement et les habitants du voisinage espéreront que leprojet se réalisera ailleurs.

En général, les divergences entre ou parmi les acteurs doivent être tranchées en faveur duclient. Ceci ne veut pourtant pas dire que les besoins et attentes des autres acteurs ne peuventou ne doivent pas être pris en compte. Trouver la solution appropriée à ces divergencesconstitue 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, agencesgouvernementales, 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 surpied. La maturité d’une organisation quant à ses systèmes de gestion de projet, sa culture, sonstyle, sa structure organisationnelle et sa fonction de gestion de projet peut également avoirune influence sur le projet. Les sections suivantes décrivent les aspects majeurs de ces grossesstructures organisationnelles importantes qui vont probablement influencer le projet.

2.3.1 Systèmes organisationnelsLes organisations basées sur les projets sont celles dont les opérations sont principalementconstitué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 lecompte 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 deprojet. Par exemple, leurs systèmes financiers sont souvent conçus spécifiquement pour lacomptabilité, 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, desystè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 organisationsgé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 degestion de projet devra alors peut-être prévoir des contrôles pour s’assurer que les membresdu personnel facturés sont réellement affectés au projet.



18

2.3

|2.

3.3

2.3.2 Cultures et styles organisationnelsLa plupart des organisations ont développé une culture propre. Cette culture se reflète dans lesvaleurs, normes, convictions et attentes que partagent leurs membres ; dans leurs règles et leursprocédures ; dans leur perception de la hiérarchie ; et dans bien d’autres facteurs. Les culturesorganisationnelles 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 chancesd’obtenir un accord dans une organisation agressive ou dynamique.

■ Un chef de projet au style très participatif rencontrera probablement des problèmes dansune organisation très hiérarchisée, alors qu’un chef de projet autoritaire aura tout autant deproblèmes dans une organisation participative.

2.3.3 Structure organisationnelleLa structure de l’entreprise maîtresse d’œuvre impose souvent des contraintes et des conditionsquant à la disponibilité des ressources. Les structures organisationnelles peuvent être caracté-risées par un éventail allant de fonctionnel à par projets, avec diverses structures matriciellesentre les deux. La figure 2-6 présente les caractéristiques principales liées au projet des typesde structures organisationnelles rencontrées dans les entreprises. L’organisation des projets esttraitée à la section 9.1, « Planification de l’organisation ».

L’organisation fonctionnelle classique, représentée à la figure 2-7, est une hiérarchie selonlaquelle chaque salarié a un supérieur clairement identifié. Les membres du personnel sontregroupés par spécialité, tels la production, le marketing, l’ingénierie et la comptabilité auniveau supérieur, l’ingénierie étant ensuite divisée en unités fonctionnelles qui recouvrent lesactivités de l’entreprise (par exemple, mécanique et électrique). Les organisations fonctionnellesré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



Figure 2-6 Influences des structures organisationnelles sur les projets

du service de fabrication ou de marketing. Par exemple, lors du développement d’un nouveauproduit dans une organisation purement fonctionnelle, la phase d’étude est souvent appeléeprojet d’étude et n’inclut que le personnel du service d’ingénierie. Si des questions se posentau sujet de la fabrication, elles sont transmises par la voie hiérarchique au chef de service quis’en entretient avec le chef du service de fabrication. Le chef du service technique communiquepar 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 figure2-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 etles 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 cesgroupes 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élangedes structures fonctionnelles et par projets. Les matrices faibles conservent de nombreusescaractéristiques des organisations fonctionnelles, et le rôle du chef de projet est plutôt celuid’un coordinateur ou agent d’ordonnancement que celui d’un directeur. De la même façon, lesmatrices fortes conservent de nombreuses caractéristiques des organisations par projets : chefsde 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 organisationsmodernes, 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 équipepré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 propresprocédures de fonctionnement et travaillant en marge du système hiérarchique officiel.



20

Figure 2-7 Organisation fonctionnelle

Figu

re 2

–7|

2.4

2.3.4 Cabinet de projetUn cabinet de projet remplit diverses fonctions. Il peut être en place en permanence et sesfonctions 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. Ellecomprend, entre autres :

■ Finances et comptabilité, ventes et marketing, recherche et développement, et fabricationet 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’espritd’é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 lechef 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 susceptiblesd’affecter un projet et qui ne seront pas traitées ailleurs dans cet ouvrage. La documentation



Figure 2-8 Organisation par projets



22

Figure 2-9 Structure matricielle faible

Figure 2-10 Structure matricielle équilibrée

Figu

re 2

–9|

Figu

re 2

–12



Figure 2-11 Structure matricielle forte

Figure 2-12 Structure mixte

qui traite de la gestion définit bien ces compétences d’ordre général, que l’on applique fon-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 danscertains projets ou champs d’application. Par exemple, la sécurité des membres de l’équipe estessentielle dans tous les projets de construction, mais elle compte très peu dans les projets dedéveloppement de logiciels.

2.4.1 Aptitude à dirigerKotter (4) fait la distinction entre diriger et gérer, tout en insistant sur la nécessité de l’un et del’autre : il est probable que l’un ne peut fonctionner sans l’autre si l’on veut obtenir de bonsré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égiespour 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 dontla coopération est nécessaire à sa réalisation ;

■ motiver et inspirer : aider les intervenants à trouver en eux-mêmes l’énergie pour surmonterles obstacles politiques, bureaucratiques et matériels au changement.

Dans un projet, surtout de grande envergure, on attend généralement du chef de projetqu’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 CommunicationLa 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 puisseles recevoir correctement. Ce dernier a la responsabilité de s’assurer qu’il a bien reçu toutes lesinformations 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 avecune entreprise partenaire).

Les compétences en gestion dans le domaine de la communication s’apparentent, mais nesont pas identiques, à la gestion des communications du projet (décrite au chapitre 10). Lacommunication 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 etdue forme, etc. ;



24

2.4.

1|

2.4.

5

■ 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 auxbesoins 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égociationLa 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érentsniveaux du projet. Au cours d’un projet typique, l’équipe du projet est susceptible de négociersur 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èmesLa 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. Lesproblè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 estretardée). Les problèmes peuvent être d’ordre technique (différences d’opinion quant à lameilleure 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 destyles).

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’organisationInfluencer l’organisation consiste à « s’assurer que les choses sont faites ». Cela demande quel’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.



Les termes « pouvoir » et « politique » sont employés ici dans un sens positif. Pfeffer (5)définit le pouvoir comme « la capacité potentielle d’influer sur les comportements, de changerle cours des événements, de vaincre les résistances et d’amener les intervenants à faire deschoses 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 avoirdes intérêts tout à fait différents. Elle traite de la volonté d’utiliser de façon créative les conflitset 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 ENVIRONNEMENTALESComme en gestion, les influences socio-économiques comportent un grand nombre de sujetset de problèmes. L’équipe de gestion de projet doit comprendre que les conditions du momentet 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 desbouleversements 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églementationsL’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 uneutilisation généralisée et répétée, des règles, des directives ou des caractéristiques pour desproduits, des processus ou des services, et dont l’application n’est pas obligatoire ». Il existede nombreuses normes en usage, qui régissent tout, de la stabilité thermique des liquideshydrauliques à 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 deréglementation.

Il faut être prudent lorsque l’on parle de normes et de réglementations, car la distinctionentre 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 sontadopté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 gestiondu 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, leurinfluence est inconnue ou incertaine et doit faire partie de la gestion des risques du projet(décrite au chapitre 11).



26

2.5

|2.

5.4

2.5.2 InternationalisationDe 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élaiset 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 denombreux conflits.

2.5.3 Influences culturellesLa 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 lasocié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, quiaffectent les relations entre les personnes et les organisations.

2.5.4 Durabilité socio-économique et environnementalePresque 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. Lesorganisations sont de plus en plus tenues pour responsables de l’impact d’un projet (parexemple, 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 cebien après l’achèvement de celui-ci (par exemple, une route peut faciliter l’accès à une zoneinhabitée, mais aussi faciliter sa destruction).




Chapitre 3

Processus de la gestion deprojet

La gestion de projet est un effort intégratif, c’est-à-dire qu’une action ou le manque d’actiondans un domaine a généralement des répercussions dans d’autres domaines. Les interactionspeuvent ê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 lesdifférents objectifs du projet ; les performances dans un domaine ne peuvent être amélioréesqu’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 projetpasse par la gestion active de ces interactions. De nombreux professionnels de la gestion deprojet qualifient la triple contrainte d’un projet de « structure servant à évaluer les demandesconcurrentes ». La triple contrainte d’un projet est souvent illustrée par un triangle dont lescô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’importancede cette intégration, cet ouvrage décrit la gestion de projet selon ses processus constitutifs etleurs interactions. Ce chapitre fournit une introduction au concept de gestion de projet en tantqu’ensemble de processus liés et donne donc les bases nécessaires à la compréhension desdescriptions de processus proposées dans les chapitres 4 à 12. Il comprend les sections prin-cipales suivantes :3.1 Processus du projet3.2 Groupes de processus3.3 Interactions entre processus3.4 Personnalisation des interactions entre processus3.5 Représentation des processus de gestion de projet

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

■ Les processus de gestion de projet décrivent, organisent et réalisent les travaux du projet. Lesprocessus applicables à la majorité des projets, la plupart du temps, sont décrits brièvementdans 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é à lasection 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 duprojet sans une connaissance minimale des modalités de réalisation du produit.

3.2 GROUPES DE PROCESSUSLes processus de gestion de projet peuvent être classés en cinq groupes comprenant chacunun 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 meilleureligne 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 deré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 etl’amener à une fin ordonnée.

Les groupes de processus sont reliés par les résultats qu’ils produisent, les résultats de l’undevenant 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. Cesliens sont illustrés à la figure 3-1. De plus, les groupes de processus de gestion de projet nesont pas des événements discrets et uniques ; ce sont des activités qui se chevauchent avecplus 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. Lesdonnées de clôture d’une phase fournissent les données d’entrée de la phase suivante. Parexemple, la clôture d’une phase de conception nécessite l’acceptation des documents deconception par le client. En même temps, ces documents de conception forment la descriptiondu 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 leprojet sur les besoins qu’il est censé satisfaire. Ceci doit également permettre d’arrêter le projetsi 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 phaseset 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-


Chapitre 3 — Processus de la gestion de projet

30

3.2

|Fi

gure

3–3



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

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 unprocessus itératif et continu.

L’implication des acteurs dans les phases du projet augmente les chances de satisfaction desbesoins du client, et entraîne un engagement, ou partage de la propriété du projet, de cesacteurs 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 parleurs données d’entrée et de sortie. En se concentrant sur ces liens, on peut décrire chaqueprocessus 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éesde 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 deschamps 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 interactionsentre processus illustrées ci-dessous sont également communes à la plupart des projets et deschamps d’application. La section 3.4 traite de la personnalisation des descriptions des processuset de leurs interactions.

3.3.1 Processus de démarrageLa 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 planificationLa planification est d’une importance capitale pour le projet, car il s’agit de réaliser une actionnouvelle. De ce fait, cette section comporte davantage de processus. Le nombre de processusne 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.



32

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

Figu

re 3

–4|

Figu

re 3

–5

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 defin 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 desautres, ils doivent donc être exécutés essentiellement dans le même ordre dans la plupart desprojets. Par exemple, il faut identifier les activités avant de les planifier ou d’en estimer lescoûts. Ces processus principaux de planification peuvent être répétés plusieurs fois au coursd’une même phase de projet. Ils comprennent :



Figure 3-5 Relations entre les processus de planification

■ la planification du contenu (5.2) : élaborer un énoncé du contenu par écrit comme base desdé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 pourla 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 ressourcesné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 deplanification et en tirer un document logique et cohérent.

Processus de support. Les interactions entre les autres processus de planification dépendentdavantage de la nature du projet. Par exemple dans certains projets, il peut être totalementou 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ûtet 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 sontpas pour autant facultatifs. Ils comprennent :

■ la planification de la qualité (8.1) : identifier les normes de qualité applicables au projetet 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écessairessoient 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 quelleforme ;

■ 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, etestimer 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éthodespour améliorer les opportunités et atténuer les menaces pouvant avoir un impact sur lesobjectifs du projet.



34

3.3.

2|

3.3.

3

■ la planification des approvisionnements (12.1) : déterminer ce que l’on doit acheter, enquelle 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éalisationLes 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 desgroupes, afin d’améliorer les performances du projet ;

■ la diffusion de l’information (10.2) : mettre les informations nécessaires à la disposition desacteurs, 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.



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

3.3.4 Processus de contrôleLes performances du projet doivent être examinées et mesurées régulièrement, afin d’identifierles écarts par rapport au plan. Ces écarts alimentent les processus de contrôle dans les diversesdisciplines. 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éajustementsdu plan des ressources humaines, des heures supplémentaires ou des compromis entre lesobjectifs 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 processusde 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 duprojet ;

■ 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 aucontenu 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 deperformances insuffisantes ;

■ les rapports d’avancement (10.3) : rassembler et diffuser les informations concernant lesperformances. Ceci comprend les rapports de situation, la mesure de l’avancement et lesprévisions ;



36

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

Figu

re 3

–7|

3.4

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

3.3.5 Processus de clôtureLa 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 listedes « leçons retenues » pouvant être utilisée au cours de la planification de projets ou dephases à venir.

3.4 PERSONNALISATION DES INTERACTIONS ENTRE PROCESSUSLes 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 à tousles 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écriredans 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 deprojet 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ésavant 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 laissercette tâche au processus de planification. Une date de fin de projet imposée peut entraînerdes 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 lescoû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,



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

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

3.5 MATRICE DE PRÉSENTATION DES PROCESSUS DEGESTION DE PROJETLa figure 3-9 est une matrice décrivant les trente-neuf processus de gestion de projet, répartisentre les cinq groupes de processus appelés démarrage, planification, réalisation, contrôle etclô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 processusde gestion de projet, à la fois dans les groupes de processus et les disciplines.



38

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

Figu

re 3

–9|

Sec

tion

II

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 duprojet

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 desobjectifs concurrents et divers choix possibles, afin de répondre aux besoins et aux attentes desacteurs, ou même de les dépasser. Bien que tous les processus de gestion de projet soient plusou moins intégratifs, ceux décrits dans ce chapitre le sont par essence. La figure 4-1 offre unevue 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 plusieursgroupes, selon les besoins du projet. Habituellement, tous les processus sont exécutés aumoins 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 nondé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 lorsde 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 dansd’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 performancesdu projet au fur et à mesure de son avancement (du démarrage à l’achèvement), est la gestionde 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


Chapitre 4 — Gestion de l’intégration du projet

42

acquise (VA) sera traitée dans d’autres chapitres en tant qu’outil de mesure des performancespar rapport au plan du projet.

Les logiciels de gestion de projet sont des outils qui facilitent l’intégration au sein d’unprojet. Ils peuvent couvrir tous les processus de gestion de projet.

4.1 ÉLABORATION DU PLAN DE PROJETL’é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 habituellementrépété plusieurs fois. Par exemple, la première version peut inclure des besoins généraux enressources et une succession d’activités sans date, alors que les versions suivantes du planseront 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 deplans 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ôlede gestion intégré constitue alors le contenu de tout le projet.

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

Figu

re 4

–1|

4.1.

1.5

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 etde 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éepour 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 desautres 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 etpour 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 donton doit habituellement tenir compte incluent entre autres :

■ la gestion de la qualité : vérification (audit) des processus, objectifs d’améliorationcontinue ;

■ la gestion du personnel : règles d’embauche et de licenciement, entretiens d’évaluation desperformances 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 probablementlimitera les options de l’équipe quant au contenu, aux ressources humaines et au planning. Engénéral, lorsqu’un projet est réalisé sous contrat, les conditions contractuelles sont descontraintes.

.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 projetdéterminent, documentent et confirment les hypothèses lors du processus de planification. Par





44

exemple, si la date de disponibilité d’une personne clé est incertaine, l’équipe peut avancerune date particulière hypothétique. Les hypothèses comportent en général un certain degré derisque.

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 (sursupport papier ou informatique, formel ou non) ou sous une forme plus complexe d’une sériede simulations requises (par exemple, l’analyse des risques impactant les délais par la méthodede 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 descompé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 auplan 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 lescoû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 intervenantpeut contribuer de manière significative au non-dépassement des objectifs de coût et dedé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 degestion 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 duprojet, 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 planninget des ressources servant à mesurer et à rendre compte des performances d’un projet, de sondé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 duprojet 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 seraprobablement modifié au fur et à mesure de la disponibilité des informations concernant leprojet. 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 produitlivrable.

4.1.

2|

4.1.

3.2



Il existe différentes façons d’organiser et de présenter le plan de projet, mais ce derniercomprend habituellement tous les éléments suivants (décrits plus en détail dans une autrepartie 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 degestion 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 desresponsabilité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 lesdé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 contrainteset les hypothèses), ainsi que les réponses et les provisions (le cas échéant) prévues pourchacun 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 inclusesdans 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 utilisationdans la réalisation du projet.

4.2 MISE EN ŒUVRE DU PLAN DE PROJETLa 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 decette étape, le chef de projet et l’équipe de gestion du projet doivent coordonner et dirigerles 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 effectivementcréé. 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 soutenirl’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 deprojet.

.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 avoirun 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 deprojet. 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 à unegestion 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 uneconnaissance du produit et les compétences requises adéquates. Ces compétences requisessont 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).



46

4.2

|4.

3



.3 Système d’autorisation de travail. Procédure formelle par laquelle on approuve le travail, afinqu’il soit exécuté au bon moment et dans le bon ordre. Habituellement, le mécanisme principalest 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 lavaleur 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 toutesles 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 livrablesqui 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 lasection 10.3 qui traite plus en détail des rapports d’avancement). Il faut noter que, bien que lesrésultats soient fréquemment des produits livrables tangibles, tels que des immeubles, desroutes 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 ouré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 enles 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 dansla définition du contenu du projet. (L’introduction du chapitre 5 traite de la différence entrele 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, lesrisques, la qualité et les ressources humaines.


Capítulo 4 — Gestión de la Integración del Proyecto

48

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 desinformations sur les performances du projet. Ils peuvent aussi attirer l’attention de l’équipe deprojet 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 obligatoireslé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 performancesdu projet seront suivies et évaluées ; il comporte les dispositions selon lesquelles les documentsofficiels du projet peuvent être modifiés. Il comprend les documents, les systèmes de suivi, lesprocessus et les niveaux d’approbation nécessaires à l’autorisation des changements.

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

4.3.

1|

4.3.

3.3



Dans de nombreux cas, l’entreprise maîtresse d’œuvre dispose d’un système de contrôledes changements qui peut être adopté « tel quel », et être utilisé dans le projet. Toutefois, siaucun système adéquat n’est disponible, l’équipe de gestion de projet devra en élaborer undans 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 changementset sont acceptés par tous les acteurs majeurs. Les organisations varient selon la définition ducomité ; 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 suivitechnique (TRB en anglais), des commissions d’évaluation technique (TAB en anglais) et biend’autres types. Le système de contrôle des changements doit aussi comporter des procéduresde mise en œuvre des changements pouvant être approuvés sans évaluation préalable, parexemple, 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 derniersdoivent tout de même être répertoriés et documentés, afin que l’évolution de la référencepuisse ê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émentou 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 auxbesoins.

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 duproduit 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 (valeuracquise, décrite à la section 10.3.2.4) permettent d’évaluer si les écarts par rapport au planné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 diversesré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). Lecas é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 queles autres types de leçons retenues doivent être documentés et intégrés à la base de donnéesd’historique du projet et des autres projets de l’entreprise maîtresse d’œuvre. Cette base dedonnées est également le point de départ de la gestion du capital intellectuel.


Chapitre 5

Gestion du contenu du projet

La gestion du contenu du projet comprend les processus nécessaires pour s’assurer que leprojet contient toutes les activités nécessaires à sa réalisation, et uniquement celles-ci, demanière à s’assurer de sa réussite (1). Ceci implique principalement de définir et de contrôlerce 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 plusieursgroupes, selon les besoins du projet. Habituellement, tous les processus sont exécutés aumoins une fois au cours de chaque phase du projet.


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 dece chapitre. Ceux utilisés pour gérer les spécifications du produit varient selon le domained’application et sont habituellement définis dans le cadre du cycle de vie du projet (le cycle devie du projet est traité à la section 2.1).

Un projet aboutit généralement à un produit unique, mais ce produit peut comporter descomposants annexes, lesquels comportent leurs propres spécifications de produit, distinctesbien 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 letravail accompli dans le cadre du projet aboutit à la livraison du produit spécifié.



Chapitre 5 — Gestion du contenu du projet

52

|Fi

gure

5–1

|5.

1.1.

1

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



5.1 DÉMARRAGELe démarrage est le processus par lequel on lance officiellement un nouveau projet ou quiautorise officiellement, dans un projet, le passage à la phase suivante (voir la section 2.1 pourplus 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 nedé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 denouveaux produits, commencent sans autorisation officielle et seules quelques actions limitéessont menées pour obtenir les approbations nécessaires à un démarrage officiel. Les projets sonthabituellement adoptés officiellement suite à un ou plusieurs des faits suivants :

■ une demande du marché (par exemple, un constructeur automobile adopte un projet deconstruction 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éationd’un nouveau cours pour augmenter ses revenus) ;

■ une demande de la clientèle (par exemple, une compagnie d’électricité adopte le projet deconstruction 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 nouveauprojet de développement d’un jeu vidéo, rendu possible par les progrès accomplis enmatière de mémoire informatique) ;

■ une exigence juridique (par exemple, un fabricant de peintures adopte un nouveau projetpour 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 voiede développement adopte un nouveau projet pour desservir en eau potable et en sanitairesdes 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 oudes nécessités commerciales. Le point commun à tous ces termes est que la direction doit engé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 dedé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 serviceen 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 duprojet.

De nombreux projets impliquent une organisation (le vendeur) réalisant le travail en vertud’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éfinisen 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érieursainsi que de celles concernant les performances de ces projets doit être pris en compte s’il estdisponible. Lorsque le démarrage concerne l’acceptation d’une nouvelle phase d’un projet, lesinformations 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ésdans une fonction de valeur unique), ainsi qu’un mode de calcul de la valeur tenant comptedes incertitudes existantes. Ceux-ci sont appelés modèle décisionnel et méthode de calcul. Lasélection de projet s’applique également au choix des différentes modalités d’exécution decelui-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 algorithmesde 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é, entreautres), ainsi que des techniques spécialisées (processus d’analyse hiérarchique, analyse ducadre logique, entre autres). L’utilisation de critères complexes de sélection de projet dans unmodè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 peutl’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é à unniveau 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.



54

5.1.

1.2

|5.

2.1.

4



Lorsqu’un projet est réalisé sous contrat, le contrat signé fait en général office de charte duprojet 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 deprojet (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 deprojet. Par exemple, un budget prédéfini est une contrainte qui très probablement limitera lesoptions 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éralementdes contraintes. Un autre exemple est la nécessité d’avoir un produit viable des points de vuesocial, économique et environnemental, ce qui se répercutera également sur le contenu, lesressources humaines et les délais de réalisation du projet.

.4 Hypothèses. Voir la section 4.1.1.5.

5.2 PLANIFICATION DU CONTENULa 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 pourrésultat le produit du projet. La planification du contenu du projet commence par les donnéesd’entrée de départ de la description du produit, la charte du projet et la définition initiale descontraintes 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 laconception 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 lesinformations détaillées correspondantes. Le cahier des charges constitue la base de l’accordentre le projet et le client du projet, car il identifie à la fois les objectifs et les produits livrablesdu projet. Les équipes de projet élaborent de nombreux cahiers des charges selon le niveau dedé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.




56

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’analysefonctionnelle 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 derécupération (« payback period » en anglais), pour évaluer l’intérêt relatif des différentesvariantes étudiées.

.3 Identification des variantes. Il s’agit d’un terme global désignant les techniques utilisées pourdé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 raisonnementparallè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 descriptiondu 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 produitslivrables 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 exclusionsdoivent être précisées ; en règle générale, tout ce qui n’est pas explicitement inclus estimplicitement exclu.

■ les objectifs du projet : critères quantifiables devant être satisfaits pour réussir le projet. Lesobjectifs 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 de1,5 million). Les objectifs non quantifiés (par exemple, « satisfaction du client ») signifientun 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 descharges doivent être documentées et organisées de manière à faciliter leur utilisation par lesautres processus de gestion du projet. Elles doivent toujours définir toutes les contraintes ethypothè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 quellefré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 duproduit sont en cours d’élaboration.)

5.2.

2|

5.3.

2.1



Selon les besoins du projet, le plan de gestion du contenu peut être formel ou non, trèsdé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 CONTENULa 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émentsplus 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 contenuest mal défini, on peut s’attendre à des coûts plus élevés, des modifications inévitables venantperturber le rythme du projet, entraîner des reprises, allonger les délais, diminuer la productivitéet saper le moral du personnel » (3).

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é souscontrat, les contraintes fixées par les dispositions contractuelles sont souvent un facteur impor-tant à prendre en compte lors de la définition du contenu.


.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 duprojet.

.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. Chaqueprojet 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 pourchaque phase.

Données d'entrée

.1 Cahier des charges

.2 Contraintes

.3 Hypothèses

.4 Autres données de sortie de la planification.5 Données historiques

Outils et méthodes

.1 Modèles d'organigramme des tâches.2 Décomposition

Données de sortie

.1 Organigramme des tâches.2 Mises à jour du cahier des charges



58

De nombreux champs d’application ou organisations maîtresses d’œuvre possèdent des OTstandard ou plus ou moins standard, pouvant servir de modèles. Par exemple, le ministère dela 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 ousous-produits livrables du projet en éléments plus petits et faciles à gérer, jusqu’à les détaillersuffisamment 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 duprojet. 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 figure5-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 à ceniveau de détail pour chaque produit livrable. Le sens du terme adéquat peut évoluer au coursdu projet ; la décomposition d’un produit livrable, devant être réalisée beaucoup plus tard, peuts’avérer impossible. Pour chaque produit livrable, on passera à l’étape 4 si l’obtention de détailsadéquats est possible, sinon on passera à l’étape 3. Des produits livrables différents peuventdonc avoir des niveaux de découpage divers.

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

Figu

re 5

–2|

5.3.

3.1



(3) identifier les éléments constituant le produit livrable. Ceux-ci devraient être décrits entermes de résultats tangibles et vérifiables pour faciliter la mesure des performances. Commepour 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’avancementpeut ê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éaliserl’é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 descriptionsdoivent ê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écessairespour 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

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



60

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 produitslivrables 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 constituepas un OT.

En général, on attribue un identifiant unique à chaque élément de l’OT ; ces identifiantspeuvent 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 travauxpeuvent à 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

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

Figu

re 5

–4|

5.4



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 et6.1.2.1.

Les descriptions des activités élémentaires sont souvent regroupées dans un dictionnairede l’OT. En général, celui-ci comprend la description des lots de travaux, ainsi que d’autresinformations relatives à la planification, telles que les dates prévues, les coûts budgétés etl’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 renduque 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-assemblageset 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 aucahier des charges (décrites à la section 5.2.3.1). Le cas échéant, il faut avertir les acteursconcernés de ces mises à jour.

5.4 VÉRIFICATION DU CONTENULa vérification du contenu est le processus qui permet d’obtenir l’adoption officielle du contenudu projet par les acteurs (commanditaire, client, etc.). Elle nécessite d’examiner les produitslivrables et le travail accompli, afin de s’assurer qu’ils ont été correctement réalisés. Si l’on metfin au projet prématurément, le processus de vérification du contenu doit établir et documenterle niveau et le degré d’achèvement du projet. La vérification du contenu est différente ducontrô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’acceptationet la conformité soient obtenues au même moment.



62

5.4.1 Données d’entrée de la vérification du contenu.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 deprojet (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 letravail 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 êtrevé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 inspectionssont é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’unephase.

5.5 CONTRÔLE DES CHANGEMENTS DU CONTENULe contrôle des changements du contenu consiste à : a) influencer les facteurs entraînant desmodifications 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 autresprocessus de contrôle (contrôle du planning, contrôle des coûts, contrôle de la qualité etautres, tels que traités à la section 4.3).

5.4.

1|

5.5.

3.1



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, fournissentdes informations sur les performances du contenu (par exemple, quels sont les produitslivrables intermédiaires achevés et ceux qui ne le sont pas encore). Les rapports d’avancementpeuvent 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, oublierd’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 enmesure de réduire les coûts en tirant parti d’une technologie qui n’était pas disponible lorsde 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 comprendles documents, les systèmes de suivi et les niveaux d’autorisation nécessaires à l’autorisationdes modifications. Le système de contrôle des changements du contenu doit être inclus dansle 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é souscontrat, 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 section10.3.2, permettent d’évaluer l’ampleur des écarts effectifs. Rechercher l’origine des écarts de laréférence de base et décider si ces écarts nécessitent une action corrective sont des opérationsessentielles du contrôle des changements du contenu.

.3 Planification complémentaire. Les projets se déroulent rarement selon le programme prévu. Leschangements de contenu éventuels peuvent nécessiter la révision de l’OT ou l’analyse desvariantes (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 souventun 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 sontavertis.

.2 Action corrective. Toute action visant à réaligner sur le plan de projet les performances futuresprévues.

.3 Leçons retenues. La cause des écarts, le raisonnement utilisé pour choisir les actions correc-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 ainsique 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érencecorrespondant 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.



64

5.5.

3.2

|6.

1


Chapitre 6

Gestion des délais du projet

La gestion des délais du projet comprend les processus nécessaires à l’achèvement du projeten 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. Chaqueprocessus peut nécessiter la participation d’une ou plusieurs personnes ou d’un ou plusieursgroupes, selon les besoins du projet. Habituellement, tous les processus sont exécutés aumoins une fois au cours de chaque phase du projet.


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 sontconsidérés comme un processus unique (par exemple, ils peuvent être réalisés par une seulepersonne 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ÉSLa 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’organigrammedes tâches (OT). Dans ce processus, la nécessité de définir les activités du projet de tellemanière que les objectifs de celui-ci soient atteints est implicite.


Chapitre 6 — Gestion des délais du projet

66


Figu

re 6

–1|

6.1.

3.1

Figure 6-1 Vue d’ensemble de la 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 chargesdoivent être pris en compte explicitement pour la définition des activités (voir la section5.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éfinitiondes activités du projet.

.4 Contraintes. Les contraintes sont des facteurs limitant les options de l’équipe de gestion deprojet ; par exemple, l’utilisation de durées maximales souhaitées pour les activités.


.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érerafin d’arriver à un meilleur niveau de contrôle. La méthode de décomposition est décrite avecplus de détails à la section 5.3.2.2. La principale différence entre le découpage utilisé ici etcelui décrit dans le processus de définition du contenu est qu’ici le résultat est exprimé entermes 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 finaledes activités. Dans certains champs d’application, l’OT et la liste des activités sont crééessimultanément.

.2 Modèles et formulaires. Une liste d’activités (décrite à la section 6.1.3.1), ou une partie dela 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, lesproduits 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-



68

plète et ne comprend pas d’activités ne faisant pas partie du contenu du projet. Comme pourl’OT, la liste des activités doit inclure la description de chacune des activités pour permettreaux 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’autresprocessus de la gestion de projet. Elles doivent toujours inclure les informations concernanttoutes les contraintes et hypothèses identifiées. La quantité d’informations détaillées utiliséespeut 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 desactivités requises, l’équipe de projet constate qu’il manque des produits livrables ou que ladescription 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 descoûts. Ces mises à jour sont souvent appelées perfectionnements ; elles surviennent en générallorsque le projet comporte des technologies nouvelles ou émergentes.

6.2 JALONNEMENT DES ACTIVITÉSLe jalonnement des activités consiste à identifier et à documenter les interactions logiquesentre les activités. L’ordre dans lequel les activités seront réalisées doit être établi avec soinpour que l’on puisse par la suite préparer un planning réaliste. Le jalonnement peut êtreeffectué à l’aide d’outils informatiques (par exemple, à l’aide d’un logiciel en gestion deprojet) ou manuellement. Les méthodes manuelles sont souvent plus efficaces pour les petitsprojets et dans les phases initiales des grands projets lorsque l’on ne dispose que de peu dedé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, leplan d’une usine à construire, l’interface des sous-systèmes d’un projet de développementlogiciel). Bien que cet impact soit souvent apparent dans la liste des activités, la descriptiondu 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, ilest impossible d’ériger la superstructure avant que les fondations ne soient terminées ; dansun projet d’électronique, on doit construire un prototype avant de pouvoir le tester.) Lesdépendances logiques obligatoires sont aussi appelées liaisons logiques fortes.

6.1.

3.2

|6.

2.2.

1



.4 Dépendances logiques optionnelles. Il s’agit de dépendances logiques fixées par l’équipe deprojet. Il faut les utiliser avec précaution (et bien les documenter) car elles peuvent limiter lesoptions futures de planification. Les dépendances logiques optionnelles sont habituellementfixé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ésdu 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 dansun projet de construction, des consultations sur l’environnement doivent être menées avantde démarrer la préparation du site.

.6 Étapes jalons. Les étapes jalons doivent faire partie du jalonnement des activités pour assurerque 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éespar des flèches représentant les dépendances logiques (voir également la section 6.2.3.1). Lafigure 6-2 représente un diagramme de projet simple selon la méthode PDM. Cette techniqueest aussi appelée activités sur nœuds (AON en anglais) ; il s’agit de la méthode utilisée parla plupart des logiciels de gestion de projet. La méthode PDM peut être mise en œuvremanuellement 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 pluscouramment utilisé. Les liaisons Début-Fin sont rarement utilisées et uniquement par certainsprofessionnels de la planification. L’utilisation des liaisons logiques Début-Début, Fin-Fin ouDébut-Fin avec des logiciels de gestion de projet peut produire des résultats inattendus, cestypes de liaisons n’ayant pas été mis en œuvre de façon cohérente.

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



70

.2 Méthode du diagramme fléché (ADM en anglais). Méthode de représentation du projet danslaquelle les activités sont identifiées par des flèches reliées entre elles par des points appelésnœuds représentant les liaisons logiques (voir également la section 6.2.3.1). La figure 6-3représente un diagramme réseau simple selon la méthode ADM. Cette technique est aussiappelée activités sur flèches (AOA en anglais) et, bien qu’elle soit moins répandue que laméthode PDM, elle reste la méthode de prédilection dans certains champs d’application. Lamé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. Lamé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 » enanglais) permettent la modélisation d’activités qui ne se suivent pas, telles que les boucles (parexemple, un test que l’on doit faire plusieurs fois), ou de ramifications conditionnelles (parexemple, la mise à jour d’une tâche de conception qui n’est nécessaire que si l’inspection adécelé des erreurs). Ni la méthode des antécédents (PDM), ni la méthode du diagrammeflé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’unprojet ou seulement une partie de celui-ci. Une partie d’un réseau est souvent désignée parle terme sous-réseau. Les sous-réseaux sont particulièrement utiles lorsqu’un projet comprendplusieurs fonctions identiques ou quasiment identiques, telles que les différents étages d’unimmeuble de bureaux, les essais cliniques d’un projet pharmaceutique, les modules logicielsd’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épendanceslogiques). Les figures 6-2 et 6-3 illustrent deux approches différentes de représentation d’undiagramme réseau. Le diagramme réseau du projet peut être développé manuellement ou surordinateur. Il peut comporter tous les détails du projet ou seulement un ou plusieurs groupesd’activités. Le réseau doit toujours être accompagné d’une description sommaire de l’approchede 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).

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

Figu

re 6

–3|

6.3.

1.4



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

6.3 ESTIMATION DE LA DURÉE DES ACTIVITÉSL’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 habituellementde 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 dela 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 legroupe de l’équipe projet spécialiste du type d’activité envisagé doit effectuer l’estimation, oudu 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, sila durée de durcissement du béton est de quatre jours, il faudra compter entre deux à quatreunités de temps ouvré : a) selon le jour de la semaine de début de l’activité et b) selon queles 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érentesunités de temps ouvré.

La durée totale du projet peut être également estimée à l’aide des outils et des méthodesprésentés ici, mais celle-ci est calculée de manière plus précise en tant que donnée de sortiede l’élaboration du planning (décrite à la section 6.4). L’équipe projet peut considérer que laduré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).

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 lafréquence des révisions de projet qui pourrait dicter la durée maximale des activités, parexemple 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éede la plupart des activités dépend en grande partie des ressources qui leur sont affectées. Parexemple, deux personnes travaillant ensemble peuvent terminer la conception d’un produit

Données d'entrée

.1 Liste des activités

.2 Contraintes

.3 Hypothèses

.4 Besoins en ressources

.5 Disponibilités des ressources.6 Données historiques.7 Risques identifiés

Outils et méthodes

.1 Avis d'expert

.2 Estimation par analogie

.3 Durées sur base quantitative.4 Réserve de durée (contingence)

Données de sortie

.1 Estimation de la durée des activités.2 Bases d'estimation.3 Mises à jour de la liste des activités



72

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 peutrencontrer des problèmes de surcharge au niveau de la communication, ce qui diminue laproductivité 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 aptitudesdes ressources matérielles et humaines qui leur sont affectées. Par exemple, si deux membresde 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 nombreuxtypes d’activités proviennent souvent de l’une des sources suivantes :

■ dossiers de projet : une ou plusieurs organisations impliquées dans le projet peuvent avoirconservé 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 del’é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 sontsouvent disponibles commercialement. Ces bases de données sont particulièrement utileslorsque 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 typesde demandes) ;

■ expérience de l’équipe de projet : les membres de l’équipe de projet peuvent se rappelerdes durées réelles ou estimées de projets précédents. Bien que de tels souvenirs soientutiles, 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 desmenaces ou des opportunités) pouvant avoir un impact considérable sur les durées. L’équipede projet tient compte de l’importance accordée à l’impact des risques dans l’estimation de ladurée de référence pour chaque activité, en prenant en compte les risques à probabilité forteet à 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, niveauet 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 desrisques du projet »).

.2 Estimation par analogie. Également appelée estimation descendante, l’estimation par analogieutilise la durée réelle d’une activité semblable effectuée par le passé comme base d’estimationd’une activité future. On l’utilise fréquemment pour estimer la durée d’un projet lorsqu’ilexiste 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’estimationont l’expérience nécessaire.

6.3.

1.5

|6.

4



.3 Durées sur base quantitative. On peut utiliser les quantités à réaliser pour chaque catégoriespé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 estimerla durée des activités.

.4 Réserve de durée (contingence). Les équipes de projet peuvent choisir d’inclure une duréesupplé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. Cetteréserve peut être un pourcentage de la durée estimée ou un nombre fixe d’unités de tempsouvré. 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’uneactivité.

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 pasplus 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é, 85pour 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 desincertitudes.

.2 Bases d’estimation. Les hypothèses émises lors de l’élaboration des estimations doivent êtredocumenté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 cesdates ne sont pas réalistes, il est alors peu probable que le projet sera terminé à la dateprévue. Le processus d’élaboration du planning doit être répété fréquemment (de même queles 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.



74

6.4.1 Données d’entrée pour l’élaboration du planning.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 savoirquelles ressources seront disponibles, à quel moment et sous quelle forme. Par exemple, ilest parfois difficile de planifier des ressources partagées ou clés, leur disponibilité pouvantvarier ; le niveau de détail et de précision de la description des disponibilités des ressourcesvarieront é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 (parexemple, 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 cinqjours est un exemple d’utilisation de calendrier. Les calendriers des ressources affectent uneressource ou une catégorie de ressources particulière (par exemple, un membre de l’équipepeut ê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. Lorsde l’élaboration du planning, deux contraintes de temps principales doivent être prises encompte :

■ 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 datedonnée. Bien que les quatre contraintes de date soient habituellement disponibles dansles logiciels de gestion de projet, les contraintes « démarrer au plus tôt le » et « finir au plustard le » sont les plus couramment utilisées. Habituellement, on utilise les contraintes dedate 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érielen 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 jalonsassocié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 uneliaison Fin-Début avec un décalage négatif de dix jours : le successeur commence dix joursavant 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 quieffectuera le travail), l’emplacement géographique ou le bâtiment (où le travail doit êtreeffectué) et le type d’activité (d’ensemble ou détaillé), sont très importants pour permettre par

6.4.

1|

6.4.

2.3



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 efficacementles 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 del’ensemble des ressources. Les dates obtenues ne constituent pas le planning ; elles indiquentplutôt les périodes durant lesquelles l’activité envisagée pourrait être planifiée, compte tenudes 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éterministeune seule date de début et une seule date de fin, au plus tôt et au plus tard, pour chaqueactivité en se basant sur la logique séquentielle du réseau, et sur une seule estimation dedurée pour chaque activité. La méthode CPM cherche surtout à calculer une marge afind’identifier les activités disposant d’une flexibilité moindre du point vue du planning. Lesalgorithmes 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éspour traiter les liaisons logiques et l’estimation de la durée des activités (c’est-à-dire quecertaines activités peuvent ne pas être réalisées du tout, d’autres peuvent l’être en partieet 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 desdiffé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 lamé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 (parexemple, pour respecter des dates imposées ou d’autres objectifs de délais). La compressiondes 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 desdélais pour déterminer s’il est possible, et de quelle manière, d’obtenir le maximum decompression 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 quidevraient normalement se succéder (par exemple, commencer à développer le code d’unprojet 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). Laconstruction en régime accéléré conduit souvent à des reprises et augmente généralementle niveau de risques.

.3 Simulation. La simulation consiste à calculer plusieurs valeurs de la durée du projet, à l’aidede différents jeux d’hypothèses concernant les activités. La méthode la plus courante est cellede Monte Carlo par laquelle une distribution des résultats probables pour chaque activité estdéfinie, puis utilisée pour calculer une distribution des résultats probables de l’ensemble duprojet (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, commeretarder la livraison d’un composant essentiel, allonger certains délais d’études ou incorporerdes facteurs externes (tels une grève ou un changement dans un processus d’obtention depermis). Le résultat des simulations conditionnelles peut servir à évaluer la faisabilité desdélais en cas de circonstances défavorables et à préparer des plans de remplacement pour sur-monter ou faire face à des situations inattendues.



76

.4 Heuristique de lissage des ressources. L’analyse mathématique conduit souvent à un planningpréliminaire avec début au plus tôt, nécessitant à certaines périodes plus de ressources quecelles 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. Lelissage des ressources conduit souvent à une durée de projet plus longue que celle envisagéedans 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 moyencouramment 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-endsou 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 ladurée du planning initial. La construction en régime accéléré, si elle est envisageable (commedécrite à la section 6.4.2.2), est une autre méthode employée pour réduire la durée totale duprojet. 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 appellela planification avec affectation à rebours des ressources. La chaîne critique est une techniquequi 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 pouraider à l’élaboration des plannings. D’autres logiciels sont capables d’interagir directement ouindirectement entre eux ou avec d’autres outils informatiques, pour satisfaire aux exigencesd’autres disciplines. Ils effectuent automatiquement le calcul de l’analyse mathématique et du

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

Figu

re 6

–4|

6.4.

3.1



lissage des ressources ; ils permettent donc d’analyser rapidement les diverses possibilités enmatière de délais. Ils sont également très utiles pour imprimer ou visualiser les données desortie de l’élaboration du planning.

.6 Structure de codification. Les activités doivent être codifiées de manière à permettre le triet/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éliminairetant que les affectations de ressources ne sont pas confirmées. En principe, cette confirmationdevrait 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) oudétaillée. Bien qu’il puisse être présenté sous forme de tableau, on utilise le plus souvent laforme 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 chemincritique du projet (voir la section 6.2.3.1 pour de plus amples informations sur les dia-grammes réseau).

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



78

■ diagrammes à barres, appelés également diagrammes de Gantt (voir la figure 6-6). Ilsrepré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 souventdans 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. Levolume 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, leplan 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, entreautres :

■ Les besoins en ressources par unité de temps, souvent sous forme d’histogramme decharge.

■ 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 (voirla section 4.1).

.4 Mises à jour des besoins en ressources. Les mises à jour du lissage des ressources peuventavoir d’importantes répercussions sur l’estimation préliminaire des besoins en ressources.

Figure 6-6 Diagramme à barres (Gantt)

Figu

re 6

–6|

6.5.

1.1



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

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 deressources), est une composante du plan de projet décrit à la section 4.1.3.1. Il sert de basede mesure et de suivi des performances du point de vue des délais.

Données d'entrée

.1 Planning du projet .2 Rapports d'avancement .3 Demandes de changements .4 Plan de gestion du planning

Outils et méthodes

.1 Système de contrôle des changements du planning.2 Mesure des performances.3 Planification complémentaire.4 Logiciels de gestion de projet.5 Analyse des écarts

Données de sortie

.1 Mises à jour du planning

.2 Action corrective

.3 Leçons retenues

Figure 6-7 Echéancier



80

.2 Rapports d’avancement. Les rapports d’avancement, traités à la section 10.3.3.1, fournissentdes 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 parla 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ôleintégré des changements décrit à la section 4.3.

.2 Mesure des performances. Les méthodes de mesure des performances, telles que cellesdé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 deschangements du planning. Par exemple, le retard important d’une activité non essentielle peutn’avoir qu’un faible impact sur l’ensemble du projet, tandis que le retard moins importantd’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 desdates planifiées par rapport aux dates réelles et à faire des prévisions quant à l’impact (effectifou 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 lesdates de début et de fin réelles/prévues permet d’obtenir des informations utiles pour décelerles é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 desdé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 auxestimations. Dans certains cas, les retards sont tellement importants que l’on doit redéfinirla référence de base pour obtenir des données réalistes pour la mesure des performances.

6.5.

5.2

|6.

5.3.

3

Toutefois, il convient de faire attention avant de redéfinir la référence de base car l’historiquedu planning du projet sera alors perdu. Cette redéfinition ne doit être utilisée qu’en dernierressort pour contrôler le planning ; de nouvelles dates cibles devraient être le mode normalde révision du planning.

.2 Action corrective. Il s’agit de toute action visant à réaligner les dates de réalisation futures surcelles prévues dans le plan de projet. Les actions correctives au niveau de la gestion des délaisconsistent souvent à accélérer : mettre en œuvre des actions spéciales effectuées pour assurerl’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 queles autres types de leçons retenues doivent être documentés et intégrés à la base de donnéeshistoriques du projet et des autres projets de l’entreprise maîtresse d’œuvre.




Chapitre 7

Gestion des coûts du projet

La gestion des coûts du projet comprend les processus nécessaires à la réalisation du projetdans 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.



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 lecoût d’utilisation du produit issu du projet. Par exemple, la décision de limiter le nombre derevues 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énieriede 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’autresdomaines (par exemple, les projets d’investissement), la gestion des coûts inclut également ceprocessus. Lorsque de telles prédictions et analyses sont prises en compte, la gestion des coûtsdu projet comprend alors des processus supplémentaires et de nombreuses techniques degestion 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 momentsdifférents. Par exemple, le coût d’un approvisionnement peut être mesuré lorsqu’il est engagé,commandé, livré, encouru ou enregistré par la comptabilité.


Chapitre 7 — Gestion des coûts du projet

84

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

Figu

re 7

–1|

7.1.

1.2



Lorsque les coûts du projet sont utilisés dans le cadre d’un système d’appréciation dumérite et de récompense du personnel (traité à la section 9.3.2.3), les coûts contrôlables etincontrô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 desressources, d’estimation des coûts et de budgétisation sont tellement liés qu’ils sont considéréscomme un processus unique (par exemple, ils peuvent être réalisés par une seule personneen un temps relativement court). Ils sont présentés ici comme des processus distincts car lesoutils et méthodes utilisés sont différents pour chacun d’entre eux. La possibilité d’influencerles coûts est plus importante durant les phases initiales du projet, et c’est pourquoi il estessentiel 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 RESSOURCESLa planification des ressources consiste à déterminer les ressources physiques (personnes,équipement, matériel) devant être utilisées et les quantités correspondantes, ainsi que lemoment où celles-ci seront requises pour réaliser les activités du projet. Ce processus doit êtreminutieusement coordonné avec celui de l’estimation des coûts (décrite à la section 7.2). Parexemple :

■ L’équipe chargée d’un projet de construction doit connaître le code du bâtiment local. Unetelle 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 lemoyen 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 enincluant 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 desortie pertinentes en provenance d’autres processus de planification doivent être obtenues parle 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.



86

.3 Cahier des charges. Le cahier des charges (décrit à la section 5.2.3.1) contient la justificationet les objectifs du projet, deux aspects devant être explicitement pris en compte au cours dela 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 dela description de l’ensemble des ressources varie. Par exemple, durant les phases initiales d’unprojet d’ingénierie, l’équipe peut comprendre un grand nombre d’ingénieurs débutants etconfirmés. Mais, au cours des phases suivantes du même projet, l’ensemble des ressourcespourra se limiter aux personnes le connaissant bien pour y avoir travaillé durant les phasesantérieures.

.5 Politique organisationnelle. Durant la planification des ressources, on doit tenir compte de lapolitique de l’organisation maîtresse d’œuvre en matière de personnel et de location oud’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 toutepersonne possédant des connaissances ou une formation particulières ; on peut l’obtenir deplusieurs 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’ensembledes ressources. Suivant la sophistication du logiciel utilisé, on peut définir la disponibilité etle 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 pourchaque élément du niveau le plus bas de l’OT. Les besoins en ressources pour les autresniveaux 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 à lasection 9.2), soit par le processus d’approvisionnement (décrit au chapitre 12).

7.2 ESTIMATION DES COÛTSL’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 approximationdes coûts, l’estimateur doit tenir compte des causes d’écarts de l’estimation finale afin demieux gérer le projet.

Lorsqu’un projet est réalisé sous contrat, on doit bien faire la distinction entre l’estimationdes coûts et la détermination du prix. L’estimation des coûts consiste à évaluer un résultatquantitatif 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écisiond’ordre commercial (à savoir, combien l’organisation maîtresse d’œuvre facturera-t-elle pourle produit ou service ?) dans laquelle l’estimation des coûts n’est qu’une des considérationsprise en compte parmi tant d’autres.

7.1.

1.3

|7.

2.1.

8



L’estimation des coûts comprend l’identification et l’évaluation de diverses variantes enmatiè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 lescoûts de la phase de production. Le processus d’estimation des coûts doit déterminer si lecoû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ûten 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 section6.3.3.1) a une influence sur l’estimation des coûts dans tous les projets dont le budget inclutle 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égoriesde 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 avoirconservé 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 certainsmembres 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 rappelerdes 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 section11.2.3.1) lorsqu’elle élabore l’estimation des coûts, puisque les risques (qu’ils constituent desmenaces ou des opportunités) peuvent avoir un impact considérable sur les coûts. Pourchaque activité, l’équipe de projet tient compte de l’importance accordée à l’impact desrisques dans l’estimation des coûts.



88

7.2.2 Outils et méthodes de l’estimation des coûts.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é parle passé comme base d’estimation des coûts du projet en cours. On l’utilise fréquemment pourestimer le coût total d’un projet lorsqu’il existe peu d’informations détaillées sur celui-ci (parexemple, dans les phases initiales). L’estimation par analogie est une forme de méthode baséesur 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 elleest é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 lesgroupes 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. Lesmodèles peuvent être simples (la construction d’une maison coûtera un certain prix au mètrecarré 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 plusfiables 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’ils’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 duprojet.

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 lecoût et le degré de précision du processus d’estimation. L’équipe de gestion de projet doitoptimiser 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, lestableurs et les outils de simulation et de statistiques sont largement mis à contribution dansl’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 sousforme abrégée ou détaillée.

Le coût de toutes les ressources affectées au projet doit être estimé. Ceci comprend, entreautres, la main-d’œuvre, les matériaux, les fournitures et des catégories spéciales telles quedes 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 faciliterun contrôle adéquat. En général, l’estimation des coûts implique de tenir compte des mesuresde réduction prévues, telles que les plans de remplacement.

7.2.

2|

7.3.

1.2



Au cours du projet, on aura intérêt à affiner les estimations de coût pour qu’elles reflètentles informations supplémentaires disponibles. Dans certains domaines d’application, il existedes directives indiquant les moments opportuns à la réalisation de telles modifications, ainsique le degré de fiabilité prévu. Par exemple, l’AACE (Association for the Advancement of CostEngineering) International a identifié cinq types d’estimations progressives des coûts deconstruction 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 doiventcomprendre :

■ 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 €, pourindiquer qu’un élément donné devrait coûter entre 9 000 € et 11 000 €. Le volume et letype 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 decoûts (par exemple, les mesures à prendre pour les problèmes importants sont différentes decelles destinées aux problèmes mineurs). Selon les besoins des acteurs du projet, il peut êtreformel ou non, très détaillé ou formulé dans ses grandes lignes. C’est un élément annexe auplan de projet (traité à la section 4.1.3.1).

7.3 BUDGÉTISATIONLa 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 lesperformances 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 projetauxquels les coûts sont attribués.



90

.3 Planning du projet. Le planning du projet (décrit à la section 6.4.3.1) comprend les dates dedébut prévues et les dates de fin attendues pour les éléments du projet auxquels des coûtssont attribués. Ces informations sont nécessaires pour attribuer les coûts à l’unité de tempsdurant 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 dubudget 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 enadditionnant les coûts estimés par période et se présente habituellement sous la forme d’unecourbe 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 uneréférence de coûts pour la mesure des dépenses.

7.4 CONTRÔLE DES COÛTSLe contrôle des coûts consiste à : a) agir sur les facteurs entraînant des modifications de laréférence de coûts afin de s’assurer que ces modifications sont consensuelles, b) déterminersi 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 :

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

Figu

re 7

–2|

7.4.

2.2



■ le suivi des performances des coûts, pour déceler et comprendre les écarts par rapport auplan ;

■ 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 desinformations sur les performances de réalisation et des coûts du projet (par exemple, quelssont les budgets respectés et ceux qui sont dépassés). Les rapports d’avancement peuventaussi 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 parla loi ou facultatives. Suite aux modifications, il peut s’avérer nécessaire d’augmenter lebudget, 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. Ilcomprend les documents, les systèmes de suivi et les niveaux d’autorisation nécessaires pourautoriser 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 section10.3.2, permettent d’évaluer l’ampleur des écarts effectifs. La gestion de la valeur acquise



92

(EVM en anglais), décrite aux sections 7.4.2.3 et 10.3.2.4, est particulièrement utile pour lecontrôle des coûts. Déterminer l’origine des écarts et décider si ceux-ci nécessitent une actioncorrective 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 dela valeur acquise (EVM) doivent mesurer les performances du projet de façon continue enmettant 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 valeuracquise (VA), c’est-à-dire le travail effectif réellement accompli, y compris l’estimation de lavaleur 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) valeuracquise moins 1) valeur prévue constitue l’écart de prévision (EP). L’opération : 2) valeuracquise moins 3) coût réel constitue l’écart de coût pour le projet. Voir également la section10.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 larefaire 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 lestableurs, sont souvent utilisés pour effectuer le suivi des coûts planifiés par rapport aux coûtsré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 êtreavertis. L’estimation corrigée des coûts peut nécessiter ou non l’ajustement d’autres aspects duplan de projet.

.2 Mises à jour du budget. Il s’agit d’une catégorie spéciale d’estimation corrigée des coûts. Lesmises à jour du budget sont des modifications de la référence de coûts approuvée. Ceschiffres ne sont généralement révisés qu’à la suite de modifications du contenu. Dans certainscas, les écarts de coûts sont tellement importants que l’on doit redéfinir la référence de coûtspour 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 totalle plus probable du projet, basée sur les performances et la quantification des risques duprojet, décrite à la section 11.4.3. Les techniques de prévision les plus courantes sont unevariante de :

■ PAA = Coûts réels à ce jour plus une nouvelle estimation pour le travail restant. Cetteapproche est utilisée le plus souvent lorsque les performances passées ont démontré queles hypothèses émises dans l’estimation initiale étaient fondamentalement imparfaites ouqu’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 atypiqueset 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é.

7.4.

2.3

|7.

4.3.

6



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érancesacceptables.

.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 ofCertified 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 queles autres types de leçons retenues doivent être documentés et intégrés à la base de donnéeshistoriques du projet et des autres projets de l’entreprise maîtresse d’œuvre (voir la section4.3.3.3).


Chapitre 8

Gestion de la qualité duprojet

La gestion de la qualité du projet comprend les processus nécessaires pour que le projetréponde aux besoins pour lesquels il a été mis en œuvre. Elle comprend « toutes les activitésde 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 laqualité 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 lescauses de performances insuffisantes.



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étaildans 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, tellesque 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 issude 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 tousles acteurs du projet. Par exemple :


Chapitre 8 — Gestion de la qualité du projet

96

■ satisfaire aux exigences du client en surchargeant de travail l’équipe de projet peut avoirdes 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 pasdé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 sontles données d’entrée de l’élaboration détaillée des besoins du projet. Dans le contexte d’unprojet, un des aspects essentiels de la gestion de la qualité est la nécessité d’exprimer lesbesoins implicites sous forme de besoins confirmés par le biais de la gestion du contenu duprojet, décrite au chapitre 5.

L’équipe de gestion de projet doit éviter de confondre qualité et classe. La classe est « unecatégorie ou un rang donné(e) à des entités ayant un usage fonctionnel identique mais descaracté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 êtrede très bonne qualité (pas de bogues manifestes, manuel lisible) tout en étant d’une classeinfé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 classerelè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 dela qualité et la gestion de projet sont complémentaires. Par exemple, ces deux disciplinesreconnaissent l’importance de :

Figu

re 8

–1|

8.1

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



■ la satisfaction du client : comprendre, gérer et infléchir les besoins de façon à répondreaux 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 cherque 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 membresde l’équipe ; cela dit, la disponibilité des ressources nécessaires à la réussite demeure laresponsabilité de la direction.

■ les processus par phases : la répétition du cycle planifier-réaliser-vérifier-agir décrit parDeming et autres ressemble beaucoup à l’organisation par phases et par processus traitéeau chapitre 3, « Processus de la gestion de projet ».

De plus, les initiatives de l’entreprise réalisatrice visant à l’amélioration de la qualité (parex : TQM, amélioration continue, etc.) peuvent accroître la qualité de la gestion du projetautant que celle du produit issu du projet.

Cependant, il existe une importante différence dont l’équipe de gestion de projet doit avoirclairement conscience : la nature temporaire d’un projet signifie que les investissements pourl’amélioration de la qualité du produit, surtout en matière de prévention et d’évaluation desdéfauts, doivent souvent être pris en charge par l’entreprise réalisatrice, le projet ne durantpas 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 projetet à 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 ») ; ildoit être appliqué régulièrement et en parallèle avec les autres processus de planification duprojet. Par exemple, les changements apportés au produit résultant du projet et nécessairesau respect des normes de qualité identifiées peuvent entraîner des ajustements au niveau descoû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 normesISO 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éesdans les projets. Il en existe de nombreuses autres pouvant être utiles pour certains projets oudans certains domaines d’application.

L’équipe de projet doit également avoir conscience de l’un des principes fondamentauxde la gestion moderne de la qualité à savoir que la qualité doit être planifiée et non contrôléeaprès coup.



98

8.1.

1|

8.1.

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

.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 leprojet. Cependant, si l’organisation n’a pas de politique officielle en matière de qualité, ousi 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 produitslivrables du projet, ainsi que les objectifs du projet servant à définir les exigences importantesdes acteurs.

.3 Description du produit. Bien que certains éléments de la description du produit (décrite à lasection 5.1.1.1) puissent faire partie de l’énoncé du contenu, celle-ci contient souvent desdé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 lesnormes ou réglementations spécifiques à un domaine d’application, qui peuvent avoir unimpact 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érercomme 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 enmatière de qualité implique notamment moins de reprises, ce qui signifie une plus grandeproductivité, des coûts moindres et une plus grande satisfaction des acteurs. Le coût principaldu respect des exigences en matière de qualité est celui associé aux activités de gestion de laqualité du projet. Les bénéfices doivent être plus importants que les coûts : c’est un axiomede 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 normepermettant 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 relationsentre 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 diagrammesen 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.



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 approchespour les traiter.

.4 Prototypage. Le prototypage est une technique statistique aidant à identifier les facteurs ayantun impact sur des variables spécifiques. Cette technique s’applique le plus fréquemment auproduit 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, lameilleure 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 cherque 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 diversescombinaisons d’ingénieurs confirmés et débutants) permettra souvent d’identifier la solutionoptimale, à 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 à assurerla 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 desdé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’ildoit 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 duprojet (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èsdétaillé ou global.

Figure 8-2 Diagramme de causalité



100

.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 dela qualité. Par exemple, dire que le respect des dates programmées du planning est unemesure de la qualité de la gestion n’est pas suffisant ; l’équipe de gestion du projet doit aussiindiquer 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éesindicateurs.

Figure 8-3 Exemple de schéma de processus

Figu

re 8

-3|

8.2.

2.2



.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 decontrô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 organisationsdisposent 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èsd’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é peutpermettre 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 toutesles normes de qualité applicables (6). Elle doit être présente tout au long du projet. Avantl’é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é sontdes données résultant des tests et des mesures du contrôle de la qualité, enregistrées dans unformat 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 laqualité. Il permet d’identifier les leçons retenues qui pourront améliorer les performances du



102

projet en cours ou des autres projets de l’entreprise. Les audits qualité peuvent être pro-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 miseen œ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 deré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 dela 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 nomsemblable ; cela n’est pas obligatoire.

L’équipe de gestion de projet doit avoir une connaissance pratique du contrôle statistiquede la qualité, notamment en ce qui concerne l’échantillonnage et les probabilités, afin d’êtreen mesure d’évaluer les données de sortie du contrôle de la qualité. Il peut lui être utile deconnaître, entre autres choses, les différences entre :

■ la prévention (éviter les erreurs dans le processus) et l’inspection (éviter que les erreursne soient découvertes par le client) ;

■ l’échantillonnage des attributs (le résultat est conforme, ou non) et l’échantillonnage desvariables (le résultat est évalué par rapport à une échelle continue de mesure du degré deconformité) ;

■ 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 leslimites indiquées).

8.2.

3|

8.3.

2.4



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 (extraitesdu 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 inspectionspeuvent ê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 appellationsdiverses : révisions, revues de produit, audits et révisions de projet ; dans certains domainesd’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ésultatsd’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, oubien 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. Bienque le plus souvent utilisées pour suivre des activités répétitives, telles que la fabrication parlots, elles peuvent également servir à surveiller les écarts de coûts et de prévisions, le nombreet la fréquence des changements du contenu, les erreurs dans les documents du projet oud’autres résultats de gestion, et permettre ainsi de déterminer si le processus de gestion deprojet est sous contrôle. La figure 8-4 est une fiche de contrôle des performances de délaisd’un projet.

.3 Diagrammes de Pareto. Un diagramme de Pareto est un histogramme, présenté par ordre defréquence d’occurrence, montrant combien de résultats ont été générés par type ou catégoriede causes identifiées (voir la figure 8-5). Ce classement par ordre permet de guider l’actioncorrective ; l’équipe de projet doit agir en premier lieu pour éliminer les problèmes à l’originedu plus grand nombre de défauts. Les diagrammes de Pareto sont conceptuellement liés à laloi de Pareto qui stipule qu’un nombre relativement faible de causes est à l’origine de lagrande majorité des problèmes ou défauts. Ceci est communément désigné par l’expressionprincipe 80/20, où 80 % des problèmes sont dus à 20 % des causes.

.4 Échantillonnage statistique. L’échantillonnage statistique implique de choisir une partie de lapopulation intéressée pour l’inspecter (par exemple, sélectionner dix dessins techniques auhasard 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 estnécessaire que l’équipe de gestion de projet connaisse l’éventail des méthodes d’échantillon-nage.

.5 Modélisation. La modélisation est décrite à la section 8.1.2.3. Elle est utilisée dans le contrôlede 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’utilisesouvent pour surveiller :

■ les performances techniques : combien d’erreurs ou de défauts identifiés, combien qui nesont 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 dernierspeuvent 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, ellesdoivent être mises dans le dossier du projet une fois remplies.

.5 Corrections de processus. Les corrections de processus impliquent de prendre des mesurescorrectives 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.



104

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

Figu

re 8

–4|

Figu

re 8

–5



Figure 8-5 Diagramme de Pareto


Chapitre 9

Gestion des ressourceshumaines 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 acteursdu 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 plusieursgroupes, selon les besoins du projet. Habituellement, tous les processus sont exécutés aumoins une fois au cours de chaque phase du projet.


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étencesmajeures 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 lesgroupes 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 desressources humaines.

La plupart de ces matières sont directement applicables à la direction et à la gestion dupersonnel dans un projet, et le chef de projet et l’équipe de gestion de projet doivent lesconnaître. Cependant, ils doivent également être attentifs à la manière d’appliquer cesconnaissances dans le projet. Par exemple :


Chapitre 9 — Gestion des ressources humaines du projet

108

■ les projets étant par nature temporaires, les relations personnelles et structurelles serontgénéralement à la fois temporaires et nouvelles. L’équipe de gestion du projet doit choisirsoigneusement 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 leprojet change de phase de cycle de vie. Il en résulte que les méthodes adaptées à unephase 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 uneconnaissance 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é desressources humaines.

9.1 PLANIFICATION DE L’ORGANISATIONLa 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

Figu

re 9

–1|

9.1.

1.2

Figure 9-1 Vue d’ensemble de la 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 êtreexaminé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 besoinsen 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èssimples. Par exemple, l’élaboration d’un système de télécommunication complexe peutdemander la coordination de nombreux sous-traitants pendant plusieurs années, tandisque l’élimination d’une erreur de programmation dans un système installé sur un seul sitene 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érentesdisciplines techniques. Ces interfaces se produisent aussi bien pendant les phases duprojet (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 phasesdu 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’unarchitecte employé par une société de design explique les principales préoccupations enmatière de conception à l’équipe de gestion de projet d’un sous-traitant avec laquelle il n’aaucun 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 enpersonnel constituent un sous-ensemble des besoins globaux en ressources identifiés au coursde la planification des ressources (décrite à la section 7.1).



110

.3 Contraintes. Les contraintes sont des facteurs limitant les options de l’équipe de projet. Lesoptions organisationnelles d’un projet peuvent être soumises à des contraintes de différentesfaçons. Le plus souvent, les facteurs qui restreignent l’organisation de l’équipe sont, entreautres :

■ la structure de l’entreprise réalisatrice : une organisation dont la structure de base est unematrice forte implique que le rôle du chef de projet sera relativement plus important quecelui du même poste dans une organisation dont la structure de base est une matricefaible (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’autresgroupements 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 eudu 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 ladé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 lignesdirectrices et des procédures diverses pouvant aider l’équipe de gestion de projet dans denombreux 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écrivantla 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 desorganisations 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 acteursavec 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 lesresponsabilités peuvent évoluer au fil du temps. La plupart des rôles et des responsabilitésseront attribués aux acteurs activement impliqués dans les activités du projet, tels que le chefde 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éralessentiels, 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-

9.1.

1.3

|9.

1.3.

4



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 niveaupeut 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éscorrespondant à des activités spécifiques.

.2 Plan de gestion du personnel. Ce plan décrit quand et comment les ressources humainesseront 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ésd’emploi.

.3 Organigramme. Un organigramme est une représentation graphique des liens hiérarchiquesau 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 serviceinterne de trois à quatre personnes ne sera probablement pas aussi rigoureux et détaillé quecelui d’une équipe d’intervention en cas de catastrophe de 3000 personnes.

Un organigramme fonctionnel (OF) est un type particulier d’organigramme identifiant, ausein 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 :

Figure 9-2 Matrice des responsabilités


Capítulo 9 — Gestión de los Recursos Humanos del Proyecto

112

■ 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étencesrequises par le projet, l’acquisition de ces compétences devra faire partie du projet.

9.2 OBTENTION DES RESSOURCES HUMAINESL’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, ilse peut que les « meilleures » ressources ne soient pas disponibles. L’équipe de gestion duprojet doit alors veiller à ce que les ressources qui le sont répondent aux exigences du projet.

Figure 9-3 Histogramme des ressources

Figu

re 9

–3|

9.2.

2.1



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 mesured’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 travaillerensemble 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 dansle projet aient une politique, des lignes directrices ou des procédures régissant l’affectation dupersonnel. 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 personnelaux 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 affecterconvenablement 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, unresponsable 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.



114

.2 Préaffectations. Dans certains cas, du personnel peut être préaffecté au projet. Ceci se pro-duit lorsque : a) le projet résulte d’un appel d’offres, et des ressources humaines particulièresont été promises dans le cadre de l’offre ou, b) le projet est un projet de service interne, etles 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 chapitre12) 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 disposepas du personnel interne dont elle a besoin pour réaliser le projet (par exemple, suite à ladécision délibérée de ne pas embaucher ces personnes comme salariés à plein temps, parceque 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, à tempspartiel 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 lesmembres de l’équipe de projet et des autres acteurs. Selon les besoins du projet, il peut êtreformel ou non, très détaillé ou présenté dans ses grandes lignes.

9.3 DÉVELOPPEMENT DE L’ÉQUIPELe 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 quetelle. Le développement au niveau individuel (managérial et technique) est indispensable audéveloppement de l’équipe. Le développement de l’équipe est essentiel pour que le projetpuisse atteindre ses objectifs.

Le développement de l’équipe dans un projet se complique souvent lorsque les membresde 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 lienshié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.

9.2.

2.2

|9.

3.2.

4



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étencesdes 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 techniquedans 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 duprojet.

.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 deplanification les membres de l’équipe n’appartenant pas à la direction ou établir des règles debase pour aplanir et gérer les conflits, peuvent avoir comme effet secondaire d’améliorer lesperformances 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’à desséminaires prolongés et organisés à l’extérieur par des professionnels, dont l’objectif estd’améliorer les relations entre les acteurs majeurs.

Il existe de nombreux ouvrages traitant du développement de l’esprit d’équipe. En règlegé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 uneimportance 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 desactions 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 lesperformances du projet et les récompenses. Par exemple, si l’on souhaite récompenser unchef de projet pour l’atteinte des objectifs de coût du projet, celui-ci doit bénéficier d’unniveau 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 carceux de l’entreprise réalisatrice peuvent ne pas convenir. Par exemple, l’employé prêt à fairedes heures supplémentaires pour respecter un planning serré doit être récompensé, tandisque celui qui doit faire des heures supplémentaires suite à une mauvaise planification ne doitpas 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écanismeadapté 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 presquetous, les membres les plus actifs de l’équipe de projet pour améliorer leur capacité à travaillerensemble. 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 seretrouver, 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.



116

.5 Formation. La formation englobe toutes les activités d’amélioration des compétences del’é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 existede nombreux ouvrages sur la formation continue.

Si les membres de l’équipe de projet n’ont pas les compétences techniques ou de gestionnécessaires, l’acquisition de celles-ci devra faire partie du projet, ou des mesures devront êtreprises pour affecter un personnel adéquat au projet. Les coûts directs et indirects issus de laformation 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 desconflits) 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 à identifieret à développer de meilleures manières de travailler.

.2 Éléments d’évaluation des performances. Les membres du projet doivent en principe fournirdes éléments d’évaluation des performances des autres membres de l’équipe de projet aveclesquels ils sont amenés à travailler fréquemment.

9.3.

2.5

|C

hap

itre

10


Chapitre 10

Gestion des communicationsdu projet

La gestion des communications du projet comprend les processus nécessaires à assurer, entemps 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 leprojet doit être prête à envoyer et à recevoir des communications et doit comprendre à quelpoint celles dans lesquelles elle est impliquée en tant qu’individu affectent le projet dans sonensemble. 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 sousquelle forme.

10.2 Diffusion de l’information : mettre les informations nécessaires à la disposition desacteurs 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 permettantd’officialiser l’achèvement du projet ou d’une de ses phases.



Les compétences en gestion dans le domaine de la communication (traitées à la section2.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 nes’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.


Chapitre 10 — Gestion des communications du projet

118

Figu

re 1

0–1

|10

.1.1

.1

Figure 10-1 Vue d’ensemble de la 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 COMMUNICATIONSLa planification des communications consiste à déterminer les besoins des acteurs en matièred’information et de communication : qui a besoin de quelles informations, quand, sous quelleforme et de qui. Bien que tous les projets requièrent la communication des informations lesconcernant, 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 estinté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’assurerqu’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 impacttrè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 ressourcesdu 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).



120

.2 Technologie des communications. Les technologies ou les méthodes employées pour dissé-miner les informations entre les acteurs du projet varient considérablement : elles peuventprendre 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 projetcomprennent :

■ 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ésrégulièrement suffisent-ils ?

■ la technologie disponible : les systèmes déjà en place conviennent-ils, ou les besoins duprojet justifient-ils des changements ?

■ la composition prévue de l’équipe de projet : les systèmes de communication proposéssont-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 findu projet ?

.3 Contraintes. Les contraintes sont des facteurs limitant les options de l’équipe de gestion deprojet. Par exemple, si le volume d’achat est important, une plus grande attention devra êtreapportée au traitement des informations contractuelles.

Lorsqu’un projet est réalisé sous contrat, il existe souvent des dispositions contractuellesspécifiques concernant la planification des communications.


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 depouvoir y répondre (la section 2.2 traite des acteurs plus en détail). L’analyse doit prendre encompte les méthodes et les technologies, adaptées au projet, qui fourniront les informationsnécessaires. Il faut prendre soin d’éviter le gaspillage des ressources dû à des informationsinutiles 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 avecles 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é dedé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 à mesurede la progression et de l’évolution du projet.

10.1

.1.2

|10

.2.2

.2



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

10.2 DIFFUSION DE L’INFORMATIONLa 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 descommunications, 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 à lasection 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 pourconfirmer qu’elles sont bien comprises. Le destinataire doit s’assurer qu’il a bien reçu toutesles 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 avecune 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 classementmanuels, les bases de données électroniques, les logiciels de gestion de projet et les systèmesd’accès à la documentation technique telle que les dessins d’ingénierie, les spécifications deconception, les plans d’essais, etc.



122

.3 Méthodes de diffusion de l’information. Les informations sur le projet peuvent être diffuséesen 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 celaest justifié, être conservées de manière organisée. Souvent, les membres de l’équipe de projetconservent 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 acteursdu projet de façon officielle ou informelle. L’information correspond aux besoins de ceux quila reçoivent et la méthode de présentation est adaptée.

10.3 RAPPORTS D’AVANCEMENTLes rapports d’avancement consistent à rassembler et à diffuser les informations concernantles performances, afin de fournir aux acteurs des informations sur l’utilisation des ressourcespour atteindre les objectifs du projet. Ce processus comprend :

■ les rapports de situation décrivant où en est le projet ; par exemple, l’état des indicateursde 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 à cequi 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 informationssur les risques et les approvisionnements. Les rapports peuvent être préparés globalement oudans 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.

10.2

.2.3

|10

.3.2

.5



.2 Travail réalisé. Le travail réalisé (quels produits livrables ont été achevés, complètement oupartiellement, quels coûts (et/ou ressources) ont été encourus ou engagés, etc.) est unedonné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 plusdu plan de projet et du travail réalisé, les autres documents du projet contiennent souvent desinformations 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 à uneou 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 auxrésultats planifiés ou prévus. Les écarts de coûts et de prévisions sont les plus fréquemmentanalysé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 duprojet 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 laméthode de mesure des performances la plus couramment employée. Elle intègre les mesuresdu contenu, des coûts (ou des ressources) et des délais pour permettre à l’équipe de gestionde projet d’évaluer les performances de ce dernier. L’analyse de la valeur acquise implique lecalcul 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 à latotalité des coûts encourus pour travailler sur l’activité pendant une période de tempsdonné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 outous 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 valeurdu travail réellement achevé.

Ces trois valeurs sont combinées pour mesurer la réalisation du travail planifié. Lesmesures 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 êtreconverties en indicateurs d’efficacité afin de refléter les performances des coûts et des délaisde n’importe quel projet. L’indice de performance des coûts (IPC = VA/CR) est l’indicateurd’efficacité des coûts le plus couramment utilisé. L’IPC cumulé (somme de tous les budgetsdes 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.



124

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 etle degré de détail demandés par les différents acteurs, tels que décrits dans le plan de gestiondes 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. Lafigure 10-2 utilise des courbes en S pour représenter les données cumulées de l’analyse dela VA, tandis que la figure 10-3 représente un ensemble de données de VA différent sousforme de tableau.

.2 Demandes de changements. L’analyse des performances du projet entraîne souvent desdemandes de changements pour certains aspects du projet. Ces demandes de changementssont traitées de la façon décrite dans les divers processus de contrôle des changements (parexemple, gestion des changements du contenu, contrôle du planning, etc.).

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

Figure 10-2 Rapport des performances sous forme de graphique

Figu

re 1

0–2

|10

.4.3

.1



10.4 CLÔTURE ADMINISTRATIVELe projet ou une de ses phases doit être clos après avoir atteint ses objectifs ou après qu’ony 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 leclient. Elle comprend la collecte des dossiers du projet (en s’assurant qu’ils reflètent bien lesspécifications finales) ; l’analyse du succès, de l’efficacité et des leçons retenues du projet ; etl’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 desemployés, enregistrées dans la base de données de l’ensemble du personnel, doivent êtremises à 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 pendantla 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 lesprojets 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.

.2 Clôture du projet. La confirmation que le projet répond à toutes les demandes du clientconcernant le produit du projet (le client a officiellement accepté les résultats et les produitslivrables 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.



126

10.4

.3.2

|C

hap

itre

11


Chapitre 11

Gestion des risques du projet

La gestion des risques est le processus systématique d’identification, d’analyse et de réductiondes 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 principauxprocessus 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 objectifsdu projet.

11.6 Suivi et contrôle des risques : surveiller les risques résiduels, identifier de nouveauxrisques, 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. Chaqueprocessus peut nécessiter la participation d’une ou plusieurs personnes ou d’un ou plusieursgroupes, selon les besoins du projet. Habituellement, tous les processus sont exécutés aumoins une fois au cours de chaque phase du projet. Bien que les processus soient présentésici 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 interactionsentre 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 impactpositif 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 constituerune cause. La composante événement du risque réside dans le fait que l’obtention du permispeut prendre plus longtemps que prévu ou que le personnel peut ne pas être à la hauteur dela tâche. Si l’un ou l’autre de ces événements se produit, les coûts, les délais ou la qualité duprojet sont affectés. Les conditions liées à un risque peuvent comprendre certains aspects del’environnement du projet pouvant contribuer aux risques, tels que de mauvaises pratiquesde gestion de projet ou la dépendance par rapport à des participants externes que l’on nepeut 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


Chapitre 11 — Gestion des risques du projet

128


Figu

re 1

1–1

|11

.1.1

.6

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



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érienceacquise au cours de projets similaires.

Les organisations perçoivent le risque comme une menace à la réussite du projet. Lesrisques 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 dela gestion des risques. On mesure l’engagement de l’organisation par les efforts entrepris pourrassembler des données de bonne qualité sur les risques et leurs caractéristiques.

11.1 PLANIFICATION DE LA GESTION DES RISQUESLa 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, letype et le niveau de visibilité de la gestion de risques sont proportionnels à la fois au niveaude 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 peuventavoir 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 lamême tolérance au risque. Cette différence est visible dans la politique exprimée ou se révèledans les actions mises en place.

.5 Modèles et formulaires de plan de gestion des risque. Certaines organisations ont créé desmodè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.



130

11.1.2 Outils et méthodes de planification de la gestion des risques.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, lesresponsables de chaque groupe de l’équipe de projet, tout membre de l’organisation dont laresponsabilité est de gérer la planification des risques et la mise en œuvre des activités, lesacteurs clés et d’autres, s’il y a lieu. Ils utilisent des modèles et formulaires de gestion desrisques 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, lesuivi 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 plandes stratégies de réponse, traité à la section 11.5.3.1. Le plan de gestion des risques peutinclure :

■ 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 peuventconvenir 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 typed’action décrit dans le plan de gestion des risques. Les équipes de gestion des risquesexté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 êtreappliqué tout au long du cycle de vie du projet. Les résultats doivent être obtenus asseztôt pour influer sur les décisions. Les décisions prises doivent être revues et corrigéespé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 risqueseffectué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 quiet de quelle manière. Le responsable, le client ou le commanditaire du projet peuvent nepas avoir le même seuil de risque. Le seuil acceptable correspond à l’objectif par rapportauquel l’équipe de projet mesurera l’efficacité de la mise en œuvre du plan des stratégiesde 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éesaux risques qui pourraient être utiles au projet en cours ainsi qu’aux besoins futurs, etcontribuer aux leçons retenues. Il précise si les processus liés aux risques doivent fairel’objet d’audits, et de quelle manière.

11.1

.2|

11.2

.1.3



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 dupossible : 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 deprojet, les acteurs et des experts extérieurs.

L’identification des risques est un processus itératif. Elle peut être effectuée, la premièrefois, par une partie de l’équipe de projet ou par l’équipe de gestion des risques. L’équipe deprojet au complet et les principaux acteurs peuvent effectuer une deuxième itération. Pourobtenir une analyse impartiale, des personnes n’étant pas impliquées dans le projet peuventeffectuer 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, ducommanditaire 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 peuts’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 projetpeuvent être identifiés et organisés par catégories. Ces catégories doivent être bien définies etreflé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 : misersur une technologie complexe ou qui n’a pas encore fait ses preuves, fixer des objectifsde performance irréalistes, ou encore modifier la technologie utilisée ou les normes indus-trielles en cours de projet ;



132

■ les risques liés à la gestion du projet : par exemple, une mauvaise répartition du tempset des ressources, la qualité médiocre du plan de projet ou une mauvaise utilisation destechniques de gestion de projet ;

■ les risques liés à l’organisation : par exemple, fixer des objectifs incohérents en matière decoû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 entreles 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 typeforce 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 peuventavoir 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 duprojet ou d’autres personnes au sein de l’organisation.

■ des informations publiées : bases de données commerciales, études théoriques, étalonnageet 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èretâ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 desrisques la plus fréquemment utilisée. Il a pour objet d’obtenir une liste exhaustive desrisques pouvant être traités ultérieurement dans les processus d’analyse qualitative etquantitative.

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éspar 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 tousles participants les étudient durant la réunion. Les risques sont ensuite catégorisés par typeet détaillés.

■ La technique de Delphes. La technique de Delphes est un moyen d’obtenir un consensusentre des experts sur un sujet tel que les risques du projet. Ces experts sur les risques desprojets sont connus, mais leur participation est anonyme.

À l’aide d’un questionnaire, un animateur sollicite des idées concernant les risquesimportants du projet. Les réponses sont soumises, puis circulent entre les experts quiferont d’autres commentaires. Après quelques séances de ce type, un consensus estobtenu 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 tropgrande influence sur le résultat.

■ Les entretiens. On peut identifier les risques grâce à des entretiens menés avec des chefsde 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

11.2

.1.4

|11

.3



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 projetet sur d’autres sources jugées utiles.

■ L’analyse des forces, faiblesses, opportunités et menaces (analyse SWOT en anglais). Il s’agitde l’examen du projet du point de vue des forces, faiblesses, opportunités et menacesvisant à é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édentssemblables et d’autres sources d’informations. Un des avantages inhérents à une liste decontrôle est la rapidité et la simplicité de l’identification des risques. Un de ses inconvénientsest 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 encompte des éléments absents d’une liste standard s’ils se rapportent au projet concerné. Laliste de contrôle doit détailler tous les types de risques envisageables pour le projet. Il estimportant de l’examiner comme une étape formelle de toute procédure de clôture de projetpour 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 desuppositions, de scénarios ou d’hypothèses. L’analyse des hypothèses est une méthode qui enexplore la validité. Elle identifie les risques dus à l’inexactitude, au manque de cohérence ouau caractère incomplet des hypothèses.

.5 Techniques de construction de diagrammes. Les techniques de construction de diagrammespeuvent comprendre :

■ les diagrammes de causalité (également appelés diagrammes d’Ishikawa ou en arêtes depoisson) : 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 diversescomposantes 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 lesinfluences causales, l’ordre des événements dans le temps et les autres relations entre lesvariables 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 ousignes d’avertissement, sont une indication de la présence ou de l’imminence d’un risque. Parexemple, le manque d’étapes jalons intermédiaires peut être le premier signe avertissant d’unretard imminent sur le planning.

.3 Données d’entrée pour les autres processus. L’identification des risques peut déterminer lebesoin 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 estincomplet ou manque de logique.

11.3 ANALYSE QUALITATIVE DES RISQUESL’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 surles 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 auxrisques peut exagérer l’importance d’un risque. Une évaluation de la qualité des informationsdisponibles aide également à modifier l’évaluation du risque envisagé. L’analyse qualitativedes risques implique que la probabilité et l’impact des risques seront évalués à l’aide deméthodes et d’outils d’analyse qualitative reconnus. La présence de tendances dans les résul-



134

tats, lorsque l’analyse qualitative est effectuée de manière répétitive, peut nécessiter une ges-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 êtrerevue et corrigée durant le cycle de vie du projet pour rester cohérente avec les changementsau 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 projetdurant 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. Ladé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. Lesprojets 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 estconnu 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, doiventservir à 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équencesaide à identifier les risques devant faire l’objet d’une gestion active.

11.3

.1|

11.3

.2.4



.2 Matrice de classification de la probabilité et de l’impact des risques. On peut créer unematrice qui classifie les risques ou les circonstances en fonction d’échelles de probabilité etd’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 pourchaque 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 dela probabilité d’un risque peut être difficile, la méthode à avis d’experts étant utilisée souventsans 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 peutencore 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’objectifdu projet. L’impact peut être ordinal ou cardinal, selon la culture de l’organisation conduisantl’analyse. Les échelles ordinales sont tout simplement des valeurs classées par ordre (trèsfaible, faible, moyen, élevé et très élevé). Les échelles cardinales attribuent une valeur à cesimpacts. Ces valeurs sont habituellement linéaires (par exemple, 0,1/0,3/0,5/0,7/0,9), maissouvent 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 unevaleur 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 auniveau 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 estconsidéré faible, moyen ou élevé. Cet exemple utilise une échelle non linéaire pour illustrerle rejet de risques à impact élevé, mais des échelles linéaires sont souvent utilisées. On peutaussi é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 pourrésultat la classification du risque envisagé comme risque élevé (situation « rouge »), risquemodé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 cadredes 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èrefausse. Des hypothèses de remplacement pouvant s’avérer vraies devraient être identifiées, etleurs conséquences sur les objectifs du projet testées lors du processus d’analyse qualitativedes 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 risquessont 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.



136

L’utilisation de données peu précises, par exemple en cas de mauvaise compréhensiond’un risque, peut être à l’origine d’une analyse qualitative des risques inutilisable par le chefde 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 desrisques. Il peut servir à affecter du personnel ou d’autres ressources aux projets sur la base deniveaux de risques différents, à prendre une décision concernant le projet sur la base d’uneanalyse coûts et bénéfices ou à appuyer la recommandation de démarrage, de poursuite oud’annulation d’un projet.

.2 Liste des risques par ordre de priorité. Les risques et les circonstances peuvent être triés parordre 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’ilsné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ésséparément avec des classifications différentes. Les risques importants doivent comporter unedescription des raisons sur lesquelles est basée l’évaluation de leur probabilité et de leurimpact.

.3 Liste des risques nécessitant une analyse et une gestion plus approfondies. Les risques classéscomme élevés ou moyens sont de parfaits candidats pour une analyse plus approfondie, ycompris pour l’analyse quantitative des risques et pour la gestion des risques.

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

Figu

re 1

1–2

|11

.4



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

11.4 ANALYSE QUANTITATIVE DES RISQUESLe 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 risqueen général pour le projet. Ce processus utilise des méthodes telles que la simulation de MonteCarlo 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 ilscontribuent 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. Elleimplique l’identification de ces derniers. Les processus d’analyse qualitative et quantitative desrisques peuvent être utilisés séparément ou ensemble. Le temps et le budget disponibles et lebesoin de données qualitatives ou quantitatives sur les risques et leurs impacts dicteront lesméthodes à utiliser. Les tendances discernées dans les résultats, lorsque l’analyse quantitativeest effectuée plusieurs fois, peuvent indiquer le besoin d’une gestion des risques plus oumoins importante.

Figure 11-3 Matrice Probabilité-Impact



138

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 section11.3.3.3.

.5 Données historiques. Des informations sur des projets précédents et semblables, des étudessur 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 lesujet 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 plusutiles 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èlesdes 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 duprojet et des experts du domaine peut constituer la première étape de la quantification desrisques. Les informations nécessaires dépendent du type de distribution des probabilités quel’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 lamoyenne et sur l’écart-type. Des exemples d’estimations à trois points pour une estimationdes coûts sont représentés à la figure 11-4.

Des distributions continues de probabilités sont habituellement utilisées dans l’analysequantitative 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 sontrepré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 unaspect important des entretiens sur les risques, car cela peut conduire à des stratégies efficacespour faire face aux risques durant le processus de planification des stratégies de réponse(décrit à la section 11.5).

11.4

.1|

11.4

.3.4



.2 Analyse de la sensibilité. Cette analyse aide à identifier les risques pouvant avoir le plus grandimpact 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 incertainsleurs 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 sousforme d’un arbre de décision. Celui-ci est un diagramme représentant une décision retenue etles 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 unarbre 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 projetdans son ensemble. Les simulations de projet sont en principe effectuées à l’aide de laméthode de Monte Carlo.

Pour une analyse des risques et des coûts, une simulation peut utiliser l’OT classique deprojet 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 pourle 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 dedélais indiquant les dates de fin ou la durée du projet, et les coûts possibles, ainsi que leurdegré 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 tendancedans les résultats obtenus peut apparaître au fur et à mesure de la répétition de l’analyse.

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



140

11.5 DÉVELOPPEMENT DES STRATÉGIES DE RÉPONSELe développement des stratégies de réponse est le processus qui consiste à élaborer desoptions et à déterminer des actions visant à cultiver les opportunités et à réduire les menacesaffectant 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 duprojet, 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 parmiplusieurs 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.

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

Figu

re 1

1–5

|11

.5.2



.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, onpeut 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 surla 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 desstraté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 à unestratégie de réponse commune.

.11 Tendances exprimées par les résultats des analyses qualitative et quantitative des risques. Cestendances sont décrites à la section 11.3.3.4 et 11.4.3.4. Des tendances apparaissant dans lesrésultats peuvent rendre des stratégies de réponse ou des analyses plus approfondies plus oumoins urgentes et importantes.

11.5.2 Outils et méthodes de planification des stratégies de réponsePlusieurs stratégies de réponse sont envisageables. Le choix doit se porter, pour chaquerisque, sur la plus efficace. Un plan d’actions doit ensuite être élaboré afin de mettre en œuvrecette stratégie. On peut choisir une stratégie principale et une stratégie de secours.

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



142

.1 Rejet. Le rejet d’un risque consiste à modifier le plan de projet afin d’éliminer ce risque ou lacirconstance, ou encore de protéger les objectifs du projet contre leur impact. Bien quel’é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 ressourcesou 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équencesd’un risque et la responsabilité de la stratégie de réponse correspondante. Transférer le risquedonne 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 risquede 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 debonne 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 forfaitairepeut 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’unemenace jusqu’à un seuil acceptable. Prendre tôt des mesures visant à réduire la probabilité dela concrétisation d’un risque ou de son impact sur le projet est plus efficace que d’essayer d’enréparer les conséquences une fois le risque concrétisé. Les coûts de la réduction doivent êtreproportionnels à la probabilité du risque et à ses conséquences.

Figure 11-7 Simulation des risques de coût

Figu

re 1

1–7

|11

.5.3

.3



La réduction des risques peut consister en la mise en œuvre d’un nouveau plan d’actionsvisant à 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. Celapeut 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 peutnécessiter l’élaboration d’un prototype pour réduire le risque présenté par le passage d’unmodèle à petite échelle à un produit grandeur nature.

Dans les situations où réduire la probabilité est impossible, une mesure de réductionpeut 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 leplan de projet pour faire face au risque ou qu’elle n’est pas en mesure d’identifier d’autresstratégies de réduction adéquates. L’acceptation active peut inclure l’élaboration d’un planalternatif, à 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 leurconcré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 pasatteindre 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 risquesconnus. 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 del’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, pourchaque 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 auxrisques ;

■ 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 mesuresde rejet, de transfert ou de réduction. Ils comprennent aussi les risques mineurs acceptés ettraité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 mesurede réduction sont appelés risques subordonnés. On doit les identifier et planifier des straté-gies de réponse adéquates.



144

.4 Accords contractuels. Des accords contractuels peuvent être signés afin de préciser la res-ponsabilité de chacun en cas de concrétisation de risques spécifiques, ainsi que pour la miseen place d’assurances, de services et d’autres postes, s’il y a lieu, destinés à éviter les menacesou à y parer.

.5 Provisions nécessaires pour aléas. Grâce à l’analyse probabiliste du projet (11.4.3.2) et auxseuils de risque (11.1.3.1), le chef de projet peut déterminer l’importance du tampon ou desprovisions nécessaires pour réduire le risque de dépassement des objectifs du projet, à unniveau acceptable pour l’organisation.

.6 Données d’entrée pour les autres processus. La plupart des mesures concernant les risquesimpliquent une dépense de temps, d’argent ou de ressources supplémentaires et nécessitentdes 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 alternativesdoivent ê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 planificationdes stratégies de réponse doivent être incorporés dans le plan de projet afin de s’assurer quela mise en œuvre et le suivi des actions approuvées font bien partie du projet en cours.

11.6 SUIVI ET CONTRÔLE DES RISQUESLe 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 lamise en œuvre des plans de risque et en évaluant leur efficacité pour atténuer les risques. Ceprocessus 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 aufur et à mesure de la progression du projet ; de nouveaux risques apparaissent ou des risquesanticipé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 desrisques. 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’unplan 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 auchef de l’équipe de gestion des risques sur l’efficacité du plan, sur tous les effets non anticipéset sur toutes les corrections nécessaires durant l’exécution du projet pour parer aux risques.

11.5

.3.4

|11

.6.2

.5



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 à lasection 10.3.1, fournissent des informations sur les performances et les risques du projet. Lesrapports 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 avisd’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 nonencore identifiés peuvent apparaître. Pour ceux-ci, on doit mettre en œuvre le cycle des sixprocessus concernant les risques.

.5 Modifications du contenu. Les modifications apportées au contenu nécessitent souvent unenouvelle analyse des risques et de nouveaux plans de réponse. Les modifications du contenusont 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. Cesaudits 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 êtreprogrammées. Les risques du projet devraient figurer à l’ordre du jour de toutes les réunionsde 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 duprojet en les comparant à un plan de référence. Les résultats obtenus grâce à une analyse dela valeur acquise peuvent indiquer un écart potentiel du projet à l’achèvement par rapport auxcoû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 lavaleur acquise est décrite à la section 10.3.2.4.

.4 Mesure des performances techniques. La mesure des performances techniques compare lesaccomplissements 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 pourla réalisation du contenu du projet.

.5 Planification de stratégies de réponse complémentaires. Si un risque non identifié dans leplan des stratégies de réponse fait surface ou si son impact sur les objectifs est plus important



que prévu, la mesure identifiée n’est peut-être pas adéquate. Il est alors nécessaire d’effectuerune 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égiesde réponse.

.2 Action corrective. Une action corrective consiste à suivre le plan alternatif ou à prendre unedécision à chaud.

.3 Demandes de changements du projet. Mettre en œuvre des plans alternatifs ou prendre desdécisions à chaud conduit souvent à des changements du plan de projet pour faire face auxrisques. 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ôledes risques peut réduire l’impact ou la probabilité des risques identifiés. Les niveaux derisques doivent être réévalués de façon à permettre un contrôle convenable des nouveauxrisques importants. Les risques ne se matérialisant pas doivent être documentés et éliminés duplan des stratégies de réponse.

.5 Base de données des risques. Référentiel permettant de recueillir, mettre à jour et analyserles 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érificationmises à jour au fur et à mesure que l’on acquiert de l’expérience aideront à gérer les risquesdans les projets à venir.

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 USA146

11.6

.3|

Cha

pitr

e. 1

2


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 termegé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. Chaqueprocessus peut nécessiter la participation d’une ou plusieurs personnes ou d’un ou plusieursgroupes, selon les besoins du projet. Habituellement, tous les processus sont exécutés aumoins une fois au cours de chaque phase du projet. Bien que les processus soient présentésici 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 interactionsentre 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-vendeurpeut 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 nombreuxprocessus 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 optionsde l’équipe de projet (par exemple, l’accord de l’acheteur pour les décisions concernantle personnel est souvent nécessaire dans les projets de conception).


Chapitre 12 — Gestion des approvisionnements du projet

148

Figu

re 1

2–1

|12

.1.1

.2

Figure 12-1 Vue d’ensemble de la 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 formelspassé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 APPROVISIONNEMENTSLa 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’ilfaut 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ôturedu contrat (section 12.6) doivent être recommencés pour chacun. L’équipe de gestion deprojet 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 section5.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



150

12.1.3.2) décrit la partie de ce produit devant être fournie par le vendeur. Toutefois, si l’en-treprise choisit d’acheter la totalité du produit, aucune distinction n’est à faire entre ces deuxtermes.

.3 Structure d’approvisionnement. Si l’entreprise réalisatrice n’a aucun service formel chargé dela passation des contrats, l’équipe de projet devra fournir les ressources et la compétencenécessaires aux activités d’approvisionnement du projet.

.4 Conditions du marché. Le processus de planification des approvisionnements doit rechercherles 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, lesautres 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 encompte comprennent les estimations préliminaires de coûts et de délais, les plans de gestionde la qualité, les prévisions de trésorerie, l’organigramme des tâches, les risques identifiés etles ressources humaines prévues.

.6 Contraintes. Les contraintes sont des facteurs limitant les options de l’acheteur. L’une descontraintes 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, sontdé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 doitprendre en compte les coûts indirects et directs. Par exemple, la partie « acheter » de l’analysedoit 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’entrepriseréalisatrice, ainsi que les besoins immédiats du projet. Par exemple, l’achat d’équipement (ilpeut s’agir d’une grue comme d’un ordinateur), plutôt que sa location ou son leasing, n’estpas nécessairement plus rentable. Cela dit, si l’organisation en a besoin à long terme, la partdu 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éesd’entrée de ce processus. Cette expertise peut être apportée par un groupe ou une personnepossédant une formation ou des connaissances particulières ; on peut l’obtenir de plusieurssources :

■ 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 typesd’achat. On rencontre généralement trois grandes catégories de contrats :

12.1

.1.3

|12

.1.3

.2



■ les contrats à prix forfaitaire ou contrats à forfait : cette catégorie de contrats stipule unprix total fixe pour un produit bien défini. Dans la mesure où le produit n’est pas biendéfini, l’acheteur comme le vendeur prennent un risque ; l’acheteur peut ne pas recevoirle 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éressementpour inciter la partie concernée à atteindre ou à dépasser certains objectifs choisis, tels queles 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ûtsdirects ou coûts indirects. Les coûts directs sont ceux occasionnés exclusivement par leprojet (par exemple, le salaire du personnel affecté à plein temps au projet). Les coûtsindirects, également appelés frais généraux, sont ceux affectés au projet par l’entrepriseréalisatrice au titre des coûts de gestion (par exemple, le salaire des dirigeants de lasociété). Les coûts indirects sont habituellement calculés à partir d’un pourcentage descoû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 objectifschoisis, 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 certainsaspects des contrats à prix forfaitaire et des contrats à coûts remboursables. Ces contratss’apparentent aux contrats à coûts remboursables en ce qu’ils ne sont pas plafonnés, lavaleur totale de l’accord n’étant pas précisée au moment de l’attribution. La valeur d’uncontrat pièces et main-d’œuvre peut augmenter comme s’il s’agissait d’un contrat à coûtsremboursables. Inversement, les contrats pièces et main-d’œuvre s’apparentent aussi auxcontrats à prix unitaire quand, par exemple, les taux unitaires sont fixés à l’avance parl’acheteur et le vendeur, ou lorsque les deux parties s’entendent sur les tarifs payés à lacaté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 desappels 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 duprojet, tels que les rapports sur les délais et les performances ?

Selon les besoins du projet, le plan de gestion des approvisionnements peut être formelou non, et très détaillé ou présenté dans ses grandes lignes. C’est un élément annexe du plande 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 demanière suffisamment détaillée pour que les vendeurs potentiels puissent déterminer s’ils sontcapables de le fournir. Le degré de détail varie en fonction de la nature de l’élément, desbesoins de l’acheteur ou du type de contrat prévu.



152

Certains domaines d’application reconnaissent différents types de description des travaux.Par exemple, dans certaines administrations, le terme description des travaux est réservé à unachat correspondant à un produit ou service bien précis et le terme description des objectifsest 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 ouun produit moins cher que celui initialement choisi. Chaque élément approvisionné nécessiteune description des travaux particulière. On peut toutefois regrouper plusieurs produits ouservices pour former un élément approvisionné unique associé à une seule description destravaux.

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’avancementou le support opérationnel de l’élément approvisionné après la fin du projet. Dans certainsdomaines 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’OFFRESLa 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 oupartie des documents d’offres nécessaires (voir la section 12.2.3.1). Les organisations gérantde gros volumes d’approvisionnement doivent établir une version normalisée de tous cesdocuments.

.2 Avis d’experts. Les méthodes basées sur l’avis d’experts sont développées dans la section5.1.2.2.

12.2

|12

.3



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 choixdu vendeur est basé sur le prix (achat de produits commerciaux ou standard), tandis que leterme offre est généralement employé lorsque d’autres considérations, telles que l’approcheou 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 termeemployé. On rencontre couramment les termes suivants pour désigner les différents types dedocuments 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 desréponses précises et complètes de la part des vendeurs potentiels. La description complètedes 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 decontrat, 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’approvisionnementpeut être défini par des règlements.

Les documents d’approvisionnement doivent être suffisamment précis pour que lesréponses soient homogènes et comparables, mais suffisamment souples pour permettre auxvendeurs de proposer des améliorations.

.2 Critères d’évaluation. Les critères d’évaluation permettent de classer ou d’attribuer une noteaux 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 uneexpérience préalable documentée dans des projets similaires »). Les critères d’évaluation sontsouvent intégrés aux documents d’approvisionnement.

Ces critères peuvent se limiter au prix d’achat si l’élément à approvisionner est facilementdisponible auprès d’un certain nombre de sources acceptables (le prix d’achat dans cecontexte comprend le coût de l’élément, ainsi que les dépenses annexes, telles que le coût dela 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ûtd’achat plus coût d’exploitation) ?

■ capacité technique : le vendeur possède-t-il, ou peut-on raisonnablement attendre de luiqu’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 luiqu’il développe, des processus et procédures de gestion à même d’assurer le succès duprojet ?

■ capacité financière : le vendeur dispose-t-il, ou peut-on raisonnablement attendre de luiqu’il obtienne, les ressources financières nécessaires ?

.3 Mises à jour de la description des travaux. La description des travaux est décrite à la section12.1.3.2. Les modifications apportées à une ou plusieurs descriptions de travaux peuvent êtreidentifiées au cours de la planification des appels d’offres.

12.3 APPELS D’OFFRESL’appel d’offres consiste à obtenir des réponses (soumissions et propositions) des vendeurspotentiels 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.



154

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éristiquesimportantes.

Si de telles listes ne sont pas disponibles, l’équipe de projet devra alors développer sespropres sources. Des informations générales sont largement disponibles sur Internet, dans lesannuaires de bibliothèques, auprès d’associations locales, dans des catalogues commerciauxet 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 vendeurspotentiels 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’uneoffre. Elles permettent de s’assurer que ceux-ci ont une compréhension claire et identique dela prestation à fournir (spécifications techniques, exigences contractuelles, etc.). Les réponsesaux questions posées peuvent être incorporées aux documents d’approvisionnement sousforme d’annexes. Durant ce processus, tous les vendeurs potentiels doivent être sur un mêmepied d’égalité.

.2 Annonces. On peut souvent élargir les listes de vendeurs potentiels en passant des annoncesdans des publications à large diffusion, comme les journaux, ou dans des publications spé-cialisées, comme les journaux professionnels. Certaines administrations doivent passer uneannonce publique pour certains types d’approvisionnement ; la plupart d’entre elles doiventfaire 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 contenuesdans les documents d’approvisionnement. Les offres peuvent être accompagnées d’une pré-sentation orale.

12.3

.1|

12.4

.2.1



12.4 CHOIX DES FOURNISSEURSLe choix des fournisseurs implique la réception des soumissions ou offres, et l’application decritères d’évaluation à la sélection d’un prestataire. Lors de la sélection des fournisseurs, denombreux 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 plusbas proposé n’est pas nécessairement le coût le plus bas, si le vendeur s’avère incapablede 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. Parexemple, 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 pluscomplè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éset 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 projetont 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é, lesmodalités et la loi applicables, les approches de gestion technique et commerciale, le finan-cement du contrat et le prix.



156

Dans le cas d’éléments d’approvisionnement complexes, la négociation du contrat peutêtre un processus indépendant comportant des données d’entrée (par exemple, une liste deproblèmes ou de questions non résolus) et des données de sortie (par exemple, un protocoled’accord) propres.

.2 Système de pondération. Un système de pondération est une méthode servant à quantifierdes donnés qualitatives pour minimiser les effets des préjugés individuels lors du choix duvendeur. 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) demultiplier le cœfficient par le classement et 4) de faire le total des résultats obtenus pourarriver à 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 potentielpeut se voir imposer de proposer un chef de projet ayant des qualifications particulières, parexemple 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 relationlégale et peut être porté devant les tribunaux. L’accord peut être simple ou complexe, reflétanthabituellement, 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éduresformelles (habituellement appelées délégation des pouvoirs d’approvisionnement) identifiantspé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évisionet d’approbation, l’obligation légale qu’implique un contrat signifie, en principe, qu’il serasoumis à 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 importantsentrepris 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 CONTRATSL’administration des contrats est le processus assurant que les performances du vendeurré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’administrationdes contrats consiste à gérer les interfaces entre les divers prestataires. Au vu de l’obligationlégale qu’implique la relation contractuelle, il est impératif que l’équipe de projet soitconsciente des conséquences juridiques des actions prises lors de l’administration des contrats.

12.4

.2.2

|12

.5.1

.4



L’administration des contrats comprend l’application des processus de gestion de projetconvenant aux relations contractuelles, et l’intégration des données de sortie de ces processusdans 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 degestion 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 etles performances techniques du contractant ;

■ le contrôle de la qualité, décrit à la section 8.3, pour inspecter le produit du contractant eten vérifier la conformité ;

■ le contrôle des changements, décrit à la section 4.3, pour s’assurer que les changementssont 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 livrablesachevé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 miseen œ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 letravail du vendeur n’est pas satisfaisant, la décision de résilier le contrat sera aussi traitéecomme une demande de changement. Les changements contestés, à savoir ceux pour lesquelsle vendeur et l’équipe de gestion de projet n’ont pas pu se mettre d’accord sur le payeur, sontappelés, selon les cas, réclamations, différends ou appels.

.4 Factures des vendeurs. Le vendeur doit envoyer des factures au fur et à mesure pourdemander le paiement du travail effectué. Les conditions de facturation, documents justifica-tifs nécessaires compris, sont définies dans le contrat.



158

12.5.2 Outils et méthodes d’administration des contrats.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’autorisationnécessaires à l’autorisation des changements. Le système de contrôle des changements ducontrat 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 dansquelle mesure le vendeur atteint les objectifs contractuels. Les rapports d’avancement ducontrat doivent être intégrés aux rapports d’avancement intégrés du projet, décrits à la section10.3.

.3 Système de règlement. Les règlements versés au vendeur sont habituellement gérés par lesystème comptable de l’entreprise réalisatrice. Dans les projets de plus grande envergure, dansle 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 approbationspar 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 desavertissements dans le cas de performances insuffisantes, et des modifications ou clarificationsapportées au contrat.

.2 Changements du contrat. Les changements (approuvés ou non) sont répercutés à l’aide desprocessus 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 correspondentalors aux « règlements ».

12.6 CLÔTURE DU CONTRATLa clôture du contrat ressemble à la clôture administrative (décrite à la section 10.4) car elleimplique à la fois une vérification du produit (le travail a-t-il été effectué convenablement etde 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). Lesmodalités du contrat peuvent imposer des procédures spécifiques de clôture. La résiliationd’un contrat constitue un cas particulier de clôture.

12.5

.2|

12.6

.3.2



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 etapprouvé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, parexemple) 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 approvisionnementsjusqu’à 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’approvisionnementpour 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 administrativeet 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éesdans le contrat.

SECTION III

ANNEXES

A. Processus de normalisation du Projet Management Institute

B. Evolution du Guide du référentiel des connaissances engestion de projet du PMI (A Guide to the ProjectManagement 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 deprojet


Annexe A

Processus de normalisationdu 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 lesmodifications simultanées des procédures de gouvernance du PMI.

A.1 LES NORMES DU PMILes 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 normalisationdu PMI, avec l’avis et sous réserve de l’accord du Project Management Standards ProgramMember 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 PMILes 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 normalisationdu 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 AdvisoryGroup et décide avec lui de les accepter ou de les rejeter.


Annexe A — Processus de normalisation du Projet Management Institute

164

■ Le directeur informe le ou les auteurs potentiels de sa décision et de la raison la motivant.Si une proposition approuvée nécessite un financement dépassant le budget alloué pourla 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 doiventsigner 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é etdécident de son transfert à des personnes compétentes pour un examen complémentaireou 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 enrevue 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éed’étude d’un mois minimum à six mois maximum, b) l’avis de disponibilité pour étude dela version pour commentaire dans le PM Network® (et/ou sur d’autres supports similaireset 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 pourcommentaire comprend une notice demandant l’envoi des commentaires au directeur dela 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 etdoivent 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 lescommentaires reçus avec le PMI Standards Program Member Advisory Group et travailleen collaboration avec le ou les auteurs, et d’autres personnes au besoin, à l’incorporationdes commentaires pertinents. En présence d’un grand nombre de commentaires, le PMIStandards Program Member Advisory Group peut choisir de répéter le processus d’étudede la version pour commentaire.

■ Lorsque le directeur de la normalisation du PMI et le PMI Standards Program MemberAdvisory Group ont approuvé le document proposé, le directeur le soumet sans délai audirecteur administratif pour révision finale et accord. Le directeur administratif vérifie laconformité du document aux procédures et s’assure que l’avis des membres a bien été prisen compte. Il peut décider de : a) approuver le document tel que soumis, b) rejeter ledocument ou c) demander la répétition du processus d’étude. Il motive sa décision.

Ann

exe

A

Annexe A — Processus de normalisation du Projet Management Institute


165

A.3 ATTRIBUT DU STATUT DE NORME À DES OUVRAGES EXTÉRIEURSLes normes établies par des ouvrages émanant d’autres organisations ou individus sontpublié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’acceptercomme 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 lePMI Standards Program Member Advisory Group, au moins trois personnes compétentespour 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écidentde : 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) demanderune 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 lamotivant.

■ Lorsque le directeur de la normalisation du PMI et le PMI Standards Program MemberAdvisory Group ont approuvé le document proposé, le directeur le soumet sans délai audirecteur administratif pour révision finale et accord. Le directeur prépare à l’attention dudirecteur administratif une proposition de collaboration éventuelle avec le ou les auteursdu document.

■ Le directeur administratif du PMI vérifie la conformité du document avec les procédureset s’assure que l’avis d’un nombre suffisant de membres a été pris en compte. Il peutdé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.


Annexe B

Évolution du Guide du référentiel desconnaissances en gestion de projet du PMI

B.1 LES PREMIERS PASLe Project Management Institute (PMI) est fondé en 1969 sur l’idée qu’il existe de nombreusespratiques 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 pratiquescommence à ê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 brancheslocales. 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 delongues réunions d’un groupe du sud de l’Ontario comprenant Dave MacDonald, DaveNorman, Bob Spence, Bob Hall et Matt Parry. La composante « gestion des coûts » est élaborée


Annexe B — Evolution du Guide du référentiel des connaissances en gestion de projet du PMI

168

à la suite de longues réunions au sein du service des coûts de Stelco, sous la direction deDave Haeney et Larry Harrison. D’autres composantes sont élaborées par le groupe ESA. JohnAdams 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 ladirection 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 ducontenu, gestion des coûts, gestion des délais, gestion de la qualité, gestion des ressourceshumaines et gestion des communications ;

■ des lignes directrices pour l’accréditation (reconnaissance de la qualité des programmesproposés par des structures d’enseignement) et pour la certification (reconnaissance de laqualification 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 estaccrédité en 1983 et les premiers diplômés « Professionnels en gestion de projet » (PMP) sontcertifiés en 1984.

B.2 MISE À JOUR DES ANNÉES 1986–87La publication du rapport de base de l’ESA entraîne de nombreuses discussions au sein duPMI sur la pertinence des normes. En 1984, le directoire du PMI approuve un deuxième projetde 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 disciplinesidentifié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 directoiredu PMI et publié pour commentaires dans le Project Management Journal d’août 1986. Lesprincipaux 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 sonenvironnement externe, et entre la gestion de projet et la gestion en général.

Ann

exe

B



169

■ 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 defaç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é enaoût 1987 sous le titre de The Project Management Body of Knowledge.

B.3 MISE À JOUR DE 1996Le débat sur la forme, le contenu et la structure des normes clés du PMI continue après lapublication de la version de 1987. En août 1991, le directeur de la normalisation du PMI, AlanStretton, lance un projet de mise à jour du document sur la base des commentaires adresséspar les membres. L’élaboration du document révisé dure plusieurs années et découle d’unesérie de documents de travail largement diffusés et d’ateliers durant les séminaires du PMI deDallas, Pittsburgh et San Diego.

En août 1994, le comité de normalisation du PMI émet une version pour commentaire dudocument. 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 ofKnowledge (PMBOK® Guide) représente l’achèvement du projet lancé en 1991. Une liste descollaborateurs 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 neconnaissent 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 leré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 principessolides 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 sectioncomporte trois chapitres :

■ « Introduction », qui définit l’objectif du document et explique en détail les termes projetet 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 lescompétences clés en gestion en général.

■ « Processus de la gestion de projet », qui décrit les interactions entre les divers domainesde la gestion de projet.



170

3. Nous avons élaboré une définition revue et corrigée du projet. Nous souhaitions une défi-nition qui soit à la fois exhaustive (il devait être impossible d’identifier comme projet uneentreprise généralement considérée comme telle mais ne répondant pas à la définition) etexclusive (elle ne devait pas décrire une entreprise répondant à la définition mais n’étant pasgénéralement considérée comme un projet). Nous avons trouvé de nombreuses définitions duprojet dans les ouvrages existants, et aucune ne nous a semblé complètement satisfaisante. Lanouvelle définition prend en compte les caractéristiques uniques d’un projet : un projet estune 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 lesphases 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 nombreet 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’uneorganisation 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 existaitdepuis un certain temps un consensus, visant à reconnaître la gestion de projet comme unprocessus intégratif. Le chapitre 4, « Gestion de l’intégration du projet », reconnaît l’importancede 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 humainesparticuliers uniquement, ou presque, au contexte du projet.

8. Nous avons choisi de décrire les disciplines par les processus qui les composent. Larecherche 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 estdécrit en termes de données d’entrée, données de sortie et outils et méthodes. Les donnéesd’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). Lesoutils 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 plusieursautres 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 pratiquespeuvent facilement être assimilés en ajoutant un nouveau processus, en modifiant l’ordredes 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 permetde comparer les principaux titres de chapitres du document de 1987 à ceux du document de1996 :

Ann

exe

B



171

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 desconnaissances en gestion de projet (AGuide to the Project Management Body ofKnowledge)

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 de1996 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èrementutiles. En premier lieu, les sujets inclus ne sont pas exhaustifs, c’est-à-dire qu’ils n’incluent pasde pratiques novatrices ou inhabituelles. En second lieu, de nombreux éléments étant utilisésdans 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é dediverses manières aux différentes versions du document de 1996. Le PMI les remercie de leuraide.

Comité de normalisationLes 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



172

CollaborateursEn plus des membres du comité de normalisation, les personnes suivantes ont contribué pardes 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 duprojet »)

■ David T. Hulett, D. T. Hulett & Associates (chapitre 11, « Gestion des risques du projet »)

■ Edward Ionata, Bechtel/Parsons Brinckerhoff (chapitre 10, « Gestion des communicationsdu projet »)

■ John M. Nevison, Duncan•Nevison (chapitre 9, « Gestion des ressources humaines duprojet »)

■ 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 duprojet »)

■ 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éviseursEn 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

Ann

exe

B



173

■ 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

■ 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 productionMention 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



174

Ann

exe

B |

Ann

exe

C


Annexe C

Collaborateurs et réviseursdu Guide PMBOK®

Édition 2000

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

C.1 PMI PROJECT MANAGEMENT STANDARDS PROGRAM MEMBER ADVISORY GROUPLes personnes suivantes étaient membres du PMI Standards Program Member Advisory Grouppendant 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 duGuide 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


Annexe C — Collaborateurs et réviseurs du Guide PMBOK®, Édition 2000

176

C.3 COLLABORATEURSEn plus des membres du PMI Standards Program Member Advisory Group et de l’équipe deprojet du Guide PMBOK®, les personnes suivantes ont contribué par des textes originaux oudes 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, « Gestiondes 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 deprojet du Guide PMBOK® et des collaborateurs, les personnes suivantes ont adressé desremarques 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

Ann

exe

C



177

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



178

C.5 CONTRIBUTIONS AUX DOCUMENTS PRÉCÉDENTSCertaines portions de l’édition de 1996 et d’autres documents antérieurs sont incluses danscette é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 leurcontribution.

C.6 PERSONNEL DE PRODUCTIONNous 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 GuidePMBOK®

■ 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

Ann

exe

C|

Ann

exe

D


Annexe D

Notes

CHAPITRE 1. INTRODUCTION1. 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. NewYork : McGraw-Hill.

CHAPITRE 2. CONTEXTE DE LA GESTION DE PROJET1. 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 fromManagement. New York : The Free Press.

5. Pfeffer, Jeffrey. 1992. Managing with Power: Politics and Influence inOrganizations. 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 bonnepratique 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 PROJET1. The American Heritage Dictionary of the English Language, 3ème édition.

CHAPITRE 4. GESTION DE L’INTÉGRATION DU PROJETAucune note pour ce chapitre.


Annexe D — Notes

180

Annexe D — Notes

CHAPITRE 5. GESTION DU CONTENU DU PROJET1. Turner, J. Rodney. 1992. The Handbook of Project-Based Management.

2. Ïyigün, M. Güven. 1993. « A Decision Support System for R&D ProjectSelection and Resource Allocation Under Uncertainty ». Project ManagementJournal 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 PROJETAucune note pour ce chapitre.

CHAPITRE 7. GESTION DES COÛTS DU PROJETAucune note pour ce chapitre.

CHAPITRE 8. GESTION DE LA QUALITÉ DU PROJET1. 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 PROJETAucune note pour ce chapitre.

CHAPITRE 11. GESTION DES RISQUES DU PROJETAucune note pour ce chapitre.

CHAPITRE 12. GESTION DES APPROVISIONNEMENTS DU PROJETAucune note pour ce chapitre.

Ann

exe

D|

Ann

exe

E


Annexe E

Extensions des champsd’application

E.1 NÉCESSITÉ D’EXTENSIONS DES CHAMPS D’APPLICATIONDes 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 laplupart 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 projetdoit 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 denombreux 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 pratiqueset 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écoulantde 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 courantesdé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 auxresponsabilité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 ;


Annexe E — Extensions des champs d’application

182

■ organisées de la même manière que cet ouvrage, c’est-à-dire qu’elles identifient et décri-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èred’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 êtreabordés dans des manuels ou guides pouvant être émis comme normes du PMI, mais ilsne correspondent pas à ce que l’on entend par « extensions »).

E.2 CRITÈRES D’ÉLABORATION DES EXTENSIONS DES CHAMPS D’APPLICATIONLes 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 (oupresque) à 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 demettre 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 duprocessus de normalisation de gestion de projet du PMI à laquelle sont soumises toutesles autres normes du PMI.

E.3 PUBLICATION ET FORMAT DES EXTENSIONS DES CHAMPS D’APPLICATIONLes 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 avecl’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 lesinformations développées.

■ Les sections et les paragraphes de cet ouvrage qui ne sont pas développés ne sont pasrepris 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’APPLICATIONLorsqu’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éeset mises à jour conformément au processus décrit ci-après.

Ann

exe

E



183

■ 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 uneautre organisation externe au PMI, mais approuvée par le PMI Standards Program MemberAdvisory Group et le directeur de la normalisation du PMI. On donnera la préférence à unco-parrainage avec le PMI. Toutes les approbations devront prendre la forme d’un accordofficiel écrit entre le PMI et l’entité de parrainage, lequel accord devra inclure, entresautres, l’accord des deux parties concernant les droits de propriété intellectuelle et lesdroits de publication de l’extension.

■ Un projet d’élaboration, de publication et/ou de mise à jour d’une extension doit êtreapprouvé par le programme de normalisation du PMI. L’autorisation de lancer, élaborer etmettre à jour une extension doit émaner du PMI ; celle-ci fera l’objet d’un accord entre ouau 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 etle directeur de la normalisation du PMI, leur demandera conseil et sollicitera leur appuitout 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 aucours de son élaboration, pour détecter tout conflit ou toute similitude avec des projetssemblables qui seraient en cours de réalisation.

■ Le groupe commanditaire préparera une proposition d’élaboration de l’extension. Cetteproposition 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 sontaffectées. Elle devra également contenir l’engagement d’un nombre suffisant de rédacteurset réviseurs qualifiés ; l’identification des besoins en financement, y compris les coûts dereproduction, d’affranchissement, de téléphone, de mise en page, etc. ; l’engagement derespecter les procédures d’élaboration et de mise à jour des extensions de normes duPMI ; 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 projetqui 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évisionspériodiques de l’extension avec des rapports à l’équipe du programme de normalisationdu 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 auprocessus de normalisation du PMI. Le directeur de la normalisation du PMI déterminerasi 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 dece processus de détermination, le directeur de la normalisation du PMI sollicitera l’aide duPMI Standards Program Member Advisory Group et, s’il y a lieu, d’un groupe de personnesqualifié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 MemberAdvisory Group, effectuera le suivi et apportera son aide à l’élaboration du projetapprouvé.

■ L’organisation commanditaire élaborera l’extension conformément à la charte du projetapprouvée, ce qui inclura également une coordination avec l’équipe de normalisation duPMI pour ce qui est de l’aide, de la révision et des commentaires.

■ Une fois l’extension achevée à la convenance de l’organisation commanditaire, ellesera soumise au directeur de la normalisation du PMI qui se chargera des processusd’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 devracomporter 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 auplan approuvé.



184

Ann

exe

E|

Ann

exe

F


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 surle sujet sont publiés régulièrement. Les organismes listés ci-dessous offrent un large éventailde produits et services pouvant être utiles à toutes les personnes intéressées par la gestion deprojet.

F.1 ORGANISMES TECHNIQUES ET PROFESSIONNELS Cet ouvrage a été élaboré et publié par le Project Management Institute (PMI) dont voici lescoordonnées :

Project Management InstituteFour Campus BoulevardNewtown Square, PA 19073-3299 États-UnisTéléphone : +610/356-4600Fax : +610/356-4647Courriel : [email protected] : 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 del’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 deprojet) (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 etrecherche économique) (CERIK)

Téléphone : +822-3441-0801 Fax: +822-544-6234

■ Defense Systems Management College Alumni Association (Association des anciens élèvesdu Defense Systems Management College) (DSMCAA)

Téléphone : +703/960-6802 Fax: +703/960-6807

■ Engineering Advancement Association of Japan (Association japonaise d’avancement del’ingénierie) (ENAA)

Téléphone : +81-3-3502-4441 Fax: +81-3-3502-5500


Annexe F — Autres sources d’informations sur la gestion de projet

186

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

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

■ International Project Management Association (Association internationale de gestion deprojet) (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 projetet 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 quipeuvent être à même de fournir des informations supplémentaires sur la gestion de projet. Parexemple :

■ Academy of Management (Académie de gestion)

■ American Management Association International (Association américaine internationale degestion)

■ 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 dansle 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 desachats)

■ National Contract Management Association (Association nationale de gestion de contrats)

■ Society for Human Resource Management (Association de gestion des ressourceshumaines)

Ann

exe

F

Annexe F — Autres sources d’informations sur la gestion de projet


187

■ 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 ettechniques du monde entier peuvent généralement être obtenues sur Internet.

F.2 MAISONS D’ÉDITIONLe PMI est le plus gros éditeur d’ouvrages sur la gestion de projet. De nombreuses maisonsd’édition publient des ouvrages sur la gestion de projet et les domaines connexes. Celles quipublient 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 incluentune bibliographie ou une liste exhaustive d’ouvrages à consulter.

F.3 FOURNISSEURS DE PRODUITS ET PRESTATAIRES DE SERVICESLes 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 destirages à 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 gestionde projet (les diplômés PMP) et d’autres acteurs de la gestion de projet, en mettant en rapportles acteurs et les coordinateurs de formation avec des prestataires de services de formation etdes fournisseurs de produits qualifiés. Une liste des prestataires de services de formationagréés (les R.E.P.) et des services correspondants peut être obtenue sur le sitehttp://www.pmi.org/education/rep.

F.4 ORGANISMES D’ENSEIGNEMENTDe nombreuses universités et écoles d’enseignement supérieur offrent des programmes deformation 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.


Annexe G

Résumé des disciplines de lagestion de projet

GESTION DE L’INTÉGRATION DU PROJETSous-ensemble de la gestion de projet englobant les processus nécessaires à la coordinationadé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 tirerun document logique et cohérent ;

■ la mise en œuvre du plan de projet : concrétiser le plan de projet en accomplissant lesactivités le composant ;

■ le contrôle intégré des changements : coordonner les modifications sur l’ensemble duprojet.

GESTION DU CONTENU DU PROJETSous-ensemble de la gestion de projet englobant les processus nécessaires pour s’assurer quetoutes les activités nécessaires au succès du projet, et seulement celles-ci, sont incluses dansle 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 aucontenu du projet.


Annexe G — Résumé des domaines de compétence de la gestion de projet

190

GESTION DES DÉLAIS DU PROJETSous-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 desactivité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 PROJETSous-ensemble de la gestion de projet recouvrant les processus nécessaires à l’exécution duprojet dans les limites budgétaires approuvées, elle comporte :

■ la planification des ressources : déterminer la nature (personnes, équipement, matériel) etla 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 ressourcesné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 PROJETSous-ensemble de la gestion de projet recouvrant les processus nécessaires pour s’assurer quele 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 duprojet 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 PROJETSous-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 soientaffectées au projet et y travaillent ;

■ le développement de l’équipe : développer les compétences individuelles et de groupeafin d’améliorer les performances du projet.

Ann

exe

G

Annexe G — Résumé des domaines de compétence de la gestion de projet


191

GESTION DES COMMUNICATIONS DU PROJETSous-ensemble de la gestion de projet recouvrant les processus nécessaires à la rédaction, lacollecte, 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 sousquelle forme) ;

■ la diffusion de l’information : s’assurer que les informations nécessaires sont mises, entemps 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 PROJETLa 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 minimisela 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épercussionssur le projet et en établir les caractéristiques ;

■ l’analyse qualitative des risques : analyser qualitativement les risques et les circonstancesafin 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 risqueset é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 duprojet ;

■ le suivi et le contrôle des risques : surveiller les risques résiduels, identifier les nouveauxrisques, mettre en œuvre les plans d’atténuation des risques et évaluer l’efficacité de cesderniers pendant le cycle de vie du projet.

GESTION DES APPROVISIONNEMENTS DU PROJETSous-ensemble de la gestion de projet recouvrant les processus nécessaires à l’obtention, endehors de l’entreprise réalisatrice, des produits et des services qui permettront de réaliser lecontenu 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 identifierdes 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.

SECTION IV

GLOSSAIRE ET INDEX

Glossaire

Index


GLOSSAIRE

1. INCLUSIONS ET EXCLUSIONSCe glossaire comprend des termes qui :

■ s’appliquent presque exclusivement à la gestion de projet (par exemple, cahier descharges, 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 (parexemple, 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 del’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 termede référence (par exemple, « rapport des écarts majeurs » est défini alors que « rapporterles é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 gestiondes risques du projet, car de nombreux termes utilisés dans ces disciplines s’appliquentpresque exclusivement à la gestion de projet ;

■ de nombreux termes relatifs à la gestion de la qualité du projet, puisqu’ils y sont employésavec 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 sensrestreint et particulier aux différents champs d’application.


Glossaire

196

2. ABRÉVIATIONS COURANTESAC 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èchesAON Activity-on-Node Activités sur nœuds

AS Actual start date Date de début réelleBAC 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ôleCCB Change Control Board Comité de contrôle des changements

CPFF Cost-Plus-Fixed-Fee Contrat à rétribution fixeCPIF Cost-Plus-Incentive-Fee Contrat en dépenses contrôlées avec

intéressementCPI Cost Performance Index Indice de performance des coûts (IPC)

CPM Critical Path Method Méthode du chemin critiqueCV Cost Variance Écart de coûts (EC)DD Data Date Date de mise à jourDU Duration Durée

EAC Estimate At Completion Prévision à l’achèvementEF Early Finish Date Date de fin au plus tôtES Early Start Date Date de début au plus tôt

ETC Estimate (or Estimated) to Coût estimé pour achèvementComplete (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-FinFFP 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 graphiqueIFB Invitation For Bid Appel à candidaturesLF Late Finish Date Date de fin au plus tard

LOE Level Of Effort Niveau de chargeLS Late Start Date Date de début au plus tard

MPM Modern Project Management Gestion de projet moderneOBS Organization(al) Breakdown Organigramme fonctionnel

StructurePC Percent Complete Pourcentage d’avancement (physique)

PDM Precedence Diagramming Méthode des antécédentsMethod

PERT Program Evaluation and Review Technique d’évaluation et de suivi des Technique programmes

PF Planned Finish Date Date de fin prévuePM (1) Project Management Gestion de projet

(2) Project Manager Chef de projet

Ab

bre

viat

ions

cou

rant

es|

Act

ivité

Glossaire


197

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

PMP® Project Management Professional Professionnel en gestion de projetPS Planned Start Date Date de début planifiéePV Planned Value Valeur prévueQA 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 restanteRFP Request For Proposal Appel d’offresRFQ 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élaisSS 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 projetTF (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ÉFINITIONSUn assez grand nombre de mots, définis ci-dessous ont, dans les dictionnaires une définitionplus 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 esten 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 aussiterme connexe).

Acceptation des risques / Risk Acceptance. L’utilisation de cette technique du processusde planification des stratégies de réponse indique que l’équipe de projet a décidé de ne pasmodifier le plan de projet pour pallier à un risque, ou n’est pas en mesure de déterminer uneautre stratégie de réponse adéquate.

Acteur / Stakeholder. Personnes ou organisations activement impliquées dans le projet, oudont 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 sesrésultats.

Action corrective / Corrective Action. Modification apportée pour aligner les performancesfutures du projet sur le plan du projet.

Activité / Activity. Élément de travail réalisé dans le cadre d’un projet. Habituellement, unedurée prévue, un coût prévu et des besoins prévus en ressources sont définis pour chaqueactivité. Les activités peuvent être décomposées en tâches.


Glossaire

198

Activité critique / Critical Activity. Activité située sur le chemin critique. Généralementdé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 rarementutilisé dans le contexte d’un projet.

Activité fictive / Dummy Activity. Activité de durée nulle utilisée pour figurer un lien logiquedans la méthode du diagramme fléché. L’activité fictive est utilisée lorsqu’un lien logique nepeut 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é sous-critique / Near-Critical Activity. Activité dont la marge totale est de faiblevaleur.

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. Voiraussi 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 deshypothè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 encompte les probabilités ou les risques, ainsi que le coût ou les avantages de chaquechemin logique d’événements et de décisions futures.

Analyse qualitative des risques / Qualitative Risk Analysis. Analyse qualitative desrisques et des conditions permettant d’établir la priorité de leurs effets sur les objectifs duprojet. Elle comprend l’évaluation de la probabilité et de l’impact des risques du projet etl’utilisation de méthodes telles que la matrice des probabilités et des impacts pour classerles 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 laprobabilité 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 lessimulations 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 termeappel 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 desoffres de la part de fournisseurs potentiels de produits ou de services. Dans certainsdomaines d’application, il peut avoir une signification plus restreinte ou spécifique.

Appel d’offres / Solicitation. Obtention de devis, soumissions, offres ou propositions, selonle cas.

Assurance de la qualité / Quality Assurance (QA). (1) Processus d’évaluation systématiquedes performances d’un projet, afin de s’assurer que le projet sera conforme aux normes dequalité 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. Parexemple, dans une liaison Fin-Début avec une avance de 10 jours, le successeur peutdébuter au plus tôt 10 jours avant l’achèvement de l’antécédent. Voir aussi Retard.

Act

ivité

crit

ique

|C

heva

uche

men

t

Glossaire


199

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 gestiondes risques. Les programmes de « leçons retenues » utilisent une base de données derisques. 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 laméthode du chemin critique, et la technique d’évaluation et de suivi des projets (PERT). Lesboucles 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 dechaque activité.

Cadre hiérarchique / Line Manager. (1) Responsable de tout groupe fabriquant un produitou 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étationcommune du contenu du projet entre les acteurs. Au fur et à mesure de l’avancement duprojet, il peut s’avérer nécessaire de revoir ou de peaufiner le cahier des charges, afin dereflé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 detoutes les activités inachevées d’un réseau. Ces dates sont calculées à l’aide de la logiquedu réseau, en partant de la date de fin du projet. Cette date de fin peut avoir été calculéeau 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 causestechniques, 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 dessecteurs industriels similaires), soit en fonction du type de client (par exemple, interne ouexterne, 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’unautre é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 desactivités dont la marge est inférieure ou égale à une valeur donnée souvent nulle. Il s’agitdu 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 dansun diagramme réseau du projet.

Chevauchement / Overlap. Voir Avance.


Glossaire

200

Choix des fournisseurs / Source Selection. Sélection parmi les fournisseurs potentiels.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ésolutionde 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èsanalyse 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 parchevauchement d’activités normalement effectuées en séquence, telles que la conceptionet la construction. Quelquefois confondue avec ingénierie simultanée.

Contenu / Scope. Ensemble des produits et services devant résulter d’un projet. Voir aussiContenu du projet et Contenu du produit.

Contenu du produit / Product Scope. Caractéristiques et fonctions d’un produit ou d’unservice.

Contenu du projet / Project Scope. Ensemble des travaux devant être réalisés afin de livrerun 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 decontrats :■ 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 biendé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 lelivrer. 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’unecommission représentant le bénéfice du vendeur. Ces coûts sont généralement classésen 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 auprojet). Les coûts indirects, également appelés frais généraux, sont ceux affectés auprojet par l’entreprise réalisatrice au titre de coûts de gestion (par exemple, le salaire desdirigeants de la société). Les coûts indirects sont habituellement calculés à partir d’unpourcentage 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. Cescontrats s’apparentent aux contrats à coûts remboursables en ce qu’ils ne sont pas pla-

Cho

ix d

es fo

urni

sseu

rs|

Coû

t b

udgé

té d

u tr

avai

l pré

vu (C

BTP

)

Glossaire


201

fonnés, la valeur totale de l’accord n’étant pas précisée au moment de l’attribution. Lavaleur d’un contrat pièces et main-d’œuvre peut augmenter comme s’il s’agissait d’uncontrat à 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 sontfixés à l’avance par l’acheteur et le vendeur, ou lorsque les deux parties s’entendent surles 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 duvendeur.

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 deperformance définis à l’avance.

Contrat à rétribution fixe / Cost Plus Fixed Fee Contract (CPFF). Type de contrat parlequel l’acheteur rembourse au vendeur les coûts réels autorisés (tels que définis auxtermes 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 certainscritè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 correctivesappropriées, si nécessaire.

Contrôle de la qualité / Quality Control (QC). (1) Processus de suivi de certains résultatsd’un projet afin de déterminer s’ils sont conformes aux normes de qualités applicables etd’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’unprojet.

Contrôle des stratégies de réponse / Risk Response Control. Suivi de la mise en placeet 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ù plusieurschemins 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 quantitativedes risques d’un planning, des risques significatifs peuvent se produire à cet endroit.

Correction à chaud / Workaround. Réponse à une menace. Se distingue du développementdes stratégies de réponse en ce sens qu’elle n’est pas prévue avant l’occurrence du risqueen 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 forteau 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’unesimulation, outil de l’analyse quantitative des risques.

Coût budgété du travail prévu (CBTP) / Budgeted Cost of Work Scheduled (BCWS). Ceterme a été remplacé par le terme Valeur prévue.


Glossaire

202

Coût budgété du travail réalisé (CBTR) / Budgeted Cost of Work Performed (BCWP).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 laqualité comprend la planification, le contrôle et l’assurance de la qualité, ainsi que lesreprises.

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 destechniques de prévision du CEA comportent des réajustements de l’estimation initiale, enfonction 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 accomplisdurant une période définie (il peut inclure soit des heures de travail directes ou des coûtsdirects uniquement, soit l’ensemble des coûts y compris les coûts indirects). Voir aussivaleur acquise.

Coût réel du travail réalisé (CRTR) / Actual Cost of Work Performed (ACWP). Ce termea été remplacé par le terme coût réel.

Cycle de vie du projet / Project Life Cycle. Ensemble généralement séquentiel des phasesdu projet, dont le nom et le nombre sont déterminés en fonction des besoins de suivi parl’organisation ou les organisations impliquées dans le projet.

Date cible de fin de projet / Target Completion Date (TC). Date imposée qui contraint ouinfluence 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 jalondonné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) peuventdémarrer, compte tenu de la logique du réseau et des contraintes de délai. Une date dedébut au plus tôt peut changer lorsque le projet avance et que des modifications sontapportées au plan de projet.

Date de début cible / Target Start Date (TS). Date à laquelle le démarrage d’une activité estrequis.

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 datede 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éellementcommencé.

Date de fin / Finish Date. Date à laquelle une activité est complètement terminée. Souventassociée à l’un des qualificatifs suivants : réelle, prévue, estimée, planifiée, au plus tôt, auplus 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, datela plus tardive à laquelle une activité peut se terminer sans retarder une étape jalon donnée(généralement la fin du projet).

Coû

t b

udgé

té d

u tr

avai

l réa

lisé

(CB

TR)

|D

iagr

amm

e ré

seau

chr

onol

ogiq

ue

Glossaire


203

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 datede fin au plus tôt peut changer lorsque le projet avance et que des modifications sontapportées au plan de projet.

Date de fin cible / Target Finish Date (TF). Date à laquelle l’achèvement d’une activité estrequise.

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 finau 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é soitconsidé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 êtreeffectuées pour produire les différents produits livrables du projet.

Définition du contenu / Scope Definition. Décomposition des principaux produits livrablesen é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 duprojet.

Développement de plans alternatifs / Contingency Planning. Élaboration d’un plan degestion 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 à laplanification des activités d’un projet. Dans le diagramme à barres classique, les activitésou d’autres éléments du projet sont listés sur la partie gauche du diagramme, l’échelle detemps apparaît horizontalement en haut, et la durée des activités est représentée par desbarres 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) pourla 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ésententla durée. Essentiellement, il s’agit d’un diagramme à barres dans lequel est incluse lalogique du réseau.


Glossaire

204

Diagramme réseau du projet / Project Network Diagram. Représentation graphique desliens logiques entre les activités d’un projet. Toujours tracé de la gauche vers la droite pourreflé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 autrespériodes non ouvrées) nécessaires à l’exécution d’une activité ou de tout autre partie duprojet. Généralement exprimée en jours ouvrés ou semaines ouvrées. Quelquefoisconfondue à 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.É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éthodede 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 detous 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 logiquedes activités, de leurs durées et des ressources nécessaires afin d’élaborer le planning duprojet.

É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 deprojet.

Estimation / Estimate. Évaluation d’un résultat quantitatif probable. Habituellement appliquéeaux 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 (parexemple, 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 estimationdétaillée).

Estimation de la durée des activités /Activity Duration Estimating. Estimation du nombred’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 uneestimation.

Étape jalon / Milestone. Événement significatif d’un projet, généralement la disponibilité d’unproduit livrable principal.

Dia

gram

me

rése

au d

u p

roje

t|

Ges

tion

des

dél

ais

du

pro

jet

Glossaire


205

Évaluation du coût du cycle de vie / Life-Cycle Costing. Concept consistant à inclure lescoûts d’acquisition, de fonctionnement et d’élimination lors de l’évaluation de possibilitésdiverses.

Événement à risque / Risk Event. Événement ponctuel pouvant affecter le projet de façonpositive ou négative.

Événements sur nœuds / Event-on-Node. Technique de représentation graphique parréseau dans laquelle les événements sont représentés par des rectangles (ou nœuds) reliésentre eux par des flèches indiquant l’ordre dans lequel ils doivent se succéder. Utilisée dansla technique d’évaluation et de suivi des projets (PERT).

Fiches de contrôle / Control Charts. Graphiques représentant les résultats d’un processussur une période de temps donnée et par rapport à des limites de contrôle établies. Cesfiches permettant de déterminer si le processus remplit son rôle de contrôle, ou s’il doit êtreajusté.

Flèche / Arrow. Représentation graphique d’une activité. Voir aussi Méthode du diagrammefléché.

Flottement / Slack. Terme utilisé dans la méthode du diagramme fléché comme équivalentde marge.

Gestion de la qualité du projet / Project Quality Management. Domaine de compétencede la gestion de projet regroupant les processus nécessaires pour s’assurer que le projetré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 courammentutilisé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 coordinationadéquate des divers éléments du projet. Il comporte l’élaboration du plan de projet, la miseen œ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 auxbesoins du projet.

Gestion d’ensemble des changements / Overall Change Control. Coordination deschangements 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, lagestion 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 desinformations concernant le projet, de façon adéquate et en temps voulu. Il est constitué dela planification de la communication, la diffusion de l’information, les rapports d’avancementet 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 leslimites 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 dela gestion de projet regroupant les processus nécessaires pour assurer l’achèvement duprojet 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.


Glossaire

206

Gestion des ressources humaines du projet / Project Human Resource Management.Domaine de compétence de la gestion de projet comprenant les processus permettantl’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 del’équipe.

Gestion des risques du projet / Project Risk Management. Processus systématiqued’identification, d’analyse et de réponse aux risques du projet. Il implique qu’on maximisela 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 dela gestion des risques, l’identification, l’analyse qualitative et l’analyse quantitative desrisques, 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étencede la gestion de projet recouvrant les processus nécessaires pour s’assurer que toutes lesactivités nécessaires au succès du projet, et seulement celles-ci, font partie du projet. Ilcomporte le démarrage, la planification du contenu, la définition, la vérification du contenu,et le contrôle des modifications du contenu.

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 enmatiè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ésconnexes 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 tousles 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 duprocessus de planification. Les hypothèses comportent en général un degré de risque.

Identification des risques / Risk Identification. Détermination des risques pouvant avoirun impact sur le projet et documentation de leurs caractéristiques. Les outils utilisés à cettefin comprennent le remue-méninges et les listes de contrôle.

Indice de performance des coûts (IPC) / Cost Performance Index (CPI). Rapport de lavaleur 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). Rapportde performance des délais (valeur acquise réelle par rapport à la valeur planifiée). L’IPD serapporte à 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 approchecré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 lesressources plus efficacement.

Jalonnement des activités / Activity Sequencing. Détermination et documentation del’ordre d’enchaînement des activités dans le temps en fonction des liaisons logiques entreelles.

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.

Ges

tion

des

res

sour

ces

hum

aine

s d

u p

roje

t|

Mat

rice

d’a

ttrib

utio

n d

es r

esp

onsa

bili

tés

Glossaire


207

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 typesde 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 desniveaux de ressources difficiles à gérer).

Liste de contrôle / Checklist. Liste des nombreux risques pouvant survenir au cours d’unprojet. On s’en sert comme outil dans le processus d’identification des risques. Les listesde contrôle sont exhaustives ; on y trouve divers types de risques rencontrés au cours desprojets antérieurs.

Livrable / Deliverable. Article, produit ou résultat mesurable, tangible et vérifiable devant êtreproduit pour mener à bien un projet ou une partie d’un projet. Terme souvent employé dansun sens plus restreint quand il désigne un produit livrable externe, qui est un produit livrablesoumis à l’approbation du commanditaire ou du client.

Logiciels de gestion de projet / Project Management Software. Catégorie d’applicationslogicielles spécialement conçues pour faciliter la planification et le suivi des coûts et desdé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 lerésultat d’un calcul arithmétique, et peut varier au fur et à mesure de l’avancement du projetsi 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ôtde 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 destâches, et qui permet de vérifier que la responsabilité de chacun des éléments de travail ducontenu du projet est attribuée.

Matrice d’attribution des responsabilités / Accountability Matrix. Voir Matrice d’alloca-tion des responsabilités.


Glossaire

208

Matrice de probabilité et d’impact / Probability and Impact Matrix. Manière courante dedéterminer si un risque est considéré comme faible, moyen ou élevé, en combinant sesdeux 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 derepré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 deré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 plustô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 auplus tôt).

Méthode du diagramme fléché / Arrow Diagramming Method (ADM). Technique dereprésentation schématique d’un projet dans laquelle les activités sont représentées pardes 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 illustrerl’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 avecle 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 decharge uniforme pendant un laps de temps correspondant à la réalisation des activités qu’ilgè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 desressources humaines à affecter et à employer pendant le projet.

Organigramme des tâches (OT) / Work Breakdown Structure (WBS). Décompositionorienté 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 projetplus 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 deslots de travaux à des unités organisationnelles.

Mat

rice

de

pro

bab

ilité

et

d’im

pac

t |

Pla

nific

atio

n d

es c

omm

unic

atio

ns

Glossaire


209

Organisation fonctionnelle / Functional Organization. Type de structure organisationnelledans 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êmedivisée en mécanique, électricité, etc.).

Organisation matricielle / Matrix Organization. Structure organisationnelle dans laquellele chef de projet partage, avec les responsables fonctionnels, la responsabilité de définir lespriorités et de diriger le travail du personnel affecté à un projet.

Organisation par projets / Projectized Organization. Structure organisationnelle danslaquelle 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éalisatricedu projet. Voir aussi Plan des comptes.

Plan de gestion des risques / Risk Management Plan. Document décrivant commentseront exécutés les processus de gestion des risques durant le projet. Il s’agit du résultatde la planification de la gestion des risques.

Plan de projet / Project Plan. Document formel et approuvé, utilisé pour mener à bien à lafois l’exécution et le contrôle du projet. Le plan de projet sert principalement à documenterles 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 etle planning. Un plan de projet peut être détaillé ou global.

Plan des comptes / Code of Accounts. Système de codification utilisé pour identifierchaque é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. LesPCC 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 lesrisques 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. Égalementappelé 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 unprojet.

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 etattribution des rôles, des responsabilités et des liens hiérarchiques dans un projet.

Planification des appels d’offres / Solicitation Planning. Établissement des spécificationsrelatives 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 besoinsdes acteurs d’un projet en matière d’information et de communication(s) : qui a besoin dequelles informations, quand, et sous quelle forme ces informations seront transmises.


Glossaire

210

Planification des ressources / Resource Planning. Détermination des moyens (en per-sonnel, équipement, matériaux) et des quantités nécessaires à la réalisation des activitésdu projet.

Planification des stratégies de réponse / Risk Response Planning. Établissement desprocédures et des techniques visant à améliorer les opportunités et à réduire les menacesconcernant les objectifs du projet. Les outils comprennent le rejet, la modification, le trans-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 descharges 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 planningfinal d’un projet doit toujours être piloté par les ressources.

Pourcentage d’avancement (physique) / Percent Complete (PC). Estimation, expriméeen 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 desméthodes d’estimation de la prévision à l’achèvement comportent des réajustements del’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épassementdes 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 unmodificateur (par ex., référence de coûts, de temps, de mesure des performances).

Pla

nific

atio

n d

e re

ssou

rces

|S

ous-

pro

jet

Glossaire


211

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épenddes 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 successeurne peut commencer au plus tôt que 10 jours après l’achèvement de l’antécédent. Voir aussiAvance.

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. Ils’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, quelleque 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 undomaine particulier. Généralement, ce type de session est organisé de façon à enregistrerles idées de chacun des participants afin de les analyser ultérieurement. Cet outil est décritdans 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 sontcensés être couverts. La signification précise du terme caractérisé varie en fonction dudomaine d’application.

Responsable fonctionnel / Functional Manager. Responsable chargé des activités d’unservice 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éeavant 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, peutavoir 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égiesde réponse.

Risque subordonné / Secondary Risk. Risque résultant directement de la mise en œuvred’une stratégie de réponse.

Rupture / Hanger. Rupture non intentionnelle dans un chemin de réseau. Une rupture estgé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 objectifsexprimé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 habituellementeffectuées à l’aide de la méthode de Monte Carlo.

Sous-projet / Subproject. Partie du projet global.


Glossaire

212

Sous-réseau / Subnet. Partie du diagramme réseau du projet représentant en général unesorte 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-

tant à partir d’un nœud. (2) Dans la méthode des antécédents, activité à laquelle aboutit unlien logique.

Suivi / Monitoring. Collecte, analyse et préparation de rapports sur les performances duprojet, 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 risqueset é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ésdéclencheurs ou signes d’avertissements, sont une indication de l’occurrence de risquesou 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 desrisques.

Tâche / Task. Terme générique désignant tout travail non inclus dans l’organigramme destâ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’unprojet.

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 pourestimer 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 desestimations de durée optimiste, pessimiste et des plus probables. Elle calcule l’écart typede la date d’achèvement à partir de ceux des durées du chemin critique. Égalementappelée Analyse de la méthode des moments.

Technique d’évaluation et de suivi graphique (GERT) / Graphical Evaluation andReview Technique. Technique d’analyse de réseau qui permet le traitement conditionnelet probabiliste des liaisons logiques (c’est-à-dire que certaines activités peuvent ne pas seré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 deré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 dessemaines. Elles peuvent aussi correspondre à des équipes, voire à des minutes. Ce termeest principalement utilisé par les logiciels de gestion de projet.

Valeur acquise / Earned Value (EV). Le travail physique accompli plus le budget qui lui estimparti. La somme des coûts estimés approuvés (peut inclure des frais généraux) pour lesactivité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é dutravail 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 budgetautorisé pour son accomplissement. Ce terme remplace l’ancien terme « Coût budgété dutravail 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.

Sou

s-ré

seau

|In

dex


AAC/CR Voir Coût réel (CR)acteur(s) 6, 11–12, 16–18, 24, 32, 34–35, 41,

43–44, 49, 54, 56, 61, 63, 74, 80, 91–92,107–08, 114–15, 119–22, 124, 129–32, 147,169, 197Voir aussi acteur(s) du projet

acteur(s) du projet 4, 11, 16, 35, 83, 89, 95,98, 102, 107–08, 110, 117, 119–22, 132, 138,141, 144, 191Voir aussi acteur(s)

action corrective 30, 46, 49, 63-64, 80-81, 91-93, 102-03, 144, 146, 197

activité(s) 14, 36, 47, 68-69, 71-75, 77-78, 80-81, 87- 88, 100- 01, 103, 123, 170, 197critique 76, 80, 198description de l’ 203durées 34, 65, 67, 72-73, 75, 190fictive 198identification des 7, 34, 65, 67, 71, 190jalonnement des 7, 34, 49, 65, 68-70, 190,

206liste 60, 67-68, 71, 73successeur 74

estimation 7, 34, 65, 71-73, 73-75, 80, 86-87, 190

activité critique Voir activité, critiqueactivité fictive Voir activité, fictiveactivité sous-critique 80, 198activités sur flèches (AOA) 70, 198activités sur nœuds (AON) 69, 198ACWP/CRTE Voir Coût réel du travail réalisé

(CRTR) AD/DA Voir description de l’activitéADM Voir Méthode du diagramme fléchéAF Voir date de fin réellealéas 45analyse mathématique 75-77, 198analyse qualitative des risques 8, 34, 127,

133–37, 140, 191, 198analyse quantitative des risques 8, 34,

127, 130, 132, 134, 136–39, 141, 143, 191,198

antécédent Voir activité, antécédentAOA Voir activités sur flèches

AON Voir activités sur nœuds appel à candidature 153, 198appel d’offres (AO) 153, 198AQ Voir assurance de la qualitéAS Voir date de début réelleassurance de la qualité (AQ) 7, 35, 95, 97,

99, 101–02, 190, 198

BBAC Voir Budget à l’achèvement BCWP/VBTR Voir Coût budgété du travail réalisé

(CBTR)BCWS/ VBTP Voir Coût budgété du travail prévu

(CBTP)boucle 46, 199

Budget à l’achèvement (BAC) 92, 199

budgétisation 7, 34, 83, 85, 89-90, 190, 199

Ccahier des charges 150–53, 156, 199calcul à rebours 199calcul au plus tôt 199CAP Voir plan des comptesCCB Voir Comité de contrôle des changementscharte du projet 45, 54-55, 114, 129, 131,

183, 199charte Voir charte du projetchef de projet 4, 16, 19-21, 24, 46, 54-55, 60-

61, 96, 107, 110, 114-15, 130, 136, 144, 153,156, 181, 199

chemin critique 9, 76-77, 80, 200méthode du 26, 75, 208

chemin(s) 139, 199convergence des 201marge d’un 207

chevauchement 4, 9, 16, 30, 41, 51, 65, 83,95, 107, 117, 127, 147, 199

choix de fournisseurs 8, 35, 147, 153,155–56, 191, 200

classe 96, 200clôture administrative 8, 37, 117, 125, 158-

59, 191, 200

INDEX


Index

214

Comité de contrôle des changements 49,200

compression de durée 75, 200construction en régime accéléré 12, 75,

200contenu 19, 25, 27, 30, 32–33, 43–45, 59–63,

68, 89, 123, 131–32, 137, 142, 170–71, 200Voir aussi contenu du produit, contenu du projet,

gestion du contenu du projet et plan de gestion du contenu du projet

modification du 29, 56, 62–63, 80, 92, 103, 124,145

Référence de 63, 210contrôle des changements du projet 7,

36, 51, 62–64, 91, 189, 201définition du 6–7, 34, 37, 51, 57, 59, 67, 85,

110, 149–50, 189énoncé du 34, 45, 51, 55–57, 60–62, 67, 86,

98, 149, 170, 189planification du 7, 34, 51, 55–56, 189vérification du 7, 36, 51, 61–62, 189

contenu du produit 6, 41, 47, 51, 63, 200contenu du projet 6, 32, 36, 41–42, 47, 51,

55–56, 60–61, 63, 71, 75, 91, 96, 143, 147,149,189, 191, 200

Contingences ou aléas 73, 75, 88, 90, 129,143-44développement de plans alternatifs 203plans alternatifs 41, 63, 88, 143-44, 146provision pour aléas 78, 137, 144, 210

contrat à coûts remboursables Voir contrat,à coûts remboursables

contrat à forfait Voir contrat, à forfaitcontrat à prix fixe Voir contrat, à prix fixecontrat à prix forfaitaire (FFP) Voir contrat, à

prix forfaitairecontrat à prix forfaitaire avec

intéressement (FPIF) Voir contrat, à prixforfaitaire avec intéressement

contrat à rétribution fixe (CPFF) Voircontrat, à rétribution fixe

contrat en dépenses contrôlées avecintéressement (CPIF) Voir contrat, endépenses contrôlées avec intéressement

contrat(s) 6, 14, 25, 43-44, 47, 54-55, 57, 63,74, 86, 120, 125, 150-51, 153-59, 169, 171,173, 181, 200-01à coûts remboursables 151, 200à prix fixe ou à forfait 142, 151, 200, 201à prix forfaitaire avec intéressement

196, 201à rétribution fixe 201clôture du 8, 37, 147, 149, 151, 158-59, 191,

200documentation contractuelle 159en dépenses contrôlées avec intéressement

201gestion des 8, 35, 147, 156-59, 191, 205

modifications du 158-59négociation du 155-56pièces et main-d’œuvre 200

contrôle 11-12, 36, 42-43, 45-47, 49, 57, 59,62-63, 67, 79-80, 85, 88-89, 91, 102-03, 115,124, 130, 144-45, 149, 157, 170, 201Voir aussi Comité de contrôle des changements,

système de contrôle des changements, contrôle des coûts, contrôle intégré des changements, contrôle de la qualité, suivi et contrôle des risques, contrôle du planning et contrôle du contenu

plan des comptes de contrôle 42, 92, 209fiches de 103, 205

contrôle de la qualité 7, 36, 61–62, 91, 95,99–104, 157, 190, 201

contrôle des coûts 7, 36, 62, 83, 90-93, 190,201

contrôle intégré des changements 7, 36,41, 47-49, 63, 79-80, 91, 102, 104, 146, 158,189, 201

courbe en S 90, 124, 170, 201Coût budgété du travail prévu (CBTP) 92,

123, 196, 198, 201Coût budgété du travail réalisé (CBTR)

92, 123, 202coût de la qualité 99, 202Coût réel (CR) 88, 92, 123, 202Coût réel du travail réalisé (CRTR) 123,

202CPFF Voir contrat, à rétribution fixeCPI/IPC Voir indice de performance des coûts

(IPC)CPIF Voir contrat, en dépenses contrôlées avec

intéressementCPM Voir méthode du chemin critiqueCV Voir écart de coûtscycle de vie du projet 6, 11-14, 30, 51, 57-58,

127, 130, 145, 169-70, 181, 191, 202

Ddate cible de fin de projet 37, 197, 202date de début cible 197, 202date de fin cible 197, 203date de début 44, 202

Voir aussi date de début réelle, date de début prévue, date de début au plus tôt, date de début au plus tard, date de début planifiée, date de début programmée et date cible de début

date de début au plus tard 196, 202date de début au plus tôt 196, 202date de début prévue 197, 202date de début réelle 196, 202date de fin 36, 45, 73, 75, 77, 80, 90, 202

Com

ité d

e co

ntrô

le d

es c

hang

emen

ts|

gest

ion

de p

roje

t

Index


215

Voir aussi date de fin réelle, date de fin prévue, date de fin au plus tôt, date de fin au plus tard, date de fin planifiée, date cible de fin de projet et date cible de fin

date de fin au plus tard 196, 202date de fin au plus tôt 196, 203date de fin prévue (SF) 203date de fin réelle (AF) 196-97, 203date de mise à jour 196, 198, 200, 203DD Voir date de mise à jourDD Voir liaison Début-Début (DD)décalage négatif 26, 74décalage positif 74, 119, 130, 134, 136, 138décision(s) à chaud 63, 146demande de devis (RFQ) 153, 197, 203démarrage 7, 30, 32, 41, 44, 51, 53-54, 69, 136,

189, 203dépendance 74, 127, 203développement de l’équipe 7, 35, 44, 107,

114–16, 190, 203développement des stratégies de

réponse 8, 34, 45, 88, 127, 130, 134,140–41, 143, 145–46, 191

DF Voir liaison Début-Fin (DF)diagramme à barres 78, 124, 198, 203diagramme de Gantt 78, 124, 198, 203diagramme de Pareto 103, 203diagramme PERT 70, 203

Voir aussi technique d’évaluation et de suivi des projets ou PERT

diagramme réseau 203diffusion de l’information 8, 35, 98, 117,

121-23, 191, 204discipline(s) 4, 7, 13, 30, 36, 43, 45, 46, 47, 51,

56, 57, 62, 65, 68-69, 76, 78, 83, 89, 95, 98,107, 110-11, 117, 125, 131, 144, 147, 161,168-71, 181-82, 195, 198

DU Voir durée(s)durée restante (RDU) 196, 204durée(s) (DU) 4-5, 44, 57-58, 71-73, 75-76, 78,

81, 86, 99, 138-39, 196-98, 200-01, 204compression de 75, 200

EEAC Voir Prévision à l’achèvement écart de coûts (CV) 89, 91-92, 123, 196, 204EF Voir date de fin au plus tôteffort 10, 13, 32, 37, 41, 44-45, 49, 51, 65, 67,

73, 83, 95, 104, 107, 117, 147, 149, 153-54entreprise réalisatrice 4, 8, 10-12, 16, 19, 25-

26, 41, 44, 49, 53-54, 64, 81, 86-87, 93, 97-98,101, 110, 113-16, 147, 149-51, 158-59, 170,191, 198-99, 204

EP Voir écart de prévisions

équipe de projet 5–6, 20, 29, 42, 44, 46, 48,63, 68, 71–72, 80, 85, 87, 91, 96–97, 99,103–04, 110–11, 114–16, 122, 129–32, 138,142–43, 147, 149–50, 154, 156, 167, 183Voir aussi équipe de gestion de projet et

développement de l’équipemembre(s) 4, 16, 68, 111, 114–16, 122,

208Voir aussi membre(s) de l’équipe

ES Voir date de début au plus tôtestimation 34, 71-73, 75, 83, 86, 88-90, 92,

123, 138, 190, 204Voir aussi activité, estimation ; estimation d’ordre

de grandeur et estimation paramétrique coût estimé pour achèvement (CEA) 92, 196,

202prévision à l’achèvement 92-93, 196, 210

estimation de type ordre de grandeur 204estimation des coûts 7, 34, 73, 83, 85-88,

190, 204estimation détaillée 204estimation paramétrique 204étape jalon 13, 69, 78, 145, 204EV/VA Voir valeur acquise (VA)évaluation du coût du cycle de vie 83, 205événement(s) à risque 46, 127, 134, 142, 205événements sur nœuds 205EVM Voir valeur acquise, gestion de la

FFF Voir Liaison Fin-Fin (FF)FFP Voir contrat, à prix forfaitaireflèche 198, 205flottement 205FPIF Voir contrat, à prix forfaitaire avec

intéressementFS/FD Voir liaison Fin-Début (FD)

GGERT Voir technique d’évaluation et de suivi

graphique ou GERTgestion de la qualité du projet 7, 95-96, 98,

171-72, 190, 195, 205gestion de l’intégration du projet 7, 41,

170-71, 189, 205gestion de projet (CPM) 3-4, 6-7, 9-12, 18,

21, 29, 32, 45-46, 55, 58, 96, 99, 102, 127,132, 135, 147, 163, 167-71, 189-91, 195-96,205équipe de 3, 7, 11, 16, 18, 26-27, 37, 44, 46-

47, 49, 67, 69, 74, 88, 92-93, 96-103, 107-10, 112-13, 115, 120, 123, 147, 149, 151, 157-58, 181, 204

logiciels de gestion de projet 42, 44, 68-69, 74, 76, 80, 86, 88, 92, 121, 198, 207


Index

216

processus de 7, 30, 32, 38, 41-42, 44, 56, 68, 97, 103, 157, 169-70, 172, 181

professionnels (PMP®) de 4, 153, 156, 168, 175, 196, 210

référentiel des connaissances en (PMBOK®) 3,13, 19, 163, 169, 179, 181, 196, 211

Voir aussi équipe de projet, membre(s) de l’équipe de projet, développement de l’équipe et membre(s) de l’équipe

gestion des approvisionnements duprojet 8, 114, 147, 171-72, 191, 195

gestion des communications du projet 7,24-25, 117, 149, 171-72, 191, 195, 205

gestion des coûts du projet 7, 83, 171-72,190, 195, 205

gestion des délais du projet 7, 65, 171–72,190, 195, 205

gestion des ressources humaines duprojet 7, 107, 149, 170-72, 190, 195, 206

gestion des risques du projet 8, 26, 72-73,171-72, 191, 195, 206

gestion du contenu du projet 7, 32, 51,171–72, 189, 195, 206plan de 45–46, 55–57, 63

gestion intégrale de la qualité 95, 97, 197graphe du projet 69-71, 74, 77, 197, 203-05groupe d’activités 70, 206Guide du référentiel des connaissances

en gestion de projet (Guide PMBOK®)Voir Guide PMBOK®

Guide PMBOK® 9-10, 173, 179, 185

Iidentification des risques 8, 34, 37, 127,

130, 131, 132, 133, 137, 145, 146, 191, 206IFB Voir appel à candidatureindice de performance des coûts (IPC)

92, 123, 196, 206ingénierie de la valeur 56, 83, 197, 206

Llivrable(s) 11-13, 34, 44-45, 47, 51, 55-58-63,

65, 67-68, 74, 78, 85, 98, 100, 102, 123, 126,147, 157, 189-90, 197, 207

LOE Voir niveau de chargelogique 11, 15, 68-69, 75, 77, 138, 207

Voir aussi logique du réseaulot de travaux 34, 47, 60–61, 67, 88–90, 111,

195, 198, 207LS Voir date de début au plus tard

Mmarge 75, 80, 207

Voir aussi marge libre et marge totalemarge libre 196, 207marge totale 197, 207

matrice de probabilité et d’impact 208matrice de responsabilités 110, 196–97,

208membre(s) de l’équipe 4, 16, 20, 24, 68, 72,

74, 87, 111, 114–16, 121–22, 130, 198, 208Voir aussi membre(s) de l’équipe de projet

mesure des performances techniques145, 208

méthode de l’arbre de décision 139méthode de Monte Carlo 44, 75, 208méthode des antécédents 69-70, 139, 196-

98, 203-04, 208méthode du diagramme fléché 70, 196-98,

208

Nniveau de charge 196, 208nivellement 202, 208nœud 69-70, 198, 208

Voir aussi activités sur nœuds

Oobjectifs du projet 5, 29-30, 34, 36, 55-56, 63,

65, 67, 86, 98, 122, 127, 133-35, 137-39, 142-44, 151, 191

OBS/OF Voir organigramme fonctionnel (OF)obtention des ressources humaines 7, 34,

46, 86, 107, 112–14, 190, 208organigramme des tâches (OT) 9, 42–43,

45, 57–63, 65, 67–68, 71, 75, 85–87, 89, 111,129, 131, 133, 136, 138–39, 143, 150, 170,181, 195, 197, 208

organigramme fonctionnel (OF) 61, 111,196, 203

organisation fonctionnelle 19-20, 170, 208organisation par projets 20-21, 209

PPC Voir pourcentage d’avancement (physique)PDM Voir méthode des antécédentsPERT Voir technique d’évaluation et de suivi des

projets ou PERTPF Voir date de fin planifiéephase 10-14, 20, 30, 32-33, 37, 51, 53-54, 57,

62, 70, 87, 108, 117, 125, 189, 191, 197, 209phase du projet 11-12, 32, 41, 51, 53-54, 62,

65, 77, 83, 95, 109, 117, 119, 170, 209plan comptable 87, 198-99 plan de projet 26, 30, 32-33, 35, 41-46, 48-49,

51, 57, 61-62, 64, 78-81, 89, 92, 99, 103, 111,115, 121-23, 132, 134, 142-46, 151, 158, 189,209élaboration du 7, 34, 41-44, 77, 99, 111, 151,

189, 204mise en œuvre du 7, 35, 41, 45-47, 55, 62, 123,

157, 189, 208

gest

ion

des

ap

pro

visi

onne

men

ts d

u p

roje

t|

tech

niq

ue d

’éva

luat

ion

et d

e su

ivi d

e p

roje

t ou

PE

RT

Index


217

plan des comptes 198-99planification de la gestion des risques 8,

34, 45, 46, 74, 90, 127, 129–131, 134, 138,140, 145, 191, 209

planification de la qualité 7, 34, 95, 97–99,101, 190, 209

planification de l’invitation àsoumissionner 8, 35, 147, 149, 151–54, 191

planification de l’organisation 7, 19, 34,107-11, 119, 190

planification des approvisionnements 8,35, 98, 147, 149-52, 159, 191, 209

planification des communications 8, 34,109, 117, 119, 120, 191, 199, 209

planification des ressources 7, 34, 46, 83,85, 86, 109, 190, 209

planification du projet 33, 34, 36, 43-45, 53,55, 97, 131, 158, 198, 210

planning 14, 25, 36–37, 43–47, 55–56, 61, 68,73–81, 91, 97, 99–100, 115, 120, 122–23, 127,129, 131, 133, 136–37, 143, 145, 150–51, 157,183, 198–99, 210Voir aussi référence, planning ; planning du projet

et planning de référencecontrôle du 7, 36, 62, 65, 79–81, 91, 124, 190,

201écart de prévisions 92, 103, 123, 197, 204élaboration du 7, 34, 65, 71, 73–77, 190, 204indice de performance des délais (IPD) 123, 197,

206performances des délais 79– 81, 102, 104, 123

plan de gestion du 45, 78, 80planning de référence 81planning directeur 77, 210planning du projet 34, 36, 44-45, 65, 73-75,

77-81, 90, 96, 103, 139, 152, 190, 210PM Voir gestion de projet et chef de projetPMBOK® Voir référentiel des connaissances en

gestion de projet ou PMBOK®

PMP® Voir professionnel(s) en gestion de projet(PMP®)

pourcentage d’avancement (physique)122, 196, 210

prévisions budgétaires 198, 210processus d’identification des risques

134, 141, 198programme 10, 70, 74, 146, 168, 210PS Voir date de début planifiéePV/VP Voir valeur prévue

QQC Voir contrôle de la qualitéquantification des risques 92

RRAM Voir matrice des responsabilitésrapport des écarts majeurs 195, 201rapports d’avancement 8, 36, 47, 117, 122-

25, 151-52, 157-58, 191, 210RDU Voir durée restanteréduction 142-43, 210réduction des risques 143, 210référence 43, 45-49, 57, 63-64, 72, 122, 139,

145, 168, 198, 210Voir aussi date de fin, référence de contenu, date

de début et planning de référencecoût 45, 89-92, 198des performances 44-47, 198planning 45, 79, 198

référence de base des performances Voirréférence des performances

référence de coût Voir référence, coûtrelation d’antériorité 69, 211réseau 70, 75, 170, 198

analyse de 198chemin du 199logique du 69-70, 75, 198, 207

réserve 73, 78, 88, 137, 143–44, 198–99, 211responsable fonctionnel 4, 18, 25, 113-14,

211RFP/AO Voir appel d’offres (AO)RFQ Voir demande de prixrupture 211

SSF Voir date de fin programméesous-réseau 70, 202, 209SOW Voir cahier des charges détailléSPI/IPD Voir indice de performance délaisSS Voir date de début prévuesuccesseur Voir activité, successeursuivi 30, 36, 80, 91, 95, 102, 127, 130, 144-45,

190-91, 212suivi et contrôle des risques 8, 36, 127,

144, 145, 146, 191, 212système de contrôle des changements

48-49, 80, 91, 158Voir aussi contrôle intégré des changements et

contrôle des changements du contenu

Ttâche 101, 127, 195, 197, 212TC Voir date cible de fin de projettechnique d’évaluation et de suivi des

projets ou PERT 70, 75, 196, 212Voir aussi diagramme PERT


Index

218

technique d’évaluation et de suivigraphique ou GERT 70, 75, 196, 212

TF Voir date cible de fin et marge totaleTQM Voir gestion intégrale de la qualitétransfert des risques 212TS Voir date cible de début

Uunité calendaire 198

Vvaleur acquise (VA) 41, 49, 92, 123-24, 145,

196-98, 212analyse de la 123, 145, 198gestion de la 41-42, 44, 60, 91-92, 196

valeur attendue 75, 139valeur prévue (VP) 92, 123, 196-98, 212VE Voir ingénierie de la valeur

WWBS/SDP Voir Organigramme des tâches (OT)

tech

niq

ue d

’éva

luat

ion

et d

e su

ivi g

rap

hiq

ue o

u G

ER

T|

WB

S


219

À propos du Project Management InstituteDepuis sa fondation en 1969, le Project Management Institute (PMI®) est devenu l’organisation de prédilection deceux qui, à travers le monde, travaillent ou s’intéressent à la gestion de projet. En fait, le PMI® est la première asso-ciation professionnelle à but non lucratif mondiale dans le domaine de la gestion de projet.

Certains des programmes, produits ou services du PMI® sont décrits ci-après :

NormesLe PMI® développe des normes destinées aux professionnels de la gestion de projet plébiscitées par les membres duPMI®, du marché et les autres acteurs. Le document principal de normes du PMI®, Le guide du référentiel des connais-sances en gestion de projet (Guide PMBOK®), constitue de facto la norme mondiale en matière de connaissances etde pratiques de gestion de projet sur le marché global d’aujourd’hui. Le PMI® s’engage à améliorer sans cesse et àdévelopper le guide PMBOK®, ainsi qu’à développer des normes supplémentaires.

CertificationDepuis 1984, le PMI® s’attache à la mise en place et au maintien d’un programme de certification professionnellerigoureux, basé sur un examen, destiné à promouvoir la profession de gestionnaire de projet, et à récompenser lesaccomplissements professionnels individuels. La certification de professionnels en gestion de projet (Project Mana-gement Professionals en anglais ou PMP®) du PMI constitue l’accréditation professionnelle la plus reconnue dans lemonde pour les praticiens en gestion de projet et pour d’autres dans la profession. Le PMI offre aussi un Certificatd’assistant en gestion de projet (Certified Associate in Project Management ou CAPM™ en anglais) et des certificatsde spécialisation (Certificates of Added Qualification ou CAQ™) dans les domaines du développement automobile,des projets d’investissement en capital, des réseaux informatiques, des systèmes d’information et de services Pro-jets (Project Management Office ou PMO en anglais). En 1999, le service Programmes de Certification du PMI estdevenu le premier département de ce type dans le monde à obtenir la certification ISO 9001.

RecherchePMI se concentre sur l’expansion du référentiel des connaissances de la gestion de projet. Dans ce but, les besoinsdes professionnels de ce domaine sont étudiés par l’intermédiaire de sondages périodiques et d’autres méthodes. Larecherche en gestion de projet est encouragée par l’intermédiaire d’une conférence biennale sur la recherche en ges-tion de projet, de bourses de recherche externes, d’une base de données de recherche, et par l’identification de sujetsde recherche. Les informations d’actualité, la connaissance et les enseignements de la profession sont recueillis etdiffusés. Enfin, l’avenir de la profession est étudié.

PublicationL’édition mensuelle de la revue professionnelle du PMI, PM Network®, et de la lettre d’information, PMI Today®, infor-ment les membres du PMI des dernières nouvelles de l’Institut, ainsi que des derniers logiciels, des dernières tech-niques de gestion de projet, des conférences à venir, des bonnes pratiques ou des leçons retenues de projets encours. Le PMI publie aussi le trimestrielle le Project Management Journal®, revue académique leader présentant lesdernières techniques, recherches, théories et applications de gestion de projet. De plus, le PMI est le premier éditeurmondial d’ouvrages spécialisés, d’outils de formation et d’outils pratiques de gestion de projet. Des centaines de livressont disponibles sur le site en ligne du PMI, à l’adresse www.pmibookstore.org.

FormationPMI supporte une large gamme d’activités de formation. Le programme Seminars World du PMI est une vitrine dumeilleur de la gestion de projet et de son enseignement. Ces séminaires sont organisés tout au long de l’année dansle monde entier. Le PMI reconnaît aussi l’importance de l’accréditation académique pour le développement de la pro-fession de gestionnaire de projet. L’accréditation de diplômes post-universitaires et l’agrément de cursus de mastèresspécialisés en gestion de projet sont disponibles pour des écoles ou des organismes de formation. Le programmeRegistered Education Provider (R.E.P.) du PMI permet l’accès à environ 800 fournisseurs agréés de produits de for-mation et de développement d’activités liées à la gestion de projet. Tous les R.E.P. adhèrent aux critères d’activitésde développement professionnels établis par le PMI.

AdhésionPMI est une organisation à adhésion individuelle. Les membres du PMI bénéficient d’avantages divers, allant deréductions sur des séminaires de formation et des livres, à des abonnements à des périodiques de haute qualité. Pourplus d’informations sur l’adhésion au PMI ou sur ses programmes, produits et services, visitez le site Internet du PMIà www.pmi.org, ou bien contactez le service Clients du PMI pour recevoir une documentation au + 1 610 356 4600ou à l’adresse électronique [email protected].

Project Management InstituteFour Campus BoulevardNewtown Square, PA 19073-3299 USAwww.pmi.org

ISBN: 1-930699-23-9 US $35.95Le Guide PMBOK®, Édition 2000

Pmi fr

Business

Transcript of Pmi fr