TenStepV10 Ebook FR

Methodologie TenStep de Management de Projet®
(Version 10.0)
TenStep Francophone
En Algérie au Cameroun en France au Maroc au Québec en Tunisie

Table détaillée des matières Page
Bienvenue 6
A1 Les avantages d'une méthodologie de management de projet 8
A1.1 La modularité de la méthodologie – un facteur-clé 13
A2 Le style d’écriture de TenStep 14
A3 Comment utiliser la Méthodologie TenStep 15
A4 Le contexte de la méthodologie TenStep 16
A5 Déroulement de la méthodologie TenStep 19
A5.1 Modèle CMMI 21
A5.2 Management de projet par rapport au cycle de vie d'un projet 23
A5.3 Management de projet par rapport à la gestion de produit 25
A6 Comparer la méthodologie TenStep de management de projet 27
®
A6.1 Comparaison de la méthodologie TenStep avec le Guide PMBOK , quatrième
28
édition
A6.2 Comparaison de la méthodologie TenStep avec la méthode Agile de
33
développement de logiciels
A6.3 Comparaison entre la méthodologie TenStep et ISO 10006 37
Démarrer -
0.0 Démarrage du projet 44
0.0.1 Identifier et gérer les parties prenantes 46
Planifier -
1.0 Définir le travail 50
1.0.1 Qu’est-ce qu’un projet? 53
1.0.1.1 Les dates de début et de fin de projet 55
1.0.2 Le rôle de chef de projet 58
1.0.3 Dimensionner votre projet (petit, moyen, grand) 64
1.1 Définir le travail / Processus 65
1.1.1 Petits projets 66
1.1.2 Projets de taille moyenne 69
1.1.3 Grands projets 73
1.1.3.1 Rédiger la charte du projet 78
1.2 Définir le travail / Techniques 81
1.2.1 Buts, stratégies et objectifs 87
1.2.2 Rôles et responsabilités 90
1.2.3 Matrice de responsabilités 94
1.2.4 Organisation du projet 96
1.2.5 Approche du projet 97
1.3 Définir le travail / Références rapides 100
2.0 Élaborer l'échéancier et le budget du projet 104
2.1A Élaborer l'échéancier / Processus 106
2.1A.1 Estimer l’effort et la durée 112
2.1A.2 Seuil d’estimation 118
2.1A.3 Liens logiques 120
2.1A.4 Estimer les heures productives par jour 122
2.1A.5 Structure de découpage du projet 124
2.1A.5.1 Exemples de structures de découpage de projet (SDP) 130
2.1A.6 Chemin critique 133
1
Méthodologie Conseil Formation Management de Projet Bureau des Projets - PMO Portefeuille de Projets
TenStep Francophone, siège du groupe : 40, rue du Tivoli, 67009 Strasbourg, France | admin@TenStep.fr | www.TenStep.fr | Téléphone +33 (0)9 75 18 01 50
2.1A.7 Créer le plan de management de l'échéancier 138
2.1A.8 Établir les révisions à l'achèvement des phases 139
2.1B Élaborer le budget / Processus 140
2.1B.1 Estimer les coûts 143
2.1B.2 Comptes de contrôle 145
2.1B.3 Créer le plan de management des coûts 147
2.2A Élaborer l'échéancier / Techniques 148
2.2B Élaborer le budget / Techniques 154
2.2.1 Techniques d'estimation de l’échéancier et du budget 155
2.3 Élaborer l'échéancier et le budget du projet / Références rapides 166
Piloter -
3.0 Gérer l'échéancier et le budget 169
3.0.1 Intégrer le projet et les processus de management de projet 172
3.0.1.1 Diriger et piloter l’exécution du projet 173
3.0.1.2 Surveiller et maîtriser le travail du projet 174
3.0.1.3 Mettre en œuvre la maîtrise intégrée des modifications 175
3.0.1.4 Gestion de la configuration 176
3.1A Gérer l'échéancier / Processus 179
3.1A.1 Petits projets 180
3.1A.2 GéProjets de taille moyenne 181
3.1A.3 Grands Projets 184
3.1A.3.1 Lancement du projet 188
3.1A.3.2 Jalons / Revues de points de passage 190
3.1A.3.3 Valider l’estimation du travail avec l’équipe 192
3.1B Gérer le budget / Processus 193
3.1B.1 Petit projet 194
3.1B.2 Projets de taille moyenne 195
3.1B.3 Grands projets 197
3.1B.3.1 Signes d’alarme pour le budget 199
3.2A Gérer l'échéancier / Techniques 201
3.2A.1 Éléments de suivi 209
3.2A.2 Ramener un projet dans les délais convenus 210
3.2B Gérer le budget / Techniques 215
3.2B.1 Techniques pour ramener le projet à l’intérieur du budget 217
3.2B.2 Valeur acquise 221
3.3 Gérer l'échéancier et le budget / Références rapides 225
4.0 Gérer les problèmes majeurs 229
4.1 Gérer les problèmes majeurs / Processus 231
4.2 Gérer les problèmes majeurs / Techniques 237
4.2.1 Analyse des causes et des effets 240
4.2.2 Analyse des causes profondes 243
4.2.3 Analyse de Pareto 244
4.3 Gérer les problèmes majeurs / Références rapides 246
5.0 Gérer le contenu 248
5.0.1 Définir le contenu 250
5.0.2 Créer le plan de management du contenu 253
2
5.0.3 Créer un plan de management des exigences 254
5.0.4 Réunir les exigences 255
5.0.5 Assurer la traçabilité 257
5.0.6 Vérifier le contenu 259
5.1 Gérer le contenu / Processus 260
5.2 Gérer le contenu / Techniques 266
5.3 Gérer le contenu / Références rapides 271
6.0 Gérer les communications 274
6.1 Gérer les communications / Processus 275
6.1.1.1 Gérer les attentes des parties prenantes 277
6.1.2.1 Éléments de base 281
6.1.2.2 Le cycle de vie d’un document 285
6.1.2.3 Ébauches 286
6.1.2.4 Modèle de structure du dépôt de documents 287
6.1.3.1 Gestion avancée de la documentation du projet 292
6.1.3.2 Exemples de plans de management des communications 294
6.1.3.3 Construire une marque pour un projet 296
6.2 Gérer les communications / Techniques 298
6.2.1 Gérer la documentation / Techniques 303
6.3 Gérer les communications / Références rapides 305
7.0 Gérer les risques 308
7.1 Gérer les risques / Processus 310
7.1.1.1 Analyse quantitative des risques 313
7.1.2. Grands projets 315
7.1.2.1 Créer le plan de gestion des risques 319
7.1.2.2 Hypothèses et risques 320
7.2 Gérer les risques / Techniques 322
7.2.1 Facteurs de risques inhérents 328
7.2.2 Valeur monétaire attendue (EMV - Expected Monetary Value) 330
7.2.3 Risques positifs (opportunités) 332
7.3 Gérer les risques / Références rapides 334
8.0 Gérer les ressources humaines 337
8.1 Gérer les ressources humaines / Processus 338
8.1.1 Développer le plan des ressources humaines 339
8.1.1.1 Créer le plan de gestion des ressources humaines 340
8.1.2 Former l’équipe de projet 341
8.1.2.1 Déterminer si les employés à plein temps ou les contractuels sont les plus
342
appropriées
8.1.2.2. L’entretien avec les nouveaux membres de l’équipe 344
8.1.3 Développer l’équipe de projet 345
8.1.4 Diriger l’équipe du projet 346
8.2 Gérer les ressources humaines / Techniques 347
3
8.2.1 Les techniques de constitution du staff 348
8.2.2 Développer l’équipe de projet 351
8.2.3 Diriger l’équipe de projet 355
8.3 Gérer les ressources humaines / Références rapides 377
9.0 Gérer la qualité et les métriques 380
9.0.1. Comprendre la nature de la gestion de la qualité 382
9.1 Gérer la qualité / Processus 384
9.1.2.1 Créer le plan de management de la qualité 386
9.1.3.1 Gérer les métriques / Processus 390
9.1.3.1.1 Exemples de métriques 396
9.1.3.2 La révision des livrables 398
9.1.3.3 Résoudre les problèmes de la qualité 400
9.2 Gérer la qualité / Techniques 401
9.2.1 Gérer les métriques / Techniques 407
9.2.1.1 Collecter des métriques au moyen des enquêtes 412
9.2.2 Le coût et les avantages de la qualité 414
9.2.3 Questions de contrôle qualité 417
9.2.4 Questions d’assurance qualité 419
9.2.5 Contrôle statistique de processus 423
9.3 Gérer la qualité / Références rapides 426
9.3.1 Gérer les métriques / Références rapides 428
10.0 Gérer les approvisionnements 430
10.1 Gérer les approvisionnements / Processus 431
10.1.1 Créer le plan de management des approvisionnements 434
10.1.2 Évaluer les options fabriquer vs. acheter 435
10.1.3 Gérer les projets impartis 437
10.2 Gérer les approvisionnements / Techniques 439
10.3 Gérer les approvisionnements / Références rapides 445
Clore le projet 447
40.0 Redressement des projets qui ont des problèmes 451
40.1 Tolérances du projet 453
40.2 Problème de projet #1 : Définition et planification inadéquates du projet 455
40.3 Problème #2 : Faible gestion du contenu 457
40.4 Problème #3 : Absence de gestion de l'échéancier du projet 459
40.5 Problème #4 : Mauvaise communication de projet 461
40.6 Problème #5 : Mauvais management de la qualité 463
41.0 Définissez et planifiez le redressement du projet 465
42.0 Évaluez le projet en difficulté 467
43.0 Développez un plan de redressement 470
44.0 Activez le plan de redressement 473
45.0 Évaluer et surveiller le plan de redressement 474
Glossaire 476
4
______________________________________________________________________
Bienvenue
5
Bienvenue
La méthodologie TenStep de management de projet ("Méthodologie TenStep" ou "TenStep") a été

conçue pour aider les chefs de projets à gérer tout type de projet avec succès. La méthodologie
TenStep de management de projet fournit tous les renseignements dont vous avez besoin pour devenir
un chef de projet accompli. Cette méthodologie comprend une approche progressive, en commençant
par les notions élémentaires et en progressant en fonction de vos besoins dans le cadre de la
réalisation d’un projet défini.
La méthodologie TenStep de management de projet vous permet de gérer votre travail comme un
projet. Elle a été conçue pour être aussi flexible que nécessaire dans la gestion de votre projet. Cela
signifie, par exemple, qu’il n’est pas logique de consacrer beaucoup de temps à la gestion des risques
d’un projet qui ne demande que 500 heures d’effort et qui est similaire à d’autres projets réalisés
auparavant. Cela n’implique pas que vous ignoriez les risques potentiels, mais vous n’y consacrerez plus
autant de temps que pour un autre projet (par exemple, un projet pour lequel vous implantez une
nouvelle technologie). Cette approche flexible et progressive caractérise le processus TenStep et
contribue à le distinguer des autres méthodologies.
Dans le célèbre conte d’ « Alice au pays des merveilles », le roi dit à l’héroïne : « Commence au début,
puis continue jusqu’à la fin; ensuite arrête-toi ». Ces mots pourraient également s’appliquer à un projet.
(Par exemple, un projet pour lequel vous implantez une nouvelle technologie.)
L’expression « management de projet » fait référence à la définition et à la planification, ainsi qu'à la

surveillance et au contrôle qui en découlent jusqu’à la clôture du projet. Avant même de commencer,
vous devez reconnaître que chaque projet nécessite un certain niveau de gestion. Si vous y réfléchissez
bien, vous constaterez qu’en fait, vous êtes déjà en train d’amorcer un projet, même si cela se passe
uniquement dans votre tête. Plus le projet sera important et complexe, plus vous aurez besoin d’une
méthode de gestion standard, formelle et structurée. Il est possible que vous soyez capable de gérer
adéquatement un petit projet de 200 heures au total et en ne faisant appel qu’à deux personnes, sans
devoir appliquer une méthode complexe. En revanche, vous ne pouvez pas gérer de la même manière
un projet de 1.000 heures. Un tel projet emploie cinq personnes et implique plus de formalités. Il faut
déployer davantage d’efforts s'il s'agit d'un projet de 20 personnes, ce qui représente 20.000 heures
d’effort.
Naturellement, il y a des coûts liés à la gestion d'un projet. Il faudra donc adapter le niveau de gestion
à la taille du projet pour que la valeur ajoutée (par cette gestion) soit supérieure aux coûts exigés.
Pour mieux comprendre la Méthodologie TenStep, prenons d'abord connaissance des bénéfices qui
seront réalisés, révisons certaines hypothèses et mises en garde, et parcourons le fonctionnement de la
méthodologie TenStep de management de projet :
 A1 Les avantages d'une méthodologie de management de projet
o A1.1 La modularité de la méthodologie – un facteur-clé
 A2 Le style d’écriture de TenStep
 A3 Comment utiliser la méthodologie TenStep
 A4 Le contexte de la méthodologie TenStep
 A5 Déroulement de la méthodologie TenStep
o A5.1 Modèle CMMI de maturité des capacités
o A5.2 Management de projet par rapport au cycle de vie d'un projet
o A5.3 Management de projet par rapport à la gestion de produit
 A6 Comparaison de la méthodologie TenStep de management de projet, avec
6
o A6.1 le Guide du Corpus des Connaissances en Management de projet de l'Institut du
Management de Projet, PMI, " Guide PMBOK® ", Quatrième Édition
o A6.2 La méthode Agile de développement de logiciels
o A6.3 ISO 10006
Et maintenant, commençons par l’étape 1.0 et que le jeu commence !
7
A1 Les avantages d'une méthodologie de management de projet
(A1. P1)
Certaines entreprises se sont fait une réputation d’être constamment capables de gérer efficacement
leurs projets. Mais la plupart d’entre elles ne jouissent pas d'une telle réputation.
Votre entreprise présente-t-elle l’une des caractéristiques suivantes ?
 Les projets sont terminés tardivement, dépassent les budgets ou ne répondent pas aux
exigences de fonctionnalité imposées par le client.
 Les techniques et procédés préconisées par les chefs de projets sont faibles ou ne présentent
pas une utilisation incohérente.
 Le management de projet est réactif et on ne constate pas qu’il fournit de la valeur.
 Le temps nécessaire pour bien gérer des projets d’une manière proactive n’est pas pris en
compte dans l'échéancier du projet.
 Le management de projet est considéré comme « des frais généraux ».
 Les projets réussissent, malgré l’absence de planification et de management de projet, grâce à

des « héros » qui surmontent le stress important et les heures supplémentaires pour finir le
travail.
Ces difficultés peuvent être surmontées avec de bonnes méthodes de gestion de projets. Mais de
bonnes compétences en cette matière ne vous mettent pas à l'abri des problèmes, des risques ou des
mauvaises surprises. Ce qu'un bon management de projet vous apportera, ce sont des procédés
standards à mettre en place pour parer à toutes les éventualités.
Les processus et les techniques du management de projet sont utilisés pour qu’il y ait une coordination
entre les ressources afin d’atteindre les résultats attendus. Cependant, on doit comprendre dès le début
que le management de projet est loin d’être une science exacte et qu’il n y a jamais une garantie de
succès. Puisque les projets impliquent des gens, il y a toujours une certaine complexité et incertitude
qu’on ne peut absolument pas contrôler.
Le management de projet est à la fois une science et un art. C’est une science dans la mesure où il
repose sur des techniques et des processus éprouvés et réutilisables qui permettent de réaliser le projet
avec succès. C’est un art parce qu’il implique aussi de gérer des gens et d’établir des relations avec eux,
et qu’il exige du chef de projet d’adapter des compétences intuitives à des situations qui sont
absolument spécifiques à chaque projet. Une bonne méthodologie de management de projet fournit le
cadre, les procédés, les lignes directrices et les techniques pour gérer à la fois les gens et le travail. Une
bonne méthodologie augmente les chances de succès et, par conséquent donne plus de valeur à
l’entreprise, au projet et au chef de projet.
Il en va de même pour le management de projet. Gérer un projet de manière proactive demande du

temps et de l’effort. Ce coût est plus que compensé au cours de la vie du projet, puisqu’il permet de :
 Mener à terme tous les projets plus rapidement et à moindre coût. L'un des avantages
d’une méthodologie réside dans sa capacité d’être réutilisée. Une fois que les processus, les
procédures et les modèles sont élaborés, ils peuvent être réutilisés (avec des modifications
accessoires) sur tous les projets futurs. Cela entraîne une réduction du temps de lancement et
une courbe d’apprentissage plus courte pour les membres de l’équipe, et des économies de
temps parce qu’on n’est pas tenu de réinventer les procédés et les modèles à partir de rien,
pour chaque projet.
 Être plus prévisible. L’un des premiers bénéfices qui pourraient résulter d’une bonne
méthodologie de management de projet est que vous allez être plus prévisible. Vous allez
constater que si vous effectuez une meilleure planification, vous allez mieux assimiler le travail
8
à accomplir, et vous allez mieux estimer ce travail. Ensuite, plus le projet progresse plus vous
allez mieux gérer le travail afin d’atteindre votre échéancier et votre budget estimés. Cette
capacité à être prévisible est cruciale lorsque votre société est en train de prendre des décisions
commerciales concernant quel projet à exécuter. Vous devez œuvrer pour atteindre un niveau
de prévisibilité de 80%. En d’autres termes, 80% de vos projets se termineront à temps et en
respectant le budget (y compris toutes les demandes de modification du contenu approuvées).
 Réduire l'effort de travail et les coûts avec une gestion proactive du contenu.
Beaucoup de projets trouvent des difficultés dans la gestion du contenu, ce qui entraîne un
effort et un coût supplémentaires dans la réalisation du projet. Acquérir de meilleurs processus
de gestion de projets permet d’être en mesure de gérer le contenu d’une manière plus efficace.
 Trouver une solution meilleure qui " convient " dès le départ, grâce à une meilleure
planification. De nombreux projets rencontrent des problèmes en raison d’une différence
entre la volonté du client et la solution livrée. L’emploi d’une méthodologie rend possible une
meilleure planification et permet à l’équipe et au commanditaire de se mettre d’accord sur les
livrables principaux.
 Résoudre les problèmes plus rapidement. Certaines équipes consacrent trop de temps et
fournissent trop d’énergie pour résoudre certains problèmes parce qu’elles ignorent comment le
faire dès le départ. Un processus de gestion proactive des problèmes majeurs est utile pour
s’assurer que les problèmes sont résolus aussi vite que possible.
 Gérer les risques avant l'apparition des problèmes. Le management des risques du
projet consiste à identifier les problèmes potentiels et à les gérer avant qu’ils ne se produisent.
 Communiquer et gérer plus efficacement les attentes des clients, des équipiers et
des autres parties prenantes. La plupart des conflits qui surgissent au cours d’un projet
peuvent être évités grâce à une communication proactive à facettes multiples. Par ailleurs,
beaucoup de problèmes qui apparaissent lors d’ un projet ont pour origine une mauvaise
surprise plutôt qu’un problème spécifique qui survient. La méthodologie TenStep insiste sur la
communication proactive, formelle et informelle, qui réduit le nombre de ces mauvaises
surprises.
 Concevoir un produit de meilleure qualité dès la première fois. TenStep comprend des
processus de gestion de la qualité qui permettront d’emblée à l’équipe de comprendre les
besoins du client en termes de qualité. Une fois ces besoins définis, l’équipe peut mettre en
place des techniques de contrôle qualité et d’assurance qualité, afin de satisfaire les exigences
du client.
 Repérer les mauvais projets et ne pas les accepter avec plus de célérité. Les «
mauvais » projets sont ceux où la justification par le rapport coûts / bénéfices n’a plus de
sens. Un projet doit débuter avec une justification précise qui réside dans le rapport coûts /
bénéfices. Cependant, si celui-ci a pris du retard et qu’il a dépassé le budget qui lui est alloué, il
peut atteindre un seuil où l’étude de faisabilité n’est plus valide. Une gestion de projet efficace
vous permet de vous rendre compte de ces situations plus tôt, si bien que vous pouvez prendre
de meilleures décisions en redéfinissant le contenu ou en en annulant le projet.
 Améliorer la gestion des finances. Ceci est le résultat d’une meilleure définition du projet,
d’une meilleure estimation, d’une meilleure budgétisation et d’un meilleur suivi des coûts réel
du projet par rapport au budget. Une telle rigueur est susceptible de vous amener à avoir une
meilleure prévisibilité et un meilleur contrôle.
 Porter plus d’intérêt aux métriques et prendre des décisions basées sur des faits
avérés. L’un des aspects les plus élaborés de TenStep c’est que cette méthodologie donne des
conseils facilitant la collecte des métriques. Ces indicateurs vous donnent des informations vous
permettant de déterminer le degré d’efficacité et d’efficience de votre équipe et le niveau de
qualité de vos livrables. Les indicateurs vous donnent aussi les informations nécessaires pour
savoir si vous avez réussi ou pas.
9
 Améliorer le climat de travail. Si vos projets sont très réussis, vous obtiendrez des
bénéfices additionnels tangibles liés à votre équipe de projet. Vos clients se sentiront plus
concernés, votre équipe s’appropriera plus le projet, son moral sera plus élevé et pourra
acquérir un sens plus aigu de professionnalisme et de confiance en soi. Et cela est évident
,puisque ceux qui travaillent sur des projets à problèmes sont souvent mécontents. D’un autre
côté, les gens qui travaillent sur des projets réussis ont tendance à se sentir mieux dans leur
peau et à travailler dans de meilleures conditions.
Les gens qui se plaignent d’en avoir « par-dessus la tête » du management oublient ce point : tous les
projets sont gérés. La question est de savoir comment ils sont gérés. Par exemple :
 Votre projet va être confronté à des problèmes majeurs. Voulez-vous les gérer de manière
proactive ou les résoudre comme çà vient ?
 Votre projet va affronter des risques potentiels. Voulez-vous les résoudre avant qu’ils n’arrivent
ou attendre jusqu’à ce que les problèmes se présentent ?
 Allez–vous communiquer de manière proactive ou supporter les conflits et les incertitudes

causés par l’absence d’information au sujet du projet ?
 Allez-vous gérer le contenu ou supporter des dépassements de coûts et de délais causés par du
travail effectué en plus de ce que votre budget ne peut supporter ?
 Allez-vous intégrer la qualité dans votre processus ou résoudre les problèmes plus tard, quand
leur résolution deviendra plus coûteuse ?
Les caractéristiques des projets ne vont pas changer selon que vous utilisez ou non un processus formel
de management de projet. Ce qui change c’est la manière de traiter les événements lors de
l’avancement du projet. Sont-ils traités de manière hasardeuse et réactive ou de manière proactive et à
l’aide d’un processus qui avance progressivement ?
Le doute n’est plus permis : les organisations qui suivent généralement de bons processus prédéfinis et
optimisés réussissent mieux que celles qui n’en utilisent pas. Celles qui disposent de bons processus et
les appliquent sont parfois appelées "organisations conduites par un processus’’. Elles accomplissent
plus de travail et se concentrent sur ce qui a le plus de valeur. Elles présentent également des systèmes
d’organisation opérationnels qui permettent à chacun de réussir, à commencer par les chefs de projet.
Il y a plusieurs façons d’évaluer comment votre organisation suit ses processus standard. Le modèle
d’évaluation probablement le plus connu est le Modèle Maturité Capacité (MMC), décrit en détail dans la
partie A5.1 Modèle CMMI.
Pourquoi tout le monde ne pratique-t-il pas un management de projet efficace ? (A1. P2)
Après la lecture de cette partie, vous vous demanderez sans doute pourquoi tout le monde n’utilise pas
de bonnes techniques de management de projet. Peut-être même vous demanderez-vous pourquoi ne
les utilise pas moi-même ?
Il y a à cela différentes raisons :
 Cela nécessite un investissement préalable à la fois en temps et en effort. Nombreux

sont ceux qui se considèrent comme des « meneurs ». Ils ne sont peut-être pas très
compétents en matière de planification. Souvent, ils ont tendance à discuter d’un problème puis
à aller le régler. Cette méthode convient à un petit projet de cinq heures. Elle ne peut
nullement s’appliquer à un projet de 5.000 heures. Celui-ci pourra être mené à terme si vous le
planifiez correctement ,au préalable et si vous pouvez appliquer la discipline nécessaire
susceptible de le gérer efficacement.
 Votre organisation ne s’implique pas. Il est difficile d’être un bon chef de projet dans une
entreprise qui n’accorde pas d’importance aux compétences en matière de management de
projet. Par exemple, si vous consacrez du temps à donner une bonne définition du projet et
que le client vous demande par la suite pourquoi vous y avez mis tant de temps , vous ne serez
10
sans doute plus très enthousiaste quant à planifier votre prochain projet. Pour être efficace,
toute entreprise doit promouvoir un processus commun de management de projet.
 Vous n'avez pas les compétences appropriées. Vous trouvez peut-être que l’absence de
processus de management de projet n’est pas une affaire de volonté mais de compétence.
Parfois, on demande aux chefs de projets de gérer ces derniers alors qu’ils n’ont ni la formation
ni l’expérience nécessaires. Dans ce cas, les chefs de projet auront tendance à se démener
sans disposer de la formation et des outils appropriés pour gérer efficacement les projets. Il se
peut que votre organisation ne possède pas un Bureau des Projets (PMO) ou un autre
organisme chargé de faire usage de ces compétences en management de projet.
 La direction pense que le management de projet est un logiciel. Lorsque vous discutez
de management de projet avec certains managers, ces derniers pensent, au début, que vous
envisagez d’installer un logiciel qui vous permettra d’améliorer votre compétence en tant que
chef de projet. A vrai dire, si c’était un logiciel, vous auriez plus de chance des convaincre de sa
valeur. Même si certains aspects du management de projet, comme l’élaboration et la gestion
de l’échéancier, peuvent avoir recours à un logiciel, ce n’est pas là que réside la valeur du
management de projet. La vraie valeur d'une méthodologie de gestion de projets réside dans
l’utilisation disciplinée de processus précis et cohérents.
 Vous avez peut-être été « brûlé » (ou enterré vivant) dans le passé. Dès que vous
commencez à parler de processus, de meilleures pratiques et de modèles, un certain nombre
de gestionnaires pensent immédiatement surplus de travail, retards et "paperasserie". Ils
n’arrivent pas à percevoir immédiatement la valeur qu’apporte une méthodologie. Ce que l'on
reproche généralement aux méthodologies c'est qu'elles sont encombrantes, qu’elles produisent
beaucoup de papier et qu’elles retardent le travail en cours. Parfois, ces critiques sont légitimes
et fondées, du fait que la méthodologie n’est pas adaptée convenablement à la taille de votre
projet. Par exemple, si vous devez élaborer une charte de projet de quinze pages, alors que
votre petit projet ne représente que 250 heures de travail, vous serez peut-être rebuté par la
méthodologie de management de projet. Cependant, ceci n’est pas tant un problème de
méthodologie que de mauvaise application de la méthodologie.
 Les membres des équipes ont peur du contrôle. Nombreux sont ceux qui aiment effectuer
leur travail d'une manière qu'ils considèrent "créative", et avec le minimum de supervision
possible. Ils redoutent que des techniques de management de projet trop formelles
n’entraînent des contrôles plus stricts qui feraient disparaître toute créativité et tout plaisir dans
leur travail. Dans une certaine mesure, ils ont raison. Cependant, les procédures standard
éliminent une part de la créativité surtout dans des domaines où elle n’a probablement pas à
occuper le premier rang. Il n'est pas nécessaire d'être trop créatif lorsqu'on est confronté à une
modification du contenu. Il suffit de suivre les processus standard déjà en place.
 Les chefs de département ont peur de perdre du pouvoir. Si vous voulez réellement
qu’une discipline de management de projet soit respectée dans votre entreprise, vous devez
donner un certain niveau de contrôle et d’autorité aux chefs de projet. Certaines organisations
et certains managers de niveau moyen dans la hiérarchie ne veulent pas partager ce pouvoir.
Ils acceptent que le chef de projet s’occupe de la coordination, mais ils veulent, néanmoins,
prendre toutes les décisions et tout contrôler. Un management de projet formel ne sera pas
possible dans une entreprise où cette peur risque de prévaloir.
Certaines de ces peurs sont naturelles et logiques, tandis que d’autres sont irrationnelles et infondées.
Cependant, bien qu’il y ait des raisons d’hésiter à faire appel à un management de projet formalisé, ces
peurs doivent être surmontées. La ligne de conduite en management de projet est la suivante: si la
méthode de management de projet a pour conséquence une certaine lenteur dans l’exécution du
projet, ou que le coût de ce dernier est plus élevé, ou que le projet lui-même soit de qualité moindre, il
serait alors insensé de l’utiliser.
En fait, c’est l’opposé qui est vrai: l’utilisation de techniques précises de management de projet feront
en sorte que votre projet soit terminé à temps, que le budget soit respecté et que le niveau de qualité
soit acceptable.
11
Ceci dit, lorsque vous utilisez des processus de management de projet, utilisez-les de façon intelligente.
Ne créez pas des processus de management pour un projet de 10 milles heures si le votre ne nécessite
pas plus que 200 heures. Prenez en considération tous les aspects du management d’un projet et faites
en sorte que le processus approprié à votre projet soit spécifique.
Options pour obtenir une méthodologie (A1.P3)
Pour réussir à mettre au point de manière efficace une méthodologie de management de projet, vous
devez d’abord vous convaincre qu’il y a un avantage à tirer si les processus sont appliqués et utilisés
correctement. En fait, tous les projets utilisent un mélange de processus, de procédures et de modèles.
Si vous pensez que vous ne les utilisez pas, cela signifie probablement que ceux que vous utilisez sont
médiocres et informels.
Si vous avez besoin d’une bonne méthodologie de management de projet, il y a deux approches
possibles :
1. Élaborez-en une vous-même. Vous pouvez créer une méthodologie sur mesure qui reflète
parfaitement la philosophie et les pratiques de votre organisation. De nombreuses entreprises
procèdent actuellement de cette façon.
2. Achetez-en une. Si vous élaborez votre propre méthodologie, vous serez surpris d’apprendre
qu’elle ressemble finalement à la plupart de celles que les gens utilisent. Peu importe la façon
dont vous la structurez, vous aurez toujours besoin de planifier, d’intégrer un échéancier du
projet, de gérer le contenu et les risques, de communiquer, etc. C'est pourquoi de nombreuses
entreprises optent pour l’achat d’une licence leur permettant l'utilisation d’une méthodologie
préexistante et éprouvée. Ces méthodologies pré-élaborées contiennent, généralement, tout ce
dont vous avez besoin pour une organisation réussie.
Évidemment, si vous achetez une méthodologie, vous aurez encore besoin de l’adapter aux besoins
spécifiques de votre entreprise. Cela vous procure les avantages de la première option, mais cela
nécessite moins de temps et le coût sera moindre, ce qui est l’avantage principal de la deuxième option.
12
A1.1 La modularité de la méthodologie – un facteur-clé
Certaines organisations considèrent qu’une méthodologie de management de projet occasionne des

frais inutiles. D’autres pensent qu’il s’agit d’un « mal nécessaire ». Parallèlement à ces points de vue,
TenStep considère qu’une méthodologie de management de projet représente une valeur ajoutée
importante pour l’organisation. La section A1 explique comment cette valeur est ajoutée à
l’organisation, et ce, à plusieurs niveaux.
Pourquoi certaines personnes et certains organismes considèrent-ils qu’une méthodologie de

management de projet est un « mal nécessaire »? L’une des raisons les plus importantes réside dans le
fait que la grande majorité des méthodes disponibles manquent de flexibilité et de souplesse. Ces
méthodes sont conçues surtout pour faire face aux situations découlant des grands projets où on sent
le besoin d’une démarche très structurée de tous les aspects du projet. Le problème est que d’autres
types de projets sont censés suivre ces mêmes processus, sans tenir compte de leur envergure et de
leur complexité.
Cela n’est pas logique. Pour qu’une méthodologie de management de projet soit efficace, elle doit
permettre une application conforme aux caractéristiques de différents projets. Les grands projets
nécessitent plus de rigueur et de structure que les petits projets. Nous devons le reconnaître.
Habituellement, les problèmes de ces grands projets n’émanent pas d’une structure trop rigide; ils
résultent plutôt de la situation des chefs de projets débordés en raison d’un manque de procédés
adéquats. Ces chefs de projets, trop souvent, ne disposent pas de procédés de planification,
d'estimation, de gestion de l’échéancier, de modifications, de risques, etc. Cela fait en sorte que les
chefs de projets sont réactifs et confrontés en permanence à des situations d'urgence.
À l’opposé, les procédés rigoureux proposés par les méthodologies lourdes tendent à contrecarrer les
petits projets. Ces projets peuvent être gérés avec des techniques et procédés légers et informels.
L'échéancier pour un petit projet peut être établi selon une liste d’activités ou un tableur. Les petits
projets ne sont généralement pas très risqués de sorte qu'ils ne requièrent pas une gestion formelle des
risques. En général, l’impact des problèmes des petits projets est relativement minime. Par exemple, si
un projet de 100 heures se met à doubler en importance, cela n’aura probablement pas de
conséquences graves au niveau de l'organisation exécutrice. Par contre, si un projet de 10.000 heures
double en envergure, cela pourrait occasionner un impact majeur.
La méthodologie TenStep de management de projet a été conçue pour permettre une application à
échelle extensible en accord avec la taille et la complexité de chaque projet. L'idée directrice de
TenStep est d’appliquer à chaque projet le niveau optimal de gestion. Ce niveau optimal ne signifie pas
automatiquement ni peu ni beaucoup de structure. Il implique qu’il faudra appliquer une approche très
structurée pour les grands projets, tandis que pour les petits projets, le degré optimal de procédures de
gestion de projet peut être très léger. Gardez cette philosophie à valeur ajoutée contenue dans la
Méthodologie TenStep quand vous l’utilisez pour la gestion de votre projet.
13
A2 Le style d’écriture de TenStep
Cette page propose quelques conseils et avertissements qu’il faut garder à l’esprit au cours de
l’utilisation de la méthodologie TenStep de management de projet.
 Explications concises: Cette méthodologie est conçue pour offrir des avantages substantiels,
tout en restant aussi concise que possible. Après tout, vous ne recherchez pas une de ces
méthodologies, comptant des milliers de pages, qui restent inapplicables à la plupart des
projets. Il aurait été possible de donner beaucoup plus d’informations pour chacune des étapes
décrites dans le processus. Par exemple, il existe des livres entiers concernant le seul processus
de gestion des risques. L’intégration de l’échéancier du projet est également le sujet de
beaucoup de sessions de formation qui s’étalent sur cinq jours. Mais le but de la méthodologie
TenStep n’est pas de fournir la somme exhaustive et détaillée des informations disponibles sur
chaque étape. La valeur de la méthodologie TenStep tient au fait qu’elle définit clairement la
plupart des informations applicables à la plupart des projets, au lieu d’essayer de fournir toute
la matière qui pourrait s’appliquer à la totalité de ces projets.
 Les pronoms "vous" et "vos" renvoient au chef de projet, considéré comme le destinataire
pour lequel cette méthodologie a été proposée. La dénomination 'chef de projet’ est très
souvent explicitement mentionnée. Dans d’autres cas, le contenu peut référer à « vous » et «
vos », vous (le lecteur) étant supposé être le chef de projet. Bien évidemment, n’importe qui
peut lire et mettre en application le document. Mais rappelez-vous qu’il a été écrit
spécifiquement à l’intention du responsable du management du projet.
 Le pronom "il" est employé tout le long de ce document afin d'alléger la phrase en évitant la
répétition des mêmes termes. Il s'emploie par exemple à la place de "chef de projet ", sans
pour autant préjuger du genre auquel cette personne appartient.
 Les coûts exprimés en Euros (€). Le fait que la méthodologie TenStep en français libelle les
coûts en d’Euros (€) relève seulement d’une particularité de l’Union Européenne. Il est évident
que les mêmes principes seront applicables, qu’il s’agisse de Francs Suisses, de Dollars
Canadiens, de Dirhams Marocains, de Dinars Algériens, etc. Lorsque vous remarquez que les
coûts sont exprimés en Euros (€), il suffira donc de convertir les Euros dans votre propre
monnaie.
14
A3 Comment utiliser la méthodologie TenStep
Après avoir classé votre projet en tant que petit, moyen ou grand (1.0.3 Dimensionner votre projet
(petit, moyen, grand), démarrez au processus 1.0 Définir le travail à accomplir. Notez qu’il y a différents
niveaux de détail requis pour la charte du projet, selon la taille de ce dernier. Commencez par évaluer
les processus de gestion à appliquer à votre projet en vous basant sur les informations données pour
un projet de la taille du votre. Commencez par évaluer les processus de gestion à appliquer , par passer
en revue les informations relatives aux trois tailles de projet car vous pourrez peut-être vous en servir
pour votre projet particulier. Par exemple, à supposer que votre projet soit de taille moyenne, vous
avez la possibilité d'utiliser une partie ou la totalité des éléments de gestion propres à un projet de
grande taille Si vous passez en revue tous les contenus concernant toutes les tailles de projet, vous
aurez toutes les informations nécessaires pour élaborer des processus de management de projet
adaptés au vôtre.
Agissez de la même façon pour les processus 2.0 Élaborer l'échéancier et le budget du projet, 3.0 Gérer
l'échéancier et le budget et 4.0 Gérer les problèmes majeurs. Commencez par saisir les
recommandations du processus correspondant à la taille de votre projet (petite, moyenne ou grande),
puis ajoutez d’autres activités, relatives à d’ autres tailles de projets, et qui peuvent vous être utiles. La
plupart des projets devront suivre au moins les processus 1.0 à 4.0.
Voyons, maintenant, le processus 5.0 Gérer le contenu. Tout ce que vous avez lu jusqu’ici est encore
applicable, mais il y a un élément complémentaire concernant la gestion du contenu du projet. Sur de
plus grands projets, vous devrez non seulement être rigoureux sur la gestion du contenu, mais
également réaliser au préalable un travail plus approfondi afin de définir ce contenu. A cette fin, vous
trouverez des activités supplémentaires de définition du contenu ajoutées au processus 1.0 Définir le
Travail pour les projets de grande taille. La rigueur et le détail complémentaires proposés par la
procédure de définition des grands projets ont pu ne pas être compris lorsque vous avez rencontré la
première fois le processus 1.0. Vous allez maintenant commencer à voir comment le travail
complémentaire du processus 1.0 sert à la gestion ultérieure du projet. C’est pourquoi vous devez, dès
le début, classer votre projet dans l’une des catégories suivantes : petit, moyen ou grand. Dans certains
cas, les processus plus élevés de management de projet exigent également plus de rigueur dans les
procédés de définition et de planification préliminaires.
Le reste de la méthodologie TenStep de management de projet fonctionne de la même manière.
Il est à signaler que les dix processus de la méthodologie TenStep n’impliquent pas une progression
séquentielle. Vous devez définir et planifier le projet avant de le gérer. Pour cette raison, les processus
1.0 et 2.0 seront effectués avant le reste. Cependant, les activités des processus allant de 3.0 à 10.0
sont effectuées en parallèle. Cela signifie qu’un chef de projet gérera l'échéancier du projet (3.0), le
contenu (5.0), la qualité (9.0), etc., au cours de toute la durée du projet.
Les derniers processus de la méthodologie TenStep impliquent un niveau de complexité plus élevé dans
le management de projet. Par exemple, les petits projets n’ont pas nécessairement besoin de gérer les
risques (7.0) puisqu’un petit projet, en général, n’a pas à se préoccuper de beaucoup de risques. De
même, il pourrait y avoir un travail considérable pour gérer la qualité (9.0) et la gestion des
approvisionnements (10.0), ce qui veut dire que ces processus ne sont pas appliqués rigoureusement
aux projets de tailles petite et moyenne.
Passez en revue le contenu de chaque étape pour chaque taille de projet. Déterminez alors quelles
activités ont un sens pour votre projet. Par exemple, vous pouvez être à la tête d’ un grand projet, mais
il peut être intéressant de gérer les communications (6.0) comme si vous aviez à gérer un projet de
taille moyenne. Ou encore, vous pouvez assumer la responsabilité d’ un grand projet, sans avoir besoin
de collecter des métriques. Dans ce cas, vous pourriez utiliser la gestion des métriques (9.0) de la
même manière que pour un petit projet.
15
A4 Le contexte de la méthodologie TenStep
Principes directeurs (A4. P1)
Les paragraphes qui suivent présentent un ensemble de principes directeurs de la méthodologie

TenStep de Management de projet, que l’on retrouve dans toute la suite du document.
 Gérer de manière extensible: Une méthodologie de management de projet doit être flexible
et extensible; elle doit tenir compte de la taille du projet qui la sous-tend. La méthodologie de
TenStep se fonde sur le concept : « une petite méthodologie pour les petits projets, une
grande méthodologie pour les grands projets™ ». Le caractère évolutif tient compte du niveau
de complexité des processus de management de projet, ainsi que du temps et de l’intérêt qui
leur sont consacrés.
 Application à tous les projets. La méthodologie TenStep de Management de projet est

conçue pour être applicable à tous les projets, que vous projetez de construire une maison, de
fabriquer une carte électronique ou de mettre au point une application informatique.
Fondamentalement, tous les projets traitent de planification, de gestion des problèmes
majeurs, de contenu, de risques, etc. toutefois, vous allez rencontrer un certain nombre de
références ou d’exemples particuliers en relation avec le domaine du logiciel (par exemple, une
proposition de système métrique pour le système de temps de réponse d’un réseau). Dans ce
cas, substituez-y un exemple comparable qui soit applicable à votre projet (comme la vitesse
d’un circuit imprimé).
 Gérer de manière proactive. Les projets doivent être gérés de manière proactive,
indépendamment de leur taille. Les chefs de projets qui se laissent surprendre par les
évènements risquent de se retrouver face à des difficultés.
 Développer le partenariat entre l’équipe de projet et le client. Pour réussir, un projet

requiert normalement un partenariat entre l’équipe de projet et le client. Sans la participation
active du client, le projet court un grand risque d’échec.
 Etablir la méthodologie de management de projet au préalable. La méthodologie de

management de projet doit être établie à l’avance ; elle doit être assimilée par l’équipe de
projet et par le client. La plupart des méthodologies nécessitent la participation de nombreux
membres de l’équipe du client et de celle du projet. Ces personnes ne comprendront pas leur
rôle dans ces processus si ces derniers ne sont pas examinés avec eux à l’avance.
 Accorder une autorité suffisante. Pour réussir, les chefs de projets doivent avoir un niveau
d’autorité suffisant. Un chef de projet qui est responsable de la réalisation du projet alors qu’il
ne peut prendre les décisions clés nécessaires pour gérer le projet, ne peut réussir.
TenStep n’inclue pas le cycle de vie du projet (A4. P2)
Une méthodologie de management de projet est un parapluie sous le quel s’effectue le reste du travail
du projet. Rappelez-vous que c'est le management de projet qui favorise la réussite d’un projet; et non
pas le projet lui-même. Le travail du projet est désigné par « cycle de vie ». Sans tenir compte du type
du travail, le cycle de vie respecte typiquement un processus qui inclue l’analyse, la conception, la
construction, l’essai et la mise-en-œuvre (ou un autre cycle de vie parmi d'autres). Tandis qu’on
reconnait l’importance de comprendre le processus nécessaire pour produire les livrables du projet, on
doit noter que ce domaine est en dehors du contenu de la méthodologie TenStep. (Le cycle de vie des
projets de développement de logiciels est expliqué de manière détaillée dans le produit LifecycleStep
sur le www.LifecycleStep.com).
TenStep n’inclue pas la collecte des exigences détaillées (A4. P3)
Certaines méthodologies incluent la collecte des exigences commerciales comme faisant partie du
processus de management du projet. La méthodologie TenStep de Management de projet contient une
16
analyse de haut niveau pour que le document de la charte du projet soit préparée. Autrement, la phase
formelle de l’analyse des exigences commerciales est considérée comme une partie du cycle de vie du
projet et hors du contenu de la méthodologie de management de projet. (Voir le produit LifecycleStep
sur le www.LifecycleStep.com pour plus de détails sur la phase de l’analyse.)
Le projet commence officiellement lorsqu’un chef de projet est affecté (A4. P4)
Plusieurs évènements peuvent indiquer qu’un projet a officiellement commencé. Dans la méthodologie
TenStep, le projet commence officiellement lorsque le chef de projet est affecté. Typiquement, la
première mission du chef de projet est de formellement définir le travail en utilisant la charte du projet
et en créant l’échéancier et le budget. La définition de la date de commencement du projet s’applique
même si le chef de projet officiel n’achève pas la création de la charte du projet ni l’échéancier (il se
peut qu’ils soient achevés à l’avance). Notons que le management de projet est un rôle. Quiconque qui
achève la charte du projet et l’échéancier est en fait en train de remplir le rôle du chef de projet, et ce
même si une autre personne est affectée à ce rôle à la dernière minute.
Le chef de projet dispose de l’autorité et de la responsabilité (A4. P5)
Dans la méthodologie TenStep, il est supposé que le chef de projet dispose d’une certaine
responsabilité et autorité dans le projet. Ils n’ont pas nécessairement un contrôle absolu, mais ils ont
quand même un certain degré d’autorité. Si dans votre organisation les chefs de projet ont une toute
petite autorité, cela veut dire qu’ils sont probablement des coordinateurs de projet. Dans la
méthodologie TenStep, le chef de projet dispose de plus d’autorité que cela.
Reconnaitre l’objectif du dossier d'affaires et de la charte du projet (A4. P6)
Dans la méthodologie the TenStep, le dossier d'affaires est utilisé pour justifier le projet et ce d’un point
de vue commercial et il est utilisé pour affecter le financement d’un projet. Cependant, le fait que le
dossier d'affaires soit approuvé ne signifie pas que le projet est prêt à démarrer. Il se peut que
plusieurs mois s’écoulent avant que le projet ne commence effectivement.
Le projet démarre officiellement lorsque le chef de projet est assigné. La première chose que fait le
chef de projet est de définir le travail et d’élaborer l’échéancier et le budget. Le dossier d'affaires est
utilisé comme une donnée d’entrée. Le résultat de ce travail est une charte de projet, un plan de
management du projet, un échéancier et un budget. Lorsque la charte du projet est approuvée, le
projet est alors prêt à démarrer. (Opposez cela au Guide PMBOK du PMI où c’est la charte du projet qui
autorise le projet. Dans la méthodologie TenStep, le projet est autorisé lorsque le dossier d'affaires est
approuvé, et le projet est prêt à être exécuté quand la charte du projet est approuvée.)
Le modèle TenStep se concentre plus sur les projets internes (A4. P7)
L’approche générale du modèle TenStep assume que vous disposez d’un projet interne avec des clients
internes. Tandis que la plupart de la méthodologie est également applicable aux projets client-
fournisseurs, une partie du modèle doit pourtant être révisée. Par exemple, dans un projet où vous
avez un client externe, vous pouvez utiliser un « énoncé de travail » au lieu d’une charte de projet.
Vous pouvez également avoir des attentes plus sévères quand à la possibilité de dépasser l’échéancier
et le budget. Un grand nombre de ces rôles pourraient également être différents.
Le rôle du commanditaire est très important (A4. P8)
TenStep considère que le rôle du commanditaire est indispensable à la réussite du projet. Plusieurs
organisations disposent d’une telle personne remplissant cette position, mais elle peut être appelée
différemment tel que le champion du projet ou le client. La méthodologie TenStep compte sur ce rôle
pour avoir le financement du projet, pour approuver les livrables importants, pour éliminer les
obstacles, et généralement pour assurer que le projet jouit du soutien qu’il faut pour réussir.
Cependant, certaines organisations ne disposent pas de ce type de rôle du commanditaire. Dans
certaines organisations, le commanditaire est éloigné de l’accès direct au projet et est remplacé par une
personne intermédiaire qui représente l’intérêt du client. Dans certains projets, tels que les dons
17
gouvernementaux, il se peut que le rôle du commanditaire n'existe pas du tout. Cependant, dans la
méthodologie TenStep nous avons besoin d’une personne qui remplit ce rôle. Si un vrai commanditaire
n’existe pas ou ne peut pas être identifié, le chef de projet devrait chercher une autre personne pour
remplir ce rôle.
18
A5 Déroulement de la méthodologie TenStep
Il existe plusieurs modèles pour gérer les projets. Malgré que la plupart des informations fondamentales
sont similaires, ils ont chacun une manière unique d'organiser le travail de management de projet. Ils
ont aussi des rôles, termes et philosophies uniques. Les éléments suivants sont importants pour mieux
comprendre la méthodologie TenStep de Management de projet.
Les « processus » n’impliquent pas un ordre séquentiel (A5. P1)
Il est important de souligner que les dix processus de la méthodologie de TenStep n’impliquent pas une
progression séquentielle. Il est vrai que vous devez définir et planifier le projet avant de pouvoir le
gérer. Ainsi, les processus 1.0 et 2.0 seraient accomplis avant le reste. Cependant, les tâches
applicables aux processus 3.0 à 10.0 sont réalisées en parallèle.
Le processus 3 est le processus clé d’intégration (A5. P2)
Au cours de l’exécution du projet, tous les processus de gestion du projet sont intégrés dans processus
3.0 Gérer de l’échéancier et du budget. L’intégration se produit là en raison d’une philosophie
prépondérante du processus TenStep : « Ce qui est dans l’échéancier est fait ! ». En d’autres termes,
tout le travail du projet doit figurer dans l’échéancier, et une activité qui n’y figure pas ne doit pas être
effectuée.
L’échéancier est le point de convergence de la gestion du projet, et tous les processus de management
de projet sont intégrés dans l’échéancier. Des efforts et du temps doivent vous être consentis pour
communiquer, gérer le contenu, mettre à jour l’échéancier et toutes les autres activités de management
du projet. L’intégration se produit lorsque les processus de management du projet convergent, et aussi
lorsque la gestion du projet et le management des activités du cycle de vie du projet coïncident.
Considérez les exemples suivants:
 Une requête relative à une grande modification du contenu est approuvée, occasionnant plus
d’effort et une majoration de cout. Il s’agit là d’un cas typique d’intégration de la gestion de
projet et du travail relié au cycle de vie du projet. L’impact est reflété dans un échéancier et un
budget mis à jour.
 Vous identifiez les risques et créez un Plan de Management des Risques. Vous communiquez le
résultat (le plan de gestion des risques) à toutes les parties prenantes pour susciter leurs
commentaires. Il s’agit là d’intégration de la gestion des risques et de la gestion des
communications. Comme tout ce travail demande du temps et des efforts, les activités sont
inscrites dans l’échéancier et l’intégration se produit au cours de cette étape.
Tout le travail du projet doit transparaître dans l’échéancier et le budget. Par conséquent, ce processus
est celui où le projet est géré et contrôlé ; il est aussi le lieu où toutes les activités liées à la gestion du
projet et à son cycle de vie sont planifiées, exécutées, consignées et intégrées.
Les derniers processus impliquent une gestion de projet plus complexe (A5. P3)
Les processus supérieurs de la méthodologie TenStep impliquent un niveau de complexité plus élevé
dans la gestion de projet. A titre d’exemple, les plus petits projets n’ont pas nécessairement besoin de
gérer les risques (processus 7.0) parce qu’un petit projet, en particulier, n’en court pas beaucoup. De
même, le travail requis pour gérer la qualité (processus 9.0) et la gestion des approvisionnements
(processus 10.0) signifie normalement que vous ne faites pas, dans ces domaines, autant de travail
pour de petits et de moyens projets.
19
A5.1 Modèle CMMI
A5.2 Management de projet par rapport au cycle de vie d'un projet
A5.3 Management de projet par rapport à la gestion de produit
20
A5.1 Modèle CMMI (« Capability Maturity Model Integration » / Intégration du Modèle
de Maturité des Capacités)
(A5.1. P1)
Le Modèle CMMI décrit une série de cinq niveaux, qui ont pour base la manière dont votre compagnie
ou organisation suit des processus communs et renouvelables pour accomplir des tâches. La partie
inférieure de l’échelle décrit des compagnies sans processus renouvelables, où la plus grande partie du
travail est chaotique et ad hoc. La partie au sommet décrit les compagnies qui utilisent des processus
définis et renouvelables qui collectent les métriques pour améliorer continuellement leur processus et
trouver des moyens créatifs de mieux réaliser leurs tâches de manière continue.
Le CMMI a été développé de 1984 à 1987 par Watts Humphrey et le Software Engeneering Institute
(SEI). Le SEI fait partie de l’Université Carnegie Mellon. Ce travail a été subventionné par le
Département de la Défense, qui cherchait alors des moyens de comparer et d’évaluer les différents
fournisseurs qui développaient des logiciels pour son compte.
Auparavant, il y avait plusieurs modèles de CMM qui ont été réunis, en 2002, en un modèle intégré,
d’où le nouvel acronyme CMMI (« I » signifie intégration). Bien que le SEI continue d’accroître et de
développer le contenu et l’étendue de différents modèles de CMMI, la cible principale de la plupart des
compagnies est toujours le monde du développement de logiciels.
Le modèle de maturité capacité comporte cinq niveaux pour évaluer le degré de sophistication de votre
entreprise dans le domaine de l’établissement et de l’application des processus standard.
Les cinq niveaux du Modèle CMMI (A5.1. P2)
Il y a des interprétations sensiblement différentes. Certaines compagnies ont aussi identifié leur propre
version déposée du modèle CMMI. Elle est généralement répartie en cinq niveaux.
 Ad hoc / crises. Dans cette situation, votre organisation dispose de peu de processus
communs. Le succès de vos projets dépend des capacités et des qualités de votre personnel.
L’organisation n’offre qu’un environnement de soutien restreint pour parvenir à la réussite des
projets. La plupart des compagnies sont à ce niveau, bien que certaines affirment en
plaisantant être à un niveau zéro ou -1.
 Management de projet standardisé. Votre organisation a mis en place des processus de

management de projet standard. Ici, vous essayez de jeter des bases que vous pourrez
21
améliorer dans le futur. La plupart des compagnies qui débutent sur le CMMI tentent
d’atteindre ce niveau.
 Développement standardisé de logiciel. Ce niveau implique le fait d’appliquer une

standardisation de votre processus de développement, conforme à la manière dont vous avez
procédé au niveau 2. Cela inclut la standardisation et la réutilisation des processus de
développement, des livrables, des outils, etc.
 Rétroaction gérée. Vous collectez les métriques sur tous les aspects de votre management
de projet et vos processus de développement. Vous avez un répertoire de métriques et
d’enseignements relatifs à d’anciens projets qui peuvent être utiles à de nouveaux projets.
 Optimisation / amélioration continue. Vous avez une boucle fermée de processus

d’exécution, de mesure et d’amélioration continue. Vous utilisez vos mesures, votre rétroaction
et votre créativité pour optimiser vos processus.
Le CMMI est-il fait pour vous ? (A5.1. P3)
Votre compagnie devrait-elle s’engager sur la voie du CMMI ? De même qu’il y a des bénéfices réels à
réutiliser des composants communs, il y a un profit à réutiliser ces mêmes processus . Pourquoi chaque
chef de projet de votre compagnie aurait-il chaque fois des difficultés à définir un projet et à savoir
comment un échéancier de projet devrait être détaillé ? Pourquoi les chefs de projet devraient-ils avoir
des difficultés à comprendre comment gérer efficacement le contenu, les risques et la qualité ? Ce ne
sont pas là de nouveaux concepts, concernant uniquement votre compagnie. Ils devraient être définis
une fois pour toutes à un niveau organisationnel, puis réutilisés par tous les chefs de projets.
Vous pouvez utiliser le modèle CMMI comme guide lorsque vous mettez en place des processus
communs. Vous ne devez pas nécessairement commencer au niveau 1 et atteindre le niveau 5 en une
année. L’échelle du CMMI est conçue à la manière d’un voyage. La plupart des compagnies tiennent à
atteindre le niveau 2 dès le commencement. Cependant, même ce passage n’est pas sans difficultés.
Dans de nombreux, la mise en œuvre de projets communs est la partie la plus délicate du voyage.
Dans de nombreuses organisations, ce sera la première fois qu’on exige du personnel de suivre un
ensemble de processus communs, et beaucoup n’apprécieront guère cette exigence. Si vous réussissez
à parvenir au niveau 2, vous aurez alors effectué le changement de paradigme qui facilitera la transition
vers le niveau trois.
En général, de nombreuses compagnies pensent pouvoir manipuler leur valeur commerciale en mettant
en place de bons processus réutilisables au sein de leur organisation. Le modèle CMMI fournit un cadre
que les compagnies peuvent utiliser pour s’évaluer sur une échelle de 1 à 5. La plupart des compagnies
sont aujourd’hui à un niveau 1 et aimeraient bien atteindre le niveau 2. La plupart des chefs de projet
et des organisations réalisent qu’ils devraient avoir des processus communs réutilisables. Y arriver est
toutefois difficile. La difficulté provient des résistances qu’on rencontre chaque fois qu’on essaie de faire
changer les habitudes culturelles du personnel lorsqu’on lui demande de changer sa manière de
travailler. C’est pourquoi de telles difficultés se justifient par le résultat médiocre atteint. Vous les
surmonterez si votre compagnie reste concentrée sur les objectifs à atteindre, pendant toute la période
nécessaire pour que le personnel en question change de mentalité.
22
A5.2 Le management de projet par rapport au cycle de vie d'un projet
Les projets sont la forme suivant laquelle la plupart des nouveaux travaux sont réalisés. Tous les
projets présentent certaines caractéristiques communes :
 Ils ont tous un commencement et une fin.
 Tous les projets sont uniques. Ils peuvent présenter des similitudes avec des projets
précédents. Cependant, ils sont uniques en termes de délais, de personnel, d'environnement
commercial, etc.
 Les projets aboutissent à la réalisation d'un ou de plusieurs livrables.
 Les projets ont un personnel assigné, soit à plein temps, soit à temps partiel, soit les deux à la
fois.
Toutes les organisations ont des projets. Ces derniers peuvent être gérés avec un ensemble commun
de processus de management de projet. En fait, un même ensemble de processus de management de
projet peut être utilisé, quel que soit le type de projet. Ils doivent tous être définis et planifiés. Ils
doivent tous gérer le contenu, les risques, la qualité, l'état d'avancement, etc. Ce qu’il y a de précieux
dans le fait d’avoir une méthodologie commune de management de projet dans votre entreprise, c’est
que le même processus peut servir pour tous les projets.
Certains sont désorientés par la différence entre management de projet et cycle de vie d’un projet. Pour
mener à terme avec succès un projet, ces deux types d’actions sont nécessaires. La différence
essentielle réside dans le fait que le management de projet sert à définir, planifier, contrôler, surveiller
et clore le projet. Le travail lié à la construction réelle des livrables du projet est accompli à travers le
travail désigné par l’expression « cycle de vie ». Le management de projet sert à construire l'échéancier
alors que la grande majorité des actions inscrites dans l’échéancier sont le travail du cycle de vie, lié à
la construction des livrables du projet.
Ce qui fait en sorte qu’un projet soit unique, ce sont les livrables que chaque projet produit. Par
exemple, construire un pont est un type de projet différent d'un projet d’élaboration d’une solution
techno informatique ou de fabrication d’un produit de consommation. Le cycle de vie décrit les activités
qui servent à réaliser les livrables et il est, en général, unique pour chaque projet.
Bien que tous les projets soient uniques, il y a des modèles de cycle de vie communs qui peuvent servir
à réaliser les livrables de façon similaire. Le modèle générique dit « cascade » est un exemple de
modèle de cycle de vie. Dans un projet de type cascade, votre point de départ est de comprendre les
exigences de la solution, de concevoir cette dernière, de la construire et de la tester, puis de la mettre
en œuvre. Chacune de ces étapes importantes est appelée phase (phase d’analyse, phase de
conception, phase de construction, etc.). L’approche classique par le modèle « cascade » est le modèle
de cycle de vie auquel vous aboutirez probablement si vous ne connaissez rien en matière de
méthodologie et que vous avez seulement à construire un échéancier de projet en partant de rien.
Même si vous avez un petit projet, vous suivrez toujours ces étapes, même si certaines d'entre elles ne
sont qu'un exercice mental. Si vous avez un projet d'amélioration de quarante heures, par exemple,
vous avez l'impression de pouvoir y plonger en commençant à le réaliser. Mais est-ce bien vrai? Il est
plus probable que vous ayez reçu une sorte de demande de service qui décrit le travail demandé
(analyse et exigences), que vous intégrez au travail qui doit être exécuté (conception). Vous apportez
ensuite les améliorations demandées, vous les testez et les mettez en œuvre (réalisation, test, mise en
23
œuvre). L’approche classique de la cascade est le modèle de cycle de vie avec lequel vous allez
probablement finir s’il s’avère que vous ne connaissez rien sur la méthodologie et que vous devez créer
un échéancier du projet en partant de rien.
Il y a d’autres modèles de cycle de vie que la cascade classique. Bien que ce modèle puisse être
appliqué à tous les projets, d’autres modèles de cycle de vie pourront être plus efficaces, suivant les
caractéristiques du projet. Par exemple, si vous installez un package de logiciels, vous pouvez utiliser
un modèle de cycle de vie spécifique pour la mise en œuvre du package qui convient aux phases de
conception et de construction. Ainsi, si vous conduisez un projet de développement et de recherche
(R&D), vous pouvez utiliser un modèle de cycle de vie R et D qui prend en considération le fait que le
travail devra être délaissé une fois accompli. D’autres modèles importants de cycle de vie peuvent être
utilisés pour accélérer des projets ayant des caractéristiques particulières. Des projets de
développement IT en ligne, par exemple, pourront utiliser les techniques itératives de développement
Agile.
Ce qui importe c'est qu'un processus commun et graduel de management de projet puisse être utilisé
de manière efficace pour tous vos projets. Le travail détaillé d’élaboration des livrables s’appelle « le
cycle de vie ».
24
A5.3 Le management de projet par rapport à la gestion de produit
Les projets par rapport aux produits (A5.3. P1)
Les « projets » sont la voie suivant laquelle un nouveau travail est livré. Toutes les institutions ont des
projets qui peuvent être gérés à l’aide d’un ensemble commun de processus de management de projet.
« Le Management de projet » se rapporte aux processus utilisés pour créer ou développer un produit.
Les « produits », d’autre part, sont des objets tangibles produits par les projets. (Si vous avez acheté le
produit auprès d’un vendeur, c’est que ce dernier a produit cet objet en se référant à un projet). Si le
produit est temporaire ou a une courte durée de vie, il n’est normalement pas considéré comme un «
produit ». Généralement, le terme « produit » désigne quelque chose que nous construisons et dont
nous assurons l’entretien pour une longue période.
Le « management de produits » est une approche permettant la coordination centrale des activités qui
concernent la conception, le contexte commercial, le développement, la maintenance et l’amélioration
d’un produit. Vous pouvez considérer que le management de produit englobe la totalité du cycle de vie
d’un produit. La personne qui assume ces responsabilités est appelée chef de produit.
Le rôle du chef de produit varie en fonction du positionnement du produit dans le cycle de vie du
produit. Les points qui suivent décrivent certaines des responsabilités spécifiques dévolues au chef de
produit par rapport à un produit qui a été développé, qu’il soit destiné à un usage interne ou au
commerce.
Le commencement
 S’emparer de l’idée afin qu’elle puisse être explorée à fond
 Identifier les opportunités d’utilisation du produit
Analyse de rentabilité
 Lancer l’idée à travers le processus de planification commerciale de la société pour savoir si

l’idée peut être financée. Si l’idée ne trouve jamais de réalisation, c’est que le cycle de vie du
management du produit est très court.
Le projet
Un projet est lancé pour fabriquer le produit. À ce stade, le management de projet et le management
de produit coïncident. Le chef de produit peut aussi bien assumer le rôle de chef de projet, mais il est
plus courant qu’on fasse appel à un spécialiste de management de projet afin de gérer le projet jusqu’à
son terme.
 Coordonner les tests des nouveaux produits et leur mise en vente, y compris des
expérimentations avec des utilisateurs potentiels du produit
 Déterminer quand un produit est « prêt à produire » sur la base des projets de tests et
d'expérimentations
 Coordonner la diffusion du produit ou de nouvelles mises en vente
Maintenance et support
Nous abordons ici le management de produit à long terme. Le financement du travail a demandé
quelques mois et la réalisation du produit demandera aussi quelques mois. Cependant, le produit a
besoin d’être soutenu et amélioré plusieurs années de suite. Le chef de projet peut s’occuper du soutien
et du perfectionnement, mais il est fort probable qu’une société spécialisée en matière de soutien soit
impliquée.
 Agir comme contact direct dans la coordination et la communication avec le vendeur du produit
(produits vendeurs)
25
 Surveiller l'orientation du produit avec le vendeur (produits vendeurs)
 Chercher où le produit a été distribué
 Recueillir continuellement les demandes du personnel au sujet de produits particuliers
 Incorporer et ajouter de nouveaux produits et de nouvelles mises en vente (produits vendeurs)
Gestion financière
 Coordonner les négociations de contrats de produits, obtenir les agréments et les accords de
maintenance (produits vendeurs)
 S’assurer que le budget pour les achats et la maintenance est disponible
 Déterminer à quel moment il faut examiner la possibilité d’annuler ou de réduire les frais de
maintenance, sur la base de l’orientation du produit (produits vendeurs)
Management des lancements de produit
 Coordonner la certification de nouvelles mises en marché (produits internes et produits

vendeurs)
 Planifier et gérer la mise en œuvre de nouvelles mises en marché (produits internes et produits
vendeurs)
Retrait du produit
 Déterminer le moment où un produit doit être retiré
 Planifier et gérer le produit
 Retirer (désinstaller) le produit du milieu environnant
Tous ces domaines constituent le cycle de vie typique d’un produit.
26
A6 Comparer la méthodologie TenStep de management de projet
La méthodologie TenStep a pour but de gérer le travail en tant que projet. Il est à noter qu'il y a
d'autres méthodologies, d'autres normes, d'autres cadres de références disponibles. Certaines d'entre
elles sont similaires, d'autres sont complémentaires de la méthodologie en question. Le but de cette
partie est d’esquisser une comparaison entre TenStep et certains de ces ouvrages. L’objectif est d’être
juste et impartial en décrivant les différences et les similitudes. Cependant, si les lecteurs ont des avis
différents ou plus d’informations, merci de nous en faire part à admin@TenStep.fr.
Comparaison de la méthodologie TenStep de management de projet par rapport à :
A6.1 Comparaison de la méthodologie TenStep avec le Guide PMBOK®, quatrième édition
A6.2 Méthode Agile de développement de logiciels
A6.3 ISO 10006
27
A6.1 Comparaison de la méthodologie TenStep avec le Guide PMBOK®, quatrième
édition
(A6.1. P1)
Chaque méthodologie a sa propre manière de présenter les processus, les procédures, les meilleures
pratiques et les modèles exigés pour mener à bien des projets. Si vous analysez attentivement ces
méthodologies, vous remarquerez de nombreuses similitudes. Vous y trouverez des différences, non
pas tant en raison de désaccords majeurs, mais plutôt d’écarts dans l’accent qui est mis sur les
différentes questions soulevées.
L’un des meilleurs référentiels de management de projet connus est le « Guide du corpus des
connaissances en management de projet » (Guide PMBOK®), qui est la norme proposée par l’Institut
du Management de projet (PMI). Le Guide PMBOK® fournit une base des connaissances exigées pour
être un chef de projet reconnu et compétent. Toutefois, ce guide n’est pas une méthodologie que vous
pouvez utiliser pour gérer directement un projet.
D’autre part, rien n’est publié dans la méthodologie TenStep de management de projet en contradiction
directe avec le Guide PMBOK®. Puisque plusieurs lecteurs de la Méthodologie TenStep se sont
familiarisés avec le PMBOK® (plusieurs d’entre eux sont certifiés PMP®), cette section fournit une
élaboration des domaines de connaissances et des processus de management de projet dans le Guide
PMBOK®, avec les processus correspondant à la méthodologie TenStep de management de projet.
La méthodologie TenStep comporte deux modèles. Le premier modèle affiche les processus de
management classiques en dix processus de gestion. Ce modèle suit la logique originale de TenStep
publiée pour la première fois en 2000. En outre, ce même contenu est publié en visant des groupes de
processus qui s’harmonisent mieux avec le Guide PMBOK®. Les deux modèles peuvent être utilisés pour
gérer avec succès un projet. Ils contiennent exactement le même contenu TenStep, bien que la
présentation soit différente.
Les organisations qui voudraient utiliser le modèle du Guide PMBOK® comme base pour leur
méthodologie de management de projet, peuvent se référer à « TenStep PB », disponible à l’adresse
www.TenStepPB.com. Ce produit intègre tout le contenu de la méthodologie TenStep de management
de projet au sein du modèle complet du Guide PMBOK®.
Corpus de connaissances sur le

Méthodologie TenStep de management de projet
management de projet (Guide
PMBOK®) quatrième édition
4. Management de l’intégration du projet
4.1 Développer la charte du projet La charte du Guide PMBOK® contient des informations
pour autoriser le projet. La méthodologie TenStep utilise
la charte pour définir le travail et commence l’exécution
du projet.
4.2 Développer le plan de management du Le plan de management de projet est cité dans le
projet processus 1.0 Définir le travail.
4.3 Diriger et gérer l’exécution du projet Il s’agit de l’exécution du plan de management de projet.
L’exécution de l’échéancier du projet est cite dans le
processus 3.0 Gérer l’échéancier et le budget. Chaque
portion du plan de management de projet est exécutée
respectivement dans la méthodologie TenStep tel que le
processus 4.0 Gérer les problèmes majeurs, 5.0 Gérer le
contenu, etc.
4.4 Surveiller et maîtriser le travail du Il s’agit de la surveillance et de la maîtrise du plan de
28
projet management de projet. La surveillance et la maîtrise sont
abordées dans les processus 4 à 10.
4.5 Effectuer la maîtrise intégrée des 3.0 Gérer l'échéancier et le budget. L’étape 3 représente
le point d’intégration de TenStep, qui suit la philosophie
modifications selon laquelle tout le travail du projet est intégré dans
l’échéancier.
4.6 Clôturer un projet ou une phase Le coup d’envoi et la clôture d’un projet font partie de
tout le processus 90.0 Clore le projet.
5. Management du contenu du projet
5.1 Réunir les exigences 5.0 Gérer le contenu.
5.2 Définir le contenu 1.0 Définir le travail - Le contenu de la définition du

projet fait partie du document de la charte du projet.
5.3 Créer la SDP 2.0 Élaborer l'échéancier et le budget du projet – La SDP

fait partie du processus de création de l’échéancier.
5.4 Vérifier le contenu Ce sous-processus implique l’inspection et l’approbation

du client des livrables les plus importants. Dans la
méthodologie TenStep, ceci fait partie du contrôle qualité
et des critères d’acceptation, tous les deux font partie du
processus 9.0 Gérer la qualité. La vérification actuelle
pourrait faire partie de l’achèvement de la revue d’un
jalon, qui fait partie du processus 3.0 Gérer l’échéancier
et le budget.
5.5 Maîtriser le contenu Le management des modifications du contenu fait partie

du processus 5.0 Gérer le contenu.
6. Management de la durée du projet
6.1 Définir les activités Définir les activités de niveau inférieures fait partie de la
méthodologie TenStep
2.0 Élaborer l'échéancier et le budget du projet
6.2 Enchaîner les activités 2.0 Élaborer l'échéancier et le budget du projet
6.3 Estimer les ressources de l’activité 2.0 Élaborer l'échéancier et le budget du projet
6.4 Estimer les durées de l’activité 2.0 Élaborer l'échéancier et le budget du projet
6.5 Développer l’échéancier 2.0 Élaborer l'échéancier et le budget du projet
6.6 Maîtriser l’échéancier 3.0 Gérer l’échéancier et le budget
7. Management des coûts du projet
7.1 Estimer les coûts 2.0 Élaborer l'échéancier et le budget du projet
7.2 Déterminer le budget 2.0 Élaborer l'échéancier et le budget du projet
7.3 Maîtriser les coûts 3.0 Gérer l’échéancier et le budget
8. Management de la qualité du projet
8.1 Planifier la qualité Le plan de Management de la qualité est créé en tant que
partie du plan de management du projet dans le
paragraphe 1.0 Définir le travail.
29
8.2 Effectuer l’assurance qualité 9.0 Gérer la qualité et les métriques
8.3 Effectuer le contrôle qualité 9.0 Gérer la qualité et les métriques
9. Management des ressources humaines
9.1 Développer les ressources humaines 8.0 Gérer les ressources humaines
9.2 Acquérir une équipe de projet 8.0 Gérer les ressources humaines
9.3 Développer l’équipe du projet 8.0 Gérer les ressources humaines
9.4 Gérer l’équipe du projet 8.0 Gérer les ressources humaines
10. Planification des communications
10.1 Identifier les parties prenantes Fait partie du processus 1.0 Définir le travail.
10.2 Établir le plan de management des La création du plan de management des communications
communications fait partie du plan de management du projet dans le
processus 1.0 Définir le travail.
10.3 Distribuer les informations 6.0 Gérer les communications
10.4 Gérer les attentes des parties L’analyse des parties prenantes fait partie du processus
prenantes 1.0 Définir le travail. Le plan de management des
communications pour chaque groupe de parties
prenantes fait partie du processus 1.0 Définir le travail.
10.5 Établir des rapports sur la La plupart des données de performance sont réunies
performance dans le processus 3.0 Gérer l’échéancier et le budget. Les
informations sont rapportées dans le processus 6.0 Gérer
les communications.
11. Management des risques du projet
11.1 Établir le plan de management des La gestion des risques est créée comme une partie du
risques plan de management du projet réalisée à "1.0 Définir le
travail".
11.2 Identifier les risques 7.0 Gérer les risques
11.3 Effectuer une analyse qualitative des 7.0 Gérer les risques
risques
11.4 Effectuer une analyse quantitative des 7.0 Gérer les risques
risques
11.5 Établir le plan de réponses aux 7.0 Gérer les risques

risques
11.6 Contrôler et maîtriser les risques 7.0 Gérer les risques
12. Management de l’approvisionnement du projet
12.1 Planifier les approvisionnements Les Gestion des approvisionnements est créée comme
une partie du Plan de management du projet créé en 1.0
Définir le travail.
12.2 Conduire les approvisionnements 10.0 Planifier les approvisionnements
12.3 Administrer les approvisionnements 10.0 Planifier les approvisionnements
30
12.4 Clôturer les approvisionnements 10.0 Planifier les approvisionnements
Autres
Le Guide PMBOK ne soulève pas une 4.0 Gérer les problèmes majeurs. Les problèmes majeurs
gestion spécifique des problèmes majeurs. sont des problèmes importants qui pourraient gêner le
Le Guide PMBOK® désigne les problèmes projet mais qui sont hors du contrôle de l’équipe du
majeurs comme des problèmes qui projet.
pourraient gêner l’équipe de projet et
l’empêcher d’atteindre ses buts. Il identifie
également les problèmes majeurs relatifs à
la sécurité, à la performance, à la
conformité, etc. Les problèmes majeurs
peuvent survenir dans le processus 9.0
Gérer la qualité, le processus 8.0 Gérer les
ressources humaines, et même au cours
d’une autre étape.
Le Guide PMBOK® n’insiste pas sur la 9.0 Gérer la qualité et les métriques
collecte des données pour l’amélioration de
processus pendant le projet ou quand il
s’agit d’annoncer le succès du projet.
(A6.1. P2)
La méthodologie TenStep peut être entièrement élaborée dans les neufs domaines de connaissance du
Guide PMBOK® et les cinq groupes de processus dans le même Guide. Le tableau ci-dessous montre
comment la méthodologie TenStep couvre tous les éléments du Guide PMBOK® selon les groupes de
processus. La méthodologie TenStep est plus facile à assimiler parce qu’elle est déjà développée dans
un cadre de processus au lieu des connaissances étalées dans le Guide PMBOK®.
Groupe de processus
Domaines de Groupe de processus Groupe de processus Groupe de processus Groupe de processus
de surveillance et
connaissance de démarrage de planification d'exécution de clôture
de maîtrise
4.4 Surveiller et
maîtriser le travail
du projet
4.2 Élaborer le plan
Management de 4.1 Élaborer la 4.3 Diriger et piloter 4.6 Clore le projet
de management du (3.0.1.2)
l'intégration du charte du projet l'exécution du projet ou la phase
projet
projet 4.5 Mettre en œuvre
(1.1.3.1) (3.0.1.1) (90.0)
(1.1.3. P6) la maîtrise intégrée
des modifications
(3.0.1.3)
5.1 Recueillir les

exigences
5.4 Vérifier le
(5.0.4) contenu
Management du 5.2 Définir le (5.0.6)

contenu du projet contenu
5.5 Maîtriser le
(5.0.1) contenu
5.3 Créer la SDP (5.1.3. P1)
(2.1A.5)
6.1 Définir les

activités
(2.1A.5)
6.6 Maîtriser
Management des 6.2 Organiser les l’échéancier
délais du projet activités en
(3.1A.3. P2)
séquence
(2.1A. P6)
6.3 Estimer les
31
ressources
nécessaires aux
activités
(2.1A. P7)
6.4 Estimer la durée
des activités
(2.1A. P8)
6.5 Élaborer
l’échéancier
(2.1A. P9)
7.1 Estimer les coûts

(2.1B. P5) 7.3 Maîtriser les
Management des coûts
7.2 Déterminer le
coûts du projet
budget (3.1B.3. P1)
(2.1B. P6)
8.1 Planifier la 8.2 Mettre en œuvre 8.3 Mettre en œuvre

Management de la qualité l’assurance qualité le contrôle qualité
qualité du projet
(9.1.3. P2) (9.1.3. P3) (9.1.3. P4)
9.2 Constituer
l’équipe de projet
(8.1.2)
9.1 Élaborer le plan
Management des 9.3 Développer
des ressources
ressources l’équipe de projet
humaines
humaines du projet (8.1.3)
(8.1.1)
9.4 Diriger l’équipe
de projet
(8.1.4)
10.3 Diffuser les

informations
Management des 10.1 Identifier les 10.2 Planifier les (6.1.3. P3) 10.5 Rendre compte
communications du parties prenantes communications de la performance
10.4 Gérer les
projet (0.0.1) (6.1.3. P2) attentes des parties (6.1.3. P5)
prenantes
(6.1.1.1)
11.1 Planifier le
management des
risques
(7.1.2. P2)
11.2 Identifier les
risques
(7.1.2. P3)
11.3 Mettre en
œuvre l’analyse
11.6 Surveiller et
Management des qualitative des
maîtriser les risques
risques du projet risques
(7.1.2. P7)
(7.1.2. P4)
11.4 Mettre en
œuvre l’analyse
quantitative des
risques
(7.1.2. P5)
11.5 Planifier les
réponses aux risques
(7.1.2. P6)
Management des 12.1 Planifier les 12.2 Procéder aux 12.3 Gérer les 12.4 Clore les
approvisionnements approvisionnements approvisionnements approvisionnements approvisionnements
du projet (10.1. P1) (10.1. P3) (10.1. P4) (90.0. P2)
32
A6.2 Comparaison de la méthodologie TenStep avec la méthode Agile de
développement de logiciels
Ces dernières années, un certain nombre d'idées ont été publiées sur la manière de rendre les
méthodologies de développement de logiciels plus simples, plus faciles à mettre en place, et plus
adaptés aux besoins du client. « Extreme programming », « Scrum » et « Crystal » en sont trois
exemples. Dix-sept des pionniers de cette pensée se sont rencontrés dans l’Utah, les 11, 12 et 13
Février 2001 pour trouver des idées communes sur le développement de logiciels. Le résultat a été
recueilli dans un manifeste comprenant un ensemble de principes de développement et de conceptions
qui sont reproduites ci-dessous.
Alors que la majorité de ces conceptions traite des processus réels de développement de logiciels,
quelques points seulement abordent le management de projet. En général, La méthodologie TenStep
de Management de projet est parfaitement complémentaire de ce processus de développement dans la
plupart des domaines. Dans d'autres domaines, il y a des divergences d'opinion. Vous pouvez lire ci-
dessous le « Manifeste Agile », accompagné des commentaires de TenStep France sur les rapports qu’il
peut avoir avec la méthodologie TenStep.
Manifeste pour le développement du

logiciel Agile
Dix-sept anarchistes ont convenu :
Nous découvrons les meilleures manières Processus de management de projet TenStep
de développer un logiciel en le réalisant,
et en aidant les autres à le faire. À
travers ce travail nous en sommes venus
à:
D’après l'expérience de l’auteur, les projets accomplis dans

Mettre en relief des individualités et des une organisation ont une chance de réussite bien meilleure
interactions, plutôt que des procédés et avec un ensemble cohérent de processus flexibles et
des outils. évolutifs. Si ces processus ont été utilisés auparavant avec
Produire un logiciel entièrement testé et succès, il y a une plus grande probabilité que les votre le
qui fonctionne, plutôt qu'une vaste seront aussi.
documentation. Nous considérons que la méthodologie TenStep est très «
Établir une collaboration avec le client, légère ». Cependant elle représente le minimum des
plutôt que de négocier un contrat. exigences nécessaires pour gérer les projets avec succès.
Réagir aux modifications, au lieu de La plupart mais non toutes les philosophies de la
suivre un plan. méthodologie TenStep soutiendront un développement
prompt et rapide.
C'est-à-dire que pendant que nous

valorisons les articles du côté droit, nous
valorisons davantage les articles du côté
gauche.
Nous suivons les principes suivants:
La philosophie Agile encourage le développement itératif,

avec les premières exigences imposées par le code du
Notre plus grande priorité est de travail, suivies par plus d’exigences, et ainsi de suite. Cela
satisfaire le client à travers la livraison est bien, mais le développement itératif n'est pas la
rapide et continue de logiciels valables. meilleure approche pour tous les projets de logiciel.
Néanmoins, quand il peut être mis en place, on devrait
l’essayer.
Les changements de spécifications sont Dans le cadre d’un développement itératif général, les
les bienvenus, même s’ils interviennent spécifications n'ont pas besoin d'être définitivement
33
tardivement dans le développement. Le arrêtées très tôt. Cependant, même avec le
processus Agile met le changement au développement itératif traditionnel, à un certain point, les
service de l'avantage concurrentiel du spécifications doivent être bloquées pour fournir quelque
client. chose. À ce stade, le management du contenu du projet
entre en jeu.
Dans le développement Agile, les spécifications peuvent
changer à n’importe quel moment. L’idée est que le client
peut continuer à effectuer des modifications aussi
longtemps qu’il donne la priorité à ces changements au
cours de l’itération appropriée. Par exemple, si le client a
demandé trois rapports et qu’il en veut, plus tard, un
quatrième, ce dernier rapport peut être ajouté à la liste
des demandes, sans problème. A ce stade, le client donne
la priorité au nouveau rapport, et s’il en est ainsi, le
rapport doit être écrit. Si le budget du client est ouvert,
alors il n’y a pas de processus formel de changement de
contenu, et tout ce que le client veut et tout ce qu’il
considère comme une priorité doit lui être livré. Si le
budget du client est fixe, alors la priorité accordée à
l’accomplissement d’un changement, dans son essence,
signifie qu’une autre partie du travail ne sera pas réalisée.
Dans ce genre de scénario, le client veut forcer la gestion
de modification du contenu, en assurant que la priorité
n’est accordée qu’aux modifications les plus urgentes.
L’approche TenStep affirme que lorsque des modifications
interviennent, l’équipe doit être préparée à y répondre.
Cependant, les modifications de spécifications ont des
conséquences, en termes de budget et de dates de
livraison, qui doivent être approuvées par le
commanditaire. Si l’équipe agit ainsi, elle pratique le
management des modifications du contenu du projet.
Le processus TenStep recommande que les grands projets

soient décomposés en une série de projets plus petits, qui
peuvent être livrés plus rapidement et de manière
répétitive. Tous les projets n’ont pas cette flexibilité, mais,
Délivrez fréquemment les travaux sur lorsque cela est possible, la préférence doit aller aux très
logiciel, toutes les semaines ou tous les petits projets.
mois, avec une préférence pour les Les processus Agile peuvent pousser à l’extrême le cycle
échelles de temps brèves. court de livraison.
Certains projets de programmation extrêmes livrent selon
des cycles très courts, très souvent d’une semaine. Bien
que cela puisse être difficile à gérer, cette démarche n’est
pas foncièrement mauvaise.
Les hommes d'affaires et les

C'est la meilleure approche pour rester en contact avec les
développeurs travaillent ensemble
besoins des clients.
quotidiennement tout au long du projet.
Parfois, des personnes très motivées ont du mal à livrer les

Construisez vos projets autour d’individus projets à temps (Deming a reconnu cela il y a un demi-
motivés. Donnez-leur l'environnement et siècle). Elles peuvent se concentrer un peu trop sur les
le soutien dont ils ont besoin, et faites- détails de développement et pas assez sur la gestion du
leur confiance pour qu’ils puissent budget et des délais. Si des personnes motivées arrivaient
réaliser leur travail. toujours à livrer leurs projets à l'heure, il y aurait un
pourcentage plus élevé de projets réussis. Parfois, vous
avez besoin de placer les personnes motivées dans un
34
environnement plus structuré où elles pourront être plus
efficaces. L'auteur croit que la meilleure approche est
d'établir des projets autour de personnes motivées, et de
s’assurer qu’elles ont les outils, processus et qualifications
qui conviennent pour réaliser le travail.
Il n’y a aucun doute que la communication directe est la

meilleure formule dans beaucoup de circonstances.
Cependant, il y a des périodes où d'autres moyens de
communication sont très valables, par exemple, l’e-mail
La méthode la plus efficace et la plus
pour l’envoi de mises à jour à 20 personnes. Certaines
rentable pour transmettre des
informations pertinentes ont également besoin d’être
informations à l'équipe de développement
notées par écrit pour le cas où on en aurait besoin plus
et la diffuser en son sein, est la
tard, alors que tous les développeurs originaux seront
conversation de vive voix.
absents. Cette documentation devrait seulement contenir
les informations importantes. La documentation est
rarement tenue à jour par l'équipe de soutien et pourrait
perdre de la valeur au fil du temps.
Dans le cadre d’un développement itératif, le fait de

disposer de logiciels fonctionnant à la fin de chaque
itération est un bon moyen de mesurer les progrès.
Cependant, tous les projets ne peuvent être réalisés selon
Des logiciels qui fonctionnent sont le
une méthode de développement itérative, la mise en
premier facteur de progrès.
œuvre de packages par exemple. Aussi, dans la plupart
des projets, vous pouvez continuer à surveiller le plan à
l’aide des jalons majeurs de l'échéancier, pour vous
assurer que vous respectez bien ce dernier.
Le Processus Agile favorise un

développement durable. Les Le développement Agile met l’accent sur une semaine de
commanditaires, les développeurs et les travail de 40 heures et un rythme qui peut être maintenu
utilisateurs devraient être capables de indéfiniment. Naturellement, avec la planification et la
maintenir constamment un rythme gestion appropriées, c'est la meilleure approche.
constant.
Une attention continue à l’excellence L'excellence technique et l’anticipation de bonnes décisions

technique et à la bonne conception relatives à la conception sont essentielles pour que le
augmente la flexibilité. processus Agile puisse fonctionner.
D’accord. Les développeurs de logiciels et les clients

devraient se concentrer d'abord sur la livraison du noyau
des exigences. Ceci « maximise le travail non effectué ».
Cela permet également au logiciel d'être livré plus
La simplicité – l’art de maximiser l'effort rapidement.
de travail non fait -- est essentielle.
La méthodologie TenStep suit aussi ce modèle simple. Les
projets devraient être gérés selon la taille et la complexité
du travail, en tenant compte du fait que le tout le
management de projet doit donner de la valeur.
Si chaque équipe était très performante et techniquement

supérieure, il serait facile de se mettre d’accord ce point.
Les meilleures architectures, Cependant, certaines équipes de projet ne sont pas assez
spécifications et conceptions émergent mûres et n'ont pas le niveau nécessaire de compétence
des équipes auto- organisées. pour développer les meilleures conceptions et
architectures. Il est important que les bonnes personnes
soient choisies pour ce type de projets.
À intervalles réguliers, l'équipe réfléchit D’accord. Les équipes doivent constamment essayer de
35
sur la façon de devenir plus efficace, puis comprendre leurs forces et leurs faiblesses, et de
ajuste son comportement en comprendre comment les processus peuvent être
conséquence. améliorés. TenStep pense que ces changements
recommandés devraient également se faire jour dans
l'entreprise, de telle sorte que des idées d'amélioration
puissent être bénéfiques pour tout le personnel.
Kent Beck, Mike Beedle, Arie van

Bennekum, Alistair Cockburn, Ward
Cunningham, Martin Fowler, James
Grenning, Jim Highsmith, Andrew Hunt,
Ron Jeffries, Jon Kern, Brian Marick,
Robert C. Martin, Steve Mellor, Ken
Schwaber, Jeff Sutherland, Dave Thomas
www.agileAlliance.org
36
A6.3 Comparaison entre la méthodologie TenStep et ISO 1006
La méthodologie TenStep de management de projet® est compatible avec ISO 10006 (et la
surpasse) !
L’organisation internationale pour la standardisation (ISO) est une agence internationale spécialisée qui
promeut le développement de standards précis pour permettre de s’assurer que les produits, services et
matériaux à travers des Etats et nations membres restent conformes aux normes. Cette standardisation
facilite les échanges internationaux de marchandises et de services ainsi que le développement de la
coopération sur le plan des activités intellectuelles, scientifiques, technologiques et économiques. Les
résultats du travail technique de l’ISO sont publiés sous forme de standards internationaux. Il reste à
espérer que lorsqu’une société engage des processus aboutissant à l’obtention d’une certification, les
produits nés suite aux processus engagés soient conformes aux standards de tous les pays de la région
concernée.
Les standards internationaux pour le management de projet se trouvent réunis dans l'ISO 10006, et ils
sont de nature similaire au guide PMBOK® de l’institut de management de projet (PMI), même si les
standards ISO sont beaucoup moins élaborés). Le document ISO 10006 lui-même a été établi pour un
niveau très général. La description des processus et des clauses présentés dans la table ci-dessous ne
tient qu’en 20 pages. La méthodologie TenStep de management de projet est, en fait, beaucoup plus
élaborée et plus complète que la norme ISO 10006.
Le tableau suivant décrit le standard ISO de niveau général qui provient du document standard ISO
10006. La dernière colonne du tableau indique où l’on peut retrouver chaque domaine dans la
méthodologie TenStep de management de projet.
Il est à noter que le standard ISO 10006 comprend encore quelques sous-domaines et sous sous
domaines additionnels qui donnent une perspective et des informations plus étendues du point de vue
de l’organisation. Le tableau ci-dessous présente les processus ISO 10006 relatifs, en particulier, aux
processus concernant les projets. Il provient de l’Annexe A – organigramme des processus dans les
projets de l’ISO 10006.
ISO 10006
Méthodologie
TenStep de
Sous-
Description du management
Domaine Sous-domaine sous- Processus
processus de projet
domaine
Un ensemble de
processus de
direction qui inclut
la planification de
1.0 Définir le
l’établissement et
5 La travail
5.2 Processus l’implantation du
responsabilité 5.2 Stratégie 9.0 Gérer la
stratégique système qualité,
de la gestion. qualité et les
basé sur métriques
l’application des
principes du
management de la
qualité.
Identifier, estimer, 1.0 Définir le

6
planifier et affecter travail
Management 6.1 Processus liés Planifier les
6.1.2 toutes les 2.0 Élaborer
des aux ressources Ressources
ressources y l’échéancier et
ressources le budget
afférents.
6.1.3 Maîtriser les Comparer l’emploi 3.0 Gérer
37
Ressources actuel des l’échéancier et
ressources avec ce le budget
qui est disponible,
et agir si
nécessaire.
Définir une
structure
organisationnelle
adaptée aux
Mise en place de
besoins du projet, y
6.2 Processus liés la structure 1.0 Définir le
6.2.2 compris
au personnel organisationnelle travail
l’identification des
du projet
rôles et la définition
des niveaux
d’autorité et de
responsabilité
Sélectionner et
affecter le
1.0 Définir le
personnel suffisant,
travail
Affecter le doté des
6.2.3 8.0 Gérer les
personnel compétences
ressources
requises humaines
conformément aux
besoins du projet.
Développer les
capacités et
1.0 Définir le
compétences
travail
Développer individuelles et
6.2.4 8.0 Gérer les
l’équipe celles de l’équipe
ressources
afin d’améliorer la humaines
performance du
projet.
Évaluer les
exigences des
Lancement du
clients et des autres
7.2 Processus liés projet et
7 Réalisation parties intéressées, 1.0 Définir le
aux 7.2.2 développement
du produit préparer un plan de travail
interdépendances de son plan de
management de
management
projet et engager
d’autres processus.
3.0 Gérer
Gérer les l’échéancier et
Gestion des le budget
7.2.3 interactions au
interactions
cours du projet. 6.0 Gérer les
communications
3.0 Gérer
Anticiper les
l’échéancier et
Gestion des changements et les le budget
7.2.4
changements gérer à travers tous
5.0 Gérer le
les processus. contenu
Clore les processus 3.0 Gérer

Clore les
et obtenir les l’échéancier et
7.2.5 processus et les
retours le budget
projets
d’informations. (Clôture du
38
projet)
Définir les lignes

7.3 Processus liés Développement générales de ce 1.0 Définir le
7.3.2
au contenu du concept que sera le produit travail
du projet.
Consigner et
Développement maîtriser les 9.0 Gérer la
7.3.3 et maîtrise du caractéristiques du qualité et les
contenu produit du projet en métriques
termes mesurables.
Identifier et
consigner les
2.0 Élaborer
Définition des activités et les
7.3.4 l’échéancier et
activités processus requis le budget
afin de réaliser les
objectifs du projet.
Maîtriser les 3.0 Gérer

Maîtrise des
7.3.5 travaux exécutés l’échéancier et
activités le budget
au cours du projet.
Identifier les
Planifier les interdépendances 2.0 Élaborer
7.4 Processus liés
7.4.2 dépendances et les interactions l’échéancier et
à la durée le budget
des activités logiques parmi les
activités du projet.
Estimer la durée de
chaque activité, en
rapport avec les 2.0 Élaborer
7.4.3 Estimer la durée conditions l’échéancier et
spécifiques et les le budget
ressources
requises.
Mettre en
corrélation les
objectifs liés à la
durée du projet, les
charges et la durée
des activités, de 3.0 Gérer
Développer
7.4.4 manière à l’échéancier et
l’échéancier
constituer le cadre le budget
dans lequel vont
être développés
l’échéancier global
et les échéanciers
plus détaillés.
Maîtriser la
réalisation des
activités du projet
3.0 Gérer
Maîtriser en respectant les
l’échéancier échéances le budget
proposées et en
prenant les
mesures correctives
39
nécessaires pour
rattraper les délais.
Développer les 2.0 Élaborer

7.5 Processus liés
7.5.2 Estimer les coûts estimations des l’échéancier et
aux coûts
coûts pour le projet le budget
Produire le budget
du projet en
2.0 Élaborer
utilisant les
7.5.3 Budgétiser l’échéancier et
résultats de le budget
l’estimation des
coûts.
Maîtriser les coûts 3.0 Gérer

Maîtriser les
7.5.4 et les déviations du l’échéancier et
coûts le budget
budget du projet.
Planifier les
1.0 Définir le
7.6 Processus liés systèmes
Planifier les travail
à la 7.6.2 d’information et de
communications 6.0 Gérer les
communication communication du communications
projet.
Mettre les
informations
nécessaires à la
Gestion de disposition des 6.0 Gérer les
7.6.3
l’information membres de communications
l’organisation du
projet et des autres
parties intéressées
Maîtriser les
communications en
Maîtrise des 6.0 Gérer les
7.6.4 conformité avec le
communications communications
système planifié de
la communication.
1.0 Définir le
Déterminer les
7.7 Processus liés Identifier les travail
7.7.2 risques pour le
aux risques risques 7.0 Gérer les
projet. risques
Évaluer la
probabilité
1.0 Définir le
d’occurrence des
Évaluation des travail
7.7.3 événements à
risques 7.0 Gérer les
risque et leur risques
impact sur le
projet.
1.0 Définir le
Développer les
Traiter les travail
7.7.4 plans de réponse
risques 7.0 Gérer les
aux risques. risques
Mettre en place et
Maîtriser les 7.0 Gérer les
7.7.5 mettre à jour les
risques risques
plans de risques.
40
Identifier et
Planification et
7.8 processus liés maîtriser les achats 1.0 Définir le
7.8.2 maîtrise des
aux acquisitions et l’échéancier travail
achats
associé
Compiler les
Documentation
conditions
des exigences 1.0 Définir le
7.8.3 commerciales et les travail
concernant les
exigences
achats
techniques.
Évaluer et
déterminer quels
Évaluation des fournisseurs et 1.0 Définir le
7.8.4
fournisseurs sous-traitants travail
inviter à fournir des
produits.
Solliciter des
soumissions, les
évaluer, les
Contracter des 1.0 Définir le
7.8.5 négocier, préparer
engagements travail
et attribuer le
contrat de sous-
traitance
S’assurer que les

performances du
3.0 Gérer
Maîtrise des sous-traitant
contrats remplissent les le budget
exigences du
contrat.
Indique comment
l’entreprise source
8 Mesurer, du projet et celle 9.0 Gérer la
8.1 Processus liés
analyser et 8.1 Amélioration qui l’exécute qualité et les
à l’amélioration métriques
améliorer aspirent à
apprendre, à partir
du projet.
Indique comment
mesurer, recueillir
9.0 Gérer la
8.2 Mesurer et Mesurer et et valider les
8.2 qualité et les
analyser analyser données en vue de métriques
l’amélioration
continue.
Les activités que

l’organisation
Amélioration
source devrait
continue au 9.0 Gérer la
8.3 Amélioration effectuer visant
8.3.1 niveau de qualité et les
continue l’amélioration métriques
l’organisation
continue du
source
processus du
projet.
Amélioration Informations à 9.0 Gérer la

8.3.2 continue de fournir par qualité et les
l’organisation du l’organisation qui métriques
41
projet exécute le projet à
l’entreprise source,
afin de permettre
une amélioration
continue.
4.0 Gérer les
Pas spécifiquement traité dans ISO 10006 problèmes
majeurs
5.0 Gérer le
Pas traité de manière adéquate dans ISO 10006 contenu
6.0 Gérer les

Pas traité de manière adéquate dans ISO 10006 communications
9.0 Gérer la
Pas traité de manière adéquate dans ISO 10006 qualité et les
métriques
Le modèle cité ci-dessus est soumis à la norme IS0 2003.
42
______________________________________________________________________
Processus 0
Démarrage du projet
43
0.0 Démarrage du projet
(0.0. P1)
La méthodologie TenStep de management de projet ("Méthodologie TenStep" ou "TenStep") vous

enseigne comment gérer (planifier et piloter) un projet de manière proactive. Cependant, cela suppose
l'existence d'un projet à gérer. Chaque organisation dispose de procédures (ou processus) pour
identifier et autoriser les projets. Ces processus comportent généralement les caractéristiques suivantes
:
 Certains procédés pour identifier tous les projets qui pourraient potentiellement être entamés.
 Un processus d'entonnoir pour simplifier l'ensemble des projets potentiels dans le plus petit
nombre possible qui ont le plus de valeur et qui sont le plus centrés sur les objectifs et les
stratégies d'affaires de l’organisation.
 Un moyen de documenter les coûts et les avantages afin que le projet puisse être comparé à
d'autres projets.
 Ce document est généralement appelé « analyse de rentabilisation ».
 Identification d'un ensemble de renseignements requis pour obtenir l'approbation finale du

projet.
Le processus décrit ci-dessus est employé pour obtenir l'approbation préliminaire d’un projet.
Cependant, il peut y avoir un décalage entre le moment où un projet est initialement approuvé et celui
où le projet commence réellement. Par conséquent, lorsqu'un projet est prêt à débuter, un certain
nombre d'éléments doivent être validés pour garantir que le projet est prêt à démarrer.
Démarrer les projets de petite taille (0.0. P2)
Ce processus initial n'est pas nécessaire pour les petits projets.
Démarrer les projets de taille moyenne (0.0. P3)
Ce processus initial est facultatif pour les projets de taille moyenne. Si le projet est assez grand, vous
pouvez mettre en œuvre le processus de démarrage conçu pour les grands projets. Sinon, le processus
peut être omis.
Démarrer les grands projets (0.0. P4)
Les projets de taille moyenne et les grands projets ont suffisamment de masse critique pour justifier un
processus formel de démarrage avant le début du projet. Ce processus peut être très rapide ou prendre
un certain temps, en fonction de la disponibilité du commanditaire et de l'organisation exécutrice. Le
travail nécessaire à ce stade comprend les éléments suivants :
 Valider si l'analyse de rentabilisation est toujours valable
Il est possible que la conjoncture économique ait changé entre le moment où le projet a reçu
l'approbation préliminaire et le projet en cours. La valeur du projet et l'analyse de rentabilisation
devraient être validées pour garantir que rien n'a changé. Le fait que le projet ait reçu l'approbation
préliminaire ne signifie pas pour autant que ce dernier ait automatiquement droit à l'exécution.
 Identifier le commanditaire officiel
Le commanditaire initial était probablement la personne ayant aidé à l’élaboration du plan de

rentabilisation et qui a demandé des fonds pour le projet. Maintenant que le projet est prêt à démarrer,
le commanditaire doit être validé. Il est possible que l'équipe de direction ait changé et qu'un nouveau
44
commanditaire doive être identifié. Il est également possible que le commanditaire d'origine se situe à
un niveau trop élevé dans la hiérarchie de l’organisation pour jouer le rôle d’un « commanditaire actif »
requis pour le projet. Dans ce cas, le commanditaire d'origine jouerait le rôle de commanditaire exécutif
et déléguerait les détails à un commanditaire de projet qui jouerait un rôle plus concret à mesure que le
projet progresse.
 Affectation d'un chef de projet
Le chef de projet est celui qui dirige le projet lors du processus de planification plus détaillé, et qui gère
le projet jusqu’à la fin. Le chef de projet doit être affecté à ce stade.
 Identifier et gérer les parties prenantes
Lorsque le projet démarre, il est important de commencer à comprendre et à gérer les différentes
parties prenantes. Vous pouvez obtenir de plus amples renseignements en consultant le chapitre 0.0.1
Identifier les parties prenantes.
L'approche à suivre pour compléter le processus de démarrage peut varier en fonction de l'entreprise et
de la taille du projet. Il est probable que le travail puisse être complété de manière informelle par le
simple fait que le commanditaire confirme que le travail est prêt à démarrer et qu’il affecte un chef de
projet pour commencer à travailler sur les détails. Si le projet est important et si une controverse est en
cause, il est possible que l'analyse de rentabilisation elle-même doive être formellement validée à
nouveau et qu’un certain nombre de réunions et de documents soient requis afin que le projet puisse
débuter officiellement.
Le processus de démarrage ne garantit pas encore que le projet soit vraiment mis en œuvre. Le but de
cette étape consiste tout simplement à lancer le projet dans le processus de définition du travail,
d’élaboration de l’échéancier plus détaillé et d’un budget final. la charte du projet devra à nouveau être
approuvée, de sorte que l'exécution effective du projet puisse commencer par la suite.
45
0.0.1 Identifier et gérer les parties prenantes
Les parties prenantes sont des personnes ou des groupes spécifiques qui ont un enjeu ou un intérêt
dans l'issue du projet. Normalement, les parties prenantes viennent de l'intérieur de l'entreprise et
pourraient inclure des clients internes, le management, les employés, les administrateurs, etc. Un projet
peut également avoir des parties prenantes externes, y compris les fournisseurs, les investisseurs, les
groupes communautaires et les organismes gouvernementaux..
Outre que le management des attentes du commanditaire du

projet, le responsable du chef de projet, l'équipe du projet et le
client, les petits projets ne doivent généralement pas trop se
soucier de la compréhension et du management de la
communauté des parties prenantes dans son intégralité.
En revanche, à mesure que votre projet prend davantage de taille,

vous avez généralement à vous soucier de plus en plus de parties
prenantes. Si vous avez une communauté large et diversifiée de
parties prenantes il est logique d'en effectuer une analyse. Dans
certains cas, vous pourriez avoir besoin de leur aide et vous devez vous en approvisionner, et dans
d'autres cas, vous devez les mettre au courant des réalisations de votre projet. Cette analyse des
parties prenantes vous aidera à déterminer les divers groupes de parties prenantes et savoir quel rôle
ils ont dans votre projet.
Utilisez le processus suivant pour l'analyse des parties prenantes.
Rôle Processus d'analyse des Parties Prenantes

1 Chef de Identifier les Parties Prenantes
projet, Vous ne pouvez pas faire l'analyse des parties prenantes sans savoir au préalable
équipe de qui sont les vôtres. Organisez une session de remue-méninges avec votre équipe
projet pour identifier les parties prenantes possibles. Celles-ci pourraient être des
individus ou des groupes de parties prenantes. La liste ci-dessous est un exemple
de liste de parties prenantes potentielles.
 Commanditaire
 Client
 Directeur de projet
 Équipe de management opérationnelle
 Équipe de projet
 Les utilisateurs finaux
 Fournisseurs
 Autres départements internes / projets
 Entreprises partenaires
 Tierces parties (fournisseurs, investisseurs, syndicats, organismes
gouvernementaux)
Il est important de reconnaître l'équipe du projet en tant que groupe spécifique de
parties prenantes. Cela permettra au chef de projet de se concentrer sur leurs
besoins et de s'assurer que leurs besoins sont pris en considération sur une base
continue tout au long du projet.
2 Chef de Déterminer l'importance de chaque partie prenante

projet, Regardez chaque partie prenante et déterminez dans quelle mesure elle joue un
équipe de rôle important pour la réussite de votre projet ou de ce que serait l'impact sur
projet votre projet si la partie prenante n'était pas du tout en relation avec vous. Classez
46
chaque partie prenante en termes de haute / moyenne / faible importance. Par
exemple, si votre projet se déroule bien sans aucune partie prenante, alors cette
partie prenante a probablement une faible importance. Si votre projet ne peut
réussir sans elle, elle a probablement une grande importance. Cette évaluation est
importante parce que parfois, vous dépensez trop de temps et d'efforts à travailler
avec des parties prenantes qui présentent peu d'importance pour votre projet,
alors que vous écourtez le temps que vous passez avec les parties prenantes qui
ont une très grande importance.
Un autre domaine que vous devez prendre en considération lors de la
détermination de l'importance d'une des parties prenantes est le rayonnement
inhérent à une personne. Vous pourriez vous demander si la partie prenante a le
pouvoir de bloquer ou d'entraver les progrès du projet, si cette dernière a le
pouvoir ou si elle est suffisamment influente pour aider à faire progresser le projet
d'une manière plus harmonieuse? Cette information est importante à connaître.
Par exemple, vous pouvez considérer qu'une partie prenante a peu d'importance si
elle ne montrait pas d'engagement actif. Vous pouvez par contre la considérer
comme importante si elle devait s'impliquer dans le projet.
3 Chef de Identifier le niveau d'intérêt de chaque partie prenante

projet, Chaque partie prenante, à des degrés divers, a un enjeu ou un intérêt dans votre
équipe de projet. Vous devez maintenant déterminer ce que sont pour chacun ces enjeux et
projet intérêts. Dans certains cas, une partie prenante peut espérer obtenir quelque
chose de spécifique à partir du projet et souhaite être tenue au courant du progrès
réalisé et souhaite être impliquée autant que faire se peut. Dans d'autres cas, la
partie prenante peut avoir très peu d'intérêt dans le projet, et ne cherche pas
tellement à être tenue informée. Là encore, vous pouvez classer chacune des
parties prenantes en termes de haut / moyen / faible intérêt.
4 Chef de Identifier l'impact que chaque partie prenante peut avoir sur le projet
projet, Vous pouvez maintenant recueillir une longue liste de personnes et d'organisations
équipe de qui seront touchées, à divers niveaux par votre projet. Déterminer maintenant quel
projet sont leurs impacts et influences. Certaines parties prenantes peuvent bloquer votre
projet. D'autres n'ont aucun pouvoir formel, ni d’influence. Cette information vous
aidera à déterminer la façon de travailler avec les parties prenantes. Certains
peuvent être intéressés par ce que vous faites et d'autres n'en prennent pas soin.
Vous avez besoin de classer chaque partie prenante dans des groupes communs
afin de déterminer comment manager au mieux chaque partie prenante.
5 Chef de Comprendre l'engagement affectif de chaque partie prenante

projet, Comprendre l'engagement affectif de chacun des intervenants est très important
équipe de pour votre projet. Vous avez besoin de comprendre leur point de vue actuel sur le
projet projet et comment ils pourraient réagir à son égard. Vont-ils en être ou non des
partisans ? Vous devez trouver les facteurs susceptibles d’influencer leurs opinions
et d'utiliser cette information pour élaborer votre plan d'engagement.
Dans la plupart des cas, votre équipe et vous-même devraient être en mesure de
déterminer le niveau d'engagement émotionnel de chaque partie prenante. Mais
pour les cas où vous ne le pouvez pas, vous devriez organiser une réunion avec
ces parties prenantes et le leur demander directement.
6 Chef de Déterminer comment engager chaque partie prenante

projet, Pour chaque partie prenante, vous devez penser à un ensemble d'activités, voire à
équipe de une approche globale pour répondre à leurs besoins. Vous devez identifier les
projet activités qui vous aideront à atteindre vos intérêts tout en reconnaissant
également l'importance de chaque partie prenante. Évidemment, vous passerez
plus de temps à travailler avec les parties prenantes les plus importantes pour
votre projet et moins de temps avec les parties prenantes qui le sont moins. Le but
de cette étape est de définir les activités que votre équipe de projet doit faire pour
47
vous assurer que vous visez l'intérêt de chaque partie prenante. Vous allez
sûrement communiquer avec un grand nombre de ces parties prenantes, de
manière à ce que ces activités coïncident avec votre plan de communication. Il est
correct de les mentionner dans ces deux emplacements. Vous êtes encore
seulement en train d'exécuter une activité à la fois. Vous pouvez utiliser le tableau
suivant pour vous aider à mener vos discussions.
Importance / Intérêt Style de management
Ce sont les parties prenantes les plus

importantes. Ces personnes et ces groupes
Grande importance and doivent être gérés de près et tenus engagés
grand intérêt pleinement dans le projet. Vous devez faire les
plus grands efforts pour satisfaire leurs
besoins.
Ces personnes et ces groupes doivent être

Grande Importance mais peu gérés de près pour vous assurer de satisfaire
d'intérêt leurs besoins, mais vous ne souhaiterez pas
les gérer plus ou communiquer plus avec eux.
Ces personnes et ces groupes ont besoin

d'être informé de façon adéquate.
Communiquez avec eux régulièrement afin de
Faible importance and grand
vous assurer qu'aucun problème majeur ne se
intérêt
manifeste. (Note: normalement, ces individus
et ces groupes peuvent être très utiles lorsque
vous définissez et planifiez votre projet)
Surveiller ces individus et groupes afin de vous

assurer de leur statut ne change pas à travers
Faible importance and peu
la vie du projet; et si c'est le cas, vous aurez
d'intérêt
besoin de réévaluer la façon dont ils sont
gérés.
7 Chef de Gagner l'approbation des parties prenantes si nécessaire

projet Dans certains cas, les parties prenantes sont intéressées par certains aspects de
votre projet. Dans d'autres cas, vous avez besoin de certains autres aspects
émanant d'elles. Si vous avez besoin de quelque chose provenant des parties
prenantes ou du groupe de parties prenantes, assurez-vous qu'ils comprennent ce
que sont vos attentes et assurez-vous qu'ils acceptent de les satisfaire. Par
exemple, le groupe de parties prenantes peut avoir besoin de ressources, de
temps, d'argent, d'attention, de retour, etc.
8 Chef de Insérez les activités dans l'échéancier

projet Vous ne souhaiteriez pas garder une feuille séparée pour les activités des parties
prenantes. Après avoir identifié les activités pour engager les groupes de parties
prenantes, insérez toutes les activités dans l'échéancier du projet avec le
responsable qui lui correspond, le calendrier, les efforts estimés, etc.
48
______________________________________________________________________
Processus 1
Définir le travail
49
1.0 Définir le travail
(1.0. P1)
Combien de fois avez-vous entendu

parler ou avez été vous-même impliqué
dans des projets qui ont échoué, ou
simplement qui n’étaient peut-être pas
aussi réussis qu’ils auraient dû l’être?
Avez-vous déjà pris la peine de prendre
du recul afin d’identifier ce qui a amené le
projet à mal tourner? Si vous l’avez fait, il
y a de fortes chances que vous vous
soyez dit: « Tu sais, on aurait dû
consacrer plus de temps à la planification
du projet. »
La plupart des projets sont soumis à des
délais et il semble que ces derniers
deviennent de plus en plus brefs. Les
délais agressifs imposés mettent le chef
de projet sous pression pour qu’il démarre
le projet aussi tôt que possible.
Cependant, avant que le travail ne
commence, il faut prendre le temps
d’établir un plan préalable afin que le travail soit correctement compris et que tout le monde soit
d’accord. Ce n’est pas du temps perdu. Cela permet au chef de projet de s’assurer que l’équipe du
projet et le client ont une perception commune des résultats à livrer à la fin du projet, de la date à
laquelle il sera achevé, de son coût, de la répartition des tâches et de la façon dont le travail sera
effectué.
Diagramme de flux simplifié

À la fin d’un projet difficile, les avantages de la planification ressortent de manière évidente. Mais les
avantages sont également connus avant la fin du projet. En général, la planification présente les
avantages suivants :
 Une entente sur les objectifs, les livrables, le contenu, les risques, les coûts, l’approche du
projet, etc. Cela permet de s'assurer que l'équipe du projet et le commanditaire sont d'accord
sur le travail demandé.
 La possibilité de déterminer si l'étude de faisabilité originale est toujours valable. Au moment de

l’approbation initiale du projet, l’estimation de ses coûts et de sa durée a probablement été
effectuée sur un plan très général – peut-être avec une marge de variation de +/- 50 %.
Maintenant que le projet est vraiment lancé, il faut affiner les estimations pour que cette marge
se rapproche du niveau souhaitable de +/- 10%. Ce processus d'ajustement pourrait bien
entraîner des estimations plus élevées que prévu, ce qui pourrait même avoir pour
50
conséquence le fait que le projet devienne soudain inintéressant du point de vue commercial.
Par exemple, un projet avec un effort de travail de 10.000 heures peut être avantageux. Mais si
une planification plus détaillée aboutit à une estimation plus précise de l'ordre de 20.000
heures, le projet pourrait alors sembler démesuré au commanditaire.
 L’’assurance que vous disposerez des ressources dont vous aurez besoin en temps utile. Ceci
est le résultat de l'élaboration de l'échéancier en tenant compte des ressources affectées.
 Disposer d'une base de comparaison générale pour évaluer la progression du projet. Ceci est le
résultat de l'établissement de jalons sur la base d'un échéancier plus détaillé.
 La validation en amont des processus utilisés pour gérer le projet avec le client. Les procédures
utilisées pour gérer le projet ne doivent pas constituer une surprise. Elles doivent être discutées
et approuvées en amont.
Il est logique de penser que les petits projets nécessitent un cycle

de planification plus court que pour les grands. Le travail requis
pour planifier un projet dépend de la quantité d'informations et du
niveau de détail qui doivent être pris en considération et être
documentés. Le temps nécessaire pour la définition d’un projet
dépend du temps nécessaire pour analyser et documenter les
informations ainsi que du temps requis pour obtenir l’accord du
client.
Parfois, le chef de projet est frustré en raison de la difficulté à se

mettre d’accord avec le client sur le contenu, les délais et les
coûts du projet. C’est bien là la raison pour laquelle ce travail doit
être effectué à l'avance. Pensez aux problèmes auxquels vous serez confronté si vous essayez d’obtenir
l’accord du client sur ces points seulement une fois que le travail a commencé et que les livrables sont
en cours de production !
Comprendre le projet (1.0. P2)
Avant d'apprendre comment définir le travail, vous devez connaître la définition précise d’un projet. La
maîtrise des techniques formelles de management de projet vous éclairera sur ce point.
 1.0.1 Qu’est ce qu’un projet?
o 1.0.1.1 Les dates de début et de fin de projet
 1.0.2 Le rôle de chef de projet
Les processus utilisés pour le management de votre projet doivent être établis en fonction de la taille
de votre projet. Les grands projets doivent être gérés avec plus de rigueur et d’organisation que les
petits projets.
Dimensionner le projet (petit, moyen, grand) (1.0. P3)
Le processus TenStep contient des conseils spécifiques pour savoir comment gérer un projet en se
basant sur sa taille. Mais auparavant, vous devez classer votre projet dans une catégorie.
La méthodologie TenStep contient des conseils spécifiques pour la façon à gérer un projet basé sur la
taille; en revanche, il faut dans premier temps situer la catégorie du projet entre grand, moyen ou petit.
Dans certaines entreprises, un projet de six mois et 10.000 heures sera considéré comme un grand
projet. Dans d’autres sociétés, le même projet sera considéré comme petit. La méthodologie TenStep
fournit quelques indications, mais chaque entreprise doit déterminer les directives qui leurs
conviennent. Voir 1.0.3 Dimensionner votre Projet (Petit, Moyen, Grand) pour plus d'informations.
Après avoir examiné les exposés précédents, poursuivez à travers l’information relative à la définition
du projet.
51
1.1 Définir le travail / Processus
1.2 Définir le travail / Techniques
1.3 Définir le travail / Références rapides
52
1.0.1 Qu’est-ce qu’un projet?
Avant que vous puissiez être un bon « chef de projet » et appliquer les bonnes techniques de «
management de projet », vous devez d’abord être sûr que le travail que vous êtes sur le point
d’entreprendre est bel et bien un projet. Certains disent que tout travail est un projet, mais ceci n’est
pas tout à fait exact. Il existe en réalité de nombreux types de travail : la maintenance, aussi appelée le
support, les opérations comptables, la gestion, les projets, etc.
 Par le travail de maintenance, on maintient les solutions déjà existantes. Pour l’équipe de
développement de solutions informatiques, le travail de maintenance consiste à répondre aux
questions qui leur sont posées, à assister à des réunions régulièrement planifiées, à résoudre
des problèmes dans les systèmes déjà en fonctionnement, etc. Pour le personnel chargé des
ventes, cela peut consister à répondre aux questions des clients, modifier les contrats existants,
rectifier les factures erronées des clients, etc.
 Le travail d’opérations comptables est un travail régulier nécessaire au bon fonctionnement des
affaires courantes. Pour un comptable, cela pourra consister à vérifier les rapports, équilibrer
les comptes, assurer les écritures comptables, etc.
 Le travail de gestion est, lui, requis pour gérer et diriger personnes et processus d’affaires.
Ces différentes catégories de travail représentent avant tout une part constante et habituelle de votre
quotidien. C’est le travail que vous effectuez aujourd’hui, que vous effectuerez demain et dans un mois.
A l’inverse, les projets, eux, ne sont pas routiniers. Ce qui différencie avant tout les projets des
catégories de travail précédemment citées est d’avoir, par essence, des dates de début et de fin bien
définies. Il est un point dans le temps où le travail n’existe pas encore (avant le projet), un autre où il
existe (le projet), et enfin un dernier où il n’existe plus (après le projet). C’est ce critère qui permet de
déterminer si un travail est effectivement un projet ou non. Il existe plusieurs options pour déterminer
les évènements marquant le début et la fin d'un projet. Ces évènements ainsi que la définition de la
date de début et de fin varient d'une société à une autre. Voir 1.0.1.1 pour plus d'informations sur
certaines de ces alternatives et des conséquences potentielles pour votre organisation.
Les autres caractéristiques d'un projet comprennent:
 Tous les projets sont uniques. Même si un projet est semblable à un autre, il est tout de même
unique en termes de cadre temporaire, de ressources, de l'environnement du travail, etc.
 Les projets aboutissent à la création d'un ou plusieurs livrables.
 Les projets disposent de ressources affectées - ou bien à plein temps, à temps partiel ou les
deux à la fois. Ceci est reflété par un budget déterminé ou un budget implicite basé sur les
ressources affectées.
 Les projets disposent d'un contenu de travail défini.
Ceci dit, il faut rester pratique. En théorie, des projets peuvent nécessiter une heure, 100 heures, ou
100.000 heures de travail. Ainsi, vous devez bien être conscient que, bien que la réalisation d’un petit
produit livrable soit un projet, celle-ci ne nécessite ni la structure ni la discipline dont on pourrait faire
usage quand il s’agit d’un projet de plus grande envergure. Un projet d’une heure, vous le réalisez de la
façon la plus simple. Toute la planification, l’analyse et la conception est élaborée dans votre tête. Pour
un projet de vingt heures, vous opérez en général de la même façon. Cependant, vous devriez cette
fois planifier un peu, peut-être communiquer un peu, et traiter quelques problèmes. Un projet de cent
heures nécessite probablement déjà trop de travail pour ne pas songer à tout planifier et à tout gérer
mentalement. Vous devriez par exemple commencer à définir le travail et à établir un échéancier du
projet simple. Un projet de 5.000 heures nécessite toute une discipline de management de projet. A
l’autre extrême, un projet de 100.000 heures nécessite probablement trop de travail pour que vous
puissiez tout avoir en tête. Il vous faudra décomposer le grand projet en de plus petits projets, ayant
des liens entre eux, afin d’effectuer la totalité du travail.
53
Il y a des critères qui permettent de déterminer si un projet doit être considéré comme petit, moyen ou
grand. Ils sont explicités dans 1.0.3 Dimensionner votre projet (petit, moyen, grand). N’oubliez pas que
ce ne sont que des indications qui ont besoin d’être ajustées et validées par votre organisation.
Avant de suivre les différentes étapes de la méthodologie TenStep, assurez-vous que vous avez bien un
projet et que vous choisissez la discipline et la rigueur qui seront à sa mesure.
54
1.0.1.1 Les dates de début et de fin de projet
(1.0.1.1. P1)
L’une des caractéristiques d’un projet est que l’on retrouve toujours une date de début et une date de
fin. Cela paraît relativement simple jusqu’à ce que vous essayiez de définir ce que ces dates
représentent précisément. Il n’existe pas de standard universel recommandé pour l’une ou l’autre. à
beaucoup d'égards, cela dépend de chaque organisation et des implications du choix de telle
alternative plutôt que de telle autre. Voici quelques options qui peuvent vous aider à identifier la date
de début de votre projet.
 Le moment où l’idée naît. Cela ramène la date du début longtemps avant que le projet ne
prenne réellement forme, et, à première vue, cette définition peut sembler ne pas avoir de
sens. Rappelez-vous cependant que la définition que vous choisissez peut dépendre des
implications qu'elle peut avoir. Vous pouvez choisir cette définition si votre entreprise
s’intéresse au temps qui sépare l’idée de la réalisation de celle-ci à travers un projet. Une des
préoccupations de l’entreprise est que la mise en œuvre des bonnes idées prend trop de temps.
Si votre entreprise désire réduire le laps de temps qui sépare une idée de sa réalisation, vous
pouvez utiliser une définition aussi précoce de la date de démarrage du projet.
 Le moment où un budget est décidé. Cette définition est un peu plus concrète que la
précédente. Dans cette définition, une idée est née, et cette idée a été suffisamment poussée
pour qu'une évaluation du rapport coûts/bénéfices soit préparée. Le projet a classé cette idée
comme prioritaire, et un budget réel a été approuvé. Gardez à l’esprit que le budget a été
approuvé durant le processus de planification commerciale de l'année précédente pendant
l'élaboration de l'échéancier du projet. Le travail réel ne commencera pas avant l’année
suivante. Cependant, cette définition aussi fait démarrer le décompte très tôt pour beaucoup
d'organisations.
 Le moment où un manager de projet a été désigné. Ce critère est plus courant. Il est
difficile de dire qu’un projet a commencé avant qu’un chef de projet n'ait été désigné. Lorsque
cela est fait, la planification et la définition du projet commencent, et on entre dans le vif du
sujet. Cette définition générale de la date de début de projet est celle utilisée dans la
méthodologie TenStep.
 Le moment où la charte du projet a été approuvée par le commanditaire. Dans

certaines organisations, le projet commence officiellement lorsque le client approuve le
document de la charte du projet. Certaines entreprises exigent que la charte du projet et son
échéancier soient approuvés avant d'affecter les membres de l’équipe. Cela permet de s’assurer
que l'accord préalable est acquis avant le lancement du projet proprement dit.
 Le moment où se tient la réunion de démarrage du projet. Avec cette définition, la

planification et la définition du travail sont considérées comme un "pré- projet". Tous les
projets débutent avec une réunion formelle de démarrage entre le client et les membres de
l’équipe. Avant la tenue de cette réunion, le client a approuvé la date du commencement du
travail et l’équipe du projet a été désignée. Cette réunion est le moment où l'on signifie à tout
le monde que le projet est prêt à commencer. En raison de ce travail préalable, beaucoup
d'organisations considèrent que la réunion de démarrage est trop tardive pour être considérée
comme la définition de la date de commencement du projet.
Pourquoi la date de début est-elle importante? (1.0.1.1. P2)
Dans une certaine mesure, vous pourriez penser que la date à laquelle commence le projet n’a pas
vraiment d’importance. Avoir une date de début non définie n’empêche pas le travail d’être un projet. Il
est évident qu’un projet commence à un moment donné, puisqu’il y a un moment où le travail n’avait
pas encore démarré, qu’il n’était pas en cours, et un moment où il était en train d'avancer. Il existe
donc un moment où l'on peut dire que le projet a effectivement commencé.
55
La raison pour laquelle il est important de connaître la date de début est qu'elle peut avoir des
conséquences et des implications financières liées à la durée nécessaire pour terminer le projet. Voici
quelques exemples de ces conséquences:
 La responsabilité de l’équipe de projet. Il est difficile de rendre les gens responsables de

circonstances pour lesquelles ils n’ont pas le contrôle. C’est pourquoi il est logique qu'un chef
de projet ne soit pas tenu pour responsable du projet avant qu'il n'ait été désigné. Si l'horloge
du projet se met en marche avant cette désignation, il est possible que certaines décisions
aient déjà été prises et que certaines ressources aient été déjà dépensées, et par conséquent, il
n’a pas un contrôle total. De même, si les membres de l’équipe sont tenus pour responsables
de l’achèvement du projet dans le respect du budget et du planning, il est en revanche difficile
de les tenir pour responsables du travail effectué et des décisions qui ont été prises avant leur
désignation. C’est pourquoi le projet devrait peut-être commencer lorsque la charte et
l'échéancier du projet sont approuvés, ou alors seulement après que la réunion qui donne le
coup d’envoi du projet ait été tenue.
 L’amélioration des processus. De nombreuses entreprises gardent une trace de la durée

totale de leurs projets, et tentent de réduire la durée moyenne de leurs projets au fil du temps.
Il est important que tout le monde au sein de l’entreprise utilise les mêmes dates de début et
de fin. Dans le cas contraire, les durées de projet n’auront aucune signification.
 Raisons financières et comptables. De nombreux projets ont des dépenses

d’investissement, d'un point de vue comptable (par opposition aux charges). La définition
précise du début d’un projet a des conséquences, en termes de travail qui peut être capitalisé
et de travail qui doit être financé.
 Comparaison avec d’autres entreprises. Si vous désirez comparer la durée de réalisation

des projets de votre entreprise à d'autres organisations ou compagnies, vous voudriez être sûr
de la définition de vos dates de début et de fin. Si votre entreprise considère qu’un projet
commence lorsqu’un chef de projet est désigné, et que les autres entreprises prennent pour
date de début la date de la réunion de démarrage du projet, alors il semblera que votre
entreprise met plus de temps à réaliser ses projets.
Les dates de fin de projet (1.0.1.1. P3)
De la même façon, un certain nombre d’événements potentiels peuvent signifier la date de fin du
projet. Deux définitions reviennent le plus souvent:
Premièrement, la réunion de conclusion de projet peut signifier que le projet est effectivement terminé.
Bien que la fin du projet fixée lors de la réunion de conclusion de projet nous aide un peu, cela ne
répond pas à l'ensemble de la question et ne nous dit pas quand faut-il programmer la date de cette
réunion. On peut tenir cette réunion après un certain nombre d’événements, par exemple, après avoir
terminé le projet, ou bien trente jours après. Cependant, la définition finale de l’accomplissement du
projet n’est pas résolue par cette réponse.
Une seconde définition pourrait être que le projet se termine lorsque qu’il n’y a plus d’argent. Bien que
cela soit vrai dans de nombreux projets, terminer le projet lorsque le budget est épuisé est une réponse
financière et hautement arbitraire. Cela ne répond pas à la question plus fondamentale de comment
définir la fin d’un projet.
Un certain nombre d’événements peuvent signifier que le projet est terminé. Cependant, certaines
options de date de fin n’ont pas de sens pour certains types de projet. Par exemple, si votre projet
aboutit à la création d’un document, il serait raisonnable de dire que votre projet se termine avec
l'approbation de ce document. Pour un tel projet, il ne serait pas logique de dire que le projet devrait
être mis en production pour une durée de 30 jours avant de se terminer.
 L’approbation. La date de fin de projet la plus pertinente pourrait coïncider avec celle de
l’approbation formelle des livrables du projet par le commanditaire. Cette définition est
probablement valide pour presque tous les projets. Vous produisez les livrables du projet pour
un individu ou pour un certain groupe. Il est évident que le projet n’est pas terminé tant que
les personnes qui ont commandé le travail n’ont pas eu satisfaction. Ceci peut impliquer qu’il
56
faille présenter le résultat pour approbation, et ensuite exécuter des travaux de reprise, sur la
base des informations reçues en retours. Cependant, pour que le projet puisse être mené à
terme avec succès, les livrables doivent être approuvés. Le projet pourrait aussi prendre fin
lorsque les livrables finaux ont été rejetés et que nul autre travail n’a été planifié.
 La mise en œuvre. Beaucoup de projets ont comme conséquence la mise en œuvre d’un
produit ou d’un service, en particulier les projets techno- informatiques. Dans la plupart des
cas, vous avez besoin de la signature du commanditaire avant de pouvoir commencer la mise
en œuvre, et ainsi, celle-ci ne pourra avoir lieu qu’à une date ultérieure. Cela peut constituer un
événement simple, ou peut être un ensemble complexe d’activités. Le projet ne s'achève pas
quand la mise en œuvre commence, mais lorsqu’elle se termine. Par exemple, si vous mettez
en application une solution dans des lieux multiples et en un court laps de temps, le projet se
terminera quand tous les lieux en question auront été traités avec succès. C’est une date de fin
commune pour beaucoup de projets techno- informatiques.
 Transfert vers le support. Si votre projet établit une solution qui a une longue durée de vie,
à un certain moment, les produits du projet vont passer de la catégorie « développement » à la
catégorie « support ». Parfois, ce changement de statut signifie également qu’il y a un
changement dans l’entreprise responsable de la solution. Si votre solution de projet est
transférée à une structure de support, ce sera alors le moment de dire que le projet initial a été
accompli. Même s’il n’y a pas une organisation séparée impliquée, il y a un moment où il est
clair que la solution n’est plus en développement mais en mode support, et alors on pourra dire
que le projet est officiellement terminé.
 Mise en œuvre, plus un cycle de production. Si votre solution a un cycle de production,

dans de nombreux cas, elle devra être mise en production avant que le projet ne soit considéré
comme achevé. Par exemple, si la solution comporte des opérations de traitement quotidiennes
et un cycle d'arrêt mensuel, celle-ci doit être mise en application puis soutenue par l’équipe de
projet pendant au moins un mois. Cela tombe sous le sens puisque c’est l’équipe de projet qui
connaît le mieux la solution, et qui peut répondre le plus rapidement si des problèmes
surviennent. Cela permet également de s’assurer que la solution est stable avant de la
transférer à l'équipe de support.
 Mise en œuvre, plus une année de production. Ceci est généralement basé sur le cycle du
budget plutôt que sur une définition de gestion de projet. Il peut y avoir des raisons
comptables à ce qu’un projet existe jusqu’à la fin de l’exercice budgétaire. Quand le nouvel
exercice budgétaire arrive, le projet est fini et le support commence. Encore une fois, ceci ne
répondrait pas à la question de base dans une perspective de management de projet, mais
cela peut néanmoins être la manière dont les dates de fin de projet sont définies dans votre
entreprise. Cette définition pourrait particulièrement être applicable pour de grands projets.
La question de savoir quand un projet débute et se termine de façon formelle est souvent considérée
par la plupart des gens comme évidente. Cependant, il n’existe pas de réponse facile adaptée à chaque
entreprise. Il y a probablement une ou deux réponses qui semblent plus sensées du point de vue du
management de projet , mais des facteurs culturels ou financiers peuvent amener votre organisation à
définir autrement les limites d’un projet. Si vous essayez de comparer les différents projets dans votre
entreprise, ou si vous vous comparez vous-même à d’autres entreprises, il est alors vital que tout le
monde utilise les mêmes repères de début et de fin. Si vous n’effectuez pas de comparaisons, alors,
dans une certaine mesure, ces dates n’ont besoin d’être connues et acceptées au préalable, pour
chaque projet, que par les principales parties prenantes. Cet accord vous évitera de vous retrouver
dans une situation où vous crieriez victoire, alors que d’autres pensent qu’il vous reste encore du du
pain sur la planche.
57
1.0.2 Le rôle de chef de projet
(1.0.2. P1)
Un nouvel employé dans la salle du courrier d’une entreprise remarqua un homme âgé assis dans un
coin, triant le courrier, pesant des paquets, affranchissant des lettres et faisant d’autres travaux
simples. Il demanda à son supérieur qui était cet homme.
« C’est Joseph », lui répondit son supérieur. « Il est dans l’entreprise depuis 35 ans, et il va bientôt
partir à la retraite. »
« Vraiment ? » dit le nouvel employé. « Et il a travaillé à la salle du courrier pendant tout ce temps
?»
« Non, il l’a quittée il y quelques années. Mais il a demandé à y revenir, après avoir été chef de
projet durant quelques années. »
Il est facile de décrire le rôle de chef de projet d’une manière superficielle et hâtive. En fait, c'est
probablement facile du point de vue des manuels scolaires. En réalité, on peut noter de grandes
disparités dans les rôles et les responsabilités des chefs de projets d’une entreprise à une autre. Ainsi,
bien que la méthodologie TenStep fournisse une vue d’ensemble des attributions d’un chef de projet,
vous devrez toujours déterminer quel est le rôle de chef de projet dans votre organisation ou dans
votre entreprise.
Définition générale (1.0.2. P2)
En général, le chef de projet est responsable de la réussite globale du projet.
Responsabilités par rapport aux processus (1.0.2. P3)
Le chef de projet est responsable à 100% des processus utilisés pour gérer le projet.
Qu’est ce qui détermine la réussite d’un projet ? Si vous suivez la méthodologie TenStep de
management de projet, vous devez d’abord définir le projet et élaborer un échéancier et un budget.
C’est là que commencent les responsabilités du chef de projet. Une fois le travail sur le projet engagé,
si vous découvrez que le contenu n’a pas été bien défini, c’est le chef de projet qui est tenu pour
responsable. Si votre projet n'est pas bien planifié, c’est également au chef de projet qu’incombera
cette responsabilité.
Définir le projet signifie le fait de comprendre et d'obtenir l’accord sur l’ensemble des objectifs, le
contenu, les risques qu’il comporte, l’approche, le budget qui lui est alloué, etc. Cela inclut également la
définition et l’adoption d’un Plan de Management de projet spécifique qui sera utilisé pour la gestion du
projet en question.
Ceci ne veut pas dire que le chef de projet doit effectuer tout ce travail lui-même. Il peut y avoir toute
une équipe qui participe à l’élaboration de la charte et de l'échéancier du Projet. Cependant, si quelque
chose ne fonctionne pas bien, le chef de projet en est tenu pour responsable.
Une fois le projet a commencé, le chef de projet doit gérer et contrôler le travail de façon efficace; il
doit :
 Gérer l’échéancier global en s’assurant que le travail est assigné et achevé dans les délais et
dans les limites du budget
 Identifier, chercher, gérer et résoudre les problèmes majeurs
58
 Gérer le contenu de manière proactive, en s’assurant que ce qui a été convenu seulement est
livré, à moins que des changements n’aient été approuvés dans le cadre du management de
contenu
 Diffuser de manière proactive les informations relatives au projet à toutes les parties prenantes
 Identifier, gérer et atténuer les risques du projet
 S’assurer que la solution soit de qualité acceptable
 Définir et rassembler les métriques afin d’avoir un aperçu sur l’évolution du projet et de savoir
si les livrables produits sont acceptables ou non
Rappelez-vous que ceci ne signifie pas que le chef de projet réalise physiquement tout ce travail, mais
qu’il s’assure seulement que ce travail est bel et bien fait. Si des problèmes, des changements
incontrôlés de contenu ou des risques surviennent lors du projet, ou si ce dernier ne répond pas
correctement aux attentes, alors le chef de projet sera la personne considérée comme responsable. Par
exemple, s'il y a des changements incontrôlés du contenu dans le projet, le chef de projet ne peut
avancer que c'est la faute du client. Le chef de projet est la personne chargée de gérer le contenu du
projet.
Pour gérer les processus de management de projet, on doit être bien organisé, avoir de grandes
capacités de suivi, être à l’aise avec les processus, être en mesure de réaliser des tâches multiples,
suivre un processus de pensée logique, être capable de déterminer les causes profondes des
problèmes, avoir de bonnes capacités analytiques, être capable de bien estimer et gérer un budget, et
disposer d' une grande autodiscipline.
Responsabilités par rapport au personnel (1.0.2. P4)
En plus de ses capacités en matière de processus, un chef de projet doit également avoir de bonnes
capacités de gestion du personnel. Cependant, le chef de projet n'est pas à 100% responsable du
personnel. Cette responsabilité est partagée avec un responsable fonctionnel. Ceci constitue l'une des
raisons pour laquelle le management de projet est difficile. Le chef de projet doit réaliser des résultats
avec une équipe qui ne dépend pas de lui hiérarchiquement. D’autre part, le fait de gérer du personnel
est certainement un aspect important du management de projet et cela devient encore plus important à
mesure que le projet prend de l'importance et exige plus de personnel. Les responsabilités de
management du personnel exigent :
 De l’autorité et certaines compétences en gestion afin de s’assurer que tout le monde suit les
processus et les procédures standard.
 Faire preuve de leadership pour amener l’équipe à suivre volontairement ses instructions. Ce
leadership concerne la communication d’une vision des choses et le pouvoir d’amener l’équipe à
vous accepter et à vous soutenir.
 Fixer des objectifs raisonnables, motivants et clairs pour les membres de l’équipe et les motiver
en les rendant responsables d' objectifs à atteindre. Ceci implique aussi le fait de savoir donner
une information en retour, claire et acceptable, sur leurs performances, aux membres de
l’équipe.
 Avoir la capacité de constituer des équipes de façon à ce que les gens travaillent ensemble en
harmonie et se sentent motivés pour travailler dur pour le bien du projet et des autres
membres de l’équipe. Plus votre équipe est importante et plus le projet est long, plus il est
important d’avoir ces compétences de bon constructeur d’équipe.
 Avoir des compétences de communication proactive, orale et écrite, ainsi qu’une bonne
capacité d’écoute active.
Le chef de projet est responsable de la réussite du projet. Si l’équipe a le moral bas et ne parvient pas
à respecter les délais, vous devez essayer de résoudre ces problèmes. Si les membres de l’équipe ne
comprennent pas exactement en quoi consistent leurs tâches respectives et n’arrivent pas à mener le
projet à terme tout en respectant les exigences, c’est alors vous qui êtes responsable. Il s'agit de la
59
gestion à l’aide de processus (gérer l'échéancier).
Rôles multiples (1.0.2. P5)
Selon la taille et la complexité du projet, le chef de projet peut assumer d’autres responsabilités en plus
de la gestion du travail. Il peut par exemple participer à la collecte des exigences commerciales, à la
conception d'un composant matériel, ou encore à rédiger une partie de la documentation du projet. Le
management de projet est un rôle particulier qu’une personne remplit, même si cette personne, qui est
le chef de projet, travaille sur d'autres rôles aussi.
Par exemple, un chef de projet peut gérer le projet pendant 45% de son temps, en exécuter l’analyse
pendant une autre tranche de 25%, travailler sur la conception durant 15% et écrire la documentation
pendant les 15% qui restent de son temps. Ceci ne signifie pas que l’une des fonctions d’un chef de
projet soit de passer 15% de son temps à exécuter le travail de conception. Cela signifie simplement
que le projet n’est pas assez grand pour nécessiter d’avoir un chef de projet à temps plein. Le chef de
projet passe le reste de son temps à remplir d’autres fonctions, comme celles d’analyste d'affaires, de
designer ou de rédacteur de documentation technique.
Selon la taille de vos projets et la manière dont votre entreprise est organisée, le temps d’un chef de
projet peut être réparti des trois manières différentes:
 Il peut être chef de projet à temps plein sur un grand projet.
 Il peut remplir des fonctions de management de projet dans différents projets, chacun d’eux ne
nécessitant pas un travail à temps plein, mais l’ensemble représentant un temps complet.
 Il peut remplir différentes fonctions, dans le même projet, chacune d’entre elles exigeant un
certain niveau de compétences et de responsabilités. Sur un projet spécifique, par exemple, il
peut être à la fois chef de projet et analyste. (le cercle jaune ci-dessus)
Responsabilités dans une organisation matricielle (1.0.2. P6)
La structure organisationnelle actuelle la plus courante est une certaine forme de structure matricielle
(voir 1.2.4 Définir le travail / Organisation du projet). L’organisation matricielle permet à une entreprise
une utilisation optimale des ressources humaines. Cependant, un des défis que représente
l’organisation matricielle est que les membres de l’équipe sont affectés (à plein temps ou à temps
partiel) au niveau de leur travail sur le projet, mais ils rendent des comptes à quelqu'un d'autre au
niveau de la gestion du personnel. Cela peut être à l’origine de difficultés quand il s’agit d’obtenir de ce
personnel qu’il fasse ce qui est nécessaire pour mener à bien le projet. Il est tout à fait compréhensible
que les membres de l’équipe accomplissent ce qui leur est demandé de la part de leur supérieur
hiérarchique, plutôt que de répondre aux besoins de leur chef de projet. Dans ce type de structure, il y
a toujours un certain nombre d’initiatives que vous pouvez entreprendre de manière proactive:
 Bien que les membres de l’équipe n’aient pas à rendre des comptes au chef de projet du point
de vue de l’organisation fonctionnelle de l’entreprise, leur travail sur le projet devra toujours
être pris en compte dans l’évaluation globale de leurs performances. Ainsi, vous pouvez essayer
de responsabiliser chacun en lui assurant que ses performances au sein du projet se reflèteront
dans l’évaluation de son rendement. Ceci devrait également être convenu et réitéré par les
60
supérieurs hiérarchiques. Si les gens ne respectent pas les délais qui leur sont fixés, il y aurait
peut-être lieu de combiner votre rétroaction et celle de leur responsable fonctionnel.
 Certaines techniques et certains processus de management de projet spécifiques doivent être

mis en œuvre. Tout d’abord, si la disponibilité et les performances de l’équipe sont incertaines,
vous devrez très tôt signaler ce problème comme étant un facteur de risque pour le projet.
Dans le cadre du processus de gestion des risques, vous devez établir un plan proactif pour
vous assurer que ce risque soit traité.
 Quand les gens ne parviennent pas à respecter les principaux délais qui leur sont accordés,
vous pourriez être amené à déclarer la survenance d’un problème majeur et à appliquer la
procédure de gestion des risques. Pendant la gestion des risques majeurs, vous devez identifier
les causes du problème. Par exemple, le dépassement des dates limites importantes peut être
dû à un manque de temps, du fait que votre équipe est poussée à effectuer un autre travail en
dehors du projet, par exemple une application de maintenance. Dans ce cas, cela doit être
corrigé d’une manière ou d’une autre. Il est aussi possible que les délais fixés ne puissent être
respectés parce que les estimations initiales étaient trop basses. Dans ce cas, cela doit être
corrigé d'une autre manière. Des problèmes de performance peuvent être à l'origine de certains
dépassements de délais. Cela aussi doit être corrigé avec l'aide des supérieurs hiérarchiques.
 Assurez-vous que les membres de votre équipe communiquent avec vous de manière proactive.
Dans de nombreux cas, ce n’est pas le fait que les gens dépassent les délais fixés qui frustre le
chef de projet. C’est plutôt le fait qu’il n’ait pas été averti. Par exemple, si un membre de
l’équipe doit remettre un livrable à la fin de la semaine, mais qu’il a passé trois jours à résoudre
un problème de production, il doit vous le faire savoir afin que vous puissiez prendre les
mesures appropriées pour y remédier. Si un membre de l’équipe dépasse les délais qui lui ont
été impartis sans vous en préciser la raison ou vous en avertir à temps, cela veut dire qu’il ne
gère pas les attentes comme il devrait le faire. De même, le chef de projet doit communiquer
de façon proactive pour s'assurer que l’équipe est bien au courant des délais fixés et de ses
attentes. Le chef de projet doit également communiquer de manière proactive avec ses
responsables fonctionnels et s’assurer qu’ils sont informés des problèmes de partage des
ressources ou des problèmes de performance du personnel.
La gestion matricielle implique un équilibre complexe et délicat entre chefs de projet et supérieurs
hiérarchiques du personnel. Pendant que vous vous battez pour réaliser vos objectifs avec des
personnes qui, éventuellement, ne travaillent pas pour vous à plein temps, vous pouvez également, au
sein de votre entreprise, avoir à remplir des responsabilités hiérarchiques extérieures au projet. Le chef
de projet a toujours, dans de telles situations, une autorité limitée pour gérer le personnel. Mais il est
encore possible de réaliser vos projets avec efficacité. De nombreux processus et techniques de
management de projet peuvent vous y aider. Vous devez également vous assurer que vous tirez parti
du commanditaire du projet. Après tout, c’est son projet. Le commanditaire peut vous aider à faire
naître un sentiment d'urgence et à susciter l'intérêt; il peut aussi influencer les supérieurs hiérarchiques,
au besoin, pour que le personnel nécessaire soit mis à la disposition de la réussite du projet.
Avoir la responsabilité du projet, mais pas l’autorité (1.0.2. P7)
Dans certaines organisations, le chef de projet a l’obligation de la réussite du projet, sans toutefois
avoir le niveau de responsabilité correspondant. La gestion de l’équipe, dans une organisation de type
matriciel, en est un bon exemple. On vous demande généralement de gérer un projet en utilisant des
personnes alors que vous n'exercez pas de responsabilité de gestion directe sur elles. Vous pouvez
également constater que votre capacité à résoudre les problèmes majeurs est entravée parce que vous
n’êtes pas situé à un niveau suffisamment supérieur au sein de l’organisation et que vous devez
souvent compter sur l'aide de supérieurs hiérarchiques plus haut placés. Dans d’autres circonstances,
vous pouvez constater que votre capacité à être innovant et flexible est bridée par l’inertie et la
politique organisationnelle de l’entreprise.
Toutes ces situations peuvent être des causes de frustration. L’une des manières d’y faire face est de
définir les fonctions et les responsabilités dans la charte du projet. Cela peut être utile pour déterminer
les attentes et les gérer. Par exemple, si vous n’avez aucun pouvoir de décision sur le budget ou les
dépenses, signalez-le suffisamment à l’avance, parallèlement à la mise en place d'un processus
61
d'approbation des dépenses. Ainsi, si des problèmes surviennent ultérieurement, chacun saura qui
possède le niveau d'autorité approprié pour les résoudre. La frustration de la plupart des chefs de
projet ne provient pas tant du fait de ne pas détenir l’autorité que de l’ambiguïté qui entoure cette
autorité. Si le chef de projet ne dispose d’aucune autorité, il est important qu’il sache qui la détient, et
quel processus il est nécessaire de suivre pour que l'action soit engagée.
Déterminer combien de projets peut gérer un seul chef de projet (1.0.2. P8)
Vous entendez parler de chefs de projet qui gèrent plusieurs projets, grands et petits. La question qui
se pose dès lors consiste à savoir comment plusieurs projets peuvent être gérés en même temps d’une
manière efficace.
Ce qui pourrait être surprenant est le fait que la réponse consiste en une simple opération de calcul.
D’abord, nous devons établir l'hypothèse que le management de projet occupe pratiquement 15% des
heures d'effort du projet. En d’autres termes, si un projet est estimé à 1.000 heures d’effort, vous
devriez affecter 150 heures pour le management de projet. Certaines sociétés affectent 10% des
heures au management de projet, tandis que d’autres affectent jusqu’à 20%, mais 15% est une
approximation raisonnable.
Dès que nous disposons de cette hypothèse fondamentale, vous pouvez examiner la taille des projets
que vous devez gérer. Vous appliquez le pourcentage de votre management de projet et après vous
devriez être capable de déterminer le nombre de projets qu’un seul chef de projet peut gérer.
La meilleure manière d’envisager cela est d’examiner quelques exemples.
 Project A, 12.000 heures d’effort, dont la durée est d’une année
L’effort de management de projet est estimé à 1.800 heures (12.000 * 0,15). Une personne occupée à
temps plein travaille environ 1.800 heures par an (50 semaines de travail par an à raison de 40 heures
de travail par semaine = 2.000 heures de travail moins 10% pour aléas, soit 1.800 heures de travail par
an, avec l’hypothèse d’une productivité très élevée). Puisque le projet va durer une année, on a besoin
d’un chef de projet à temps complet. Le chef de projet ne pourrait probablement pas gérer d’autres
projets puisque celui-là va absorber tout son temps.
 Project B, 6.000 heures, dont la durée est d’une année
Dans ce cas, vous auriez besoin de 900 heures d’effort pour le management de projet (6.000 * 0,15).
Puisque le projet s’étend sur une durée d’une année, il prendra moins de 20 heures par semaine pour
l’effort accordé au management de projet. Ainsi, est-il possible pour un chef de projet de gérer deux
projets de cette taille durant une période d’un an.
 Projet C, 1.000 heures, trois mois de durée, 150 heures de management de projet
 Projet D, 2.000 heures, huit mois de durée, 300 heures de management de projet
 Projet E, 500 heures, deux mois de durée, 75 heures de management de projet
Dans ce cas le projet C nécessite 12 heures par semaine et les projets D et E nécessitent chacun
environ 9 heures par semaine pour les activités de management de projet. Un chef de projet pourrait
gérer les trois projets du moment que l’effort total du management de projet est de 30 heures par
semaine.
 Project F, 20.000 heures, une année
Dans ce cas, le projet a besoin de 3.000 heures d’effort pour les activités de management de projet
(20.000 * 0,15). Ceci représente beaucoup plus d’heures que ce qu'un chef de projet pourrait gérer
pendant toute une année, car il ne travaille que +/- 1.800 heures par an. Ceci pourrait représenter une
raison suffisante pour avoir recours à un administrateur de projet ou des chefs d’équipe pour prendre
en charge certains aspects du management de projet. Par exemple, un administrateur de projet
pourrait aider à mettre à jour l’échéancier, à consolider les rapports d’avancement, organiser les
réunions, et exécuter d’autres taches administratives afin d’aider le chef de projet.
Certainement, l’effort réel nécessaire pour le management de projet ne se traduit pas uniquement par
62
une stricte moyenne d'heures par semaine. Certains projets nécessiteront plus ou moins d’effort de
gestion et certaines semaines seront plus aisées et d’autres plus stressantes. Cependant, ceci est le
modèle global que vous pourrez utiliser pour déterminer si un chef de projet est chargé de trop, de peu
ou de juste de ce qu'il faut de projets à gérer.
63
1.0.3 Dimensionner votre projet (petit, moyen, grand)
La méthodologie TenStep de management de projet™ est à échelle variable et elle est basée sur la
taille du projet. Tous les processus de TenStep fournissent des conseils suivant que le projet soit petit,
moyen ou grand. Chaque entreprise qui utilise la méthodologie TenStep doit déterminer les critères
spécifiques qu’elle emploiera pour classer ses projets. TenStep se sert de trois critères de base pour
déterminer la taille globale d’un projet.
1. Le premier et le plus important est l'effort estimé du projet. Les lignes directrices utilisées par la
méthodologie TenStep sont les suivantes:
Taille Nombre d'heures d'effort
Petit 1-250 heures
Moyen 251 – 2.500 heures
Grand plus de 2.500 heures
2. Dans votre entreprise, les critères pour classer les projets par catégorie peuvent être différents.
Cependant, en général, plus le projet est grand, plus vous souhaiterez une structuration et un
formalisme bien établis dans le processus de gestion de ce projet.
3. e deuxième facteur est le niveau d’expérience du chef de projet. Si le chef de projet est bien
expérimenté, vous pouvez lui permettre de gérer de grands projets avec moins de rigueur, ou
au moins jusqu'à un seuil d'effort plus élevé. D’un autre côté, vous pouvez demander à un chef
de projet inexpérimenté de gérer un projet de 1000 heures comme s'il s’agissait d’un grand
projet, puisqu’il pourrait avoir besoin de structures plus importantes.
4. Le troisième facteur réside dans la complexité du projet. Par exemple, vous pouvez souhaiter
gérer un projet de 1.000 heures comme s'il s’agissait d’un grand projet, si ce dernier est
extrêmement sensible. Ou bien vous pouvez désirer gérer un projet de 500 heures à la manière
d’un petit projet parce que vous avez déjà géré deux projets semblables auparavant, et qu’il
représente donc pour vous un faible risque.
64
1.1 Définir le travail / Processus
Tous les projets devraient, au préalable, consacrer du temps à l'étape de définition. Peu d’informations
sont nécessaires pour définir un petit projet, ce qui rend, en règle générale, ce travail assez court.
Cependant, plus le projet est grand, plus il est important de comprendre parfaitement ce qui est
demandé; il devient aussi plus difficile d’obtenir un accord sur ce qui doit être livré. Il est par
conséquent indispensable de consacrer davantage de temps à définir le travail. Les pages web
suivantes décrivent des processus qui permettent définir le travail en fonction de la taille du projet.
1.1.1 Les petits projets - Le processus des demandes de service
1.1.2 Les projets de taille moyenne
1.1.3 Les grands projets
65
1.1.1 Définir le travail / Petits projets
Vue d’ensemble sur les petits projets (1.1.1. P1)
La définition des petits projets recouvre de nombreuses catégories d’efforts de travail. Dans la plupart
des entreprises, ces petits projets ne sont même pas du tout considérés comme ‘‘des projets’’. Votre
entreprise peut appeler ces petits projets «améliorations» ou «demandes discrétionnaires». Dans la
méthodologie TenStep de management de projet, ces types de petits efforts de travail sont considérés
comme des projets à part entière, car ils répondent à tous les critères de définition d’un projet. Le
travail est unique, il a un début et une fin; il a pour objectif la réalisation (ou l'amélioration) d’un
produit livrable, etc. Il s’agit simplement d’un petit travail, et, par conséquent, le projet aussi est petit.
Dans de nombreuses organisations, ce genre de petits travaux sont exécutés par le service de soutien
ou des opérations. En plus, beaucoup de ces petits travaux sont considérés comme faisant partie du
soutien car ils ont pour origine un problème d'amélioration d’un procédé de production. Parfois, la
demande concerne une modification qui a pour but d'améliorer le fonctionnement.
Il est parfois difficile de décider si un petit travail doit être géré en tant que demande de maintenance
ou en tant que petit projet. La distinction opérée par TenStep tient compte du caractère discrétionnaire
dans le choix du moment où le travail est réalisé. Si un problème surgit et qu’il nécessite d’être résolu
rapidement, le travail est sans aucun doute à traiter en tant que maintenance. Si, au contraire, ce
problème est prioritaire mais qu'on peut le résoudre ultérieurement, alors on le considère comme un
petit projet.
En général, les petits projets peuvent comprendre:
 Les travaux uniques qui sont, à n’en pas douter, des projets mais qui ont une courte durée et
qui ne nécessitent qu’un nombre restreint d’heures de travail.
 Les améliorations apportées aux procédés et systèmes de production existants.
 La correction des bugs et des erreurs touchant aux procédés de production, qui sont des fléaux
mais qui peuvent être résolus ultérieurement. Dans ces cas, la résolution du problème est
moins prioritaire que d’autres opérations de travail.
 De petites améliorations apportées aux processus.
 Les enquêtes pour découvrir des travaux qui peuvent amener d’autres demandes de service ou
un projet.
 Les petits changements dans les procédés de production qui découlent d’exigences légales,
fiscales ou comptables. Ces demandes ne peuvent être considérées comme des
perfectionnements puisqu’elles ne produisent aucune valeur marchande complémentaire.
Cependant, elles répondent à la définition d'un projet.
Si un travail est classé « petit projet discrétionnaire », cela ne diminue en rien l’urgence ou l’importance
de la demande. Cela signifie seulement que la date de son achèvement n’est pas fixée. Par exemple, si
une demande est assez importante, elle peut être placée en tête de la liste des travaux et traitée
immédiatement. Cependant, il se peut qu’une demande plus urgente survienne par la suite nécessitant
de faire passer la précédente à un rang inférieur dans la file d’attente. La nature du travail
discrétionnaire appelle des décisions concernant l'établissement des priorités. C’est le contraire du
véritable travail de maintenance. Si un processus de production est suspendu, ou si les résultats
produits sont mauvais, cela signifie en général que le problème doit être résolu immédiatement et qu’il
ne peut être remis à plus tard en raison d’une demande discrétionnaire.
En général, tout petit travail discrétionnaire peut être documenté, faire l’objet d’une évaluation et être
classé par ordre de priorité dans les processus de demandes de service.
Le processus des demandes de service (1.1.1. P2)
66
La définition formelle d’un petit projet ne demande en général qu’un travail minime. Cependant, un
certain travail de définition doit, malgré tout, être effectué. Le résultat de cette définition courte est un
document d’une ou deux pages, appelé Demande de Service.
Un document très court de définition (Demande de service) du projet est accompagné d’un processus
d'assignation des tâches, qui en est différent et qui est, lui aussi, propre aux petits projets. Quand la
définition d’un grand projet est terminée, le projet est, généralement, prêt à commencer. En revanche,
pour les petits projets, il peut y avoir de nombreuses demandes de service qui peuvent réellement être
effectuées à tout moment. Il convient donc d’établir une méthode pour rassembler les demandes de
service et les assigner aux membres de l’équipe, en se fondant sur les priorités des clients. comme il
peut y avoir de nombreuses demandes de service, il est important d’avoir un moyen d'en assurer le
suivi, et de s’assurer que les demandes les plus prioritaires sont traitées.
Le processus de gestion des demandes de service suivant peut être utilisé. de nombreuses
organisations, ce genre de petits travaux sont exécutés par le service de soutien ou des opérations. En
plus, beaucoup de ces petits travaux sont considérés comme faisant partie du soutien car ils ont pour
origine un problème d'amélioration d’un procédé de production. Parfois, la demande concerne une
modification qui a pour but d'améliorer le fonctionnement.
Rôle Processus de demande de service dans le cadre d’un petit projet
1 Le client Soumettre la demande de service

Le client, au besoin avec l’aide du chef de projet, remplit un simple
formulaire de demande de service où il consigne le travail demandé. Même
pour un petit travail, la demande de service sert de document formel qui décrit
le travail à faire et comporte les autorisations nécessaires du client. Une
demande de service comporte en général un descriptif du travail demandé, son
niveau de priorité et sa valeur marchande.
Modèle: Demande de Service
2 Le chef de Examiner et clarifier la demande.

projet
Le chef de projet (cela peut être un responsable de maintenance ou de
répartition de travail) examine la demande passée afin d’être sûr de
comprendre le travail. Il pose des questions au client, si besoin, pour clarifier ce
qui est demandé. Le chef de projet doit également estimer l’importance de la
demande et vérifier si des travaux préliminaires doivent être terminés avant de
réaliser le travail.
3 Le chef de Une estimation approximative est préparée.

projet
Si le chef de projet comprend suffisamment bien le travail et s'il a le niveau
d'expertise approprié, il fournit une estimation approximative du volume d'effort
et de la durée du travail que le projet représente et fera figurer ces
informations sur la demande de service. Il est possible qu’une fois que le client
a pris connaissance de l'effort de travail prévu, il change d’avis concernant la
priorité du projet. Par exemple, si l'effort de travail estimé est supérieur à ce à
quoi il s’attendait, il peut lui accorder une priorité plus faible. Si, au contraire, il
est en dessous ce à quoi il s’attendait, il est possible qu’il lui attribue une
priorité plus forte, de façon à ce que le travail soit terminé plus tôt.
Si le chef de projet ne peut pas estimer le travail que va représenter le projet, il
doit désigner un membre de l’équipe pour effectuer cette estimation. Si
personne dans l’équipe n’a le temps ou les qualifications pour faire une
estimation générale, l’estimation elle-même doit alors être placée sur la liste
des travaux en attente. Le client doit décider si le travail exigé pour rassembler
les informations nécessaires à l’estimation est assez prioritaire pour qu’un
membre de l’équipe s’y consacre plutôt que de s’occuper d’une autre demande
de service. Cette estimation générale doit être effectuée uniquement dans le
67
but de définir des priorités. Une estimation plus détaillée peut être, au besoin,
effectuée au moment où le travail est réellement assigné.
4 Le chef de La demande est assignée ou mise en attente.

projet
Le chef de projet et le client évaluent l’importance de la demande en fonction
des autres travaux assignés ou qui sont en attente. Ils passent également en
revue les compétences et les qualifications dont ils disposent au sein de
l’équipe, pour décider si le travail peut ou non être entamé immédiatement . Si
les ressources en personnel qualifié ne sont pas disponibles ou que le travail
demandé est moins prioritaire que d’autres demandes de service, la nouvelle
demande est placée sur une liste de travaux en attente sur laquelle figure tout
le travail qui a été demandé, dont on a fait une estimation, auquel on a accordé
un ordre de priorité , mais qui ne peut pas encore commencer.
5 Le chef de Passer périodiquement en revue le travail en attente.

projet, le client
Le chef de projet et le client passent régulièrement en revue la liste des travaux
en attente, en général une fois par semaine, une fois toutes les deux semaines
ou une fois par mois. Lors de cet examen, les demandes inscrites sur la liste
devraient être reclassées sur l’échelle des priorités en prenant en compte de
nouvelles demandes de service, des demandes de service complétées et les
réalités courantes. Quand une demande est considérée comme très prioritaire
et que le personnel nécessaire pour la réaliser est disponible, le travail peut
commencer. Si une demande de service figurant sur la liste d'attente est plus
critique que le travail en cours, le travail précédemment assigné est arrêté,
remis sur la liste d’attente ou poursuivi juste le temps de démarrer le travail de
la nouvelle demande.
6 Les membres (Lorsqu'elle est assignée) Valider les informations initiales sur la
de l’équipe demande de service.
Lorsque le travail est attribué à un membre de l'équipe, la(es) personne(s)
responsable de l’exécution du travail devrait vérifier si les informations figurant
dans la demande de service sont encore valables et si les estimations sont
précises. Si elles ne le sont pas, de nouvelles informations devront être
documentées et discutées immédiatement, pour voir si cela peut avoir un
impact sur l'ordre de priorité . Par exemple, le client peut vouloir réaliser un
petit projet de 40 heures. Si une estimation détaillée montre que le travail
nécessite 80 heures, le client ne voudra peut-être pas exécuter le travail à ce
moment-là. Il se peut qu’il y ait d’autres demandes qui soient plus critiques et
qui demandent moins de temps.
7 Tous Le petit projet est prêt pour être exécuté.
68
1.1.2 Définir le travail / Projets de taille moyenne
Vue d’ensemble sur les projets de taille moyenne (1.1.2. P1)
Alors qu’il peut y avoir des divergences sur le degré de rigueur que nécessitent les petits projets, cette
controverse ne devrait pas avoir lieu pour un travail d’envergure moyenne, le travail étant sans aucun
doute à définir et à gérer comme un projet. Mais vous voulez encore rester fidèle au principe de base
qu’est le processus graduel. Néanmoins, même si le travail est, à n’en pas douter, bel et bien un projet,
le processus de définition n’est, cette fois-ci, pas aussi vaste que pour de grands projets.
Le projet doit être défini clairement, mais le résultat ne pas être aussi long ou aussi détaillé que Charte
du projet formelle correspondant aux grands projets. Pour un projet de taille moyenne, on utilise, à la
place, une charte abrégée de projet. Il est généralement facile de trouver les informations
nécessaire pour définir un projet de taille moyenne.
Rôle Définir un projet de taille moyenne
1 Le chef de projet Recueillir les informations de base.

Recherchez toutes les informations déjà disponibles pour ce projet. Il peut
s’agir des livrables d’un projet précédent, de notes, d’e-mails, etc. Dans la
plupart des cas, avant que le projet ne commence, le client doit procéder à
une première analyse globale du rapport coûts / bénéfices, ou proposition
de valeur, bien que celle-ci ne soit pas obligatoire pour des projets de taille
moyenne. Toutes ces informations devront être réunies pour servir de point
de départ à la compréhension du travail à venir.
2 Le chef de projet Déterminer le processus d’approbation.

Travaillez avec votre supérieur direct et le commanditaire du projet sur le
procédé d’approbation que vous allez adopter pour la Définition courte du
projet. Par exemple, déterminez si le commanditaire veut approuver la
définition avant les autres parties prenantes, ou s’il préfère se réserver
l’approbation finale, après que les autres parties prenantes aient pris
connaissance de l'information. Vous devriez également déterminer qui doit
réellement approuver le document et qui doit juste en recevoir une copie
finale. C’est important pour des projets moyens, parce qu’ils sont souvent
trop petits pour que le commanditaire leur accorde une grande attention.
Par conséquent, le processus d’approbation des livrables peut être différent
de celui auquel vous vous attendez pour un plus grand projet.
3 Le chef de projet, Rencontrer les principales parties prenantes pour définir le travail.
les principales
Rencontrez les parties prenantes concernées (managers, clients, membres
parties prenantes
de l'équipe, parties intéressées) et essayez de comprendre leur perception
du travail demandé. Avant de rencontrer les diverses parties prenantes,
assurez-vous que les informations de base nécessaires à la définition d’un
projet de cette taille vous sont familières. Si vous ne savez pas exactement
quelles informations doivent être collectées, vous ne serez pas préparé pour
poser les bonnes questions. vous pouvez consulter le modèle de livrable de
la charte abrégée de projet pour savoir ce qui est demandé. Ces
informations incluent:
 Une vue d’ensemble du projet. Exposez l’objet du projet et les
raisons pour lesquelles il va être réalisé.
 Contenu. Dans le chapitre ‘‘contenu’’, il y a deux parties : les
livrables et les limites fixées. Pour chaque livrable, une description
détaillée doit être fournie. Reportez-vous au paragraphe 5.0.1
69
Définir le contenu pour de plus amples détails. Le contenu du projet
peut être déterminé de différentes manières mais dans les projets
moyens, cette définition doit se concentrer sur les livrables.
 Estimation des heures d'effort. Faites une estimation du nombre
d’heures de travail que va demander le projet, et fournissez des
informations sur la façon dont l’estimation a été préparée. Pour de
plus amples informations, reportez-vous à 2.1A.1 Élaborer
l'échéancier/ L'estimation.
 Estimation de la durée. Une fois que l'effort en heures de travail
est connu, vous pouvez estimer combien de temps il faudra pour
réaliser le projet (la durée). Si la date de début est connue, la date
de la fin peut aussi être déterminée. Pour de plus amples
informations, reportez-vous à 2.1A.1 Élaborer l'échéancier/
L'estimation.
 Estimation du coût. Procédez à une estimation du coût du travail,
en vous basant sur le nombre d’heures d'effort prévues. Ajoutez-y
toutes les dépenses de non- travail, telles que celles relatives au
matériel, aux logiciels, à la formation, aux voyages, etc. Pour de
plus amples informations, reportez-vous à 2.1A.1 Élaborer
l'échéancier / L'estimation.
 Les hypothèses principales. Les hypothèses sont des énoncés
que vous croyez être vrais mais dont vous n'êtes pas certains à
100%. Les hypothèses peuvent être des événements ou des
conditions extérieures qui doivent se réaliser pour que le projet
réussisse. S’il est plus que probable que ces événements se
produisent, ils doivent être classés en tant qu’hypothèses (la
définition des hypothèses est exposée avec plus de précision dans la
section 7.0 Gérer les risques). Les hypothèses peuvent être
identifiées grâce à l’expérience, qui permet de connaître les types
de conditions ou d’événements susceptibles de se produire au cours
de la vie du projet; elles peuvent l’être aussi grâce à des séances de
brainstorming (brassage d'idées) avec les clients, les parties
prenantes et les membres de l’équipe, de même qu’en examinant
les événements qui ont été signalés comme présentant un faible
risque dans le processus de gestion des risques. Pour de plus
amples informations concernant les hypothèses, reportez-vous au
paragraphe 7.1.2.2 Hypothèses et risques.
 Les principaux risques. Les risques peuvent être les conditions ou
événements futurs et externes qui seraient problématiques pour le
projet si jamais ils se produisaient. S’il y a une forte probabilité que
l’un de ces événements se produise, il devra alors être signalé en
tant que risque (les risques sont définis avec plus de précision dans
la section 7.0 Gérer les Risques). Pour de plus amples informations
sur les risques, voyez le paragraphe 7.1 Gérer les risques /
Processus.
Modèle : Charte abrégée de projet
4 Le chef de projet Créer la première ébauche de la charte abrégée de projet.

Commencez par faire une ébauche de l’échéancier et du budget du projet,
sur la base du maximum d’informations disponibles à ce moment-là. Les
informations issues de l'échéancier du projet sont intégrées dans la charte
abrégée de projet, et celles provenant de cette dernière sont utilisées,
simultanément, pour aider à élaborer l'échéancier et le budget du projet.
Voyez le paragraphe 2.0 Élaborer l'échéancier et le budget du projet pour de
plus amples informations sur l'élaboration de l'échéancier et du budget.
70
Assurez-vous que le contenu que vous rédigez profite bien au lecteur, et
non à vous-même: les informations données devront être assez claires pour
que le lecteur puisse le comprendre.
5 Le chef de projet (Facultatif) Faire circuler la première ébauche de la charte abrégée

de projet.
Faites circuler la charte abrégée du projet et les procédures de management
du projet sous forme d’ébauche, afin de recueillir des retours d’information
et d’atteindre le consensus. Les premières ébauches peuvent être
distribuées à un petit groupe de parties concernées. L'échéancier du projet
n’a normalement pas besoin d’être distribué à moins qu’il n’y ait une
demande spécifique pour qu’en en prenne connaissance. Cette étape est
facultative, puisqu’un projet de taille moyenne n’est généralement pas très
grand ni très complexe. Il est possible que l’ébauche initiale de la charte
abrégée du projet soit envoyée directement au commanditaire pour
approbation.
6 Le chef de projet (Facultatif) Mettre à jour les documents sur la base du feedback
accumulé.
Mettez les documents à jour sur la base des retours d’informations que vous
recevez suite à la diffusion de l'ébauche initiale. Cependant, les informations
en retour ne sont pas toutes pertinentes. Il revient donc au chef de ce
projet et au commanditaire de déterminer quelles informations en retour
sont appropriées pour mieux éclairer le document et le compléter.
7 Le chef de projet Faire approuver la charte abrégée de projet.

Il s’agit du même processus d’approbation que celui défini lors du processus
2 ci-dessus. Référez-vous au paragraphe 1.2 Définir le travail / Techniques,
pour de plus amples informations sur la façon de diffuser le document et les
différentes options pour signifier une approbation.
8 Le chef de projet Faire circuler la charte abrégée de projet approuvée à toutes les
parties prenantes concernées.
Une fois le processus d’approbation terminé, diffusez les copies de la charte
abrégée de projet approuvée et le Plan de management de projet à toutes
les parties prenantes concernées, y compris les membres de l’équipe du
projet.
9 Le chef de projet Créer le Plan de Management du projet.

Il est important de documenter très tôt les procédures et de vous procurer
les informations auprès de vos directeurs, de vos clients, des membres de
l’équipe et autres parties prenantes intéressées. Par exemple, il est plus
facile de répondre à une demande de changement de contenu en suivant
une procédure approuvée que d’inventer la procédure et de traiter le
changement de contenu en même temps. Ces procédures n’ont pas besoin
d’être élaborées, étant donné la taille du projet que vous êtes en train de
définir. Si vous disposez du plan de management de projet d’un projet
similaire, ou si votre société possède un ensemble commun de procédures
définies auparavant, il vaut mieux les utiliser.
71
10 Tous Le projet de taille moyenne est prêt pour être exécuté.
72
1.1.3 Définir le travail / Les grands projets
Vue d’ensemble sur les grands projets (1.1.3. P1)
Les grands projets nécessitent vraiment beaucoup de temps préalable pour définir le travail. Si vous ne
définissez pas un petit projet ou un projet moyen de manière adéquate, les conséquences ne seront
probablement pas dramatiques. Même si votre projet est initialement estimé à 500 heures de travail et
qu’il demande finalement deux fois plus de temps, cela ne sera sans doute pas catastrophique pour
votre entreprise. Vous ne pouvez pas vous payer le même luxe avec les grands projets. Si par exemple
vous estimez le travail à 10.000 heures à partir d’un processus de définition inadéquat, et que le projet
réel nécessite finalement 20.000 heures, cela peut avoir un impact matériel sur votre organisation et
sur l’ensemble de votre entreprise.
En général, plus un projet est grand, plus il faut du temps pour définir le travail. Vous devez aussi vous
assurer que vous disposez d’assez d’informations pour être sûr de savoir ce que vous êtes en train de
faire. Vous devez également réunir suffisamment d’informations précises et documentées pour être en
mesure d’obtenir l’accord de votre commanditaire sur les objectifs du projet, les livrables, l’estimation
des coûts et de la durée, le contenu, etc.
Le processus de définition d’un grand projet est similaire à celui d’un projet moyen. La différence est
qu’il y a plus d’informations indispensables à réunir, et que la durée du processus de définition est
nécessairement plus longue et plus complexe.
En plus d'une Charte de projet, les grands projets ont aussi besoin d'un Plan de Management de Projet
plus formel. Ce plan contient lui même d’autres plans encore plus détaillés que vous allez utiliser pour
gérer le projet, y compris le Plan de management des Communications, le Plan de management des
Risques, le Plan de Management du Contenu, etc. Ces plans individuels sont appelés "Plans
Subsidiaires".
Ces plans subsidiaires ne sont pas nécessaires pour les petits projets et ceux de taille moyenne puisque
les processus de management de ces projets sont plus simples. Par exemple, pensons au management
des risques. Un projet de taille moyenne pourrait probablement utiliser un modèle normalisé de
management des risques qui contient des informations sur des risques génériques et sur la manière
selon laquelle on peut les gérer. Pour un grand projet, il faut tenir compte de plus de considérations sur
la manière de gérer les risques. Le Plan de Management des Risques pour un grand projet pourrait
utiliser comme point de départ le même modèle de management des risques qu'un projet de taille
moyenne. Mais, pour le grand projet vous devriez également considérer d'autres éléments
supplémentaires pour une gestion plus approfondie des risques tels que les outils de management des
risques, la mise en œuvre du rôle de manager des risques, prévoir des audits externes autour du
management des risques, etc. Le besoin d'effectuer une gestion plus approfondie et complexe des
risques d'un grand projet et la raison pour laquelle il faudrait élaborer un vrai Plan de Management des
Risques pour ce type de projet.
Quand il s'agit de bien définir un grand projet, il faut élaborer surtout deux documents: la charte du
projet et le plan de management du projet. Ces deux importantes livrables de gestion sont décrites ci-
dessous.
Cette section focalise sur le processus utilisé pour définir le travail dans un grand projet. Le principal
livrable qui en résulte est une charte du projet :
Rôle Définir un grand projet
1 Le chef de Recueillir les informations de base.

projet Recherchez toutes les informations qui peuvent être déjà disponibles pour ce
projet. Il peut s’agir des livrables d’un projet précédent, de notes, d’e-mails,
etc. Dans la plupart des cas, avant même que le projet ne commence, le client
doit procéder à une première analyse de haut niveau du rapport coûts /
73
bénéfices ou de la proposition de la valeur. Toutes ces informations devront
être rassemblées afin de servir de point de départ pour comprendre le travail à
réaliser.
2 Le chef de Déterminer le processus d’approbation.

projet, le Travaillez avec votre supérieur et avec le commanditaire du projet pour
commanditaire comprendre le procédé d’approbation de la charte du projet. Par exemple,
vérifiez si le commanditaire veut approuver la charte avant les autres parties
prenantes, ou s’il préfère se réserver l’approbation finale, après que toutes les
parties prenantes aient examiné le travail. Vous devriez également décider qui
doit réellement approuver le document et qui doit seulement en recevoir une
copie finale.
Recueillir les exigences (1.1.3. P2)
3 Le chef de Réunir les exigences.

projet Le chef de projet doit disposer d'une certaine compréhension des exigences
importantes du projet et ce avant même de commencer la définition du travail.
Cela inclue les exigences du projet et celles des produits. Réunir les exigences du
projet inclue la compréhension des besoins du client et de ses attentes
concernant les livrables, le contenu, les délais, etc. Il peut aussi être important de
bien comprendre les exigences du produit pour bien tenir compte des estimations
relatives aux coûts et à l'échéancier et pour comprendre les types de ressources
du projet exigées. Cependant, vous ne disposez pas de suffisamment de temps
pour couvrir les exigences détaillées du produit à cette étape la. Ces dernières
seront ultérieurement définies comme étant une partie du cycle de vie du projet
une fois que l'exécution du projet est approuvée. Voir 5.0.3 Plan de management
des exigences pour plus de détails sur la manière selon laquelle planifier le
processus de la réunion des exigences. Voir 5.0.4 Réunir les exigences pour plus
de détails. Une fois que vous finissez avec les exigences, il est important d'établir
un système de suivi des exigences à travers le cycle de vie du projet. Ce
processus de suivi assure que chaque exigence est prise en compte dans les
solutions finales (autrement dit aucune des exigences ne doit être négligée) et
qu'aucun composant relatif à la conception, construction ou mise à l'épreuve ne
soit établi avant qu'il ne soit assujetti à une exigence originale. Voir 5.0.5 Assurer
la traçabilité pour plus d'informations.
Définir le contenu (1.1.3. P3)
4 Le chef de Rencontrer les principales parties prenantes pour définir le projet.

projet, les Rencontrez les parties prenantes appropriées (managers, clients, membres de
principales l’équipe, parties intéressées) et essayez de comprendre leur perception du travail
parties demandé. Avant de rencontrer les diverses parties prenantes, assurez-vous que
prenantes vous maîtrisez les informations de base nécessaires à la définition d’un projet de
cette taille. Si vous ne savez pas exactement quelles informations rassembler,
vous ne serez pas en mesure de poser les bonnes questions. Quand il s'agit d'un
grand projet vous devez faire en sorte que vous compreniez les objectifs du
projet, le contenu (livrables et limites), les hypothèses, les risques, les
contraintes, les dépendances, l'approche, l'organisation et le coût et la durée
estimés. Pour plus d'informations sur ces concepts voir 1.1.3.1 Rédiger la charte
du projet.
Élaborer la charte du projet (1.1.3. P4)
74
5 Le chef de Créer la première ébauche de la charte du projet.
projet Assurez-vous que le contenu de ce que vous rédigez profite plus au lecteur qu’à
vous. Les informations données devront être accessibles au lecteur. L’ordre de
réalisation de la charte du projet, de l’échéancier et du budget est décrit au point
intitulé "La répartition dans le temps des activités relatives à l'élaboration de la
charte du projet, de l'échéancier et du budget" (1.2. P1).
Pour plus d'informations sur la charte du projet voir 1.1.3.1 Rédiger la charte du
projet.
6 Le chef de Faire circuler la première ébauche de la charte du projet.

projet Faites circuler la charte du projet sous forme d’ébauche, afin de réunir des
retours d’information et d’atteindre le consensus. Les premières ébauches
devraient être distribuées à de petits groupes de personnes concernées.
L'échéancier du projet n’a normalement pas besoin d’être distribué, à moins qu’il
n’y ait des demandes spécifiques pour l'examiner.
7 Le chef de Mettre à jour la charte du projet sur la base du feedback accumulé.

projet Mettez à jour la charte du projet en utilisant tous les retours d’informations
provoqués par la mise en circulation de l’ébauche initiale. Les informations en
retour ne sont pas toutes pertinentes. Il revient donc au chef ce projet et au
commanditaire de déterminer quelles informations en retour sont les plus
appropriées et susceptibles de mieux éclairer mieux le document et le compléter.
8 Le chef de cultatif) Diffuser les documents révisés auprès d’un groupe plus large
projet ties prenantes pour recueillir un second flux de feedback.
Mettez à nouveau les documents à jour sur la base de ce nouveau feedback.
Approuvé la charte du projet (1.1.3. P5)
9 Le chef de re approuver la charte du projet.

projet sez le même processus d’approbation décrit ci-dessus à l’étape 2. Voir la section
nir le travail / Techniques pour savoir comment faire circuler les documents et que
t les options pour signifier l’approbation.
10 Le chef de Diffuser la charte du projet approuvée à toutes les parties concernées.

projet Lorsque le processus d’approbation est terminé, il faut transmettre des copies de
la charte du projet approuvée à toutes les parties prenantes concernées, y
compris les membres de l’équipe du projet.
Élaborer le plan de management de projet (1.1.3. P6)
11 Le chef de Développer le Plan de Management du Projet

projet Il est important d'élaborer le Plan de Management du Projet tôt dans le cycle de
vie du projet et d'obtenir l'accord de la Direction, des membres de l'équipe, des
clients et les autres parties prenantes importantes. Par exemple, il est plus facile
de résoudre une demande de modification du contenu en suivant une procédure
approuvée au préalable que devoir inventer la procédure et résoudre la
modification du contenu en même temps.
Le plus grand votre projet est, le plus votre plan de management du projet doit
être formel et sur les rails. Si vous disposez de procédures de gestion prédéfinies
75
provenant d'un projet similaire ou si votre organisation possède un ensemble de
procédures communes déjà définies pour de grands projets, utilisez-les comme
point de départ.
Le plan de management du projet contient la charte du projet ainsi que les plans
subsidiaires nécessaires à la gestion du projet. Bien que ces documents puissent
certainement être énumérés individuellement, le plan de management du projet
peut être utilisé pour les rassembler.
Le plan de management du projet peut comprendre les livrables suivants:
 Charte du Projet (voir 1.1.3 Définir le travail / Processus - grands

projets)
 Échéancier du Projet (voir 2.0 Établir l'échéancier et le budget) Vous

pouvez aussi ajouter au plan de management du projet la structure de
découpage du travail ainsi que l'ensemble des jalons de l'échéancier. Ces
derniers éléments ne sont que des sous-produits de l'élaboration de
l'échéancier.
 Plan de management de l'échéancier (voir 2.1A.7 Créer le plan de

management de l'échéancier)
 Plan de management des coûts (voir 2.1B.3 Créer le plan de

management des Coûts)
 Plan de management des exigences (voir 5.0.3 Créer le plan de

management des exigences)
 Plan management du contenu (voir 5.0.2 Créer le plan de

management du contenu)
 Plan de management des communications (voir 6.1.3 Gérer la

communication / Grands projets)
 Plan de management des risques (voir 7.1.2.1 Créer le plan de

gestion des risques)
 Plan de management des ressources humaines (voir 8.1.1.1 Créer

le plan de gestion des ressources humaines)
 Plan de management de la qualité (voir 9.1.2.1 Créer le plan de

management de la qualité)
 Plan de management des approvisionnements (voir 10.1.1 Créer le

plan de management des approvisionnements)
 D'autres plans et processus sont exigés pour assurer la planification, la

surveillance et le contrôle d'un projet.
Le Plan de Management du Projet peut être un document effectif, un bloc-notes

ou un dossier. Par exemple, vous pouvez utiliser un classeur à 3 anneaux pour
maintenir tous ces documents et le bloc-notes sera appelé Plan de Management
76
de Projet. Vous pouvez aussi créer un dossier sur votre serveur que vous appeler
Plan de Management de Projet et y placer des copies électroniques de tous les
livrables.
77
1.1.3.1 Rédiger la charte du projet
La charte du projet contient toutes les informations que vous pouvez rencontrer à travers le processus
de définition du projet. La charte du projet est rédigée par le chef de projet et approuvée par le
commanditaire du projet et ce pour démontrer qu’il y a un accord sur le travail à exécuter.
La charte du Projet comprend typiquement les informations suivantes:
 Résumé général (facultatif). Le document entier de la charte du projet pourrait avoir

tendance à devenir vague et difficile à comprendre pour les seniors managers. Vous pourriez
alors inclure un résumé général à l’intention des managers. Le résumé général est un aperçu
sur le document de la charte du projet. Il ne s’agit pas seulement d’un aperçu sur le projet.
 Aperçu sur le projet. Énoncer le but du projet. Discuter les bénéfices commerciaux du projet
et partager l’ensemble des buts de l'entreprise auxquels contribue ce projet.
 Les objectifs du projet. Énoncer les objectifs que le projet est tenu de réaliser. L’objectif du
projet devrait défendre les objectifs de l'organisation de votre entreprise et ses stratégies. Les
livrables produits devraient soutenir les objectifs du projet. Pour plus d’informations sur les buts
et objectifs, voir 1.2.1 Buts stratégies et objectifs.
 Contenu du projet. La section relative au contenu contient deux parties – les livrables et le
périmètre du projet. Il fournit une description de haut niveau pour chaque livrable. Le fait de
comprendre les livrables du projet va de pair avec la description du contenu du projet. Il est
très important de clarifier ce que le projet pourrait réaliser et ce qu’il ne pourrait pas. Ceci
facilitera la gestion des modifications du contenu tout au long du projet.
En plus des livrables, vous devriez aussi énoncer le périmètre du projet. Cette délimitation
représente une manière pour déterminer les aspects appartenant au contenu du projet et ceux
qui n'appartiennent pas à celui-ci. Le fait d’éclaircir ce qui fait partie du contenu et ce qui ne le
fait pas est tout à fait une bonne pratique. Vous devriez par la suite décrire le contenu en
utilisant des termes plus spécifiques tels que:
o données dont le projet a besoin et celles qui ne font pas partie du contenu
o Les organisations affectées à ce projet et celles qui ne le sont pas
o Les processus commerciaux appartenant au contenu et ceux qui n’en font pas partie
o Les transactions commerciales appartenant au contenu et celles qui ne lui

appartiennent pas
o Tout autre indicateur appartenant ou n'appartenant pas au contenu et qui pourrait être
utile
Voir le chapitre 5.0.1 Définir le contenu pour plus de détails.
 Le nombre d’heures d’effort. Il s’agit d’estimer l’effort requis et d’expliquer comment ces
estimations ont été réalisées. Vous pourriez avoir besoin de travailler sur l'échéancier en même
temps que sur la charte du projet dans le but de fournir une estimation précise (± 15%). Pour
plus de renseignements, voir 2.1A.1 Estimer l’effort et la durée.
 La durée estimée. Du moment que les heures d’effort sont déterminées, vous pourrez
estimer la durée que prendra le projet pour être mené à son terme en se basant,
approximativement, sur le nombre des ressources à utiliser. Si la date du début est connue, la
date estimée de la fin pourrait également être déterminée. Vous pourriez avoir besoin de
travailler sur l'échéancier en même temps que la charte du projet et ce dans le but de fournir
une estimation précise (± 15%). Pour plus d'informations, voir 2.1A.1 Estimer l’effort et la
durée.
78
 Les coûts estimés. L’estimation du coût du travail se base sur les heures d’effort fourni,
auxquelles on ajoute les dépenses qui ne relèvent pas de la main d'œuvre comme celles
relevant des équipements, des logiciels, de la formation, des déplacements, etc. Vous pourriez
avoir besoin de travailler sur l'échéancier en même temps que la charte du projet et ce dans le
but de fournir une estimation précise (± 15%). Pour plus d'informations, voir 2.1B.1 Estimer le
coût.
 Les hypothèses majeures. Les hypothèses sont des énoncés que vous croyez vrais mais
dont vous n’êtes pas sûr à 100%. Il se peut qu’il y ait des conditions et des événements futurs
qui devraient avoir lieu afin de s’assurer du succès du projet. S'il y a une grande probabilité
d’occurrence de ces événements alors ces derniers pourraient être classés comme des
hypothèses. (La définition des hypothèses est citée avec plus de précision dans la section 7.0
Gérer les risques.) Les hypothèses peuvent être identifiées à travers votre propre expérience
avec les activités ou les conditions qui pourraient avoir lieu ou exister dans votre organisation;
remue-méninges les sessions avec les clients, les parties prenantes et les membres de l'équipe;
et en observant les articles qui ont été identifiés en tant que risques faibles à travers le
processus de management des risques. Pour plus d’informations sur les hypothèses, voir
7.1.2.2 Risques et hypothèses.
 Les risques majeurs. Il est possible que des conditions ou des événements futurs qui, en se
produisant pourraient causer des problèmes. Si cela devait se produire ces événements alors
pourraient être identifiés comme des risques. (La définition du risque est citée avec plus de
précision dans la section 7.0 Gérer les risques.) Pour plus d'informations sur les risques, voir
7.1 Gérer les risques / Processus.
 Les contraintes du projet. Les contraintes sont des événements ou des limitations situés en
dehors du contrôle de l’équipe du projet et qui doivent être gérés à part. Ce ne sont pas
nécessairement des problèmes. Ce ne sont pas des risques non plus puisque la probabilité de
leur occurrence est de 100%. Ce sont des faits. Les contraintes relatives aux dates, par
exemple, impliquent que certains événements (peut être la fin du projet) doivent avoir lieu à
des dates bien déterminées. (Considérer les risques ayant une haute probabilité d’occurrence
comme étant des contraintes constitue une technique efficace. Par exemple, si vous estimez la
probabilité d’occurrence d'un risque survenant à plus de 90%, il serait préférable de gérer cet
événement comme une contrainte plutôt que de tenter de le gérer comme un risque.)
 Les dépendances du projet. Énumérez les autres projets en attente qui dépendent de votre
projet. Ces dépendances sont basées sur les livrables. C'est-à-dire, soit qu'un projet vous
donnera un livrable ou que vous donnerez un livrable à l'autre projet. Un projet n'est pas censé
être dépendant simplement parce qu'une même ressource est partagée.
 Approche du projet. Elle décrit en quelques mots les informations présentées dans
l'échéancier du projet à un niveau supérieur. Ces informations sont bénéfiques pour les clients
et les parties prenantes qui ne sauront pas interpréter facilement l'échéancier actuel. Vous
devez décrire les phases majeures et les jalons de l'échéancier, et l'enchainement général du
travail. Vous devriez aussi communiquer quand les livrables les plus importants seront produits.
Prenez aussi un peu de temps pour expliquer les techniques intéressantes qui vont être
utilisées dans le projet - par Développement rapide d'applications (RAD), sessions de travail
participatives pour le développement d'applications (JAD), etc. Il se peut que cette section soit
plus longue, mais ne dépassant pas deux pages, car cela dépend de la taille de votre projet.
Voir 1.2.5 Approche du projet pour plus d'idées sur l'approche du projet.
 Organisation du projet. L’organigramme d’un grand projet reflète souvent l’implication de

plusieurs parties prenantes. Par exemple, le projet pourrait avoir un chef de projet formel
appartenant à l'organisation du client qui rend des comptes au commanditaire du projet. Il se
peut qu'y ait un commanditaire, cadre de haut niveau, ainsi qu'un commanditaire qui lui est
subordonné pour le représenter au quotidien. Les parties prenantes les plus importantes
pourraient être organisées dans un comité de direction et ce pour fournir une direction
stratégique du projet. Les vendeurs ou les fournisseurs pourraient avoir juste un rôle formel et
avoir besoin d’être représentés au sein de la structure organisationnelle (les trois manières
importantes selon lesquelles les équipes du projet sont organisées sont décrits dans 1.2.4
79
Définir le travail / Organisation du projet). Plusieurs rôles spécifiques du projet sont décrits
dans 1.2.2 Rôles et responsabilités.
Les grands projets pourraient également bénéficier de la définition de la manière avec laquelle les
livrables sont créés et approuvés. Ceci est décrit avec plus de détails dans 1.2.3 Matrice de
responsabilité.
80
1.2 Définir le travail / Techniques
La répartition dans le temps des activités relatives à l'élaboration de la charte du projet, de

l’échéancier et du budget (1.2. P1)
La répartition dans le temps des activités relatives à l'élaboration de la charte du projet, de l’échéancier
et du budget peut varier selon la taille du projet et la quantité d’informations connues lors du processus
de définition.
 Les petits projets. La demande de service comprend les coûts estimatifs ainsi que la durée.
Le projet étant petit, toutes les informations peuvent être collectées simultanément.
 Les projets de taille moyenne. la charte du projet abrégée comprend le coût estimatif et la
durée. Le projet n’étant pas très compliqué, il est possible que toutes les informations soient
collectées simultanément.
 Les grands projets. Les activités relatives à l'élaboration de la charte du projet, de

l’échéancier et du budget peuvent être accomplies de deux manières possibles selon votre
structure et selon que vous voulez d’abord faire approuver une charte préliminaire avant qu’une
planification plus détaillée ne soit entreprise.
o Charte du projet d’abord, puis planification détaillée ensuite. Avec cette

approche, la charte du projet est réalisée dans un premier temps. Les renseignements
relatifs au contenu, aux risques, aux hypothèses, à l’approche et la majorité des autres
sections de la charte du projet peuvent être saisis. Toutefois, l’échéancier du projet est
élaboré au niveau des jalons, et le coût est estimé à un niveau global. La charte du
projet est ensuite approuvée. Après l’approbation, le travail commence au niveau de
l’élaboration de l’échéancier et du budget détaillés, et les informations détaillées sont
utilisées pour réviser la charte du projet en cas de besoin. Si la durée ou le coût
estimatif a changé par rapport à la charte du projet globale, la charte du projet plus
détaillée sera ré-approuvée.
L’avantage de cette approche est que le commanditaire a la possibilité d’approuver le

projet d’abord à un niveau global, avant qu’une planification détaillée ne commence.
Ceci peut être une meilleure approche s’il y a beaucoup d’inconnus sur le projet, et le
commanditaire veut d’abord avoir certaines informations globales avant de s’engager
pour le coût d’une planification détaillée.
Selon la vison de TenStep, cette approche signifie que vous effectuerez le processus 1
(Définir le travail) avant d'effectuer le processus 2 (Élaborer l'échéancier et le budget),
avec l’approbation de la charte du projet globale à la fin du processus 1 et
l’approbation de la charte du projet détaillée après le processus 2.
o Charte du projet, échéancier et budget réalisés simultanément. Si vous n'avez

pas besoin d'obtenir l'approbation d'une charte de projet globale avant de réaliser une
planification détaillée, vous pouvez travailler simultanément sur la charte du projet,
l’échéancier et le budget. Vous remarquerez qu’à mesure que vous collectez les
informations sur le contenu et les livrables, vous pouvez déjà commencer à esquisser
un échéancier global. À mesure que vous avez des informations sur le travail à réaliser,
vous pouvez ajouter plus de détails à l’échéancier. Lorsque la définition des livrables,
du contenu, des hypothèses et la détermination de l’approche sont élaborés, vous
devez avoir assez d’informations pour élaborer un échéancier initial. Vous pourrez
ensuite utiliser l’échéancier initial pour estimer le budget, l’effort et la durée
nécessaires; ces renseignements sont ensuite utilisés pour terminer la charte du projet.
Selon la vision de TenStep, ceci signifie que vous travaillerez simultanément sur les
processus 1 (Définir le travail) et 2 (Élaborer l'échéancier et le budget), et tous les
livrables majeurs de la définition et de la planification seront achevés au même
81
moment. L’avantage de cette approche est que la définition et la planification sont
effectuées plus rapidement étant donné qu’elles peuvent être faites en une fois, et
vous n’avez pas besoin de deux processus d’approbation.
La répartition dans le temps des activités relatives à la réalisation des processus 1 et 2 dépend des
préférences de votre organisation et du commanditaire.
Diviser les grands projets en de plus petits projets (1.2. P2)
Le temps des méga projets est révolu. Ils sont tout simplement trop difficiles à gérer et à réaliser avec
succès. Les grands projets sont porteurs d’un certain nombre de problèmes:
 Plus le travail est éloigné dans le temps, moins il est clair. Les grands projets sont en règle
générale des projets longs, ce qui rend difficile une planification réussie.
 Comme le travail futur est moins clair, il est difficile d’estimer l'effort de travail, la durée et les
coûts avec précision.
 Les conditions commerciales et techniques peuvent changer du tout au tout entre-temps,

rendant les diverses hypothèses émises au cours de la planification très incertaines. Les
certitudes techniques et commerciales d'aujourd'hui peuvent changer dramatiquement avec le
temps.
 Vous risquez de perdre le soutien de votre organisation, si vous mettez trop de temps à lui
présenter des résultats tangibles. Il est en effet difficile d’entretenir l’enthousiasme et le soutien
au sein de votre organisation sur de longues périodes.
 Il est difficile de prévoir les besoins en ressources humaines et la disponibilité de ces ressources
loin dans le futur. Bien entendu, plus vous vous projetez loin dans le temps, moins vos
estimations seront précises.
Un effort de travail très grand sera très difficile et très compliqué à gérer comme un seul projet. La
meilleure solution est de le diviser en éléments plus faciles à gérer, dont chacun est considéré comme
un projet à part, avec sa propre charte de projet et son propre échéancier.
Par exemple, vous pouvez diviser un long projet de développement techno informatique en plusieurs
projets distincts, en vous basant sur les phases du cycle de vie. Un projet sera mis en place pour le
travail d’analyse. A la fin de ce projet, un deuxième projet, basé sur ce que vous avez appris
alors, sera consacré au travail de conception. Suivra encore un projet de production et de test, puis
finalement un projet dédié à la mise en œuvre. D'autres grands projets peuvent aussi être décomposés
en de petits projets qui sont réalisés en parallèle. Certaines autres grandes initiatives peuvent se
présenter sous la forme de combinaison de petits projets - certains réalisés en séquences successives,
d’autres en parallèle. Chaque équipe travaillera à la réalisation de son propre petit projet, mais tout le
travail sera coordonné de telle sorte que l’ensemble soit une réussite.
Établir un programme pour coordonner un ensemble de projets liés entre eux (1.2. P3)
Si vous décomposez un effort de grande ampleur en plusieurs sous-projets, il est nécessaire de

maintenir une gestion et une coordination globales. C’est la raison pour laquelle il faut mettre en œuvre
un ‘‘programme’’. Un programme est une structure qui sert de parapluie à la gestion d'une série de
projets reliés les uns aux autres. Chaque projet a un chef de projet à temps plein ou à temps partiel. Le
programme est dirigé par un gestionnaire de programme. Celui-ci ne produit lui-même en aucune façon
des livrables. Les livrables sont les résultats produits par les différentes équipes de projets reliés les uns
aux autres. Le but du programme est de:
 Donner l'orientation, la conduite et la direction globales globale des projets.
 S’assurer que les différents projets liés communiquent efficacement entre eux.
 Servir de plate-forme centrale de contact pour le client et les équipes du projet.
82
 Déterminer comment les projets particuliers doivent être définis afin que l’ensemble du travail
soit une réussite.
Travailler avec votre client quand il n’est pas en mesure de définir le projet de manière
précise (1.2. P4)
Il arrive parfois que le chef de projet place de grands espoirs dans la capacité d’anticipation et de
prévoyance des clients. Dans de nombreux cas, le chef de projet se tournera vers le client afin de
chercher des réponses permettant d'arriver à définir le projet, alors que le client ne dispose pas de
toutes les informations nécessaires. Cela se produit souvent et ne signifie pas que le client ne sait pas
ce qu’il fait. Dans beaucoup de cas, particulièrement pour de grands projets, le client peut se faire une
idée sur ce que seront les résultats finaux, mais ne peut pas encore articuler cette vision autour de
livrables concrets. Il se peut également qu’il n’ait pas en sa possession toutes les réponses demandées
sur le contenu, les risques, l’organisation du projet, etc.
Quand les informations dont il dispose sont incomplètes, le chef de projet va peut-être éprouver le
besoin d’émettre des hypothèses concernant les détails. Ce n’est cependant pas une bonne solution. Au
lieu de cela, si vous êtes confronté à une telle situation, vous pouvez procéder de deux manières
différentes :
 Commencez par exposer tout que vous savez, mais aussi tout ce que vous ne savez pas. Si on
vous demande tout de même de proposer une estimation de l'effort de travail, du coût et de la
durée, vous devriez élaborer une estimation qui comporte une réserve de temps et de budget
suffisante pour compenser l’incertitude qui persiste. Votre évaluation peut prévoir une marge
de 20%, 40% ou même plus.
Si vous n’êtes pas autorisé à répartir le projet en des lots de travaux plus petits, tâchez néanmoins d’en
savoir assez pour pouvoir planifier le travail sur les 90 premiers jours. Dans une telle approche, planifiez
le travail à court terme dans le détail, et le travail à long terme avec moins de précision. Tous les mois,
vous devriez redéfinir et planifier à nouveau le travail restant. Car plus vous découvrirez d’informations,
plus vous pourrez planifier le travail restant de manière plus détaillée. Puisque vous découvrez plus de
détails, vous pouvez affiner vos estimations et travailler avec le commanditaire pour vous assurer que
l’accord sur la poursuite du projet tient toujours.
 Divisez le travail en une série de projets plus réduits (comme il est décrit précédemment).
Même si les résultats finaux ne peuvent pas encore être définis clairement, vous devriez
disposer d’un certain effort de travail bien déterminé qui mènera peu à peu aux informations
requises pour la solution définitive. Vous ne devriez définir un projet que dans la limite de ce
que vous ‘‘voyez’’ aisément à l’instant. Ensuite, définissez et planifiez les projets pour couvrir le
travail restant, au fur et à mesure que de plus amples détails sont connus. Par exemple, vous
pourriez réaliser un projet qui permet de rassembler les exigences commerciales, puis utiliser
les résultats de ce projet pour définir un second projet pour élaborer les livrables définitifs.
S’assurer que chacun comprend les rôles et les responsabilités du projet (1.2. P5)
Pour de petits projets, l’organisation est assez simple. Souvent elle ne consiste qu’en un chef de projet
et un client ou commanditaire. La personne qui gère le projet peut même être la seule personne
travaillant réellement dessus.
Les grands projets, en revanche, finissent par avoir une structure organisationnelle étoffée et formelle.
Elle peut consister en une équipe de plusieurs membres, un commanditaire exécutif, un commanditaire
de projet, un gestionnaire de projet appartenant à l’entreprise du client, un directeur de projet, un
comité de pilotage, des fournisseurs, des clients et d’autres parties concernées. Plus le nombre de
personnes impliquées dans un projet est élevé, plus il est important que chacun comprenne bien son
rôle et ses responsabilités. Par exemple, la dernière chose à souhaiter est que certaines personnes se
mettent à vous imposer des directives comme si elles étaient le commanditaire du projet, alors qu’elles
ne sont en fait que des parties prenantes au niveau de la gestion.
Un des aspects de la définition de projet est la définition de la structure organisationnelle et des rôles et
responsabilités des principaux participants au projet. Habituellement, les rôles et responsabilités
83
particuliers peuvent être définis depuis longtemps au sein de votre organisation ; ils sont ensuite
réutilisés de façon appropriée, de projet en projet. Plusieurs des rôles et des responsabilités habituels
sont décrits au paragraphe 1.2.2 Définir le travail / Rôles et responsabilités.
Soumettre l’approbation du projet aux personnes appropriées (1.2. P6)
Une fois le projet défini, le chef de projet doit obtenir l’approbation officielle du commanditaire et des
parties prenantes appropriées. Il y a de nombreuses manières de l’obtenir. Comme pour la plupart des
activités de la méthodologie TenStep de management de projet, la clé du succès réside, encore une
fois, dans un minimum de planification. Pour de petits projets, une signature du client ou du
commanditaire principal du projet est probablement suffisante pour signifier leur approbation au sujet
du commencement du travail. Cette approbation peut également être obtenue par l’intermédiaire d’un
e-mail de confirmation. Toutefois, elle ne doit pas être verbale.
Pour des projets de grande ampleur, demandez à votre supérieur et au commanditaire du projet de
préciser qui doit fournir une approbation explicite de la charte du projet, qui doit en fournir une
approbation implicite et qui doit seulement en recevoir une copie pour information. En général,
employez l’approche suivante comme point de départ:
 Le Commanditaire du projet et les principales parties prenantes: Demandez-leur une

approbation explicite. Cette approbation peut se présenter sous la forme d’une signature
formelle sur une copie papier de la charte du projet. Elle peut également prendre la forme d’un
simple e-mail exprimant clairement leur approbation. Vous aurez parfois à suivre tout un
processus d’approbation formelle complexe. L’essentiel est que l’approbation soit explicite et
que vous en gardiez une trace. Le commanditaire et les autres parties prenantes principales
doivent avoir déjà vu les ébauches avant que vous ne fassiez circuler la version finale. Cette
approbation finale ne doit être qu’une formalité. Vous ne voudriez pour rien au monde être
dans la position de celui qui demande une approbation définitive alors que le commanditaire a
encore beaucoup de doutes ou se pose encore des questions.
 Les autres parties prenantes au niveau de la gestion. Demandez-leur une approbation

implicite. « Implicite » signifie que vous supposez qu’ils sont d’accord avec la charte du projet à
moins qu’ils ne vous fassent part de leur désaccord d’une autre manière. Vous leur enverrez
une première fois une copie de la charte du projet, dans une version résumée ou in extenso.
Informez-les que vous désirez qu’ils l’examinent et vous donnent leur avis en retour, en
particulier s’ils ont des questions ou des doutes. Donnez-leur une date limite pour répondre et
faites-leur savoir que s'il n'y a pas de réaction de leur part avant cette date, vous supposerez
que leur approbation est acquise. S’ils expriment des préoccupations, adressez ces dernières au
commanditaire du projet afin qu’il y réponde. Il est important que ces personnes aient vu une
ébauche préalable et aient eu la possibilité d’apporter leur contribution. Quand vous envoyez la
charte du projet pour une approbation finale, vous voulez que toutes les préoccupations aient
été déjà exprimées. Vous ne cherchez pas à avoir des problèmes, des soucis ou des
incertitudes alors que vous essayez d’obtenir l’approbation finale du commanditaire.
 Les autres parties concernées. Envoyez-leur une copie de la charte du projet. Informez-les
que vous la leur transmettez à titre d’information seulement. Tenez-vous à leur disposition pour
discuter du contenu de la définition afin qu’ils puissent mieux la comprendre, au besoin, mais
vous ne la leur envoyez pas pour la soumettre à leur approbation. Cela pourrait être la
première fois que ces personnes voient la charte du projet. Cependant, vous n’êtes pas en
mesure d’accepter les demandes de modification du document avant que vous n’ayez eu
probablement l’approbation du commanditaire. S’il y a des préoccupations majeures, la
personne qui les exprime doit les soumettre au commanditaire.
Instaurer la triple contrainte lorsque la charte du projet est approuvée (1.2. P7)
A la fin du processus de définition et de planification (étapes 1 et 2), vous devriez avoir passé un
accord avec votre commanditaire sur le travail à effectuer, le coût (temps) et la durée, nécessaires pour
effectuer le travail. Ces trois éléments constituent la « triple contrainte ». Le caractère principal de cette
triple contrainte est que si l’un des éléments au moins change, les deux autres éléments, doivent
84
également changer. (La triple contrainte est une réalité exprimée de plusieurs manières similaires.
L’élément du coût est aussi appelé effort de travail, ce qui est plus logique si les coûts des travaux sont
tous internes et s’il n’y a pas de coût de non travail. Parfois, le contenu est appelé qualité, et se focalise
alors sur la livraison d’un certain niveau de qualité pour un certain coût et une certaine durée. Ce sens
de la triple contrainte est plus restreint, mais les concepts généraux restent valables).
Pour plus d'informations sur la façon de gérer le projet en utilisant le modèle de la triple contrainte,
voir 3.2A. P13.
Tenter de comprendre les besoins exprimés par vos clients et leurs vrais besoins (1.2. P8)
La charte du projet donne une vue d’ensemble du projet. Elle décrit en particulier les besoins du client,
de même que l’estimation de l’équipe de projet concernant l'effort de travail, la durée et le coût
susceptibles de répondre à ses besoins. Les besoins du client sont alors définis avec plus de détails à
travers la collecte des exigences commerciales.
Il est important que le chef et l’équipe de projet comprennent que les besoins réels du client puissent
être ou ne pas être les mêmes que ceux qui leur ont été communiqués et qui sont à la base de la
charte du projet ainsi que des exigences commerciales. Dans de nombreux cas, le client ne peut pas
estimer ses besoins réels au début du projet. Ces besoins réels peuvent parfois évoluer au cours du
projet. De même, le client peut avoir une vision claire de ses besoins, mais avoir des difficultés à
communiquer cette vision à l’équipe de projet. Dans une certaine mesure, l’objectif de la gestion des
modifications du contenu est de permettre au client de changer les exigences commerciales du projet
lorsque ce dernier est en cours.
L’équipe de projet ne peut rien faire de mieux que documenter les besoins exprimés par le client et les
utiliser comme base pour l’approbation de la Définition de Projet et des exigences commerciales.
Cependant, l’équipe en question devra faire de son mieux pour déceler les besoins réels du client. Cela
implique de recourir à des techniques telles que : poser les bonnes questions, poser des questions
ciblées, faire appel à la contribution des parties prenantes principales, poser des questions
supplémentaires lorsque les spécifications manquent de cohérence, etc. De toute évidence, l’équipe de
projet devra mettre tout en œuvre afin de découvrir les besoins réels du client. Plus les besoins réels
sont proches des besoins exprimés, plus vous aurez de chances de réussir votre projet dès le départ.
Utiliser un « Projet découverte » séparé pour définir le travail pour un grand projet (1.2. P9)
Pour les Grands Projets, le projet de définition du travail a tendance à s’étaler dans le temps et à
s’éparpiller. Définir le travail pour un très Grand Projet prend tellement de temps qu’il devrait être lui-
même structuré comme un projet. C’est l’objectif visé par la définition séparée d’un « Projet Découverte
».
Cette idée est pertinente. Par exemple, si le projet va, au bout du compte, demander 50.000 heures
d’effort, la définition et l’approbation du projet risquent de durer des mois. Dans ces cas-là, un premier
projet distinct est établi pour définir le second projet, lui-même de plus grande taille. Le livrable final
pour un « projet découverte » c’est : la charte du projet, le Plan de Management du Projet et
l’échéancier du projet, dûment achevés, pour le grand projet qui va suivre.
Les projets « découverte », comme tous les projets, peuvent être de toutes les tailles. Vous devez
estimer l’effort et la durée requis par le projet découverte. Sur la base de l’effort requis par ce dernier,
vous pouvez le classer comme petit/ moyen/ grand, en utilisant les mêmes critères décrits
précédemment. Il ne faut pas oublier qu’il s’agit de la taille propre au projet découverte et non de celle
du projet final. Selon la taille du projet découverte, vous aurez à nouveau trois options pour définir le
travail.
Pour un petit projet « découverte », une demande de service peut être formulée, mais ce n’est pas
obligatoire. Pour un tel effort de travail, reprenez simplement la définition du travail suivant le
processus décrit dans 1.1.2 Définir le travail / Projet de taille moyenne. On suppose que si vous avez
besoin d’un projet « découverte », c’est que le projet final sera assez grand pour nécessiter une Charte
complète de projet.
85
Pour un projet « découverte » de taille moyenne, suivez la méthodologie TenStep de management de
projet correspondant aux projets moyens. Le projet découverte lui-même devrait avoir une charte
abrégée et un échéancier de projet, et être géré comme n’importe quel autre projet de taille moyenne,
en ce qui concerne les problèmes, le contenu, les risques, etc. (Il n’est pas nécessaire d’élaborer un
Plan de management de projet pour le Projet découverte lui-même). Les résultats de ce projet «
découverte », lorsqu’il est achevé, sont la charte du projet, le plan de management et l'échéancier
créés pour le grand projet qui va suivre. Le processus d’approbation de ces documents est en général
une partie du projet découverte. A supposer que la charte du projet ait été approuvée, le grand projet
peut alors commencer à tout moment. Cependant, les étapes 1.0 Définir le travail et 2.0 Élaborer
l'échéancier et le budget devront avoir déjà été effectuées (ces documents étaient le but du projet
découverte). Le processus de management de projet pour le grand projet suivant peut commencer
directement à l’étape 3.0 Gérer l'échéancier et le budget.
Si votre projet « découverte » est, en fait, lui-même un grand projet, vous devez suivre les étapes de
définition des grands projets. Prenons un exemple. Votre but est définir un projet très grand, peut-être
même un programme (un ensemble de projets reliés, gérés comme un ensemble). Supposons que le
projet découverte lui-même nécessite 5.000 heures. Si ce dernier est un grand projet, le suivant qui est
en cours de définition sera très, très grand. Le projet découverte doit alors être géré comme un grand
projet. Quand le projet découverte est terminé, le grand projet peut commencer, puisque les livrables
du projet découverte incluaient la charte du projet, l'échéancier et le Plan de management de projet.
Choisissez les types de contrats adéquats à votre projet (1.2. P10)
Il y a plusieurs types de contrats fondamentaux qui incluent les éléments suivants
 Coût Remboursable (CR)
 Prix Fixe (PF)
 Temps et Equipement(T&E)
Plusieurs définitions de contrats et plusieurs techniques seront décrites ultérieurement dans la section
10.2 Gérer les métriques / Techniques.
86
1.2.1 Buts, stratégies et objectifs
(1.2.1. P1)
Les buts commerciaux sont des spécifications générales qui décrivent le contexte global de ce que le
projet tend à réaliser. Les stratégies décrivent comment les buts seront atteints. Les objectifs sont les
spécifications de base qui désignent les produits et livrables spécifiques et tangibles que le projet
réalisera. La définition des buts et des objectifs est plus une science qu’un art, et il est parfois difficile
des définir et des faire concorder. Cependant, à travers la pratique et l’usage de certaines définitions
courantes, on peut les identifier et ainsi faire la différence entre buts et objectifs.
Les buts commerciaux (1.2.1. P2)
TenStep n’utilise pas l’expression « buts du projet ». Les buts se situent au niveau de l’entreprise, alors
que les objectifs se situent au niveau du projet.
Les buts sont les spécifications générales qui décrivent le contexte global de ce que le projet tend à
réaliser pendant les trois ou cinq années suivantes. Par exemple, un but de projet pourrait être : «
améliorer le degré de satisfaction globale des clients appelant la hotline de l'entreprise pour des
demandes de service ».
Puisque le but n’est pas détaillé, il faudra éventuellement réaliser plus d'un projet pour l’atteindre. Dans
l’exemple ci-dessus, il y a un élément technologique qui peut permettre d’accroître la satisfaction du
client. Mais pour atteindre ce but, on pourra tout aussi bien passer par de nouveaux procédés, de
nouvelles sessions de formation, une réorganisation du service de la hotline et une modification du
système de primes de l’entreprise. Pour atteindre un but, il faudra donc parfois réaliser plusieurs projets
sur une longue période.
Le but doit être en rapport étroit avec les intérêts commerciaux de l’entreprise en termes de coûts, de
vitesse et/ou de qualité. Dans l’exemple précédent, on se concentrera ainsi sur la qualité du service de
la hotline. Même si le projet ne contribue pas de manière directe aux affaires de l’entreprise, il le fera
de manière indirecte. Par exemple, un projet d'infrastructure de technologie informatique ayant pour
but de mettre en place de nouveaux serveurs web pourra finalement permettre de répondre plus
rapidement aux clients, de leur proposer de meilleures performances ou tout autre avantage marchand.
Si le projet n’a aucune valeur marchande, il ne devrait pas être lancé.
Si vous pouvez mesurer la réalisation de votre but, vous verrez qu'il se situe probablement à un niveau
plus bas, et dans ce cas, il s’agit plutôt d’un objectif que d’un but.
En revanche, si votre but n’est pas réalisable au travers d’une combinaison de projets, c’est sans doute
qu’il se situe à un niveau plus élevé. Dans l’exemple précédent, un ou plusieurs projets qui mènent à
une amélioration du degré de satisfaction des clients sont envisageables. Se fixer pour but d’obtenir
l’entière satisfaction du client n’est pas réaliste et ne serait pas possible, même en combinant plusieurs
projets. Il s’agit alors de l’expression d’une vision, c’est-à-dire d’une déclaration de principe encore plus
générale, qui indique une direction ou une aspiration, mais qui ne peut être entièrement traduite dans
la réalité.
Il est important de bien comprendre les spécifications des buts commerciaux de l’organisation, bien que
les buts ne fassent pas partie de la charte du projet. Les buts n’ont de valeur que lorsqu’ils sont placés
dans la perspective générale des affaires de l’entreprise. L'objectif d'un projet doit être la contribution à
l'atteinte des stratégies et buts commerciaux. C'est ce qu'on appelle “l'alignement”. Si votre projet ne
s'agligne pas avec des buts et stratégies organisationnels il ne doit pas être lancé. Le chef de projet se
doit de comprendre ces buts commerciaux auxquels le projet essaie de contribuer.
Les stratégies commerciales (1.2.1. P3)
Les buts commerciaux vous indiquent ce qui est important. Les Stratégies vous indiquent comment
vous allez réaliser ces buts. Les stratégies de votre entreprise sont un ensemble de directives de haut
87
niveau qui démontrent la manière avec laquelle l'entreprise va réaliser ses buts et progresser
finalement vers sa vision à long terme.
On peut autoriser les projets qui contribuent directement aux buts commerciaux, ou les projets qui
peuvent contribuer dans une stratégie. Généralement, on ne devrait entreprendre aucun projet (ni un
travail) qui ne s'aligne pas avec votre stratégie.
Les objectifs du projet (1.2.1. P4)
Les objectifs d’un projet sont des spécifications concrètes de ce que le projet tend à réaliser. Un objectif
devrait être inscrit à un niveau plus bas, de façon à ce qu’il puisse être évalué, lors de la conclusion
d’un projet, pour savoir s’il a été réalisé. Les spécifications d'un but doivent rester vagues. Un objectif
bien formulé sera précis, mesurable, atteignable/réalisable, réaliste et limité dans le temps (SMART :
spécifique, mesurable, atteignable, réaliste, temporellement défini).
Un exemple de formulation d’objectif pourrait être: « mettre à jour le système téléphonique de la

hotline pour le 31 décembre afin d’atteindre une attente moyenne du client qui n'excède pas deux
minutes. »
 Remarquez que l’objectif est beaucoup plus concret et précis que le

but.
 L’objectif est mesurable en termes de durée moyenne d’attente du

client, que le nouveau système téléphonique essaie d'atteindre.
 Vous pouvez supposer que l’objectif est réalisable et réaliste.
 L’objectif est limité dans le temps et doit être atteint le 31

décembre.
Les objectifs doivent se rapporter aux livrables du projet. Dans l'exemple précédent, l’objectif est la
mise à niveau du système téléphonique. Si vous ne parvenez pas à déterminer quels livrables doivent
être réalisés pour atteindre l’objectif, c’est peut-être que l’objectif du projet a été fixé avec trop peu de
précision. A l’inverse, si sous un objectif, on trouve le détail des caractéristiques des livrables, c’est qu’il
est décrit avec trop de détail. Lorsque les spécifications décrivent les dispositifs et les fonctions du
projet, alors il s’agit d'exigences et non d’objectifs.
Si le projet fait partie d’un grand programme, les objectifs de tous les sous-projets devront être alignés
sur les objectifs du programme.
Importance des objectifs (1.2.1. P5)
Les objectifs sont importants parce qu’ils sont les témoins du consensus entre le chef de projet et le
commanditaire du projet sur l'objet principal du projet. Les livrables spécifiques d’un projet techno-
informatique peuvent être par exemple plus ou moins compréhensibles pour le commanditaire du
projet. Cependant, les objectifs doivent être rédigés de façon à être compréhensibles pour toutes les
parties prenantes du projet.
Les objectifs ont aussi de la valeur dans le sens ou ils s'alignent aux buts et aux stratégies du projet .
Votre entreprise ne devrait pas autoriser des projets qui ne correspondent pas aux buts et stratégies.
Définissez des objectifs avant le début du projet (1.2.1. P6)
Les objectifs du projet, les buts de l’organisation et les stratégies auxquels ils contribuent, devraient
être définis et approuvés avant que le projet ne commence. Les livrables du projet sont réalisés d’après
les objectifs.
Dans beaucoup de projets, cependant, il est plus facile de voir quels sont les livrables qui doivent être
exécutés plutôt que les objectifs qui pilotent les livrables. Il est important d'avoir à la fois les objectifs et
88
les livrables. Si vous pensez savoir quel livrable doit être réalisé, travaillez avec votre commanditaire
pour savoir pourquoi il doit être exécuté. Les réponses à cette question peuvent vous aider à découvrir
les objectifs du projet. Vous pouvez alors vous assurer que ces objectifs correspondent aux objectifs
commerciaux et aux stratégies. Si vous pensez devoir exécuter certains livrables et que vous n’êtes pas
capable d’établir le lien entre eux et les objectifs commerciaux, vous devez vous poser sérieusement la
question de savoir pourquoi vous êtes en train des exécuter.
Des réunions de médiation entre toutes les parties prenantes principales sont la bonne voie pour fixer
ces objectifs et obtenir en même temps un consensus à leur sujet.
89
1.2.2 Rôles et responsabilités
Des projets de différentes envergures impliquent des manières diverses d’organiser le personnel et des
exigences variées en conséquence. Un petit projet a besoin d'une structure d’organisation assez
réduite. Il suffit d’avoir un commanditaire, un chef de projet et une équipe de projet, peut-être même
un chef de projet et un commanditaire seulement. Cependant, pour les grands projets, le nombre de
personnes impliquées est élevé, et il est important que les gens comprennent ce que l’on attend d’eux
et le rôle qu’ils ont à jouer. Ce chapitre décrit certains des rôles courants (parfois pas si courants) qui
devront, peut-être, être définis pour votre projet.
 Les clients : ce sont les personnes (ou groupes) qui sont les bénéficiaires directs d’un
produit réalisé par le projet. Ce sont les personnes pour qui le projet est entrepris. (Les
bénéficiaires indirects sont probablement les parties prenantes.) Elles peuvent aussi
être désignées par le terme “usagers“, mais le processus TenStep les désigne par le
terme générique “clients“.
 Le manager fonctionnel. Le manager fonctionnel est la personne à laquelle vous

rendez des comptes dans la hiérarchie de votre organisation. En général, c’est la
personne qui procède à l’évaluation de votre performance. Le chef de projet peut
parfois être également un manager fonctionnel, mais ce n’est pas indispensable.
Comme membre d'une équipe, si votre chef de projet n’est pas la même personne que
le manager fonctionnel, c’est que l’organisation utilise probablement la gestion
matricielle.
 Le directeur de programme. Le directeur de programme est la personne détenant

l’autorité de la gestion du programme (un programme est une organisation parapluie
qui donne une orientation générale à un nombre de projets reliés les uns aux autres).
Le directeur du programme dirige la planification globale et le
management du programme. Tous les chefs de projet à
l’intérieur du programme rendent des comptes au directeur de
programme en ce qui concerne l’objet du projet.
 Le directeur de projet. Dans le processus TenStep, ce rôle

est attribué au supérieur hiérarchique du chef de projet. Les
responsabilités liées à cette fonction sont flexibles et doivent
être définies pour votre organisation et votre projet.
Cependant, cette fonction implique, dans la plupart des
organisations, que le chef de projet n’est pas totalement
responsable du projet. D’ordinaire, le manager fonctionnel du chef de projet a
90
également un rôle à jouer. Ce rôle inclut un travail d’aide dans la mise à disposition du
personnel, dans la résolution de problèmes majeurs délicats et de prise en charge des
questions de politiques organisationnelles, etc.
 Le chef de projet.C’est la personne qui détient l’autorité de la gestion d'un projet.

Cela signifie, entre autres, diriger la planification et le développement de tous les
livrables du projet. Le chef de projet a la responsabilité de gérer le budget, l'échéancier
du projet et le plan de son management projet (gestion du contenu, des problèmes,
des risques, etc.). Pour de plus amples détails, voir le paragraphe 1.0.2 Rôle de chef de
projet.
 L’équipe du projet. L’équipe du projet comprend les ressources en personnel

employées à temps plein ou à temps partiel, à qui on a confié le travail sur les livrables
du projet :
o Exécuter les livrables du projet
o Comprendre le travail qui doit être réalisé.
o Planifier en détail les activités qui lui ont été confiées, en cas de besoin.
o Terminer les travaux qui lui ont été confiés, conformément aux attentes
concernant le budget, les délais et la qualité
o Informer le chef de projet des problèmes qui se posent, des modifications du

contenu, des risques et des soucis au niveau de la qualité, qui pourraient surgir
au cours du projet.
o Communiquer de manière proactive sur la situation, et gérer les attentes.
L’équipe du projet peut se composer de personnel interne appartenant à une même organisation
fonctionnelle ou de membres provenant de différentes organisations fonctionnelles. Si l’équipe
comprend des membres provenant de différentes organisations, elle est appelée équipe
interfonctionnelle. Une équipe inter fonctionnelle est en règle générale un signe que votre organisation
utilise la gestion matricielle. Les membres de l’équipe de projet doivent être considérés comme parties
prenantes à part entière.
 Le manager qualité. Dans un grand projet, la gestion de la qualité peut occuper une
grande part du temps de gestion du projet. Dans ce cas, il vaut mieux nommer
quelqu'un comme manager qualité. Sous la direction du chef de projet, cette personne
rédigera le plan de management de la qualité, développera les procédures de contrôle
qualité et d’assurance qualité, vérifiera qu’elles sont bien suivies et conseillera les
membres de l’équipe sur les problèmes majeurs liés à la qualité.
 Le manager des risques. Dans un grand projet, il se peut que le management des
risques du projet occupe une grande place dans le travail du chef de projet. Il peut
alors s'avérer plus avantageux de nommer une personne pour coordonner le processus
de gestion des risques. Le chef de projet conserve la responsabilité globale des risques
du projet, mais le manager des risques contrôlera le processus d’identification, de
classement, de quantification des risques et de surveillance du plan de gestion des
risques, pour s’assurer de sa réussite.
 Le commanditaire (commanditaire exécutif et commanditaire de projet). Le

commanditaire est la personne qui détient les pleins pouvoirs sur le projet. C’est celui
qui fournit les fonds nécessaires au projet, résout les problèmes majeurs et les
modifications du contenu, approuve les principaux livrables et donne l’orientation
générale du projet. Il défend également le projet au sein de l’entreprise. En fonction du
projet et de sa position dans la hiérarchie, le commanditaire exécutif peut déléguer la
gestion tactique quotidienne du projet à un commanditaire de projet. Dans ce cas, le
commanditaire de projet représente le commanditaire exécutif au quotidien et prend la
plupart des décisions exigeant l'approbation du commanditaire. Si la décision est trop
91
importante pour qu’il la prenne seul, le commanditaire de projet la soumettra au
commanditaire exécutif.
De plus, le commanditaire doit :
o définir les objectifs commerciaux du projet ;
o représenter les intérêts du projet à l’échelon hiérarchique immédiatement plus

élevé ;
o déterminer si le projet est un succès. S’il ne l’est pas totalement, le

commanditaire détermine le degré de réussite ;
o obtenir l’accord pour toute dépense de capital ;
o surveiller le développement du projet ;
o surveiller l’environnement commercial pour s’assurer que le projet remplit

toujours les besoins commerciaux
o présider le comité de pilotage du projet, le cas échéant.
Le commanditaire est le propriétaire du projet et de la solution créée. Alors que le chef de projet est
responsable de la réussite du projet, le commanditaire a la responsabilité de procurer des bénéfices
commerciaux à l’organisation.
 Les parties prenantes. Ce sont les personnes ou les groupes spécifiques qui ont soit
une participation financière soit des intérêts dans les résultats du projet. Normalement,
les parties prenantes font partie de l’entreprise et peuvent comprendre les membres de
l'équipe, des clients internes, des gestionnaires, des employés, des administrateurs,
etc. Un projet peut également avoir des parties prenantes externes, y compris des
fournisseurs, des investisseurs, des organismes gouvernementaux.
 Le comité de pilotage. Un comité de pilotage est un groupe de parties prenantes de

haut rang qui remplissent une fonction de conseil et d'orientation stratégique du projet.
Le commanditaire pourrait remplir ce rôle, mais au cas où l’impact du projet serait
trans-fonctionnel, il n’appréciera peut-être pas le fait d’être le seul susceptible de
prendre toutes les décisions. Le commanditaire pourrait alors composer un comité de
pilotage dont les membres sont des représentants provenant des diverses organisations
impliquées dans le projet. Le comité de pilotage ne remplace pas le commanditaire,
mais contribue à diffuser des informations stratégiques concernant le projet et à
gagner la bienveillance d’une grande partie de l’entreprise. Le comité de pilotage se
compose, en règle générale, de collègues de rang équivalent dans la hiérarchie. Le
comité est une combinaison de clients directs et de parties prenantes indirectes.
 Les fournisseurs/vendeurs. Bien que certaines entreprises aient quelquefois des

fournisseurs internes, dans la méthodologie TenStep de management de projet, ce
terme renvoie toujours à des entreprises externes ou « tierces-parties » et à des
personnes particulières qui travaillent pour ces tierces-parties. Il peut s’agir de sous-
traitants qui travaillent sous votre direction ou d’entreprises qui vous livrent du
matériel, des équipements, des logiciels ou des fournitures pour votre projet. Selon leur
rôle, les fournisseurs devront être identifiés dans la liste de fournisseurs de votre
organisation. Par exemple, si vous êtes dans une relation de partenariat avec un
fournisseur pour la production d'un composant très important, vous voudriez
probablement qu'il figure sur la liste des fournisseurs de votre organisation. En
revanche, si un fournisseur vous livre, par exemple, un composant ordinaire de
hardware, vous ne le considérerez probablement pas comme faisant partie de l’équipe.
 Les utilisateurs. Ce sont les personnes qui utiliseront réellement les livrables du
projet. Parfois, elles sont profondément impliquées dans certaines activités, comme par
exemple la définition des spécifications commerciales. Dans d'autres cas, elles ne
seront impliquées que dans le processus de tests. Il peut être opportun d’identifier
92
clairement l’organisme utilisateur ou les utilisateurs particuliers de la solution et de leur
confier un ensemble de responsabilités. Les utilisateurs peuvent être à l'intérieur
comme à l'extérieur de l'organisation cliente. Par exemple, si votre compagnie opte
pour un système de rapport temporel, l’organisation cliente devrait être le service des
ressources humaines. Cependant, les utilisateurs seront des personnes de chaque
organisation qui utilise le système de rapport temporel.
93
1.2.3 Matrice de responsabilités
Dans un grand projet, plusieurs personnes à la fois peuvent jouer un rôle dans la réalisation et
l’approbation des livrables du projet. Dans certains cas, c’est assez simple, par exemple quand une
personne rédige un document et qu’une autre l’approuve. Dans d’autres cas, plusieurs personnes
peuvent participer à la production des livrables et beaucoup d'autres ont besoin d'intervenir à divers
niveaux d’approbation.
Pour les scénarii compliqués impliquant la participation de nombreuses personnes, il peut être utile
d’avoir un livrable de matrice des responsabilités. Cela s'appelle aussi la grille RACI. Elle s’avère utile
pour établir les attentes et s'assurer que les gens savent ce qu’on attend d’eux. Par exemple, vous
voulez savoir si les membres du comité de pilotage doivent ou non approuver le document relatif aux
exigences commerciales. La matrice permet de clarifier le rôle de chacun.
Dans la matrice, les différentes personnes (ou rôles) apparaissent dans les colonnes, et les livrables
dans les lignes. Utilisez les points d’intersection pour déterminer la responsabilité de chacun par rapport
à chaque produit livrable. Un exemple de matrice simple est présenté ci-dessous:
Commanditaire Directeur de Chef de Équipe du Comité de

du projet projet projet projet pilotage
Charte de projet A A R C A
Plan de management
A C R I C
des communications
Exigences
A I R C I
commerciales
Rapports
I I R C I
d'avancement
”R” signifie que la personne (ou rôle) est responsable du livrable. Habituellement, une seule personne
est responsable de la création d'un livrable, bien que plusieurs personnes peuvent fournir des données
d'entrée.
‘‘A” signifie que la personne (ou rôle) approuve le livrable.
”C” signifie que la personne (ou rôle) est consulté à propos du livrable. Cela implique qu'une discussion
a lieu dans les deux sens.
“I” signifie que la personne (ou rôle) est informée du livrable. Il s’agit d’une manière de communication
à sens unique.
D’après le tableau ci-dessus, c'est le chef de projet qui est responsable de la charte du projet. Cette
dernière est approuvée par le commanditaire, le directeur de projet et le comité de pilotage, l’équipe de
projet est consultée.
Le but de la matrice est de gagner en clarté en se mettant d’accord sur qui fait quoi. Ainsi, vous pouvez
définir le contenu des colonnes avec autant de précision que possible. Dans l’exemple ci-dessus,
"l’équipe du projet" peut être divisée en plusieurs colonnes portant des noms de personnes, ou bien la
personne responsable de l’élaboration des exigences commerciales peut apparaître dans une colonne
séparée. Une fois la matrice achevée, elle doit être diffusée pour approbation. Si elle a déjà été établie
au cours du processus 1.0 Définir le travail, elle peut constituer une annexe à la charte du projet. Si elle
a été établie au cours de la phase d’analyse, elle devra être diffusée comme document à part.
La capacité à gagner en clarté est vitale pour l’efficacité de la matrice. Elle doit refléter les attentes et
les responsabilités des gens. Par exemple, si le commanditaire a délégué l’approbation des exigences
commerciales à un subordonné, ce fait doit apparaître dans la matrice pour que tous puissent en
94
prendre connaissance et l’approuver. D’autre part, si le commanditaire est d'accord pour approuver lui-
même les exigences commerciales, c’est son accord à lui qui est requis, et non pas celui d’un
subordonné à qui il aurait délégué la responsabilité.
Voici quelques exemples supplémentaires de codes de responsabilité. Votre projet peut définir des
codes différents pour autant que vous en expliquiez le sens afin que les personnes impliquées sachent
ce que l’on attend d’elles.
 N – être notifié qu’un produit livrable est achevé
 G – gère les livrables (comme un bibliothécaire ou la personne responsable du répertoire de

documents)
95
1.2.4 Organisation du projet
(1.2.4. P1)
La manière dont l’équipe du projet est organisée est directement liée à la manière dont l’organisation
toute entière est structurée. Il y a trois structures d’organisation principales pour gérer le travail et les
personnes.
Organisation fonctionnelle (1.2.4. P2)
Dans une organisation fonctionnelle, l’équipe de projet est formée de personnes d’un même service.
Toutes les ressources en personnel de l’équipe de projet viennent de la même organisation
fonctionnelle. Par exemple, si le projet relève du domaine financier, le personnel du projet dépend de la
division financière. Si vous avez besoin de personnels spécialisés en techno-informatique, en finances et
droit, elles sont toutes disponibles dans la division financière.
Un projet dans une organisation fonctionnelle peut être pourvu en personnel d’une deuxième manière,
celle qui passe par l’exécution de portions d’un projet dans une organisation fonctionnelle à la fois. Par
exemple, disons qu'un grand projet nécessite des ressources, des services, des finances, des achats, de
la TI et de la fabrication. Dans une organisation fonctionnelle, le projet sera partagé entre diverses
unités organisationnelles et chaque unité s’occupera de sa partie du travail, de manière indépendante.
Le service TI s’occupera de sa partie, le service des finances de la sienne. Les services de production et
des achats s'occuperont chacun de sa partie. A la fin, toutes les solutions indépendantes seront
intégrées dans la solution finale.
Le grand avantage des projets basés sur la fonctionnalité est que l’autorité est clairement définie,
puisque les chefs de projet sont généralement aussi les managers fonctionnels. Vous n’avez pas non
plus besoin de négocier avec d’autres organisations pour le personnel, puisque tout le personnel que
demande votre projet vient de la même organisation fonctionnelle. L’autre avantage que présente ce
type d’organisation est que les membres de l’équipe sont habituellement familiers les uns des autres,
puisqu’ils travaillent tous dans le même secteur. Les membres de l’équipe ont également tendance à
apporter des connaissances dans le domaine commercial applicables au projet.
Un inconvénient important de l’organisation fonctionnelle est que votre domaine fonctionnel peut ne
pas disposer de tous les spécialistes nécessaires pour travailler sur un projet. Dans un projet financier
comportant une composante techno informatique, on peut, par exemple, se heurter à des difficultés
pour obtenir des spécialistes en TI tels que les administrateurs de bases de données, car les seules
personnes disponibles travaillent déjà au sein de leur propre service fonctionnel. Un autre inconvénient
96
est que les membres des équipes du projet ont parfois d’autres responsabilités dans l’organisation
fonctionnelle, puisqu’ils n’ont pas toujours à travailler à plein temps sur un projet. Il arrive qu’ils soient
assignés à d’autres projets, mais il est plus courant qu’ils aient des responsabilités de soutien qui
pourraient affecter leur capacité de respecter les délais du projet.
Organisation par projets (1.2.4. P3)
Quand les projets sont assez grands, il est possible de constituer des services fonctionnels
indépendants à partir de l’équipe du projet. C’est particulièrement pratique quand un grand programme
nécessite des centaines de personnes sur une longue période. Les avantages incluent une autorité
clairement établie (puisque le chef de projet est également le manager fonctionnel), et une grande
convergence, puisque chaque membre de l’équipe a pour responsabilité primordiale le projet et lui seul.
L’un des inconvénients est le dédoublement du personnel, puisque des ressources humaines rares
doivent être dédoublées pour différents projets. Par exemple, un grand projet peut avoir son propre
staff chargé des ressources humaines, qui serait redondant par rapport au service central des
ressources humaines. Il peut également y avoir des soucis concernant la façon de redéployer les
personnels quand les projets sont terminés. Dans une organisation fonctionnelle, les gens ont toujours
leur travail dans leur service fonctionnel. Dans une organisation basée sur le projet, il n’est pas aussi
évident de savoir où reclasser les gens à la fin du projet.
Organisation matricielle (1.2.4. P4)
Les organisations matricielles permettent aux services fonctionnels de se concentrer sur leurs
compétences spécifiques dans le domaine des affaires, et aux projets d’être pourvus de spécialistes
provenant de toute l’entreprise. Par exemple, les administrateurs de base de données vont tous
dépendre d’un même service fonctionnel, mais seront affectés en dehors de ce
dernier pour travailler sur divers projets, dans d’autres services. Un juriste peut
dépendre du service juridique, mais être affecté à un projet dans un autre service qui
a besoin d’expertise légale. Il est courant que les gens puissent dépendre
hiérarchiquement d’une personne dans l’organisation fonctionnelle, tout en travaillant
pour un ou deux chefs de projets différents, relevant d’autres services.
L’avantage principal de l’organisation matricielle est la répartition efficace de toutes

les ressources humaines, particulièrement les qualifications rares dans une spécialité,
et qui ne sont pas entièrement utilisées par un seul projet. Par exemple, des
spécialistes en modélisation de données peuvent ne pas être utilisés à plein temps sur
un projet, mais peuvent être occupés à plein temps en travaillant simultanément sur
plusieurs projets en même temps. L’organisation matricielle est également la plus
flexible, car elle prend en compte les changements de besoins et de priorités.
L’inconvénient principal est que les rapports relationnels sont complexes. Certaines personnes peuvent
dépendre d'un manager fonctionnel pour qui elles effectuent une tâche limitée, tout en travaillant
réellement pour un ou plusieurs chefs de projet. Il devient de plus en plus important pour les membres
du personnel de développer de fortes compétences de gestion du temps afin de s’assurer qu’ils
accomplissent le travail attendu par plusieurs managers. Cette organisation exige également une
communication accrue et une bonne coopération entre les nombreux managers et chefs de projet qui
ont sans cesse besoin, au même moment, des mêmes ressources.
97
1.2.5 Approche du projet
L'approche du projet est une section dans la Définition du projet qui décrit en quelques mots la
démarche de la création de l'échéancier du projet. Deux avantages résultent de la création d'une
section sur l'approche. D'abord, ces informations vont permettre au client aux parties prenantes de
comprendre la manière avec la quelle le projet progresse sans avoir besoin d'interpréter le présent
échéancier.
L'autre avantage de l'approche du projet est qu'elle permet au chef de projet et à l'équipe du projet
d'étaler une vision de haut niveau de l'exécution du projet et d'utiliser cette vision pour permettre la
création d'un échéancier d’un niveau moindre. Parfois, l'équipe du projet trouve qu’il est difficile de
créer un échéancier qui permette d'achever le travail. La création, dans un premier temps, d'une
approche de haut niveau facilite la création, ultérieurement, d'un échéancier d’un niveau moindre.
La section peut être préparée de plusieurs manières. Vous devez souvent commencer avec un contenu
général décrivant l'organisation et l'environnement qui aura un impact sur le projet. Ensuite vous
parcourrez le projet chronologiquement, en allant du début jusqu'à sa fin. Vous n'allez certainement pas
décrire les détails au niveau de l'activité. Vous avez besoin de respecter le jalon, l'étape ou le niveau de
la phase.
Il est parfois difficile de commencer avec cette section. Les informations suivantes vous donnent plus
de détails et d'exemples sur les domaines susceptibles d’être décrits. Vous allez constater qu'un grand
nombre de ces informations pourraient être disponibles ailleurs, cependant c'est dans la section relative
à l'approche que vous associez tout dans un contexte permettant le bénéfice du lecteur.
 Cherchez à savoir s'il y a des initiatives plus larges de la société ou des stratégies qui pourraient
avoir un impact sur la structure de ce projet.
 Identifier toute contrainte en termes de budget, d'effort, de durée ou de qualité, et l'impact sur
le projet.
 Décrivez toutes les normes de la société qui pourraient avoir un impact sur l'exécution du
projet.
 Notez les meilleures pratiques industrielles ou celles de la société qui auront un impact sur le
projet.
 Décrivez les autres options de l'ensemble de l'approche et les raisons pour lesquelles vous
choisissez certaines options et pas d'autres. Notez pourquoi vous pensez que cette approche a
de meilleures chances de succès et pourquoi d'autres n’en ont pas.
 Discutez comment les livrables vont être soutenus et maintenus à la fin du projet. Indiquez
aussi si l'approche a été influencée par les implications du soutien et de la maintenance.
 Discutez tout autre projet lié qui est achevé, en cours d'exécution ou qui a été suspendu, ce qui
a pu influencer l'approche de ce projet et les raisons sous-jacentes.
 Cherchez ensemble à savoir comment le projet va progresser du début jusqu'à la fin ainsi que
les interdépendances entre les phases et les étapes de haut niveau.
 Discutez de toutes les techniques qui pourraient avoir un intérêt pour le lecteur. Par exemple, si
les exigences vont être réunies dans une session de Joint Application Design (JAD) de trois
jours, vous pouvez constater cela dans l'approche.
 Voyez s’il existe si une nouvelle technologie ou de nouveaux processus qui sont en train d'être
utilisés ou non et pourquoi.
 Identifiez toute exigence inhabituelle relative au personnel, tels que les consultants ou les
experts externes, et expliquez les raisons pour lesquelles vous en avez besoin.
98
 Décrivez l'utilisation des sous-traitants, des contractants ou des fournisseurs, surtout s'ils sont
entrain d'exécuter un travail important.
 Il s'agit certainement d'idées contenues dans la section de l'approche du projet. Vous n'avez
pas besoin de les commenter toutes et d'ailleurs, plusieurs d'entre elles pourraient ne pas
s'appliquer à votre projet. L'objectif de cette approche est de décrire ces facteurs et leur impact
sur l'échéancier du projet. Cette section est généralement bénéfique pour le lecteur - l'auteur
connaît déjà ces informations. Il y a une tendance pour rédiger cette section brièvement et
rapidement, n'offrant ainsi que peu de valeur au lecteur. Si l'auteur est diligent et s'il fournit un
bon contexte, cette section pourrait alors s'avérer très précieuse pour le lecteur.
99
1.3 Définir le travail / Références rapides
Les livrables (1.3. P1)
Les livrables suivants sont disponibles dans les bibliothèques de modèles TenStep, réalisés pour
soutenir ce processus. (Certains de ces modèles ne peuvent être consultés que par des utilisateurs
ayant une licence.)
 Demande de service
 Charte abrégée de projet
 Charte de projet
 Procédures de gestion de projet
 Check-list de planification des approbations
 Plan de management de projet
 Matrice d'affectation des responsabilités
 Analyse des forces, faiblesses, possibilités, risques
 Répertoire des membres de l’équipe
Activités de l’échéancier (1.3. P2)
Taille Informations nécessaires
Activité Effort Commentaires
Examiner et clarifier la Le chef de projet confirme qu’il comprend le

1-2 heures
demande de service travail.
Préparer une estimation Il est probable que l'estimation d’une petite

générale de l’effort, du 1-4 heures Demande de Service ne durera pas aussi
coût et de la durée longtemps.
Attribuer la demande ou
Si la demande est classée de grande priorité, vous
Petits la transférer dans une
1 heure pouvez l’attribuer à un membre de l’équipe, sinon
projets liste de travaux en
elle demeure dans la liste des travaux en attente.
attente.
Passer périodique- ment

Examinez la liste du travail en attente avec votre
en revue le travail en 1 heure
client.
attente d’exécution
(En cas d’attribution)

Valider l’information
initiale relative à la 1-2 heures
demande de service.

Projets
moyens Recueillir les
1-2 heures
informations de base
100
Nécessité de déterminer qui doit examiner,
Déterminer le processus
1 heure approuver et recevoir la copie de la charte
d’approbation.
abrégée de Projet.
Rencontrer les
principales parties
ouvert Processus itératif pour définir le travail.
prenantes pour définir le
travail.
Créez votre première

ébauche de la charte 2-4 heures
abrégée de projet.
Documenter le plan de Il est à espérer que vous disposez dans votre

management de projet 1-3 heures organisation des procédures standard que vous
pour ce projet. pouvez utiliser pour tous les projets.
(Facultatif) Diffuser
l’ébauche initiale de la
1-2 heures
charte abrégée de
projet
Mettre à jour les

documents sur la base 1-3 heures
du feedback accumulé.
Faire approuver la
charte abrégée de 1-2 heures
projet.
Diffuser la charte
abrégée de projet
approuvée à toutes les 1 heure
parties prenantes
intéressées.
Recueillir les
1-4 heures
informations de base.
Nécessité de déterminer qui doit examiner,

Déterminer le processus
2 heures approuver et recevoir la copie de la charte du
d’approbation.
projet.
Rencontrer les
Processus itératif pour définir le travail. Cette
principales parties
Grands Ouvert activité peut durer des jours ou des semaines,
prenantes pour définir le
projets selon la taille du projet.
travail.
Créez votre première

5-10
ébauche de la charte du
heures
projet.
Documenter le plan de Il est à espérer que vous disposez, dans votre

management de projet 2-3 heures organisation, de procédures standard que vous
pour ce projet. pouvez utiliser pour tous les projets.
(Facultatif) Élaborez une Il est à espérer que vous disposez, dans votre
101
stratégie et un plan de organisation, de procédures standard que vous
gestion des pouvez adapter à vos besoins.
fournisseurs.
(Facultatif) Diffuser
l’ébauche initiale de la 1-2 heures
charte du projet
Mettre à jour les

documents sur la base 1-3 heures
du feedback accumulé.
(Facultatif) Diffuser les

documents mis à jour à
un groupe élargi de
1-3 heures
parties intéressées pour
un second flux de
feedback
Faire approuver la
1-2 heures
charte du projet.
Diffuser la charte du
projet approuvée à
1 heure
toutes les parties
prenantes intéressées.
102
______________________________________________________________________
Processus 2
Élaborer l'échéancier et le
budget du projet
103
2.0 Élaborer l'échéancier et le budget du projet
(2.0. P1)
L'échéancier du projet doit être élaboré

parallèlement à la charte du projet réalisée
au cours du processus 1.0 Définir le travail.
L'échéancier du projet est un outil vital
pour s’assurer que l’équipe de projet sache
ce qu’elle doit accomplir. De nombreuses
personnes ne se sentent pas à l’aise
lorsqu’il s’agit d’élaborer un échéancier du
projet. Cela dépend généralement du fait
que le projet a été mal défini. Il est très
difficile d'élaborer un bon échéancier de
projet si le chef de projet n’est pas certain
des aboutissements du projet.
Le budget représente les sommes d’argent disponibles pour les dépenses encourues dans le cadre du
projet. En fonction de votre organisation et de la manière de tenir votre comptabilité, le budget pourra
couvrir uniquement les coûts externes du projet (fournisseurs, hardware, logiciels, matériel, etc.).
Certaines organisations incluent également le coût du travail interne dans le budget. Ces organisations
disposent en général de certains processus d’imputation des coûts, permettant d’assigner les coûts
internes aux clients de l’organisation ou à leur propre service à la clientèle.
Au cours du processus 1.0 Définir le travail, vous avez obtenu l’accord du commanditaire sur le travail
qui doit être réalisé. À présent, c’est le chef de projet qui détermine comment le travail sera effectué.
Suivant la taille du projet, il est possible d’utiliser un pack de gestion de projet comme MS Project, une
feuille de calcul de tableur, ou tout simplement garder mentalement une trace des activités.
La relation entre l’échéancier et le budget (2.0. P2)
La méthodologie TenStep a toujours jumelé l'échéancier et le budget en un seul processus intégré.

Cependant, bien que liés, ces deux concepts sont différents. L’échéancier du projet indique les activités
nécessaires pour concevoir les livrables du projet. Le budget indique les sommes d'argent nécessaires à
la réalisation du projet ainsi que le calendrier des dépenses.
104
Le processus TenStep considère qu’il s’agit de deux processus fondamentaux essentiels à la réussite du
projet. Dans de nombreuses organisations, ils représentent les deux éléments fondamentaux pour
mesurer la réussite du projet : a-t-on rempli les attentes par rapport à l’échéancier et au budget? Il est
évident que ces deux éléments de la gestion de projet sont généralement liés.
 Si un projet est en retard, il dépasse fréquemment son budget.
 Si un projet dépasse le budget, il a généralement tendance à excéder les délais. (Évidemment,

il y a des exceptions, mais les deux éléments ont généralement une tendance commune.)
 Si vous avez sous-estimé la charge de travail nécessaire, c’est-à-dire l’effort, vous êtes dans
une situation d’avoir sous-estimé autant la durée que les coûts.
 Les heures d’effort véritablement nécessaires auront un impact autant sur l’échéancier que sur
les coûts.
 Ces deux éléments font partie de la triple contrainte globale du projet qui relie les délais, les
coûts et le contenu du projet. Si le contenu du projet est augmenté (ou diminué), les délais
et/ou les coûts seront affectés.
L'expérience révèle qu’un rapport étroit existe entre les délais et les coûts du projet. Si le chef de projet
est tenu responsable de l’échéancier et du budget, il doit tenir compte de ce lien.
Relation entre définir et planifier le travail (2.0. P3)
Il est à noter que « définir le travail » représente le processus 1 de la Méthodologie TenStep, et que
créer l'échéancier et le budget représente le processus 2. Cependant, cela n’implique pas que ces
étapes se déroulent consécutivement. Vous vous rendrez compte que vous ne pouvez pas compléter
votre définition de projet sans d’abord concevoir son échéancier. Dans de nombreux cas, ces deux
livrables doivent être élaborés en parallèle. Au fur et à mesure que vous rassemblerez des
renseignements sur le contenu et les livrables du projet, vous éprouverez le besoin de commencer à
concevoir une courbe chronologique et, sur cette base, vous procéderez à l’estimation de l'effort de
travail et de sa durée. À travers les renseignements utiles recueillis pour la « définition », vous pourrez
compléter plus en détail l'échéancier du projet. Lorsque les livrables, le contenu, les hypothèses et
l’approche seront définis, vous devriez avoir suffisamment de renseignements dans l'échéancier du
projet pour estimer le budget nécessaire, l'effort de travail et la durée – éléments qui seront à leur tour
utilisés pour compléter la charte du projet.
2.1A Élaborer l'échéancier / Processus
2.1B Élaborer le budget / Processus
2.2A Élaborer l'échéancier / Techniques
2.2B Élaborer le budget / Techniques
2.3 Références rapides
105
2.1A Élaborer l'échéancier / Processus
(2.1A. P1)
Il existe un certain nombre de techniques pour élaborer l’échéancier du projet. Peut-être la meilleure
option est d'utiliser, comme point de départ, l’échéancier d'un projet similaire antérieur. Toutefois, en
raison de la nature unique des projets, cela peut s'avérer difficile.
Une alternative est l’utilisation d’un modèle générique d’échéancier pour ce type de projet. Supposons,
par exemple, que le livrable de votre projet soit l’installation d’un logiciel. Bien que ce soit la première
fois que ce logiciel particulier est mis en œuvre dans votre entreprise, vous pourriez être en mesure de
trouver un modèle générique pour ce type de travail.
Si au départ vous ne disposez ni de l’échéancier d’un projet antérieur similaire ni d’un modèle générique
pour ce type de projet, vous pouvez commencer par l’élaboration d’une structure de découpage de
votre projet. L’élaboration d’une SDP est une technique qui permet premièrement d’examiner le projet à
un niveau général et le découper progressivement en composantes de plus en plus petites jusqu’à ce
que la totalité du travail à effectuer soit révélée. Toute l'équipe peut collaborer à cet exercice. Pour la
plupart, la technique d’élaboration d’une structure de découpage du projet (SDP) peut toujours être
utilisée comme point de départ pour créer un échéancier à partir de rien. Si vous (et d’autres) ne
comprenez pas clairement le travail à effectuer pour élaborer une structure de découpage du projet (au
moins pour le travail à réaliser durant les prochains trois mois), cela signifie probablement que vous
n’êtes pas encore en mesure de démarrer le projet. Dans ce cas, vous pouvez commencer par la
définition d’un projet d’analyse. Une fois la partie d’analyse terminée, vous devriez détenir les
renseignements nécessaires pour définir le reste du projet.
Petits projets (2.1A. P2)
En général, un petit projet ne mérite pas l’utilisation d’un processus formel pour élaborer l'échéancier. Il
est facile de se représenter mentalement les étapes qui doivent être suivies et l’ordre dans lequel elles
sont établies. Il n’y a probablement pas plus d’une ou deux personnes impliquées, et il sera donc facile
de déterminer le rôle de chacun. Bien que vous puissiez concevoir l'échéancier mentalement,
l'échéancier final devra être documenté. Pour un petit projet, vous pouvez employer un logiciel de
gestion de projet de type MS Project, comme vous pouvez utiliser un tableur, voire une simple feuille de
papier. L’essentiel est de vous réunir autour d’une table avec les autres membres de l’équipe et de
planifier le travail qui doit être réalisé. Un fois l'échéancier rédigé, les membres de l’équipe de projet et
votre client pourront mieux comprendre le travail à effectuer.
Une fois que vous avez réalisé les estimations initiales de l'effort de travail, des coûts et de la durée,
vous pouvez remplir le formulaire de demande de service pour un petit projet.
Projets moyens et grands (2.1A. P3)
Pour les plus petits des projets moyens, vous avez la possibilité d’employer les mêmes techniques que
pour un petit projet. Cependant, plus le projet est grand, plus ce processus informel devient complexe.
Dans la section 2.2A Techniques de ce processus, vous trouverez des renseignements sur la manière
d'élaborer un échéancier à partir de projets antérieurs ou de modèles préétablis. Ces options sont
souvent les meilleures et les plus rapides pour élaborer un échéancier pour votre projet. Cependant,
dans cette partie, nous ferons comme si vous deviez commencer l’élaboration d’un échéancier à partir
de zéro. La meilleure manière de procéder dans ce cas est d’élaborer une structure de découpage du
projet (SDP). Le processus général est le suivant :
Rôle Élaborer l’échéancier à partir de zéro
1 Le chef de Créer un plan de management de l'échéancier

projet Ce document définit et communique la manière avec laquelle l'échéancier sera
maintenu pendant le projet. Il fait partie du plan de management de projet. Voir
106
2.1A.7 Créer le plan de management de l'échéancier pour plus de détails.
Réunir les documents de base déjà existants (2.1A. P4)
2 Le chef de Examinez la charte du projet pour bien comprendre les livrables à produire, les
projet délais, les risques et les hypothèses du projet, etc. La charte du projet ne sera
peut-être pas complète, mais elle doit au moins se présenter comme une ébauche
décente, de façon à ce que l’ébauche de l'échéancier du projet puisse d’ores et
déjà être esquissée. la charte du projet et tous les autres documents qui s’y
rapportent doivent être examinés avant que vous ne commenciez à élaborer la
SDP.
Identification des activités/ Élaborer la structure de découpage du projet (SDP) (2.1A. P5)
3 Le chef de
projet
Structure de découpage du projet (SDP)

L’objectif de la structure de découpage du projet est de saisir tous les éléments
détaillés du travail nécessaire pour achever le projet. Le Séquencement n'est pas
important à cette étape. Ce processus de décomposition des grands éléments d'un
travail en éléments de travail plus petits est appelé ''découpage''. Lorsque la
structure de découpage du projet est achevée, vous obtenez une structure
d’activités en forme d’arbre à l’envers (la tête en bas).
Le projet global lui-même est appelé niveau 0 et le premier niveau de découpage
est appelé niveau 1.
Pour plus d'astuces et de techniques pour établir une structure de découpage du
projet, voir 2.1A.5 Structure de découpage du projet.
4 Le chef de Estimer l’effort de travail pour toutes les activités détaillées

projet Vous avez déjà effectué une estimation de haut niveau de l'effort dans le but de
déterminer si le travail pour chaque activité dépasse le seuil des estimations.
Vous devez maintenant réviser toutes les activités détaillées et estimer les heures
réelles d'effort (les activités détaillées sont celles qui se trouvent au plus bas
niveau et qui ne sont pas divisées davantage). Vous pouvez utiliser les techniques
d'estimation contenues dans 2.1A.1 Estimer l’effort et la durée et 2.2.1 Techniques
d'estimation pour l’échéancier et le budget. Par exemple, vous pouvez déterminer,
à l'aide d'un spécialiste, si une certaine activité requiert un effort de 70 heures.
Ensuite, vous pouvez utiliser une technique d'analogie pour déterminer si d'autres
activités ayant presque la même taille nécessiteront aussi 70 heures pour être
107
achevées.
Organiser les activités en séquence (2.1A. P6)
5 Le chef de Élaborez un diagramme de réseau par l'intermédiaire de la

projet chronologie des composantes détaillées de la structure de découpage
du projet
La première étape pour convertir la structure de découpage du projet en

diagramme de réseau, consiste à examiner toutes les activités détaillées (et non
les activités sommaires) et à les classer par ordre chronologique. N’oubliez pas
d’y inclure toutes les activités qui n’ont pas pu être découpées davantage,
indépendamment du niveau où elles se situent dans la structure de découpage
du projet (SDP). À travers le processus de détermination de l’ordre d’exécution
des tâches, vous déterminez le travail qui sera accompli en premier lieu, celui qui
sera fait en second lieu, puis en troisième lieu, etc. Vous déterminez également
le travail qui peut être effectué en parallèle avec d'autres activités. Cette étape
est la raison pour laquelle l’ordre séquentiel initial des activités dans la structure
de découpage du projet (SDP) n’a pas d’importance. Si vous retrouvez tout le
travail dans la SDP, c’est que l’ordre séquentiel des activités est à présent établi.
Une fois une première ébauche de la chronologie des activités établie, révisez le
travail encore une fois. À cette étape, repérez tous les rapports logiques entre les
activités. Vous devriez constater si une activité ne peut commencer que
lorsqu'une autre est terminée. Dans plusieurs cas, deux ou plusieurs activités
pourraient devoir être achevées avant même qu'une autre ne puisse débuter.
Pour plus de renseignements sur l'organisation des activités en séquence, voir
2.1A.3 Liens logiques.
6 Le chef de Déterminer le chemin critique du projet

projet
Lorsque vous aurez terminé d’élaborer la chronologie des activités, votre
échéancier présentera plusieurs voies d’activités dépendantes, du début à la fin
du projet. L’une de ces trajectoires est plus importante que toute autre : le «
chemin critique ». C’est la voie qui mène à la date de fin du projet. Une fois que
vous aurez déterminé l’ordre des activités, vous devrez comprendre le chemin
critique du projet. Voir 2.1A.6 Chemin Critique, pour plus de renseignements sur
ce concept très important.
7 Le chef de Repérez les dates contraignantes

projet
À présent, vous devriez noter toutes les dates contraignantes. Ces dates
consistent en des événements qui échappent au contrôle de l’équipe de projet
mais qui doivent être gérées éventuellement. Il ne s’agit pas obligatoirement de
108
problèmes ou de risques, mais elles doivent tout de même être prises en
considération dans votre échéancier. De nombreuses contraintes ont des
implications au niveau des dates, mais ce n’est pas forcément le cas pour toutes.
Par exemple, un produit livrable doit être terminé avant la réunion du conseil
d’administration qui doit se tenir à telle date. Vous pouvez aussi avoir besoin de
passer une commande à un fournisseur avant une date donnée.
Estimation des ressources nécessaires aux activités (2.1A. P7)
8 Le chef de Affectation des ressources

projet
Jusqu’à présent, vous avez élaboré l'échéancier du projet sans donner aucune
indication sur le personnel. Au cours de cette étape, vous affectez des ressources
aux différentes activités de travail. Si on vous a attribué des ressources humaines
spécifiques pour votre projet, vous pouvez les assigner directement aux activités
qui leur sont appropriées. Si toutes les ressources humaines n'ont pas été
assignées, l’assignation devra se faire selon des concepts génériques. Par exemple,
si vous avez besoin de trois programmeurs, vous devez les désigner dans votre
échéancier par : « programmeur 1 », « programmeur 2 » et « programmeur 3 ».
Estimation de la durée des activités (2.1A. P8)
9 Le chef Élaborez l’échéancier initial du projet

de Si vous utilisez un logiciel de gestion de projet pour la programmation initiale du
projet projet, il est temps de commencer à élaborer l’échéancier. En se basant sur l'effort
de travail, les charges de personnel et les contraintes qui vous sont imposées, le
logiciel calculera la chronologie globale du projet du début à la fin.
10 Le chef Nivellement des ressources

de Au cours des étapes précédentes, vous avez assigné du personnel en vous basant
projet strictement sur le nombre de personnes nécessaires pour effectuer le travail. Ce que
vous devez chercher à savoir est si une ressource sera affectée pour un grand
nombre d'heures pendant une semaine et pour un nombre d'heures insuffisantes la
semaine suivante. Au cours de cette étape, vérifiez si la charge de travail imposée à
chacun de vos collaborateurs n’est pas trop lourde ou trop légère (si vous avez un
grand projet et que vous n’utilisez pas un logiciel de gestion de projet, cela sera
probablement impossible). Ce travail d’harmonisation des charges de travail
s’appelle « nivellement des charges du personnel ». Les techniques permettant de
niveler les charges du personnel comprennent :
 La programmation séquentielle des activités, même si ces dernières
pourraient être effectuées en parallèle s’il n’y avait pas de contraintes de
personnel. Par exemple, vous pouvez avoir deux activités estimées chacune
à 40 heures, qui pourraient être réalisées au même moment. Cependant, la
même personne est indispensable à chacune de ces activités. Dans ce cas,
une activité doit être programmée pour une semaine et l’autre activité pour
la semaine suivante.
 Le transfert du travail d’une personne surchargée de travail à une autre
personne « sous-chargée » au même moment et possédant des
qualifications similaires.
 Repérer les creux partout dans l'échéancier et y intégrer du travail. Par
exemple, la réalisation d’une activité qui représente un effort de travail de
cinq jours peut avoir été planifiée pour un créneau de 30 jours. Une
personne peut être appelée à réaliser d'autres activités au préalable, mais
avoir un peu de temps disponible vers la fin des 30 jours. Dans ce cas,
109
l’activité la plus flexible peut être remise à plus tard, après la réalisation
d'autres activités moins flexibles.
 Diversifier le personnel. Si deux personnes (ou plus) sont affectées à une
activité, voyez si l’une d’elles peut être libérée pour exercer une autre
activité qui présente des contraintes de personnel, même si la première
activité demande alors plus de temps. De même, voyez si des personnes en
sous-charge de travail peuvent être affectées à une activité afin d’en
accélérer la réalisation et de permettre à une autre activité de commencer
plus tôt.
D'après ll’échéancier initial, Pierre Dupont est surchargé les jours 8 et 9. Après le
nivellement des ressources, une partie du travail est déplacée au jour 10, et le reste
au jour 11. L’activité demande désormais un jour de plus, mais ne surcharge pas
Pierre Dupont.
11 Le chef Mettre le plan au point

de Une fois que vous avez estimé l'effort de travail de chaque activité et que vous avez
projet affecté le personnel nécessaire, vous pouvez programmer à nouveau le projet et
évaluer le temps qu’il demandera (la durée). À ce stade, vous disposez d’une
première véritable ébauche de votre échéancier.
Élaborer l’échéancier (2.1A. P9)
12 Le chef de Réexaminez l'échéancier pour vérifier qu’il est cohérent

projet
Vous devez vous sentir à l’aise pour défendre vos estimations auprès de votre
supérieur et de votre commanditaire. Si vous sentez que le budget ne reflète pas
vos besoins, effectuez les changements appropriés. Par exemple, votre échéancier
fait apparaître une durée de dix mois, mais vous ne disposez que de huit mois
pour le mener à terme. À ce stade, vous devez examiner des alternatives telles
que : ajouter du personnel, faire des heures supplémentaires ou supprimer
certaines activités.
Vous pouvez aussi avoir l’impression que l’échéancier n’est pas au point compte
tenu de vos expériences antérieures.
Vous devez vous sentir à l'aise que l'estimation de la durée du projet est dans les
15%, avant le démarrage du projet.
L'essentiel est que lorsque vous présentez votre estimation du budget, le moins
que les autres puissent faire est d’interroger vos chiffres. Si vous n’êtes pas
suffisamment à l’aise pour leur répondre, c’est qu’il vous reste du travail à
effectuer. En d'autres termes, si vous n’êtes pas en mesure de défendre les
chiffres que vous avancez, vous devez passer plus de temps à tenter d’élaborer
une estimation dont vous êtes sûr.
110
13 Le chef de Fixez des jalons de l'échéancier et établissez les révisions à
projet l'achèvement des différentes phases
Déterminez quand des livrables-clés seront réalisés et fixez des jalons en lien avec
ces événements. Un jalon est une activité de durée nulle qui est utile pour gérer
le travail à un niveau global. Si vous (ou votre manager) rédigez un rapport
faisant état des jalons de l'échéancier du projet, vous devriez pouvoir rapidement
affirmer si vous êtes dans les délais ou bien en avance ou en retard par rapport à
l'échéancier.
Vous pourrez définir des jalons importants à la fin des phases du projet. Cette
technique est appelée "révisions à l'achèvement des phases". Pour plus de détails,
voir 2.1A.8 Établir les révisions à l'achèvement des phases. L'objectif et le format
réel de la révision de points de passage sont décrits dans le paragraphe 3.1A.3.2
Jalons / Revues de points de passage.
14 Le chef de Gardez une copie de l’échéancier comme version élémentaire

projet
Une fois que l’échéancier est élaboré et que le projet est approuvé, conservez une
copie de l’échéancier qui servira de version élémentaire. Plus tard, quand
l’échéancier sera en cours de gestion, la version mise à jour pourra être comparée
à l’original pour déterminer les variations.
111
2.1A.1 Estimer l’effort et la durée
(2.1A.1. P1)
D’après le dictionnaire, l’estimation est l’action d’apprécier la taille, le nombre, la valeur, la distance, la
qualité, etc. de quelque chose qui nécessite un calcul ou une évaluation.
Ce chapitre décrit un processus permettant d’estimer l'effort de travail, le coût et la durée d’un projet. Il
faut commencer par estimer le nombre d’heures de travail. La durée et le coût peuvent être déduits de
l’estimation de l'effort de travail établie comme point de départ.
Avant de commencer (2.1A.1. P2)
Examinez les techniques suivantes avant d'entamer le processus d'estimation.
 Établissez une image claire du travail qui doit être estimé. De nombreux problèmes
concernant l’estimation surviennent parce que la personne qui en est chargée n’est pas sûre de
ce que le travail implique. Vous devriez éviter d’estimer un travail que vous ne comprenez pas.
Ceci n’implique pas que vous devriez connaître chaque détail. La contingence d’estimation
(définie plus loin) est une manière de refléter cette incertitude persistante.
 Déterminez qui sera impliqué dans le processus d’estimation. Le chef de projet peut
être ou non en mesure de réaliser seul les estimations. C’est habituellement une bonne manière
de procéder à l’estimation d’avoir recours aux membres de l’équipe, aux clients, aux
spécialistes, etc. Cela permet en général d’obtenir des estimations beaucoup plus précises que
celles que vous auriez pu réaliser seul.
 Déterminez s’il y a des contraintes à considérer lors des estimations. S’il en existe, il
est important de les connaître à l’avance. Par exemple, la date de fin peut être fixée : c’est une
contrainte. Vous devriez également définir si le client s’attend à un niveau de qualité Six Sigma
dans les livrables, ou si c’est la règle du 80/20 qui sera appliquée. Il est parfois possible qu'on
dispose d’un budget fixe qui ne peut être révisé à la hausse. (Cela peut être intéressant car
vous pourriez réduire le contenu, si nécessaire, pour ne pas dépasser votre budget fixe).
Connaître ce genre de contraintes aidera les personnes chargées de l’estimation à formuler des
hypothèses valables en rapport avec le coût global, la durée et la balance de qualité.
 Employez, si possible, différentes méthodes d’estimation. Un certain nombre de

techniques s’offrent à vous pour estimer un travail. Dans la mesure du possible, essayez
d’employer deux techniques différentes ou plus pour l'estimation. Si les résultats provenant de
techniques différentes sont relativement proches, vous pourrez accorder plus de confiance à
vos chiffres. Si les estimations sont éloignées les unes des autres, vous devriez réexaminer vos
chiffres et vérifier que vous utilisez des hypothèses semblables. Vous pouvez également tenter
d’utiliser une troisième (voire une quatrième) technique d’estimation pour juger si l’une ou
l’autre de ces estimations peut être validée et l’autre rejetée.
Estimer l'effort de travail (2.1A.1. P3)
L'effort de travail doit toujours être estimé en premier, avant que l'estimation de la durée et du coût ne
soit fixée. Utilisez le processus suivant pour estimer l'effort de travail.
Rôle Estimation de l’effort
1 Chef de Déterminez le degré de précision nécessaire à votre estimation.

projet Généralement, plus l’estimation est précise, plus vous vous êtes en mesure de
connaître de détails, plus vous aurez peut-être besoin de temps pour la
réaliser. Si on vous demande une estimation avec un ordre de grandeur
approximatif (-25% - +75%), vous devez être en mesure de terminer les
112
travaux rapidement, à un niveau global et avec une quantité minimale de
détails. Peut-être même pourriez-vous donner une estimation avec un ordre de
grandeur approximatif, sur la base des connaissances que vous avez en tête.
D’un autre côté, si vous devez fournir une estimation précise à 10% près, vous
passerez sans doute un peu plus de temps pour comprendre plus en
profondeur et avec plus de détails le travail à réaliser.
2 Chef de Réalisez l’estimation initiale du nombre d’heures de travail.

projet Estimez chaque activité en utilisant les techniques décrites au paragraphe 2.2.1
Techniques d'estimation de l’effort et de la durée.
3 Chef de (Facultatif) Pondérez le nombre d’heures en fonction du personnel

projet assigné.
Vos estimations sont probablement basées sur le nombre d’heures dont aura
besoin une personne moyenne pour effectuer le travail (ou alors, il se peut que
les estimations soient basées sur l'effort requis si vous faites vous-même le
travail). Parfois, vous connaissez également la personne exacte ou le type de
personnel qui sera assigné à une activité. Si c'est le cas, vous aurez peut-être
avantage à pondérer l’estimation de la durée de travail vers le haut ou vers le
bas. Par exemple, vous pouvez estimer une activité à 40 heures de travail.
Cependant, vous savez également que la personne qui effectuera le travail est
un stagiaire inexpérimenté. Dans ce cas, vous pourriez doubler l’estimation à
80 heures. Un autre ensemble d’activités sera estimé à 200 heures. Cependant,
vous savez que vous utiliserez les services d’une personne expérimentée pour
effectuer le travail. Vous pouvez peut-être ainsi réduire facilement votre
estimation à 150 heures. Évidemment, cette étape ne peut être franchie que si
vous avez une bonne connaissance du personnel qui sera réellement assigné
au projet.
4 Chef de Ajoutez le temps de travail des spécialistes.

projet Assurez-vous que vous avez réservé des heures aux personnes employées à
temps partiel et aux spécialistes qui seront impliqués dans le projet, par
exemple : des personnes travaillant en free-lance, des spécialistes de la
formation, du soutien administratif, etc. Ce sont des gens qui ne viennent pas à
l’esprit immédiatement, mais vous pouvez en avoir besoin pour des activités
spécifiques. Du fait qu'ils remplissent, d'une manière générale, des rôles de
soutien au projet, on oublie parfois d’inclure leurs activités dans la structure de
découpage du projet initial.
5 Chef de (Facultatif) Prenez en compte les corrections.

projet Dans un monde parfait, tous les livrables du projet seraient parfaits dès la
première fois. Dans la réalité, cela est rarement le cas. Les échéanciers qui ne
prennent pas en compte le travail de reprise peuvent facilement sous-estimer
l'effort de travail requis pour réaliser les livrables.
Cela ne doit pas être confondu avec les modifications du contenu. Si vous
produisez un produit livrable qui ne répond pas à toutes les exigences
originales ou qui présente un problème de qualité, alors des travaux ultérieurs
de reprise peuvent être exigés. Si le livrable original n’est pas acceptable en
raison de demandes complémentaires concernant de nouveaux dispositifs,
fonctions ou exigences, le processus de gestion des modifications du contenu
devra alors être utilisé. Il existe de nombreuses manières de prendre en
compte l'effort et la durée liés à ce travail de reprise :
 Ajoutez-les dans l’estimation originale. C’est probablement
l’approche la plus courante. Si vous pensez qu’un produit livrable
nécessitera 50 heures pour être accompli, vous avez probablement
déjà calculé mentalement le travail requis pour effectuer un ou peut-
être deux ensembles de corrections.
113
 Ajoutez-les en tant qu’activités séparées. Dans cette approche,
vous estimez l'effort de travail nécessaire pour réaliser le produit
livrable d’un côté, et ajoutez d’un autre côté un deuxième (et
troisième) ensemble d’activités, d'effort de travail et de durée pour les
corrections.
 Ajoutez-les en tant que blocs de temps. Plutôt que d’associer le
travail de reprise à des livrables particuliers, ajoutez un bloc de temps
de contingence pour le travail de reprise à la fin de chaque phase. Cela
revient à ajouter un tampon général à l’échéancier et au budget pour
résorber le travail de reprise associé à un groupe de livrables. L'effort
de travail et le coût liés à ce tampon peuvent être basés sur des
estimations séparées du travail de reprise de chaque livrable, ou
simplement selon un pourcentage du temps de développement du
livrable.
6 Chef de Ajoutez le temps nécessaire au management de projet.

projet Le management de projet prend du temps et un coût lui est associé. Vous
devez allouer des heures d’effort pour gérer un projet avec succès et de
manière proactive. Vous devriez ajouter 15% de l'effort de travail pour le
management de projet. Par exemple, si une estimation de projet s’élève à
12.000 heures (7-8 personnes), le travail d’un chef de projet à temps plein
(1.800 heures) sera nécessaire. Si l’estimation du projet est de 1.000 heures, le
temps de gestion du projet sera de 150 heures. Cela ne sera pas suffisant pour
occuper un chef de projet à plein temps. Dans ce cas, le chef de projet
travaillera à temps partiel sur le projet ou bien sur des activités autres que
celles de gestion qui lui seront assignées en dehors du projet.
7 Chef de Ajoutez des heures de réserve.

projet La réserve est utilisée pour refléter l’incertitude ou les risques associés à
l’estimation. Si on vous demande d’estimer un travail qui n’est pas défini
correctement, vous pouvez ajouter 50%, 75% de temps ou plus, pour refléter
l’incertitude. Si l’estimation est demandée à la dernière minute, une grande
réserve peut être nécessaire. Même si vous avez le temps de procéder à une
estimation raisonnablement précise, la réserve devrait encore être de l’ordre de
10% à 25%. Si vous n’ajoutez pas le quota lié à la réserve, cela signifie que
vous êtes confiant à 100% dans votre estimation. Cela peut être le cas si des
projets similaires ont été réalisés auparavant. Quand vous ajoutez des périodes
de réserve, la meilleure approche est de le faire sur une ligne séparée.
Cependant, si votre organisation ne vous autorise pas à inclure une réserve
d’estimation formelle, vous risquez de ne pas disposer d’un autre choix que
celui de gonfler les estimations de toutes les activités qui sont à la base de
cette réserve. Ce n’est certes pas la meilleure approche, mais c’est une réaction
naturelle si votre organisation ne vous autorise pas à inclure un budget formel
de réserve d’estimation pour refléter l'incertitude de l'estimation.
8 Chef de Calculez l'effort de travail total

projet Cela peut se faire en additionnant toutes les composantes de travail décrites
précédemment.
9 Chef de Passez en revue et procédez à des ajustements, si nécessaire.
114
projet Parfois, quand vous additionnez toutes les composantes, l’estimation apparaît
de manière évidente trop haute ou trop basse. Si votre estimation ne vous
semble pas juste, révisez le tout et ajustez vos hypothèses d'estimation pour
mieux refléter la réalité. Assurez-vous, en outre, que votre modèle d’estimation
est cohérent et raisonnable. Par exemple, si une activité répétitive est planifiée,
vous calculerez l'effort total en multipliant l'effort de réalisation d'une activité
par le nombre de fois où cette activité est exécutée. Cependant, d'après une
nouvelle évaluation, vous constaterez que l'effort de réalisation de l’activité
diminuera au fur et à mesure qu'elle deviendra routinière. Assurez-vous
également que des activités semblables soient estimées de façon similaire. Si
ce n’est pas le cas, procédez aux ajustements nécessaires.
10 Chef de Documentez toutes les hypothèses.

projet Vous ne pourrez jamais connaître tous les détails d’un projet de façon certaine.
Par conséquent, il est important de consigner chacune des hypothèses que
vous émettez tout au long de l’estimation.
Estimer la durée (2.1A.1. P4)
Alors que l'effort de travail est indiqué en termes d’heures, la durée est indiquée en termes de jours et
de date de fin. Il serait par exemple déconcertant d’indiquer qu'une durée de projet est de trois mois,
alors que vous ne savez pas si cela signifie que la durée est réellement de 90 ou de 60 jours de travail.
Indiquez plutôt une durée de projet de 90 jours et une date de fin estimée. Si vous fournissez les
estimations de durée en ces termes, le nombre de jours de la durée estimée aussi bien que la date de
fin visée seront clairs.
Si chacun travaille pendant huit heures par jour et qu'il est réellement productif à 100%, vous pouvez
facilement calculer la durée en prenant le nombre d’heures de travail et en le divisant par le nombre de
personnes et par le nombre d’heures de travail par jour. Par exemple, si une activité estimée à 80
heures est attribuée à une personne travaillant huit heures par jour, la durée sera de (80/1/8) = 10
jours. De même, si la même activité est répartie entre quatre personnes, la durée sera de (80/4/8) =
2,5 jours.
Cependant, ces circonstances parfaites ne sont pas révélatrices de la façon dont un travail est exécuté
en réalité. Par conséquent, quand vous disposez d’un personnel réduit pour un travail, vous pouvez
convertir le nombre d’heures de travail requis en durée en utilisant la méthode suivante :
Rôle Estimation de la durée
1 Chef de Estimez le nombre d’heures productives par jour

projet Normalement, la première étape est de déterminer sur combien d’heures de
travail productives vous pouvez compter pour chaque personne au fil du temps.
En d’autres termes, si une activité est planifiée pour durer 40 heures d’effort, il
est peu probable qu’elle puisse être accomplie en une semaine de calendrier sans
heures supplémentaires. Employer un facteur de 6,5 heures productives par jour
vous aidera à prendre en compte le temps octroyé pour maladies, réunions de
service, activités administratives, pauses, toilettes, etc. Voir 2.1A.4 Estimer les
heures productives par jour.
2 Chef de Déterminez combien de personnes seront affectées à chaque activité

projet En général, plus vous pouvez affecter de personnes à une activité, plus elle sera
accomplie rapidement. Évidemment, deux personnes peuvent réaliser une activité
plus rapidement qu’une seule personne, mais elles ne peuvent néanmoins pas
être deux fois plus rapides. De même, une troisième personne peut permettre à
l’activité d’être exécutée plus rapidement, mais pas trois fois plus vite. Au-delà
d’un certain point, ajouter du personnel n’accélèrera pas la réalisation de
l’activité, mais en ralentira l’exécution.
115
3 Chef de Convertissez en jours ouvrables, en tenant compte des vacances, congés et
projet sessions de formation. Ces éléments n’ont pas été pris en compte dans le facteur
productivité du premier alinéa puisque ce temps de non projet peut être
programmé et comptabilisé à l’avance. Par exemple, sur un projet de trois mois,
un membre de l’équipe peut être en congé pendant deux jours, alors que
d’autres prendront dix jours de vacances. Pour que votre échéancier soit plus
précis, considérez tous les jours où votre équipe ne sera pas disponible pour
travailler sur le projet.
4 Chef de Tenez compte de toutes les personnes qui ne travaillent pas à temps
projet plein
Si une personne disponible est 50% du temps, elle prendra au moins deux fois
plus de temps pour réaliser le même effort de travail qu’une personne qui
travaille à temps plein. Si vous avez une activité pour un temps de travail estimé
à 40 heures et que vous l’attribuez à une personne disponible à 25% seulement
pour votre projet, la durée qui en résulte est d’au moins quatre semaines, si ce
n’est plus.
5 Chef de Prenez en compte la perte de productivité due aux tâches multiples du

projet personnel à temps partiel
Si une personne travaille sur différents projets, ou peut-être une combinaison de
projets et d'actions de support, une réduction sensible de la productivité doit être
prise en considération. Ceci reflète le fait que si une personne est partagée entre
plusieurs activités indépendantes, cela prend du temps pour en arrêter une et en
commencer une autre. Par exemple, si une personne travaille sur deux projets à
raison de 20 heures par semaine et par projet, elle perdra du temps productif à
basculer sans cesse d’un projet à l’autre. Si la personne est sur deux projets, ceci
pourrait occasionner une perte de productivité de l’ordre de 10% au niveau des
deux projets. Si la personne travaille sur trois projets (ou plus), il est possible
d’atteindre une perte de productivité allant jusqu’à 20%.
Imaginons, par exemple, qu’une personne soit partagée entre trois projets à
raison de 24, 10 et 6 heures par semaine. Les chefs de projets respectifs devront
plutôt compter sur des périodes productives de 20, 8 et 4 heures. De plus,
puisque trois projets sont en jeu, impliquant des temps d’arrêt et de départ, le
temps productif pourrait en réalité se rapprocher respectivement en plages de
16, 6 et 3 heures par projet.
6 Chef de Calculez les retards et les décalages dans le temps

projet Certaines activités ne requièrent qu’un nombre restreint d’heures de travail, mais
une longue durée. Par exemple, si vous comptez sur du personnel provenant
d’un fournisseur, vous devrez attendre que le fournisseur soit prêt avant de
commencer. Un autre exemple est la durée nécessaire pour obtenir l’approbation
d’un livrable. Vous pouvez estimer l'effort de travail à quelques heures
seulement. Toutefois, obtenir une approbation peut nécessiter un certain nombre
de jours ou de semaines.
7 Chef de Identifier les contraintes au niveau du personnel

projet Lorsque vous élaborez votre échéancier initial, identifiez les activités qui peuvent
être effectuées consécutivement et celles qui peuvent être faites en parallèle. Si
vous avez suffisamment de personnel, plusieurs activités peuvent être réalisées
en parallèle. Cependant, vous ne pouvez réaliser ces activités que si le personnel
approprié est disponible au bon moment. Si vous n'avez pas un personnel
suffisant (et vous l'avez rarement), vous vous rendrez compte que les activités
parallèles doivent être exécutées l'une après l'autre, puisque les mêmes
personnes doivent être assignées à ces activités. Même si vous pensez avoir
assez de personnel, vous devez reconnaître que toutes les activités et tous les
membres de l’équipe ne sont pas interchangeables. Un ensemble d’activités
116
pourraient parfois être menées en parallèle, mais ces activités devront être
effectuées l’une à la suite de l’autre, parce qu’une seule personne possède les
qualifications nécessaires pour réaliser le travail même lorsque d'autres
personnes sont disponibles.
8 Chef de Documentez toutes les hypothèses

projet Vous ne pourrez jamais connaître tous les détails d’un projet. Par conséquent, il
est important de consigner chacune des hypothèses que vous émettez tout au
long de l’estimation.
117
2.1A.2 Seuil d’estimation
(2.1A.2. P1)
Lorsque vous créez un échéancier, généralement vous n’êtes pas en mesure d’y inscrire toutes les
activités détaillées du premier coup. Au lieu de cela, vous identifiez d'abord de grandes portions de
travail, et vous les divisez ensuite en plus petites parties. Ces dernières sont, à leur tour, découpées en
activités plus petites et plus discrètes. Cette technique est appelée : élaboration d’une structure de
découpage de projet (SDP).
La question pertinente est de savoir quelle petite taille les activités doivent atteindre, pour ne pas avoir
à être découpées davantage. C’est ce qui est considéré comme votre 'seuil d'estimation’. Le travail peut
être découpé en activités plus petites que le seuil d’estimation, mais, normalement, aucun travail ne
devrait rester à un niveau plus élevé. Le seuil peut être différent selon la taille de votre projet et le
degré de compréhension du travail.
Vous pouvez employer les critères suivants comme modèle à suivre. Pour un grand projet particulier
(disons 5000 heures d’effort ou plus) en général, n'importe quel travail qui nécessite plus de 80 heures
d’effort devrait être découpé. Les projets moyens (disons1000 heures d'effort) devraient avoir des
activités qui ne dépassent pas 40 heures d’effort. Si le projet est petit (disons 200 heures), vous devriez
découper les activités de telle sorte qu’elles n’excèdent pas 20 heures d’effort. Rappelez-vous que ce
seuil est la limite supérieure. Vous pouvez donc découper les activités davantage, si vous le voulez.
Assigner des tâches qui sont de taille inférieure à votre seuil, rend le travail plus facile à gérer. Ceci
s'explique par le fait que lorsque vous affectez une tâche à un membre de l'équipe, vous ne êtes pas
vraiment sûr comment ce dernier va progresser jusqu'à l'échéance (ou la date de l'achèvement si le
travail est exécuté avant l'échéance). Par exemple, si vous affectez une tâche du travail qui doit être
achevée dans quatre semaines à un membre de l'équipe, vous ne saurez pas si le travail est entrain
d'être effectué dans les délais déterminés jusqu'à la fin du délais des quatre semaines. Si le travail est
achevé, vous allez savoir que vous êtes sur la bonne voie. Si le travail est en retard, vous le saurez
également. Cependant, le délai des quatre semaines (ou même encore plus) est très long pour savoir si
le travail est sur la bonne voie ou non. Une meilleure approche est la suivante: découpez l'activité de
quatre semaine en des activités d'une semaine chacune. Dès la fin de la première semaine, vous allez
découvrir si le travail est dans les délais ou s'il ne l'est pas.
Naturellement, il est possible que des activités qui doivent être effectuées dans un futur éloigné soient
difficiles à découper en dessous du seuil, parce qu'il y a encore beaucoup d’inconnues concernant le
travail lui-même. Dans ce cas, une des approches possibles serait de diviser réellement le travail
en plusieurs petits projets. Le deuxième projet peut être défini plus exactement en se basant sur les
résultats du premier.
Si vous ne pouvez pas opter pour des projets multiples, les travaux futurs peuvent être laissés à un
niveau supérieur au seuil. Cependant, si vous laissez les travaux futurs à un niveau élevé, il est
absolument nécessaire de diviser le travail en de plus petites parties au moins deux à trois mois avant
le commencement de l’exécution de travail.
En plus de vous permettre de contrôler plus efficacement le travail, le découpage des activités en plus
petites parties vous permet de vous assurer que vous comprenez ce que le travail signifie. Quand vous
affectez à un membre de l’équipe une activité qui figure dans l’échéancier, il peut ne pas comprendre
ce qu'est le travail et vous demander une explication. Si vous ne savez pas non plus ce que signifie le
travail, vous risquez d’avoir des difficultés. C’est pourquoi vous devrez vous assurer que le travail est
découpé en activités si réduites qu’elles sont compréhensibles. Par exemple, si une activité est estimée
à 80 heures et n'a jamais été réalisée avant, il est possible de la découper en de plus petites activités
pour s'assurer que le membre de l’équipe qui est chargé de l’effectuer sait exactement ce qu’on attend
de lui.
Ces deux facteurs – la capacité de gérer le travail efficacement et de comprendre le travail demandé -
devraient guider votre décision concernant la réduction de la taille de vos activités.
118
Seuil de durée (2.1A.2. P2)
En général (mais il ne s’agit pas d’une règle absolue), la durée des activités devrait être découpée
jusqu’à un niveau n’excédant pas deux fois le cycle des comptes rendus de l’équipe. Par exemple, si
vous recevez de votre équipe un rapport formel sur la situation toutes les deux semaines, le seuil de
durée sera de quatre semaines. Si vous avez des réunions hebdomadaires sur la situation du projet, la
durée des activités assignées ne devrait pas excéder deux semaines. Cette règle permet de s’assurer
qu’il n’y aura pas plus de deux périodes de comptes rendus avant qu’une activité soit ou bien accomplie
ou bien considérée comme étant en retard. Par exemple, si vous vous réunissez avec votre équipe
chaque semaine et que la durée de toutes les activités ne dépasse pas deux semaines, aucune activité
ne sera en cours durant plus de deux réunions. Au contraire, si vous avez une activité d’une durée de
cinq semaines, il est possible que vous ayez jusqu’à cinq rapports sur la situation du projet, avant que
vous sachiez avec certitude si l’activité sera accomplie dans les délais. C’est un exemple qui montre que
l’activité devrait être découpée au moins à un niveau inférieur. De plus petites activités permettent de
découvrir et de résoudre les problèmes beaucoup plus tôt.
Le contraire de cette situation est également vrai. Supposons que vous avez découpé une activité de
200 heures en quatre activités plus petites - chacune d'elles est de moins de 80 heures-. Cependant,
lorsque vous êtes prêt d'affecter le travail, vous allez voir qu'il est en fait affecté à une équipe de trois
personnes. Dans ce cas, le seuil de 80 heures devrait être très court. Au lieu de cela, vous pourriez
retrousser les quatre plus petites activités à l'activité sommaire de 200 heures. Du moment où il y a
trois membres dans cette équipe, ils sont encore capable d'achever cette activité de 200 heures dans
un délai de deux semaines.
Notez que le seuil de durée entre en jeu lorsque l'échéancier du projet est finalisé et non pas quand la
structure de découpage du projet (SDP) est réalisée. Au moment où la structure de découpage du
projet (SDP) est réalisée, vous connaissez seulement l’estimation de l'effort de travail. Après
l’affectation du personnel, vous pouvez affirmer que le seuil de durée a été fixé.
119
2.1A.3 Liens logiques
En élaborant le diagramme réseau, vous remarquerez que chaque activité de la structure de découpage
du projet (SDP) est en relation étroite avec au moins deux autres activités : il y a au moins une activité
qui précède et/ou une activité qui suit. Il y a plusieurs manières de représenter ces liaisons. La
technique la plus courante est la Méthode des antécédents (Precedence Diagramming Method, PDM).
Cette technique est aussi appelée Activité sur nœuds (Activity On Node, AON). Dans la méthode des
antécédents, les activités sont placées dans des cases (ou « nœuds ») qui sont reliées par des
flèches pour montrer l'ordre dans lequel elles doivent être exercées.
Le cas le plus courant que vous rencontrerez est celui d’une activité qui ne peut démarrer tant qu’une
autre n’est pas terminée. Cette liaison est connue sous le nom de « Liaison Fin - Début ». Il existe, en
tout, quatre manières de relier une activité à une autre.
 Liaison Fin - Début. L’activité B ne peut pas démarrer tant que l’activité A n’est pas terminée.
Il s’agit de la relation la plus courante entre des activités multiples. Dans la plupart des
échéanciers, toutes les relations seront du genre fin - début. Par exemple, vous devez acheter
un nouvel ordinateur avant que le nouveau logiciel puisse être installé.
 Liaison Début - Fin. L’activité A doit démarrer avant que l’activité B soit terminée. Cette
relation est très rare. Supposons, par exemple, que vous voulez fertiliser votre jardin mais que
les plantes doivent toutes être arrosées avant de répandre le fertilisant. Par conséquent, la
personne B doit continuer à arroser le jardin jusqu'à ce que la personne A soit prête à mettre le
fertilisant. La relation dit que la personne A doit commencer à fertiliser le jardin avant que la
personne B ne puisse finir de l’arroser. Remarquez que la personne A peut commencer à
arroser n'importe quand et que la personne B peut finir d'arroser n'importe quand. La relation
lie seulement le commencement de l'activité A à l'achèvement de l'activité B.
120
 Liaison Début - Début. L’activité A doit démarrer avant que l’activité B ne puisse démarrer.
Par exemple, vous devez d’abord démarrer les travaux pour peindre les murs avant que le
papier peint ne puisse être posé. Vous voulez réduire la perturbation totale et vous assurer que
les deux activités sont effectuées au même moment. La relation implique que la personne A
doit commencer à peindre les murs, avant que la personne B ne puisse commencer à poser le
papier peint. Les fins de chacune des activités ne sont par reliées les unes aux autres et, en
fait, une activité pourrait se terminer nettement plus tard que l'autre. Dans ce cas, le poseur de
papier peint doit être prêt, mais il ne peut commencer avant que la peinture ne démarre.
 Liaison Fin - Fin. L’activité (A) doit être terminée avant que l’activité (B) ne puisse être
également terminée. Par exemple, supposons que vous êtes en train de préparer le dîner, et
que vous voulez que tout soit prêt à peu au même moment. La relation dit que la dinde doit
finir de rôtir avant que les pommes de terre ne finissent de cuire. Cette relation est basée sur la
fin des activités. Chacune d’elles peut débuter à n’importe quel moment du moment qu’elles se
terminent dans cet ordre.
121
2.1A.4 Estimer les heures productives par jour
Quand vous estimez le nombre d’heures d'effort, la durée et les coûts, vous devez commencer par
estimer les heures d'effort. Si vous n'avez pas une idée sur les heures en question, vous ne pouvez
estimer de façon précise ni la durée, ni le coût.
L'un des facteurs clés, lors de la conversion des heures d'effort en durée, c'est de déterminer le nombre
d’heures de travail productives que vous pouvez espérer en une journée de travail ordinaire. Par
exemple, si vous avez estimé une activité à quarante heures de travail, il est peu probable qu’elle
puisse être accomplie en cinq journées calendaires de huit heures. Personne n’est productif à 100%. Si
vous ne tenez pas compte de cela, votre estimation de l'effort de travail en nombre d’heures sera
correcte, mais vous surévaluerez probablement l'estimation relative à la durée. Vous avez besoin d'un
"facteur de réalité" pour convertir le nombre estimé d’heures d'effort en durée estimée. Vous devez
déterminer le nombre d’heures productives par jour pendant lesquelles une personne va effectivement
travailler.
Le facteur de productivité tient compte du temps qu'une personne ordinaire passe réellement à
travailler en une journée. Ce facteur de productivité tient compte d’un certain nombre d‘éléments tels
que les interactions sociales au cours de la journée, (aller aux toilettes ou se déplacer pour assister aux
réunions). Il tient également compte des personnes qui ont besoin d'un peu de temps le matin pour
démarrer et de ceux qui commencent à s'affaiblir en fin d'après-midi. Vous pouvez essayer d’estimer le
nombre exact d’heures productives par jour où votre équipe travaillera vraiment, mais cela risque d’être
difficile, si ce n'est impossible. Le nombre d’heures productives moyennes par jour généralement admis
est de 6,5 heures, sur la base d'une journée de huit heures. Ceci ne signifie pas qu’une personne ne
peut pas être productive durant huit heures pleines; mais cela représente la moyenne des heures
productives, par jour, qu'une personne peut effectuer tout le temps.
Faites part à votre équipe de vos hypothèses de planification ainsi que de vos attentes. Les membres
de votre équipe doivent alors prendre l‘initiative de vous indiquer s’il existe des influences extérieures
qui les empêchent de se consacrer au projet durant le temps qui leur est imparti. Cela vous permettra
d’apporter des modifications au sujet des responsabilités de travail de chacun ou de modifier leurs
facteurs de disponibilité et de productivité.
Lorsque vous avez des contractuels, vous devez prendre en compte un facteur de productivité. Même si
ces personnes sont contractuelles, elles feront toujours l’expérience de plusieurs facteurs qui mènent à
une productivité inférieure à 100%. Par exemple, elles devront faire la connaissance des autres
membres de l’équipe et se rendre aux toilettes. Cependant, vous ne vous attendez pas à ce que les
contractuels aient le même niveau de temps non productif que les employés. Un bon taux d’occupation
pour les contractuels est d’environ de 7 à 7,25 heures productives par jour. Ce facteur est une façon
d’admettre que les contractuels ne sont pas des robots et qu’ils ne seront pas productifs à 100% tous
les jours. Bien sûr, vous devez les payer pour huit heures de travail par jour. Cependant, dans l’objectif
de réaliser votre échéancier, vous devez également prendre en compte le facteur de la productivité.
Prenons un exemple. Disons que vous avez une activité estimée à 80 heures. Si un employé travaille à
plein temps, il lui faudra un peu plus de douze jours (80/6,5 heures productives par jour) pour la mener
à terme. Si un contractuel travaille à plein temps sur cette même activité, la durée sera de onze jours
(80/7,25 heures productives par jour).
122
123
2.1A.5 Structure de découpage du projet
Créer la structure de découpage du projet SDP (2.1A.5. P1)
Le processus permettant d'établir la SDP s'effectue comme suit.
1. Découpez le projet en composants
Déterminez d’abord les grands lots de travail à réaliser pour mener à bien le projet dans sa totalité. A
ce stade, peu importe encore la manière dont vous procédez pour définir ces grands blocs de travail, du
moment qu’à la fin du processus, tout le travail soit défini. Par exemple, un découpage courant peut
être constitué par les éléments suivants: « Planification / Analyse / Conception / Construction / Tests /
Mise en Œuvre », ce qui revient à concevoir un calendrier approximatif. Le découpage peut également
se faire en fonction des livrables, par exemple: « Application en ligne / dépôt de données / répertoires
de données/ Outils d'interrogation des clients ». Il peut également se faire par rapport aux
fonctionnalités suivantes comme l’« Extraction des données / le Chargement des données / le Rapport
sur l'information ». Vous pouvez décomposer le travail suivant n’importe laquelle de ces structures, du
moment qu’elle s’adapte bien à votre projet.
2. Évaluez chaque composant de la SDP
Vérifiez chaque composant de niveau inférieur pour voir s'il respecte les deux critères suivants :
 L’effort requis pour réaliser le composant est-il en dessous du seuil d’estimation ? (Voir
2.1A.2 Élaborer l’échéancier /Estimation du seuil, pour de plus amples informations).
 Est-ce vous-même (ou l’un des membres de votre équipe) qui comprenez le travail
détaillé nécessaire pour réaliser cette portion de travail ? Les éléments de travail
détaillés nés de la SDP doivent, en fin de compte, être transférés dans l’échéancier.
Vous ne voulez sûrement pas inscrire sur votre échéancier des activités que personne
dans votre équipe ne comprend parfaitement.
Si vous comprenez le travail détaillé requis pour réaliser les éléments et que vous estimez que le niveau
d’effort est en dessous du seuil fixé, vous n’avez pas besoin de pousser le découpage plus loin.
3. Continuez de découper chaque composant quand cela est nécessaire
Les éléments de travail qui nécessitent un effort supérieur au seuil estimé ou ceux que vous ne
comprenez pas entièrement, doivent être subdivisés davantage.
Il est important de comprendre qu'au fur et à mesure que vous découpez le travail, vous allez
finalement créer des activités. Les activités détaillées de la SDP sont celles qui sont reportées à
l'échéancier.
Ce processus de découpage des composants du travail en des composants plus petits placés à un
niveau inférieur (étapes 3-4 ci-dessus) devrait se poursuivre jusqu’à ce que tous les composants du
travail soient représentés sous une forme aussi réduite que possible, pour être sûr qu’aucune activité
ne nécessite un effort supérieur par rapport au seuil fixé, et que vous comprenez le travail. Cela vous
amène aux niveaux 3, 4, 5, etc. Vous aurez rarement besoin de découper le travail au-delà du niveau 5.
Il n’y a pas d’exceptions à ce processus. Si votre projet est important, il est probable que vos
connaissances ne suffiront pas pour subdiviser le travail jusqu’à un niveau très détaillé. Si vous ne
pouvez pas décomposer le travail en éléments suffisamment petits, cela devrait aller tant que les
composants de plus grande taille ne doivent pas être réalisés à une date rapprochée. Dans ce cas, vous
pouvez laisser de côté les composants du travail jusqu’au moment où vous serez plus près de
l’exécution (trois mois), moment où vous en saurez assez pour être en mesure de décomposer le travail
en composants plus réduits.
Tant que vous n’avez pas encore fixé l’ordre de réalisation des tâches, vous ne pouvez pas savoir si un
travail doit être accompli plus tôt ou plus tard. Cependant, si vous ne savez pas décomposer le travail
124
en composants plus petits et inférieurs au seuil fixé, laissez-le au niveau où il est jusqu’à ce que l’ordre
de réalisation des tâches soit établi. A ce stade, vous saurez si vous avez un problème. Si le travail doit
être réalisé relativement tôt, vous serez obligé de trouver comment ramener les éléments les plus gros
à une taille plus réduite, afin de pouvoir attribuer le travail à un membre de l’équipe. Si le travail ne doit
être réalisé que dans un futur éloigné, les éléments peuvent être maintenus momentanément au niveau
élevé actuel.
Créez des activités détaillées et des activités sommaires (2.1A.5. P2)
Si, après avoir examiné une activité de la structure de découpage du projet (SDP), vous décidez qu’elle
doit être découpée davantage, cette activité prend le nom d’activité - sommaire. Une activité -
sommaire n’a pas d'effort de travail ou d’heures de travail propres. Elle représente un résumé logique
des activités qui lui sont subordonnées.
D’un autre côté, les activités ‘‘détaillées’’ sont celles qui n’ont pas été découpées davantage.
Les activités - sommaires sont découpées en activités détaillées. Par conséquent, une fois que ces
dernières qui sont sous l’activité - sommaire ont été achevées, l’activité - sommaire est, elle aussi
considérée comme achevée. S’il y a encore du travail à faire, cela signifie que des activités détaillées
doivent être ajoutées sous l’activité - sommaire.
Employez les "post-it" comme une approche commune dans l’élaboration de la SDP (2.1A.5.
P3)
Vous seriez surpris de connaître le nombre de personnes qui emploient des post-it et un mur blanc pour
créer la première ébauche de la structure de découpage du projet (SDP). Cette technique est très
simple. Vous devez d’abord rassembler les personnes appropriées dans une même pièce. Ce sont les
membres de l’équipe et les clients du projet qui ont les qualifications requises pour élaborer la structure
de découpage du projet (SDP). En général, commencez par écrire les noms des principaux livrables sur
des post-it – un produit livrable par post-it. Assurez-vous que les participants sont d’accord sur les
principaux livrables avant de commencer. Si certains des livrables sont très grands, vous pouvez utiliser
d’autres post-it pour décrire les livrables plus en détail, et amener à la taille de produits correspondants
à un travail individuel. Ces post-it sont alors placés sous le produit livrable plus général. Le livrable doit
être découpé en de nombreux éléments pour que vous compreniez bien ce qui est nécessaire pour le
produire. En général, deux niveaux de découpage devraient suffire. Un seul tour de découpage est plus
courant.
Ensuite, pour chaque produit livrable, décrivez les activités à accomplir pour le réaliser. Chacune est
notée sur un post-it distinct et toutes sont placées en dessous du produit livrable auquel elles se
rapportent. Si vous avez une idée de l’ordre dans lequel les activités doivent être accomplies, vous
pouvez classer les post-it suivant leur ordre d’exécution. Cependant, il n’est pas indispensable de le
faire à ce moment-là. Ce qui importe c’est de bien identifier tout le travail.
Examinez les activités requises pour élaborer chaque livrable (ou produit du travail) et estimez le travail
correspondant à chaque activité. Si l'effort de travail lié à une activité est supérieur au seuil d’estimation
que vous avez défini, identifiez les activités plus détaillées qui constituent un niveau un plus élevé.
Chacune de ces activités détaillées est représentée par un nouveau post-it placé sous l’activité plus
générale (qui maintenant devient une activité - sommaire). Continuez ce processus jusqu’à ce que tous
les travaux exigés pour accomplir tous les livrables soient définis de la meilleure façon possible, compte
tenu de ce que vous savez à ce moment-là. Les niveaux des activités ne seront pas les mêmes pour
chacun des livrables. Certains livrables simples peuvent descendre en dessous du seuil en un ou deux
découpages successifs. D’autres peuvent en nécessiter trois ou quatre, voire plus.
L’avantage de cette approche est que votre équipe peut appréhender visuellement le travail et qu’elle
vous aide de façon à ce que, pour que le projet puisse être accompli, tout le travail soit identifié
clairement. Les post-it vous donnent la possibilité de déplacer les éléments. Si vous ajoutez une
activité, puis que vous décidez de la supprimer, vous avez juste besoin de retirer le post-it. De même, si
un produit livrable ou un groupe d’activités est au mauvais endroit, vous avez juste à déplacer les post-
it pour les placer là où ils devraient être.
125
Lorsque tout est fait, vous pouvez saisir les activités détaillées et les activités - sommaires dans votre
logiciel de gestion de projet.
L’approche commune consiste à d’identifier les livrables au 1er ou au 2ème niveau, puis
d’identifier les activités (2.1A.5. P4)
Parfois les gens ont du mal à démarrer une structure de découpage du projet (SDP) parce qu’ils ne sont
pas sûrs de ce qui est à mettre tout en haut, ni de la façon de découper le travail vers le bas. Bien qu’il
y ait de nombreuses manières d’entamer la structure de découpage du projet (SDP), vous devriez, en
premier lieu, vous concentrer sur les livrables.
Puisque le niveau supérieur est le projet global (niveau 0), le niveau suivant peut commencer à décrire
les principaux livrables. Une fois ces derniers décrits, vous pouvez commencer à identifier les activités
nécessaires pour élaborer les livrables. L’échéancier du projet se compose finalement des activités, mais
elles doivent être énumérées dans le contexte de la réalisation des livrables.
 Il est logique de placer les principaux livrables du projet directement au niveau 1 et de le

découper en de plus petits composants au niveau suivant, si nécessaire.
 Une autre option pour le niveau 1 consiste à décrire les organisations qui seront impliquées,
telles que le service des ventes, celui de marketing, la techno informatique, etc. Le niveau
suivant devra alors mentionner les livrables produits par chaque organisation.
 Une troisième option consiste à considérer le niveau 1 en termes de cycle de vie du projet,
comportant par exemple l’analyse, la conception, la construction, les tests. Encore une fois, si
c’est la meilleure façon de considérer le premier niveau, alors le niveau 2 devra mentionner les
livrables à réaliser pendant chacune de ces phases du cycle de vie du projet.
Comme vous le voyez, le niveau 1 peut démarrer avec les livrables comme il peut tracer une autre voie
pour grouper de manière cohérente les majeures parties du projet. Cependant, si vous choisissez une
autre manière d’organiser votre vision du projet, vous devez effectuer immédiatement une transition
pour passer aux livrables, puis aux activités nécessaires pour produire ces derniers. Voyez le
paragraphe 2.1A.5.1 Exemples de structures de découpage de projet (SDP) pour de plus amples
informations.
Utilisez ces techniques additionnelles pour découper les activités sommaires (2.1A.5. P5)
Lorsque l’équipe établit la structure de découpage du projet (SDP), elle se pose généralement des
questions sur le niveau de détail avec lequel doivent être définies les activités détaillées. La question
clef est de savoir à quel moment arrêter le découpage du travail en de plus petites activités. Une partie
de la réponse réside dans l’utilisation d’un seuil d’estimation, comme nous l’avons expliqué au
paragraphe 2.1A.2 Seuil d’estimation. Les autres critères à prendre en compte sont les suivants:
 L’activité principale doit contenir des sous-activités connexes et continues les unes par rapport
aux autres. Par exemple, si vous définissez une activité comme "Création de la stratégie de
tests et de la stratégie de formation", elle devra probablement être découpée plus en détail, car
la stratégie des tests et la stratégie de formation ne sont ni reliées entre elles, ni en relation de
continuité.
 L’activité doit pouvoir être accomplie par une personne ou des personnes formant un même
groupe. Si vous avez une activité qui nécessite plusieurs personnes pour effectuer des sous-
activités différentes, cette activité devra être encore découpée en sous-activités de telle sorte
qu'une personne ou le même groupe de personnes puisse exécuter l'activité entière. Souvenez-
vous que les activités détaillées doivent être, en fin de compte, transférées vers l’échéancier.
Vous ne voulez certainement pas qu'une activité de votre échéancier soit assignée à deux
groupes différents ou à deux personnes n'ayant pas de lien entre elles.
 En général, le travail devrait être décomposé jusqu'à un niveau raisonnable et qui reste gérable
pour le chef de projet. Théoriquement, l'échéancier pourrait être décomposé à un tel point que
chaque activité ne représente plus qu’une ou deux heures de travail. Évidemment, cela n’a
126
aucun sens de décomposer le travail à ce point. Les membres de l’équipe assignés à ces tâches
n’ont pas besoin d’une définition du travail aussi détaillée, pas plus que le chef de projet n’a
besoin ni ne souhaite gérer le travail à ce niveau de détail.
La structure de découpage du projet (SDP) ne doit pas devenir trop grande (2.1A.5. P6)
Si vous envisagez d’élaborer la structure de découpage du projet (SDP) avec des post-it sur le mur, il
est important que vous ne devriez pas laisser la structure de découpage du projet devenir trop grande
(ou descendre à un bas niveau). En fonction de votre approche de la structure de découpage du projet,
il vous faudra un à trois niveaux pour aboutir à des livrables définis. Le principe de base est que le
nombre de niveaux pour chaque produit livrable ne devrait pas excéder cinq, et même ce chiffre
pourrait être un chiffre trop élevé. Les plus petits projets ne nécessiteront pas plus de deux ou trois
niveaux de découpage des activités pour chaque livrable. Si vous avez un projet très grand, vous aurez
parfois besoin de plus de niveaux encore. Cependant, à partir d’un certain point, le détail sera trop
complexe à gérer. Si vous constatez que vous avez besoin de définir cinq niveaux d’activités ou plus
pour un livrable, arrêtez-vous et évaluez ce que vous êtes en train de faire. D’abord, vous êtes peut-
être en train de définir le travail à un niveau trop réduit. En second lieu, vous avez peut-être défini
votre produit livrable de façon trop détaillée. Dans ce cas, voyez si un grand produit livrable ne pourrait
pas être découpé en de plus petits lots intégrés de travail. Le travail associé aux plus petits livrables ne
devrait pas exiger tant de niveaux.
Découpez les grands projets en phases et étapes (2.1A.5. P7)
Différents termes sont utilisés pour décrire les façons dont les grands projets peuvent être divisés et
subdivisés. On utilise souvent les termes phases et étapes. Il peut ne pas exister de définitions
universellement reconnues pour ces termes, mais voici leur sens courant:
 Étape: C’est le terme le plus simple. Il désigne couramment un découpage interne du travail
d’un projet. Par exemple, vous pouvez appeler « étape d’analyse » la collecte des exigences
commerciales et tout le travail qui s’y rapporte. De même, si votre projet demande la
construction d’un prototype, vous pouvez appeler cette dernière « étape du prototype ».
 Phase: Ce terme a deux significations. D'abord, le mot « phase » est souvent utilisé comme
l’équivalent exact de ce qui vient juste d’être décrit comme une « étape ». Par exemple, un
projet peut avoir une phase des exigences ou une phase prototype. Dans ce contexte, la phase
renvoie à un découpage de niveau général d'un travail interne. Si le terme « étape » est
également employé, il désigne alors la subdivision d’une phase. Par exemple, dans la phase
d’analyse, il peut y avoir l’étape des exigences et une étape de définition de la stratégie.
La deuxième utilisation du terme « phase » se rapporte à une série de projets indépendants, mais liés
entre eux. Par exemple, l’exécution d’un premier projet dont le but est de livrer des fonctionnalités de
base, peut être désignée sous le nom de « phase I ». Un projet suivant qui ajouterait plus de
fonctionnalités peut être appelé « phase II ». Enfin, la mise en œuvre de l'ensemble serait la « phase
III ». Dans tous ces cas, le mot « phase » implique que bien qu’il s’agisse de projets séparés, chacun
d’entre-deux est relié, dans une série continue, à celui qui le précède et à celui qui le suit.
Élaborez un dictionnaire de la structure de découpage de projet (SDP) pour les grands

projets (2.1A.5. P8)
Normalement, un dictionnaire n’est pas nécessaire, mais si votre SDP compte des centaines ou des
milliers d’activités détaillées, il est difficile d’en garder une trace à portée de la main. Quand la structure
de découpage du projet (SDP) est très grande, il peut être raisonnable de placer toutes les informations
importantes dans un « dictionnaire de données ». Un tel dictionnaire garde une trace de toutes les
activités - sommaires et de toutes les activités détaillées sous-jacentes, avec une courte description,
l’identifiant numérique dans la SDP (1.1, 1.1.1, 1.1.2, etc.) et l'effort de travail estimé pour chaque
activité. Une fois que vous avez saisi toutes les informations de la SDP dans un logiciel de gestion de
projet, cet outil informatique peut aussi enregistrer les modifications du travail. Vous pouvez ainsi suivre
les répercussions des changements sur la SDP et l'échéancier. Avoir la structure de découpage du
127
projet (SDP) dans un logiciel de gestion de projet facilite aussi la réutilisation des informations pour de
futurs projets.
Employez vos activités sommaires comme des jalons de l’échéancier (2.1A.5. P9)
Votre SDP contient à la fois des activités de détail et des activités - sommaires. Cependant, quand vous
établissez le diagramme de réseau dans votre échéancier, vous devriez inclure seulement les activités
détaillées, pas les activités - sommaires. Pour la clarté et la lisibilité, il est souvent nécessaire d'inclure
aussi ces activités - sommaires de niveau supérieur dans l’échéancier pour représenter une vue
d’ensemble des activités détaillées. Une activité - sommaire qui représente l'achèvement d'un livrable
important, pourrait également être incluse dans l’échéancier comme un jalon.
Découpez les activités sommaires en deux activités détaillées ou plus (2.1A.5. P10)
Puisque vous avez choisi de diviser une activité - sommaire en de plus petites activités, il n’est pas
logique d’en inscrire une seule sous une activité - sommaire. Si vous le faites, l'activité détaillée
représente exactement le même travail que l'activité récapitulative. Cela ne vous apporte rien. Si cela se
produit dans votre SDP, vous aurez le choix entre:
 diviser l’activité - sommaire en de multiples tâches plus petites
 ou vous débarrasser de l'activité détaillée et associer le travail à l’activité - sommaire, qui

devient alors une activité détaillée.
Les activités détaillées devraient être inscrites en tant qu'activités axées sur l'action (2.1A.5.
P11)
Les activités détaillées de votre SDP sont transférées dans votre échéancier. Pour cette raison, leur
transfert est plus facile si elles sont axées sur l'action, exactement comme les activités de votre
échéancier devraient l’être. Par exemple, au lieu d'énoncer une activité détaillée de SDP en tant que
"meeting", vous devriez l'énoncer en tant que « prévoir une réunion hebdomadaire ». Au lieu d'avoir
une activité détaillée pour « le plan d'essai », vous devriez l'énoncer plutôt comme " créer le plan
d'essai ". De cette façon, les activités détaillées peuvent être déplacées vers l’échéancier avec un
minimum de changements de terminologie.
Ne placez pas les exigences sur la SDP (2.1A.5. P12)
La SDP est utilisée afin de découper de plus grandes parties de travail en sections plus petites. Si vous
placez un livrable sur votre SDP, vous pouvez le découper en activités qui permettent par la suite la
création de ce livrable. Le découpage des livrables ne doit pas déboucher sur les exigences qui le
décrivent. Les exigences ne font pas partie de la SDP.
Les activités détaillées de votre SDP sont transférées dans votre échéancier. L'échéancier ne contient
pas des items tels que : « a besoin d'avoir une interface simple » ou « doit pouvoir travailler 25 pieds
sous l'eau ». Ce sont là des constats d’exigences. Les exigences appartiennent au plan de gestion des
exigences. Elles n'appartiennent ni à l’échéancier ni à la SDP.
Pour les grands projets, vous pouvez laisser votre SDP au niveau des « lots de travail »
(2.1A.5. P13)
Les très grands projets ont généralement des livrables de très grande taille. Un des moyens permettant
d'élaborer votre SDP pour ces projets, consiste à définir vos livrables puis à les diviser en composants
plus petits. Quand tous les composants sont accomplis et intégrés, le plus grand livrable sera alors créé.
Parfois, quand il s’agit de projets très grands, il n’est pas pratique de déterminer les activités -
sommaires et les activités de détail, tout simplement parce qu’il y en a un très grand nombre. Dans ces
grands projets, la SDP peut seulement être décomposée jusqu’au niveau des « lots de travail ». Le lot
128
de travail peut être assez grand pour constituer un sous-projet et quelquefois assez grand pour qu’un
compte de coût lui soit rattaché.
Dans un grand projet, vous pouvez arrêter la SDP au niveau du lot de travail. Cependant, le travail ne
devrait pas être assigné aux membres de l'équipe à ce niveau. Le lot de travail devrait être attribué à
une équipe. Le chef de l'équipe doit encore découper le lot de travail en activités permettant de réaliser
le composant de travail (ou de réaliser tout le contenu du lot de travail).
Dans ce scénario, La totalité de la SDP est ramenée vers le niveau inférieur des activités détaillées.
Cependant, cette opération se déroule en deux temps : la première itération s'arrête au niveau élevé du
lot de travail, alors que les activités détaillées sont définies quand le lot est réellement assigné à une
équipe de travail.
129
2.1A.5.1 Exemples de structures de découpage de projet (SDP)
(2.1A.5.1. P1)
Rappelez-vous que la structure de découpage du projet (SDP) est la première étape pour élaborer un
échéancier du projet. Ce n'est pas l'échéancier du projet lui-même. Il est important d’employer la SDP
pour identifier tout le travail à réaliser. Il n’est pas important, par contre, de découper le travail jusqu'à
des niveaux ou des schémas qui permettent d’ordonner les lots de travail de façon séquentielle. Cela
sera fait plus tard.
Il y a de nombreuses voies permettant d'élaborer une structure de découpage du projet. Voici quelques
exemples de la manière dont une SDP peut être structurée.
Structure générique (ou classique) de découpage de projet (SDP) (2.1A.5.1. P2)
Cet exemple montre un modèle générique de découpage d’un livrable en lots de travail, puis le
découpage des lots de travail en activités, puis des activités en tâches. Souvenez-vous que vous pouvez
d’abord découper le travail en livrables ou en d’autres catégories. Cependant, quelle que soit la manière
dont vous débutez votre niveau supérieur de la SDP, vous devez établir une transition vers
les livrables, puis vers les activités. Les activités du projet sont souvent destinées à la construction d’un
livrable; de ce fait, à un certain moment, la répartition en activités doit avoir lieu. Remarquez que le
niveau " lot de travail " et le niveau " tâche " sont tous deux facultatifs. Votre structure de découpage
du projet (SDP) peut aller du livrable aux activités et s’arrêter là.
Structure de découpage du projet (SDP) en fonction des principales phases ou étapes

(2.1A.5.1. P3)
Cet exemple montre les phases principales du projet, qui n’ont pas besoin, à ce stade, d’être classées
selon l’ordre chronologique réel de leur exécution. Déterminez simplement les principaux lots de travail,
et décomposez chacun d’entre eux en de plus petites activités. (Certains de ces encadrés seront
découpés davantage pour obtenir les activités nécessaires à la réalisation du travail).
130
Structure de découpage du projet (SDP) par ordre chronologique (2.1A.5.1. P4)
Dans cet exemple, la SDP est basée sur l’ordre chronologique dans lequel la majorité des composants
doivent être exécutés. Cette approche est plus facile à examiner dans le détail dans certains projets où
existe une relative expérience de la manière dont un ordre chronologique doit être établi.
Structure de découpage du projet (SDP) en fonction des livrables (2.1A.5.1. P5)
Déterminez d'abord tous les livrables que le projet va produire, puis découpez-les en fonction du travail
requis. Une fois de plus, ceci n’implique pas un ordre chronologique. Bon nombre de ces activités
peuvent être exécutées en parallèle.
131
132
2.1A.6 Chemin critique
Si vous utilisez un outil de gestion de projet, les activités du chemin critique sont souvent surlignées
avec une barre rouge pour mieux les distinguer.
(2.1A.6. P1)
Le chemin critique se rapporte à l'ordre chronologique des activités qui doivent être accomplies dans les
délais pour que le projet entier soit lui aussi accompli conformément à l'échéancier prévu. Si la date de
fin du projet est dépassée, c’est parce qu'il y a au moins une activité placée sur le chemin critique qui
n’a pas été accomplie à temps. Il est important de comprendre l'agencement chronologique du chemin
critique pour savoir où vous avez une marge de flexibilité dans l'échéancier et où vous n’en avez pas.
Vous pouvez avoir une série entière d'activités en retard, mais le projet global sera accompli à l'heure,
parce que les activités en retard ne sont pas sur le chemin critique. En revanche, si votre projet est en
train d'accuser un retard, placer du personnel complémentaire sur des activités qui ne sont pas dans le
chemin critique ne permettra pas de faire en sorte que le global du projet soit accompli plus tôt.
Notez que le chemin critique ne pourra être calculé que si vous avez indiqué l'ordre séquentiel de toutes
les activités dans votre échéancier. Le chemin critique est basé sur une compréhension profonde de
l'activité qui précède et de celle qui suit chaque activité. Alors, si vos activités n‘ont pas été classées par
ordre d'exécution, le chemin critique risque d’être calculé de manière erronée.
La logique du chemin critique (2.1A.6. P2)
Dans chaque projet, quelle que soit sa complexité, il y a toujours quelques activités qui peuvent
commencer plus tôt ou être accomplies plus tard, sans pour autant compromettre la date finale
d'accomplissement du projet. Cette flexibilité entre le moment le plus précoce auquel une activité PEUT
être accomplie, et l’ultime moment est appelée « la marge ». Il y a une marge similaire si l'activité
dispose d'un degré de flexibilité entre le moment le plus précoce où elle PEUT commencer et le moment
le plus reculé où elle DOIT commencer. Par définition, si une activité dispose d’une marge associée aux
dates de début et de fin, c’est qu’elle n'est pas sur le chemin critique.
Maintenant, intéressons-nous aux activités où vous ne disposez pas de flexibilité dans les dates du
début et de la fin. Ces activités ne peuvent pas être accomplies plus tôt parce qu'elles sont en attente
de l'accomplissement d'une autre activité. Elles ne peuvent également pas être accomplies plus tard,
car cela se répercuterait sur toutes les activités suivantes. Cela revient au fait qu'aucune des activités
qui suivent ne comporte une flexibilité ou une marge dans ses dates de début et de fin. Toutes ces
activités sont étroitement reliées aux autres activités qui les précèdent ou les suivent. Le chemin
critique est la plus longue séquence d’activités qui doivent être commencées et accomplies exactement
comme prévu dans l'échéancier. En d'autres termes, il s’agit de la plus longue séquence d’activités avec
une marge zéro. Si n'importe quelle activité sur le chemin critique subit un retard, le projet entier sera
retardé (à moins que ce temps puisse être récupéré ailleurs sur le chemin critique).
La date de la fin du projet est ce qu’elle est en raison du chemin critique. S'il n'y avait pas de chemin
critique, il y aurait toujours au moins une certaine marge dans toutes les activités du début à la fin du
projet. S'il y avait une marge partout, vous pourriez la réduire et mener à terme le projet plus tôt. Si
vous avancez la date de la fin, vous commencez à supprimer une partie de la marge. A un certain point,
cependant, la marge de l’un des chemins sera totalement supprimée. Ce serait une situation où chaque
activité placée sur le chemin aurait des dates de début et de fin juxtaposées. Il n'y aurait alors plus de
marge sur cette séquence d’activités et vous auriez un chemin critique.
133
Le chemin B est le chemin critique puisque toutes les activités sont juxtaposées. Il n’y a pas de temps
mort ou de marge dans la chronologie. Les autres chemins comportent tous une certaine marge, ce qui
veut dire qu’à un certain moment, ils attendront que les autres chemins arrivent à terme. Par définition,
le chemin critique ne présente aucune marge.
Imaginons, par exemple, que vous ayez un projet d’une durée de neuf mois. Votre logiciel de gestion
de l'échéancier du projet identifie le chemin critique. Supposons qu’il y ait 22 activités sur le chemin
critique, toutes ayant une durée et un effort de travail différents. On a estimé que la deuxième activité
sur le chemin critique sera accomplie en 8 jours. Pendant que le projet se poursuit, il s'avère que cette
activité demande en réalité neuf jours pour être accomplie. Vous découvrirez alors que le projet entier
prendra neuf mois et un jour. Retarder l'accomplissement de la deuxième activité d’un jour a retardé
l'échéancier du projet entier. À moins que ce jour supplémentaire puisse être compensé ailleurs et plus
tard dans le chemin critique, le projet sera accompli avec un jour de retard.
Pourquoi le chemin critique est-il important? (2.1A.6. P3)
Franchement, pour beaucoup de projets, il n'est pas nécessaire de déterminer le chemin critique. C'est
particulièrement vrai pour les petits projets. Cependant, pour les projets plus grands et plus complexes,
il est important de comprendre le chemin critique. En effet, si le projet a pris du retard et que vous
essayez d’accélérer le rythme pour être en phase avec l’échéancier, il est très important d’identifier les
activités du chemin critique. A moins que vous ne soyez en mesure d’accélérer les activités sur le
chemin critique, la date de la fin du projet entier restera la même. Affecter du personnel
supplémentaire aux activités qui ne sont pas sur le chemin critique peut permettre à ces activités d'être
accomplies plus tôt. Cependant, cela n'affectera pas la date de la fin du projet global. Votre chance
d’avoir un impact sur la date de la fin de projet repose sur votre aptitude à identifier et à raccourcir le
chemin critique.
Le chemin critique peut changer (2.1A.6. P4)
Il y a beaucoup de séquences d’activités dans un projet pour aller du début à la fin. En fait, Il peut y
avoir de multiples chemins critiques, à condition qu’aucun d’entre eux ne présente de marge et qu’ils
mènent tous à la même date de la fin. Habituellement, s'il y a des chemins critiques multiples, nombre
de leurs activités coïncident.
Étant donné qu’il peut y avoir un très grand nombre de chemins dans l'échéancier du projet, il est
possible que le chemin critique change. Prenons le même exemple que précédemment, avec 22
activités réparties sur neuf mois. Supposons qu'il y ait un autre chemin de travail qui inclut 19 activités
et nécessite 8 mois et demi. Si vous essayez de comprimer l'échéancier pour accomplir le projet en huit
mois, cela devient compliqué.
134
D'abord, vous allez vouloir vous concentrer sur la façon d’accélérer les activités dans le chemin critique
de neuf mois. Cependant, une fois que ce chemin critique est réduit à 8 mois et demi, un autre chemin
critique apparaît, qui présente la même chronologie. Comprimer encore plus le chemin critique original
ne permettra pas d’achever le projet plus tôt, parce qu’il faudra toujours 8 mois et demi pour accomplir
le deuxième chemin. Dans ce cas, les deux chemins doivent être accélérés (ou alors, certaines des
activités qui leurs sont communes doivent être accélérées).
Le chemin peut également changer si les activités qui ne sont pas sur le chemin critique prennent du
retard. Dans l'exemple ci-dessus, supposons qu’une des activités du chemin qui dure 8 mois et demi
prenne fin avec trois semaines de retard. Comme il n'y a que deux semaines de marge dans le chemin,
ce dernier deviendra alors critique et contraindra le projet entier à se terminer avec une semaine plus
tard.
Calculer le chemin critique (2.1A.6. P5)
Il y a une méthode manuelle pour calculer le chemin critique. Elle consiste à regarder les dates du
début et de la fin « au plus tôt » possibles pour chaque activité du projet, en allant du début du projet
à la fin de celui-ci. Puis vous redémarrez à rebours, de la fin du projet vers l’avant, en regardant les
dates du début et de la fin « au plus tard » possibles pour chaque activité. La différence entre la date
du début au plus tard (LS) et la date du début au plus tôt (ES) est appelée « la marge » de l’activité.
(Cette marge finira par être identique à la différence entre la date de la fin au plus tard (LF) et la date
de la fin au plus tôt (EF). Vous devez ensuite chercher, du début à la fin, la séquence des activités qui
n’a pas de marge (c'est-à-dire une marge égale à zéro). C'est là que se situe le chemin critique.
Le passage vers l’avant implique un départ de la première activité du diagramme en réseau et le calcul
de la « date de début au plus tôt » (ES) et de la « date de fin au plus tôt (EF).
135
Une fois que l’activité finale est programmée avec le calcul vers l’avant, vous commencez à partir de la
fin et travaillez en sens inverse. Le calcul vers l’arrière implique le calcul de la « date de la fin au plus
tard » (LF), et de la « date du début au plus tard » (LS), tout en terminant le projet dans les délais.
Heureusement, la plupart des logiciels de gestion de la planification de projet calculeront le chemin
critique pour vous. Tous les projets de taille moyenne ou grande devraient utiliser un logiciel de gestion
de projet pour gérer l'échéancier et le budget. Tirez profit de cette fonctionnalité automatique, si elle
existe. Pour un petit projet, il ne devrait y avoir qu'un ordre séquentiel majeur des activités qui est
facile à identifier, même si vous n’utilisez pas un logiciel de planification.
Marge libre, marge d’un chemin et marge totale (2.1A.6. P6)
Lorsque vous examinez la marge dans votre projet, vous pouvez vous trouver face à trois cas : la
marge libre, la marge d’un chemin, et la marge totale. La marge libre s’applique à des activités
individuelles. Elle se rapporte à la quantité de marge d’une activité avant qu’elle ne retarde la suivante.
Par exemple, si l'activité B peut commencer jusqu'à cinq jours après que l'activité A ait été accomplie
sans influer sur l’activité suivante, alors l’activité B présente une marge libre de cinq jours.
Il y a également le concept de marge d’un chemin, qui est similaire à la marge libre, mis à part le fait
qu’il s’applique à un chemin entier de l’échéancier du projet. La marge d’un chemin est partagée par
toutes les activités du chemin. Si une activité épuise une partie de sa marge libre, elle réduit alors
également la marge du chemin qui est disponible pour d'autres activités. Par exemple, vous avez trois
136
activités - A, B, C - chacune d'elles ayant cinq jours de marge libre. La marge du chemin, elle aussi, est
de 5 jours. Si l'activité A commence à l'heure et est accomplie à temps, alors l'activité B aura toujours
les cinq jours de la marge totale à sa disposition. Cependant, si l'activité A accuse un retard de trois
jours, elle laisse encore deux jours disponibles pour la marge du chemin. Dans un exemple extrême,
disons que l’activité A met 5 jours de plus pour s’achever. Les activités B et C ne disposeront donc plus
d’aucune marge. Souvenez-vous que la marge d’un chemin s’applique à tout le chemin. Si une activité
consomme toute la marge du chemin, il n’en restera plus pour les autres activités du chemin. Puisque la
marge a été réduite à zéro, ce chemin fait maintenant partie du chemin critique.
La marge totale exprime la somme des marges de toutes les activités sur tous les chemins. Si vous
disposez de beaucoup de marge totale, alors vous avez habituellement de nombreuses options quant à
la façon d’allouer les ressources humaines pour respecter vos dates. Vous avez également plus de
flexibilité si votre projet accuse du retard. Si la marge totale sur le projet est faible, vous aurez plus de
risques de dépassement de délais et beaucoup moins de flexibilité. Cependant, si le projet commence à
prendre du retard, vous aurez plus de difficultés à redistribuer le personnel, puisqu’un autre chemin qui
prend du retard peut rapidement se transformer en chemin critique.
137
2.1A.7 Créer le plan de management de l'échéancier
Le plan de management de l'échéancier décrit le processus qui sera utilisé pour gérer l'échéancier du
projet, y compris le suivi des activités en cours, l'identification des activités à achever,
l'accomplissement des activités par rapport aux délais établis, l'identification des retards potentiels du
projet, et l'évaluation de la performance du projet. Les composants du plan de management de
l'échéancier pourraient inclure:
 Les rôles et les responsabilités. Vous pourriez décrire les différents rôles et leur capacité
d'accéder à l'échéancier du projet.
o Le propriétaire de l'échéancier. Il s'agirait probablement du chef de projet.
o Qui peut effectuer la mise à jour de l’échéancier? Normalement, le chef de

projet. Mais pour les plus grands projets, ceci pourrait être plus compliqué. Par
exemple, un assistant du chef de projet dans le rôle de coordinateur de projet pourrait
effectuer les mises à jour initiales en se basant sur les rapports d'avancement des
équipiers et fournir un brouillon au chef de projet pour des mises à jour finales. Il est
aussi possible que les membres de l'équipe effectuent eux-mêmes la mise à jour de
l'avancement des activités qui leur ont étés assignées et que le chef de projet mette en
œuvre les analyses finales après ces mises à jour.
o Qui peut accéder à l'échéancier pour prendre connaissance de l'état

d'avancement du projet? Souvent, l'échéancier n'est pas considéré comme étant
confidentiel, et toutes les parties prenantes prises en compte pourraient le lire.
 Fréquence des mises à jour de l'échéancier. Vous devriez établir la fréquence des mises à
jour de l'échéancier. Dans plusieurs projets, la mise à jour de l'échéancier s'effectuera le matin
du premier jour de travail de la semaine. Vous devriez aussi spécifier si l'échéancier sera mis à
jour chaque semaine ou une fois par quinzaine. Suivant la taille du projet, il peut être
recommandable d'effectuer la mise à jour d’une manière hebdomadaire.
 Informations sur l'avancement des activités de l'échéancier. Ceci décrit la manière avec
laquelle l'état d’avancement des activités de l'échéancier sera transmis au chef de projet. Dans
plusieurs cas, ces informations sont transmises par l'intermédiaire du rapport d'avancement des
membres de l'équipe. Cependant, il est aussi possible que la mise à jour du progrès soit
effectuée durant les réunions de l'équipe ou par e-mail au cas par cas.
 Révision et approbation des modifications de l'échéancier. Dans ce chapitre, vous

devez définir la procédure à suivre pour évaluer et approuver des modifications de l'échéancier.
Cette partie du plan de management de l'échéancier confère l'autorité nécessaire pour accepter
et approuver des modifications de l'échéancier. Ceci ne se rapporte pas à un dépassement des
délais pour les activités détaillées de l'échéancier. Cela s'applique à un dépassement des délais
globaux du projet. Il est possible que le chef de projet ait une certaine marge d'appréciation lui
permettant de dépasser la date limite du projet de quelques jours, voire de quelques semaines.
Mais dépassant ce seuil, une autre entité devrait approuver les modifications de l'échéancier.
 Outils. Énoncez les outils prévus pour la gestion de l'échéancier du projet ainsi que les droits
d'utilisation de chaque intervenant (lire, mettre à jour, etc.).
 Rapports. Commentez ici les types et les noms des rapports que vous utiliseriez pour gérer le
projet (qui va les recevoir, la fréquence des rapports, etc.).
 Intégration de l'échéancier. Normalement, chaque projet renferme un échéancier

indépendant. Cependant, dans quelques cas, votre échéancier de base n'est que le résultat
d'autres échéanciers plus détaillés sous-jacents. Il est aussi possible que votre échéancier soit
intégré à un programme de plus haut niveau ou à l'échéancier d'un portefeuille de projets.
138
2.1A.8 Établir les révisions à l'achèvement des phases
Lors de l'achèvement d'une phase importante du projet, l'équipe devrait prendre une petite pause pour
s'assurer que le travail précédent était achevé avec succès et que, aussi bien l'équipe du projet que le
client sont prêts à passer à la phase suivante. Parfois ces critères sont appelés critères de sortie et
d'entrée, ou "révisions à l'achèvement de chaque phase". Ces points de contrôle constituent une
méthode pour évaluer l’étape accomplie du projet et si chacun est prêt à procéder à cette évaluation.
Les points de contrôle fondamentaux et les questions soulevées ont tendance à être similaires d'une
phase à une autre, et même d'un projet à un autre. Ainsi, ont-ils tendance à être de bons candidats
pour une liste de contrôle. Chaque révision finale à ce moment là à tendance à être une sorte
d'assurance qualité relative puisque les membres de l’équipe sont plus focalisés sur les processus déjà
achevés plutôt que sur la révision de livrables spécifiques. Les révisions des livrables ont du être
achevées plutôt au sein même de la phase.
L'obtention d'une approbation formelle pour procéder est importante et ce, pour plusieurs raisons.
 L'équipe a besoin de s'assurer qu'elle ne va pas trop vite. Par exemple, si vous commencez la
phase de conception sans avoir finalisé les exigences, vous seriez exposé au risque d'élaborer
une conception du livrable qui ne pourra satisfaire les besoins du client, ou bien vous risqueriez
de fournir de l'effort et de l'argent pour effectuer des travaux de reprise.
 Vous devriez vous assurer que la Direction vous appuie encore, et vous comptez donc sur un
budget et des ressources pour continuer les travaux relatifs au projet. Le fait d'établir un point
de contrôle et d'obtenir une approbation formelle pour y procéder va apporter l’assurance que
le projet est encore valide et que vous vous attendez à obtenir les ressources dont vous avez
besoin pour achever le reliquat du travail. Si vous procédez sans approbation formelle, vous
risquez d'être en train de dépenser des ressources et de fournir beaucoup d’ effort sur un
projet qui n'est plus suffisamment prioritaire pour justifier une continuation des travaux.
Le but et le format réels de la revue des points de passage sont décrits dans le lien suivant 3.1A.3.2
Jalons / Revues de points de passage.
139
2.1B Élaborer le budget / Processus
La gestion des coûts est-elle importante pour vous? (2.1B. P1)
Cette question peut sembler étrange pour entamer cette section. Mais il est vrai qu'un grand nombre de
chefs de projets - peut-être la majorité - ne sont pas considérés comme les responsables du budget.
Certaines entreprises pourront considérer cela comme une mauvaise pratique. Mais, en fait, de
nombreuses entreprises ne se préoccupent pas vraiment des budgets des projets. Il y a un certain
nombre de raisons simples à cela :
 Les budgets sont déterminés au niveau des services. De nombreuses entreprises ne

définissent pas de budget pour les projets. Ils déterminent les budgets et imputent les coûts au
niveau des services. Dans ces sociétés, la plupart des coûts du travail concernent les employés
internes. Ces employés sont inscrits au budget central de chaque service.
 Il n’y a pas de déclaration spécifique concernant le temps de travail alloué aux

activités des projets. On ne peut pas imputer les coûts de la main-d’œuvre aux différents
projets si on n’est pas en mesure de déterminer les heures d’effort fournies par chacun pour
chaque projet. De nombreuses entreprises considèrent que l'effort et les coûts associés à une
maîtrise du temps de travail de chaque personne, sont supérieurs aux avantages de ce
contrôle.
 Les systèmes financiers ne supportent pas spécifiquement la gestion des projets. De

nombreuses entreprises ne disposent pas soit d’un progiciel financier, soit d’un système de
comptabilité capable de faire le suivi des coûts au niveau des projets.
Si l’entreprise ne comptabilise pas les coûts au niveau des projets, il est peu probable que le chef de
projet soit tenu responsable de l'estimation des coûts et de la gestion du budget. Dans ce cas, les
sections de la Méthodologie TenStep consacrées à la détermination et à la maîtrise du budget, ne
seront pas utilisées.
Les coûts externes sont-ils importants pour vous? (2.1B. P2)
Dans certaines entreprises, le chef de projet n'est tenu responsable que pour les coûts externes, et non
pour les coûts internes. Dans ce cas, les coûts de la main-d’œuvre interne ne sont pas considérés au
niveau des projets ; le chef de projet ne s’occupe que de l’estimation et de la maîtrise des coûts de la
main-d’œuvre et d’autres coûts des fournisseurs externes.
Le reste de cette section provient du principe que vous êtes un chef de projet responsable de la gestion
du budget.
La section suivante décrit le processus d'élaboration du budget du projet.
Petits projets (2.1B. P3)
Un petit projet n’a généralement pas un gros budget. Le budget peut être simplement une question de
multiplier les heures d’effort estimées par les coûts des ressources par heure. Les coûts non salariaux
sont généralement aussi petits et faciles à expliquer. Il n’y aura probablement pas de coûts de
formation ou de développement de l’équipe. Dans l’éventualité où vous aviez un petit projet avec un
budget important, vous pouvez suivre le processus d'élaboration d'un budget pour les projets de taille
moyenne et les grands projets.
Moyens et grands projets (2.1B. P4)
Rôle Élaborer le budget à partir de zéro
140
1 Le chef de Créez un plan de management des coûts
projet Ce document définit et communique la manière avec laquelle le budget sera
maintenu pendant le projet. Il fait partie du plan de management de projet. Voir
2.1B.3 Créer le plan de management des coûts pour plus de détails.
Estimer les coûts (2.1B. P5)
2 Le chef de Estimez les coûts du projet

projet Le budget comporte deux principales composantes: les coûts de la main-d’œuvre
et les coûts non salariaux. Après avoir terminé l’ébauche de l’échéancier du projet,
on comprendra mieux les besoins en main-d’œuvre pour réaliser les travaux. Cela
vous fournira l’information nécessaire pour continuer à développer le budget
prévisionnel initial. Les coûts de la main-d’œuvre peuvent être estimés sur la base
des ressources (ou types de ressources) spécifiées dans l’échéancier.
Par la suite, vous pouvez estimer les coûts non salariaux, y compris les frais de
déplacement, de formation, de matériel, de logiciels, d’autres fournitures, etc.
Vous pourriez avoir estimé plus tôt une bonne partie des coûts non salariaux, mais
c’est maintenant que vous pourrez regrouper l’ensemble des coûts de la main-
d’œuvre et les coûts non salariaux. Vous pouvez utiliser les techniques d'estimation
expliquées dans les sections 2.1A.1 Estimer l'effort et la durée et 2.2A.1
Techniques d'estimation de l’échéancier et du budget.
Il est probable que vous vouliez organiser l'estimation des coûts du projet en
éléments structurés aux fins de suivi. Voir la section 2.1B.2 Comptes de contrôle
pour plus de renseignements.
Déterminer de budget (2.1B. P6)
3 Le chef de Réexaminez l’estimation des coûts pour vérifier qu’elle est cohérente
projet Vous devez vous sentir à l’aise pour défendre les estimations des coûts auprès de
votre supérieur et de votre commanditaire. Si vous considérez que le budget ne
reflète pas vos besoins, effectuez les changements nécessaires.
Vous devez vous assurer que l'estimation de la durée du projet soit dans les 15%
avant le démarrage du projet.
L'essentiel est que lorsque vous donnez votre estimation du budget, le moins que
les autres puissent faire est d’interroger vos chiffres. Si vous n’êtes pas assez à
l’aise pour leur répondre, c’est qu’il vous reste du travail à accomplir. En d'autres
termes, si vous ne pouvez pas défendre les chiffres que vous avancez, vous devez
passer plus de temps à essayer d’élaborer une estimation dont vous êtes sûr.
4 Le chef de Finalisez le budget et l’allouer

projet Une fois que vous avez élaboré l'échéancier et que vous avez estimé le coût total
de votre projet, vous pouvez établir son budget. Pour certains projets, le budget
sera global. Dans le cas des grands projets, vous pouvez établir des comptes de
coûts pour chaque lot de travail ou pour des groupes de lots de travail.
5 Le chef de Déterminez le rythme des dépenses

projet Le chef de projet doit maîtriser les dépenses réelles du projet par rapport aux
dépenses budgétées. Pour cela, il ne suffit pas simplement d’affirmer que le projet
est à moitié écoulé et que le budget est à moitié dépensé, et de croire ainsi que
tout est conforme. Ces renseignements ne sont pas suffisants pour maîtriser les
coûts.
141
Pour mettre en œuvre la maîtrise des coûts du projet par rapport au budget, le
chef de projet doit comprendre le rythme des dépenses du projet et la charge de
travail accomplie en contrepartie du budget dépensé. Par conséquent, lorsque les
budgets sont établis, le chef de projet doit lier les dépenses aux activités de
l’échéancier - soit par activité, par livrable ou par phase. Ces liens entre les
dépenses et les activités de l’échéancier permettront au chef de projet de maîtriser
les coûts lors de l’exécution du projet.
6 Le chef de Déterminez le rythme de la mise à disposition des fonds du budget

projet, Lorsque vous démarrez le projet, il est possible que l'ensemble du budget soit mis
direction à votre disposition pour dépenser au besoin. Toutefois, si le projet s’échelonne sur
financière une certaine période de temps, il est plus probable que le budget soit mis à
disposition par tranches.
Cela serait logique pour un grand projet. Disons que votre projet a une durée
estimée de trois ans. Votre entreprise ne livrera probablement pas en une seule
fois les fonds de financement pour les trois années et ne les laissera pas
immobilisés en attente que le projet les utilise éventuellement. Il est plus probable
que le budget pour la première année soit mis à disposition au démarrage du
projet. Le budget pour la deuxième année sera peut-être disponible au début de
cette période, de même que le budget pour la troisième année.
Il est également possible que le financement de la phase suivante ne soit libéré
qu’à la fin de la phase précédente.
Libérer les fonds par tranches vise deux objectifs principaux :
1. Permet à l'entreprise d’optimiser les flux de trésorerie.
2. Fournit des points de contrôle pour s'assurer que le projet se trouve sur la
bonne voie et progresse comme prévu avant que le financement suivant
ne soit libéré.
Si vous expérimentez ce type de situations, les procédures de libération budgétaire
doivent être établies lors de la création du budget.
142
2.1B.1 Estimer les coûts
Maintenant que vous avez estimé l’effort et la durée du projet, vous êtes en mesure d'estimer les coûts.
Vous pouvez effectivement estimer plut tôt un bon nombre des coûts non salariaux, mais vous n’êtes
pas en mesure d’estimer les coûts de la main-d’œuvre jusqu'à ce que vous puissiez évaluer la main-
d’œuvre nécessaire pour atteindre les estimations de la durée.
Rôle Estimer les coûts
1 Chef de Estimer les coûts de la main-d’œuvre.

projet Le coût de la main-d’œuvre découle, pour chaque personne, du nombre d’heures
de travail multiplié par le coût horaire. Dans de nombreuses entreprises, le coût de
la main-d’œuvre des employés internes est considéré comme nul, puisque son coût
est déjà compris dans le budget du service. Cela ne signifie pas que cette main-
d’œuvre n’occasionne aucun coût, mais suppose plutôt qu’il n’y a aucun
accroissement par rapport à ce que l’entreprise paye déjà.
Si vous calculez un coût horaire moyen par employé, ce chiffre pourrait inclure ou
non les avantages sociaux. Dans certaines entreprises, les avantages sociaux des
employés sont ajoutés à l’estimation totale du projet. Pour d’autres, ces coûts ne
sont pas pris en considération. Si vous incluez le coût des avantages sociaux, il est
habituellement calculé sur la base d'un pourcentage. Vous pouvez utiliser un
pourcentage fixe des coûts horaires.
Si vous avez recours à du personnel contractuel externe ou à des consultants,
leurs coûts doivent toujours être estimés et budgétés. Vous devez déterminer de
quel type de ressources humaines externes vous avez besoin ainsi que le taux
horaire qui leur est appliqué, puis multiplier le taux horaire de chaque personne
par le nombre d’heures où chacune d'entre elles sera assignée au projet. Si vous
n’êtes pas certain du coût réel de ces ressources humaines, vous devez émettre
quelques hypothèses en vous basant sur le type général de ces ressources. Par
exemple, vous pouvez vous baser sur le coût horaire standard d’un comptable ou
d’un programmeur contractuel. Si vous n’êtes pas sûr que votre projet fera appel à
la participation de ressources externes, vous pouvez émettre des hypothèses
élémentaires concernant le personnel et les consigner sous le nom d'hypothèses.
2 Chef de Estimer les coûts non salariaux

projet Les dépenses qui ne sont pas liées à la main-d’œuvre comprennent tous les coûts
qui ne se rapportent pas directement aux salaires et à la rémunération des
contractuels. Certains de ces coûts, comme les dépenses de formation ou de
constitution de l’équipe, concernent des personnes. Cependant, ils sont tout de
même considérés comme des coûts non salariaux puisqu’ils ne concernent pas les
salaires et les heures de travail contractuels. Notez également que dans certaines
compagnies, les coûts de la main-d’œuvre incluent seulement les employés et non
les coûts liés aux contractuels. Chaque chef de projet doit être conscient des règles
de comptabilité de sa compagnie pour s’assurer que les coûts de la main-d’œuvre
et les coûts non salariaux soient répartis correctement.
Les coûts non salariaux comprennent généralement:
 L’équipement informatique et les logiciels
 Les frais de déplacement
 La formation
 La constitution de l'équipe
 D’autres équipements
 D’autres fournitures et matériel
143
3 Chef de Documentez toutes les hypothèses
projet Vous ne pourrez jamais connaître tous les détails d’un projet. Par conséquent, il
est important de documenter chacune des hypothèses que vous émettez tout au
long de l’estimation.
144
2.1B.2 Comptes de contrôle
(2.1B.2. P1)
De nombreux projets disposent d’un budget global qui inclut tous les coûts de la main-d’œuvre du
projet, les coûts du hardware et des logiciels, les coûts du matériel, etc. Cela convient aux projets de
petite et de moyenne tailles. Cependant, plus un projet est important, plus il est utile de diviser le
budget global en sous-ensembles plus petits. Cela ressemble au concept de répartition d’un projet de
longue durée sur des projets de moindre importance. La répartition de votre budget en enveloppes
budgétaires plus réduites vous permet de mieux contrôler les détails et de mettre en évidence les
problèmes éventuels du budget, plus rapidement qu'avec un budget consolidé unique rassemblant tous
les coûts.
Des comptes de contrôle sont utilisés pour répartir le budget en plusieurs montants inférieurs. Ils sont
établis formellement dans le grand livre de la comptabilité de votre organisation afin que votre budget
soit réparti sur des comptes de coûts détaillés. Les dépenses réelles du projet sont également reportées
à ce niveau.
Les comptes de contrôle peuvent être établis de deux manières. La première consiste à diviser les
différents types de coûts en budgets séparés. Avec cette approche, vous pourriez avoir un compte de
contrôle pour les coûts de la main-d’œuvre interne, un autre pour les coûts de la main-d’œuvre
externe, ou encore pour les coûts du hardware, du software, de la formation, de déplacement, etc.
L’autre manière d’établir les comptes de contrôle consiste à se baser sur la structure de découpage du
projet. Après avoir terminé la SDP, vous pouvez créer des comptes de contrôle pour chaque groupe
d'activités reliées entre elles. Théoriquement, vous pouvez établir un compte pour chaque activité, mais
cela n’est pas très pratique. Établissez plutôt un compte de contrôle et un budget séparés pour chaque
phase, chaque étape ou chaque jalon de l’échéancier. (Un jalon de l'échéancier représente
l’achèvement d’un ou de plusieurs livrables.)
Si vous établissez des comptes de contrôle pour des ensembles de travaux reliés de la SDP, vous
disposez de plusieurs options pour assurer le suivi de votre budget. Vous pouvez suivre uniquement les
coûts de la main-d’œuvre (interne et externe). Une autre option consiste à se conformer à tous les
coûts de la main-d’œuvre et aux coûts non salariaux associés à l’élaboration d’un livrable. Les différents
types de coûts peuvent être suivis à l'aide des chiffres de sous-comptes appartenant au compte de
contrôle en question. Bien entendu, plus vos comptes sont détaillés, plus vous aurez de travail à
accomplir pour allouer et assurer le suivi des budgets de comptes de contrôle. Cependant, si votre
projet est très grand et particulièrement coûteux, vous devriez vous inspirer de cette technique. Dans
les très grands projets, les budgets de comptes de contrôle individuels peuvent être plus importants
que les budgets de projets au sein de certaines entreprises.
Voici des exemples de comptes de contrôle (2.1B.2. P2)
Cette section fournit des exemples d’utilisation de comptes de contrôle afin d'isoler et de catégoriser les
différents coûts du projet.
Type Exemples pour découper un budget de 500.000 €

Simple Un budget, la totalité des 500.000 € sur un seul
compte.
Répartition des coûts de la main-d’œuvre et des 1000 Main-d’œuvre 325.000 €
coûts non salariaux 9000 Coûts non salariaux 175.000 €
Différenciation des coûts de la main-d’œuvre 1100 Main-d’œuvre interne 200.000 €
1200 Main-d’œuvre externe 125.000 €
9000 Coûts non salariaux 175.000 €
145
Différenciation des coûts de la main-d’œuvre et des 1100 Main-d’œuvre interne 200.000 €
coûts non salariaux 1200 Main-d’œuvre externe 125.000 €
9010 Fournitures 5.000 €
9020 Matériel 45.000 €
9030 Logiciels 75.000 €
9040 Formation 25.000 €
9050 Frais de déplacement 25.000 €
Différenciation des coûts de capital Investissements
1200 Main-d’œuvre externe 125.000 €
9020 Matériel 45.000 €
9030 Logiciels 75.000 €
Dépenses
1100 Main-d’œuvre interne 200.000 €
9010 Fournitures 5.000 €
9040 Formation 25.000 €
9050 Frais de déplacement 25.000 €
Allouer les coûts par phases du projet 122-5005 Recherche 25.000 €

Supposons que le code du projet soit le chiffre 122. 122-5010 Analyse 50.000 €
Les coûts sont répartis entre les phases du projet. 122-5015 Développement 300.000 €
Au sein de chaque phase du projet, le budget peut
122-5020 Preuves alfa et beta 100.000 €
être alloué par type de coûts, investissements /
dépenses, etc. Par exemple, 122-5005-1200 122-5025 Lancement 25.000 €
correspondrait à « sous-traitance » dans la phase
de recherche du projet 122.
146
2.1B.3 Créer le plan de management des coûts
Le plan de management des coûts décrit le processus qui sera utilisé pour gérer le budget, y compris le
suivi des dépenses actuelles, des dépenses imminentes, l'identification des dépassements potentiels du
budget et l'évaluation de l'ensemble du projet par rapport au budget. Les composants du plan de
management des coûts comprennent:
 Les rôles et les responsabilités. Vous pourriez décrire les différents rôles et leur capacité
d'accéder à l'échéancier du projet.
o Le responsable du budget. Il s'agirait probablement du chef de projet.
o Qui peut approuver les dépenses? Ce point est important à identifier d'avance. Il
est possible que seul le chef de projet puisse approuver des dépenses du projet, mais
dans certains cas, cela peut être délégué à quelqu'un qui a une relation plus étroite
avec la dépense. Par exemple, si vous avez des entrepreneurs qui travaillent au sein
des équipes du projet, il est possible que le chef d'équipe soit autorisé à approuver le
pointage pour ces entrepreneurs.
o Qui peut y accéder? Les montants du budget peuvent être ou ne pas être des
informations délicates. Vous devez décider qui peut avoir accès aux dépenses réelles et
données budgétaires.
 Fréquence. Vous devez décrire le timing de l'analyse budgétaire. Sur de nombreux projets,
cela peut être mensuel puisque c'est la fréquence à laquelle la plupart des rapports grands-
livres sont disponibles. Sur certains projets, les dépenses peuvent nécessiter des suivis
hebdomadaires, même s'il s'agit d'un processus manuel.
 Retour d'information. Ceci décrit la façon dont les évaluations du budget seront livrées. Cela
va probablement être des rapports automatiques à partir du système grand-livre ou d'un
processus de suivi manuel, ou les deux à la fois.
 Examen du changement du budget et approbation. C'est là que vous définissez les

processus requis pour évaluer et approuver les modifications budgétaires proposées. Il définit
l'autorité pour accepter et approuver les modifications du budget. Ce processus d'approbation
ne comprend pas les éléments de dépenses internes. L'examen du changement du budget est
appliqué à des changements dans le budget global du projet. Il est possible que le chef de
projet puisse avoir une certaine liberté pour dépasser le budget d'un certain pourcentage, mais
dépassé ce seuil, une autorité formelle pourrait avoir besoin d'approuver le changement.
 Outils. Décrire tout outil de budgétisation qui sera utilisé sur ce projet, qui aura accès à l'outil
et qui sont les gens qui peuvent manipuler l'outil (accéder au budget, mettre à jour les
montants, etc.).
 Rapports. Vous pouvez commenter ici les types et les noms des rapports que vous utilisez
pour gérer le budget, qui va les recevoir, la fréquence, etc.
 L'intégration du budget. Normalement, chaque projet maintient un budget indépendant,

mais dans certains cas, votre budget global est le résultat d'un regroupement d'autres budgets
sous-jacents. Il est également possible que votre budget pourrait être intégré et regroupé dans
un programme de budget de plus haut niveau ou de portefeuille.
147
2.2A Élaborer l’échéancier / Techniques
Employez des échéanciers antérieurs similaires et des modèles d'échéancier pré- définis
(2.2A. P1)
Une technique de structure de découpage du projet (SDP) peut toujours être utilisée pour créer un
échéancier à partir de rien. Cependant, cette technique n’est pas toujours la plus efficace pour élaborer
l'échéancier du projet. La meilleure manière de le faire est de réutiliser un bon plan qui a été créé
précédemment. Si un projet similaire a été accompli dans le passé, commencez par utiliser son
échéancier comme base, et modifiez-le en conséquence. Cela vous épargnera tout le travail associé à la
« découverte » de la manière dont le travail devrait être effectué. Cela est particulièrement valable si le
chef du projet précédent gardait l'échéancier du projet à jour. Vous disposerez alors de l'échéancier du
projet réel qui a été employé pour réaliser le projet similaire.
Si vous ne disposez pas de l’échéancier d’un projet similaire, il se peut que votre entreprise emploie des
modèles préétablis d'échéanciers pour des projets ayant certaines caractéristiques. Par exemple, votre
entreprise pourrait avoir une méthodologie du cycle de vie comportant des modèles préétablis pour la
mise en œuvre d’une promotion de point de vente, d'une solution Internet ou de la fabrication d'un
produit commun. Dans ce cas, vérifiez que l’approche que vous employez pour votre projet correspond
à un de ces modèles. Si oui, il peut être employé comme point de départ.
Faites attention cependant. Les modèles préconstruits d’une méthodologie tendent à être relativement
grands et compliqués parce que le fournisseur désire qu’ils soient applicables à tous les projets ayant
des caractéristiques données. Par conséquent, après avoir vérifié que le modèle d'échéancier du projet
lui convient, le chef de projet doit encore évaluer les activités du modèle et déterminer lesquelles sont
applicables à son propre projet et ne laisser que celles-ci dans l'échéancier du projet. Celles qui ne sont
pas nécessaires doivent être retirées.
Désignez toujours une personne comme responsable principal du travail (2.2A. P2)
Une erreur courante consiste à charger deux personnes ou plus d’une activité, sans indiquer qui a la
responsabilité principale de garantir que le travail soit réalisé de manière correcte et complète.
L'absence d'un responsable principal entraîne des situations où les gens comptent les uns sur les
autres. Cela finit par provoquer un retard pour des activités qui doivent commencer rapidement. Vous
irez aussi au devant d'un problème si plusieurs personnes oublient des parties du travail qu’ils sont
tenus d’exécuter, car chacun d’eux croit que c’est quelqu’un d’autre l’a fait, alors que personne ne s’en
est occupé. Si une activité est dévolue à une seule personne, on sait clairement qui est responsable.
Mais si deux personnes ou plus sont chargées de la même besogne, assurez-vous que l’une d’entre
elles est désignée en tant que responsable principal de la coordination du travail, pour garantir que ce
travail soit réalisé correctement et entièrement, tout en respectant les critères de qualité, les
estimations de l'effort de travail et les délais.
Affectez d’abord des groupes génériques de personnel, puis des personnels spécifiques
(2.2A. P3)
Souvent, vous ne savez pas encore précisément quels membres du personnel seront affectés à votre
équipe, alors que vous êtes déjà en train de développer l'échéancier du projet. Ceci est souvent le cas
pour le personnel dont vous avez besoin dans un futur lointain. Dans ce cas, employez une
dénomination générique à leur place dans l'échéancier du projet. Par exemple, vous pouvez avoir
besoin d’un modélisateur de données trois mois après le début du projet. Dans l'échéancier du projet,
remplacez cette personne par un nom générique, par exemple « modélisateur de données # 1 ». Puis,
au fur et à mesure que vous vous approchez de la date à laquelle vous aurez besoin de lui, vous pouvez
mettre à jour l'échéancier du projet avec le nom exact de la personne qui effectuera le travail. Si vous
estimez le travail en vous basant sur un rôle générique, cela se révélera correct, indépendamment de la
personne qui est réellement chargée de l’effectuer.
148
Employez, si possible, du personnel à temps plein (2.2A. P4)
Dans beaucoup de cas, une équipe de projet se compose de personnel à plein temps et de personnel à
temps partiel. En général, cela dépend de la taille de l’entreprise, de la taille du projet, des ressources
humaines disponibles et de la manière dont le service du personnel est organisé. Cependant, si vous en
avez les moyens, votre premier choix devrait toujours être celui d’utiliser du personnel à temps plein
pour votre projet.
Par exemple, et en poussant à l’extrême, vous obtiendrez beaucoup plus d’une personne à temps plein
que de cinq personnes employées chacune à 20%. Les personnes travaillant à temps partiel sont
soumises à des charges de travail concurrentes, des priorités concurrentes, et aussi à des managers en
situation de concurrence. C’est particulièrement le cas quand le personnel à temps partiel du projet doit
partager son temps entre le projet en question et des travaux de maintenance ou de soutien, puisque
ces tâches ont normalement la priorité sur les activités du projet. En outre, dans de nombreux cas, ces
personnes ne sont pas toujours capables de répartir efficacement leur temps entre les différents
projets, ce qui requiert une plus grande attention de la part du chef de projet. Finalement, il y a une
perte de productivité à devoir passer d’un type de travail à un autre. Le membre de l’équipe doit
interrompre son travail en cours et se précipiter vers la nouvelle affectation. S’il y a trois séries de
priorités, il y aura souvent beaucoup de gesticulation, mais peu de travail productif sera effectué.
Recueillez plus de feedback si le chef de projet ne connaît pas tous les détails de la question
(2.2A. P5)
Le chef de projet est la personne qui a la responsabilité d'exécuter le projet avec succès. C’est la
personne qui doit créer l'échéancier du projet et y croire. Cependant, si l'échéancier du projet initial est
réalisé par une autre personne que le chef de projet, l'échéancier doit être examiné et, si nécessaire,
modifié par le chef de projet, afin de s’assurer qu’il accepte les délais, le budget et les livrables à
produire. Autrement, il serait trop facile pour le chef de projet de fuir ses responsabilités en disant qu’il
ne peut être tenu pour responsable d’un échéancier qu’il n’a pas élaboré.
Cela dit, le chef de projet ne dispose habituellement pas de l’expertise suffisante pour élaborer
entièrement l'échéancier par ses propres moyens. Il existe deux techniques principales pour recueillir
toutes les informations nécessaires pour mettre au point l'échéancier du projet.
 Esquissez une ébauche et diffusez-la auprès des parties prenantes. Dans cette
approche, le chef de projet produit une première ébauche de l'échéancier du projet. Un sous-
ensemble de membres de l’équipe peut être également impliqué. Quand l’ébauche est prête,
elle est distribuée aux parties prenantes pour qu’elles expriment leur avis en retour. Pendant le
processus de révision, des activités sont ajoutées, modifiées ou supprimées. Le chef de projet
prend en compte la réaction en retour des parties prenantes et l’intègre dans l'échéancier du
projet, qui est alors utilisé pour faire avancer le projet. Cette approche permet d’obtenir des
échéanciers bien développés et offre l’opportunité de profiter du feedback provenant des
parties prenantes et d’y puiser des idées. Il y a deux risques potentiels dans cette approche.
D’abord, les parties prenantes peuvent ne pas être encore entièrement engagées dans le
projet. Ceci peut avoir comme conséquence un manque de concentration sur l'échéancier du
projet. En second lieu, si l'échéancier du projet est long et détaillé, la plupart des parties
prenantes ne pourront probablement pas le comprendre. Dans ce cas, l'échéancier du projet
devra être distribué sans trop de détails; peut-être devrait-il comporter seulement les activités
présentées d’une façon sommaire ou seulement les jalons.
 Établissez la structure de découpage du projet (SDP) et l'échéancier du projet en

impliquant directement les parties prenantes. Dans cette approche, l'échéancier du
projet est élaboré en une ou plusieurs sessions avec les principales parties prenantes. Il doit
être possible de réunir toutes les parties prenantes pendant une session d’un ou plusieurs jours
afin d’obtenir un consensus sur ce qui doit être fait. Si le projet est grand, vous pouvez être
amené à rencontrer les parties prenantes principales par groupes. Par exemple, vous pouvez
avoir facilement des sessions avec chacun des services fonctionnels. Chaque service a une
manière spécifique de voir le projet, mais un échéancier du projet complet peut être produit en
prenant en compte les résultats des diverses sessions. Cette approche a l’avantage de susciter
149
une participation active de la part des parties prenantes. Elles devraient alors avoir une idée
complète du travail qui doit être fait, ainsi que du rôle qui leur est dévolu. Cette technique
pourrait prendre plus ou moins de temps, selon le nombre de sessions qui doivent être
organisées, et selon le temps mis pour renvoyer les résultats à ceux qui ont participé à la
session, pour validation.
Même si votre supérieur hiérarchique ou le commanditaire vous a donné une date de fin bien
déterminée, il est important que vous établissiez, dans un premier temps, l'échéancier attentivement
comme si vous n'aviez aucune idée sur la date de fin. Si vous faites cela au début, cela va vous
sensibiliser sur la possibilité d'atteindre la date déterminée. Par exemple, supposons que vous avez un
projet qui doit être achevé dans neuf mois. Si vous créez d'abord un échéancier “normal” qui vous
montre que le projet sera achevé dans 9 ½ mois, cela ne nécessite pas de s'investir outre mesure pour
deviner que vous êtes capable d'achever le travail en neuf mois. Cependant, si vous créez un
échéancier “normal” et que ce dernier vous montre que la date de fin va être à 13 mois d'aujourd'hui,
vous allez comprendre la difficulté et le risque qui pourrait résulter du fait d'essayer d'achever tout le
travail dans un lapse de temps de 9 mois. Ceci ne veut pas dire que vous n'allez pas disposer du délai
des neufs mois. Cependant, le fait d'avoir une discussion basée sur les faits vous offre plus
d'informations sur les risques du projet et les options qui vous sont disponibles.
Prendre en compte les dates de fin prédéterminées (2.2A. P6)
Dans un monde parfait, les dates d’accomplissement des projets seraient fixées sur la base de l'effort
de travail à fournir et du nombre des ressources humaines disponibles. Comme vous le savez, ce n’est
pas toujours le cas. Parfois il y a une date, qu'elle soit arbitraire ou justifiée, à laquelle les travaux
doivent être terminés. Par exemple, la date de la fin peut être déterminée par un décret émanant du
gouvernement ou par un événement programmé; elle peut également coïncider avec une autre
initiative de l'entreprise. Cette situation est désignée sous le nom de « contrainte de temps», ce qui
signifie qu'il y a une durée de temps fixée pour que le travail soit effectué et que la date de la fin est
"emballée".
Il n’y a aucun mal à avoir des dates de fin fixées. Cela donne un sens à la valeur commerciale du projet
et permet à chaque membre du groupe de ressentir l’urgence et de se concentrer. Il peut y avoir un
problème, cependant, si le chef de projet et l’équipe ne pensent pas qu’ils pourront effectuer le travail
avant la date limite. Dans ce cas, le chef de projet doit signaler la survenue d’un problème majeur. Voici
quelques façons de résoudre cette difficulté:
 Affecter plus de personnel au projet. Bien que chaque personne supplémentaire soit susceptible
de faire baisser le profit, c’est habituellement la première chose à faire.
 Faire faire à l’équipe des heures supplémentaires, tout en gardant à l’esprit que chaque
heure fait baisser le bénéfice et que ces heures supplémentaires, à long terme, peuvent
réellement avoir un effet négatif .
 Travailler avec les clients pour réduire les livrables requis à la date limite. Ceci peut impliquer
de supprimer des livrables entiers ou certaines de leurs fonctionnalités.
 Déterminer si certains livrables et dispositifs peuvent être livrés plus tard que la date prévue.
Dans ce cas, la solution sera par exemple prête à 90% à la date prévue, et le travail
complémentaire sera accompli peu après.
Utilisez, si possible, plusieurs techniques d’estimation (2.2A. P7)
Une partie importante de l'élaboration de l'échéancier du projet est l’estimation précise des activités de
travail. L’estimation de l'effort de travail conduira, à son tour, à l’estimation du coût et de la durée.
Plusieurs techniques peuvent être utiliser pour estimer le travail. Si c'est possible essayez d'utiliser deux
techniques ou plus pour l'estimation. Si les estimations provenant de plusieurs techniques sont proches,
vous aurez plus de confiance dans vos chiffres. Si les estimations sont très différentes, vous pouvez
examiner les raisons et déterminer si une technique pourrait être plus précise qu'une autre. Bien que le
processus d’estimation soit complexe, quelques techniques ainsi que des définitions sont fournies au
paragraphe 2.2.1 Techniques d'estimation.
150
Consacrez du temps au début pour en gagner plus tard (2.2A. P8)
Ne vous semble-t-il pas que la plupart des problèmes rencontrés lors d’un projet tendent à apparaître
vers la fin de celui-ci, lors des processus de construction et de tests ? En fait, certains chefs de projet
accélèrent les phases de planification, d’analyse et de conception, en pensant qu’ils vont déceler toutes
les erreurs lors du processus de tests.
Malheureusement, plus les erreurs sont décelées tard, plus leur rectification s’avère longue et couteuse
. Quand vous élaborez votre échéancier du projet, essayez de consacrer plus de temps à la préparation
et à la planification préalables du travail. Cela vous fera gagner du temps et réduira les coûts du projet
global. Par exemple, passer davantage de temps à planifier au départ, vous fera gagner du temps lors
de la phase d’analyse. Passer plus de temps sur l’analyse facilitera le travail de conception. Passer plus
de temps sur l'examen des livrables vous permettra de déceler des erreurs plus tôt et vous fera gagner
du temps lors des tests. Et des essais complets vous feront gagner du temps lors de la mise en œuvre
de la solution et dans le travail de support. Bien sûr, il n’est nul besoin de sur-planifier, ou de sur-
analyser, cela ne vous apportera rien. Mais soyez vigilent au cours de ce travail préliminaire. Ne le
bâclez pas. Le temps et la volonté investis au début seront largement récompensés tout au long du
cycle de vie du projet.
Élaborez un échéancier à court terme, pour guider les processus de définition et de

planification (2.2A. P9)
Le processus de définition du travail (Processus 1) et de création de l'échéancier et du budget pourrait

prendre beaucoup de temps et se révéler très compliqué. Cependant, le travail ne doit pas rester
désorganisé, pour les mêmes raisons qui font que vous êtes en train d’élaborer l’échéancier du projet
pour commencer le travail. Immédiatement après avoir été désigné, le chef de projet devrait établir un
échéancier à court terme pour planifier et guider les activités initiales. Cet échéancier initial couvrira la
durée de réalisation nécessaire pour définir le travail et le planifier (Processus 1 et 2). S’il s’agit d’un
processus de deux semaines, le chef de projet doit élaborer un échéancier provisoire d’au moins deux
semaines, voire trois. Si le temps pour définir et planifier le travail est de quatre semaines, cet
échéancier initial devrait couvrir au moins quatre, voire cinq ou six semaines. L'échéancier préliminaire
doit couvrir toute l’organisation et la planification des activités préliminaires, jusqu’à ce que l'échéancier
du projet formel du projet soit réalisé pour guider le reste du projet. Cet échéancier préliminaire doit
couvrir toutes les activités d'organisation et de planification préalables, jusqu'au moment où
l'échéancier formel du projet sera achevé et permettra de conduire le reste du projet.
Cet échéancier préliminaire devrait être prédéfini à un niveau organisationnel tel que tous les projets
utilisent le même processus pour définir et planifier le travail.
Déterminez si vous allez saisir les heures de travail effectif (2.2A. P10)
Une décision doit être prise très tôt concernant la saisie des heures de travail effectif dans l'échéancier
du projet. Par exemple, disons que vous estimez qu'une activité nécessite 40 heures d'effort sur une
durée de dix jours, il est facile de savoir quand l’activité sera terminée, pour comparer la durée estimée
avec la durée effective. Cependant, allez-vous garder une trace pour savoir si l'effort a été réellement
de 40 heures ? Saisir les heures de travail effectif requiert beaucoup plus de minutie de la part de
l’équipe de projet, pour garder trace du temps passé sur chaque activité et le rapporter en détail. La
saisie des heures de travail effectives est d'une grande valeur : elle permet, par exemple, de faire des
estimations plus précises pour les projets à venir. Cependant, de nombreuses organisations ne
procèdent pas à cette saisie. Si votre organisation ne saisit pas les heures de travail effectif, il sera
difficile pour le chef de projet d’imposer une telle discipline dans un projet spécifique. Collecter les
heures réelles d'effort est souvent requis (ou ne l’est pas) à l'échelle de l'organisation.
Évitez les temps morts dans l'échéancier du projet (2.2A. P11)
Le chemin de l’échéancier qui ne dispose d’aucune marge s’appelle le chemin critique; c’est lui qui
détermine la date de fin du projet. Par contre, les chemins non critiques disposent toujours d’une
marge pour commencer et pour terminer les activités. L’arrêt des travaux durant l’utilisation des marges
151
ne doit pas être obligatoirement un facteur contraignant. Toutefois, trop de marge sur un grand
nombre de chemins de l’échéancier peut s’avérer problématique dans des situations telles les suivantes
:
 De nombreuses personnes arrivent dans le projet et en partent, ce qui peut poser des
problèmes potentiels : il est difficile de s’assurer que tout le monde est disponible au moment
opportun et pour la durée nécessaire.
 Pareillement, si vous utilisez les mêmes personnes en dehors du chemin critique, vous risquez
de vous mêler de travail qui n’a rien à voir avec le projet, lorsque ces personnes n’ont pas de
tâches assignées dans le projet. Vous devriez leur allouer un travail, dans le projet, équivalent à
quelques semaines, puis leur trouver d’autres tâches pendant les temps morts, mais assurez-
vous qu’elles seront disponibles lorsqu’elles devront effectuer plus de travail lié au projet.
 On peut noter habituellement un manque de vigilance de la part de tout le personnel qui n’est
pas sur le chemin critique. Cela est du au fait que vous avez une ou plus d’une personne qui
travaillent dur sur les activités du chemin critique et ses dates limites, alors que d’autres ont
beaucoup de temps mort dans leur programme. Cela peut être démotivant pour les personnes
assignées au chemin critique.
Attention : trop peu de relâchement dans l’échéancier peut nuire (2.2A. P12)
De même qu’il y a un risque quand il y a trop de relâchement, un autre associé au fait qu’il n’y ait pas
assez de relâchement. Si cela arrive, des dérapages mineurs par rapport à l'échéancier, qui se
produisent en dehors du chemin critique, peuvent pousser certains chemins à devenir critiques à leur
tour. Il vaut mieux que l’échéancier du projet soit construit de telle manière que les chemins qui ne
sont pas critiques soient « remplis, mais pas trop » afin qu’un groupe de personnel puisse être utilisé
plus efficacement dans le projet.
Saisissez le travail dans votre outil de planification dans l'ordre chronologique (2.2A. P13)
Plus le projet est grand, plus il est crucial d’utiliser un outil automatisé pour élaborer l’échéancier et le
budget. Bien que les activités puissent être ajoutées dans n'importe quel ordre lors de la saisie, elles
sont plus faciles à comprendre si vous les ajoutez dans un ordre chronologique. En d’autres termes, les
activités antérieures devraient être énumérées en premier sur l’échéancier et les activités postérieures
devraient être énumérées dans l'ordre général dans lequel elles seront exécutées. En même temps que
les activités, vous pouvez également saisir les dépendances, puisque ces activités dépendantes
devraient avoir été préalablement saisies dans le logiciel.
Si la saisie des activités n’est pas faite dans un ordre chronologique, vous devez saisir les activités en
premier, puis spécifier les dépendances après avoir inscrit toutes les activités. Pour chaque activité
saisie, vous devriez également inclure l'effort de travail estimé.
Mettez au point à l'avance votre plan d’urgence pour les ressources humaines critiques (2.2A.
P14)
Votre processus de management des risques vous permet d'évaluer et de répondre aux risques élevés.
Certains de ces risques impliquent le personnel du projet et exige que vous prévoyez à l'avance
comment vous allez répondre aux risques si jamais vous aurez besoin de remplacer ou d'ajouter du
personnel. En fait, dans certains cas, vous devez actuellement planifier à l'avance pour avoir une idée
sur les ressources de secours, et sur la manière selon laquelle vous allez les utilisez si jamais vous en
aurez besoin. Cette planification de secours pourrait affecter les ressources relatives à la main d'œuvre
et celles qui ne le sont pas. Voici quelques exemples qui vous montrent quand est ce que vous devez
planifier à l'avance.
 Le temps est essentiel : Dans beaucoup de projets, si vous constatez que le travail demande
plus de temps que prévu, vous devriez avoir la flexibilité de demander du temps additionnel et
une rallonge budgétaire. Cependant, si le dernier délai est impératif et ne peut être changé,
vous n’avez plus le temps de rechercher de nouvelles personnes pour pouvoir revenir dans les
152
limites de l’échéancier. De même, si un membre de votre équipe s’en va, vous devez lui trouver
un remplaçant en un temps très bref.
Quand les dates limites sont fermes et que les livrables de projet sont urgents, vous devez mettre en
place quelques plans pour trouver le personnel qui s’avèrerait nécessaire. Par exemple, examinons les
anciens projets de YR2K d’il y a quelques années. Si, au moment de saisir les données relatives aux six
derniers mois de 1999, vous vous étiez aperçu que vous aviez besoin de plus de personnel, vous
n'auriez pas pu passer trois mois à les chercher. Vous auriez dû avoir déjà un plan pour trouver du
personnel très rapidement. Cela suppose que vous ayez prévu des employés ou des intérimaires en
réserve, pour vous permettre de procéder à des changements rapides de personnel.
 Moindre surcoût de l'achat en masse. Vous pouvez avoir du personnel qui vous revient
moins cher quand vous le recrutez en masse, mais qui vous revient très cher quand le
recrutement est échelonné. Par exemple, si la solution que vous préconisez exige un nouveau
matériel, vous constaterez que le prix par unité est moins élevé quand vous achetez plus
d'unités. Disons que vous estimez avoir besoin de 100 CDs promotionnels, plus ou moins 10.
Votre fournisseur pourrait vous offrir un prix très intéressant si vous achetez en gros, peut-être
50 ou 60% du prix unitaire. Dans ce cas, vous pouvez choisir d'acheter tout de suite la totalité
des 110 unités et de garder dix unités en réserve. Vous feriez cela parce que le prix d’achat
immédiat des dix unités supplémentaires (comme partie de la commande en gros) est
beaucoup moins élevé que celui de dix unités achetées plus tard, quand le coût se sera
fortement accru.
 De longs délais pour trouver des ressources humaines spécialisées. Parfois, un long
délai est nécessaire pour recruter du personnel spécialisé rare sur le marché. Si le besoin est
assez urgent, vous devez savoir à l’avance comment trouver ces personnes très rapidement.
Par exemple, vous pouvez avoir besoin d'experts pour un logiciel peu connu. la planification à
l’avance consiste, dans ce cas, à travailler avec le fournisseur pour identifier du personnel
potentiellement disponible pour vous, en cas d'urgence. Si un expert de votre équipe s’en va,
vous ne serez pas décontenancé. Vous auriez déjà établi un contrat pour disposer très
rapidement de ressources humaines de remplacement, même à très court terme.
Comme vous pouvez le remarquer, tous les projets n’exigent pas cette sorte de planification préalable.
Cependant, pour certains projets, elle est absolument nécessaire. Le chef de projet doit savoir à
l’avance s’il y a des risques liés au personnel, comme ceux décrits ci-dessus. Dans ce genre de cas,
quand vous vous apercevrez que vous avez besoin de ce personnel, il peut être trop tard pour le
trouver et arriver, ainsi, à réaliser le projet dans les délais fixés et dans les limites du budget. Par
conséquent, faites ce qu’un chef de projet intelligent ferait : planifier à l’avance et savoir où s’adresser
pour trouver le personnel indispensable, en cas de besoin.
153
2.2B Élaborer le budget / Techniques
Estimer les coûts fixes et les coûts variables (2.2B. P1)
Il vous arrivera de rencontrer les termes « coûts fixes » et « coûts variables » lors de l’estimation d’un
projet. Les coûts variables sont ceux qui changent en fonction du nombre d’unités employées. Le coût
variable évident sur un projet est la main-d’œuvre contractuelle. Le coût du travail contractuel varie en
fonction du nombre d’heures travaillées. Il est important d’avoir
conscience des coûts fixes et des coûts variables pour connaître
l’impact des coûts unitaires croissants et décroissants. Par exemple, si
le projet accuse un peu de retard, vous devez demander des heures
supplémentaires. Si vous augmentez les heures de vos contractuels,
vous augmentez le coût du projet. Si vous augmentez les heures des
employés de l’entreprise, il n'y aura pas d'augmentation des coûts,
étant donné qu’un taux de compensation aura été fixé.
Les coûts fixes sont ceux qui sont pratiquement les mêmes pour le
projet, quel que soit le personnel utilisé. Par exemple, si vous
construisez une maison, les coûts en bois et en béton seront plus ou
moins fixes une fois la conception convenue. Le coût du lot de terrain pour la maison sera également
fixe et ne devrait pas changer par rapport à la taille de la maison que vous construisez. Si vous sous-
traitez une partie d’un projet par un tiers pour un prix fixe, cela devient aussi un coût fixe du projet.
(Même si le travail se révèle plus long ou plus court que l’estimation, votre coût de projet devrait
néanmoins en rester au coût fixe convenu.)
Comprendre les coûts indirects et directs (2.2B. P2)
Votre projet peut avoir une combinaison de coûts directs et indirects. Les coûts directs sont attribuables
au projet. Ce sont les types de coûts que vous connaissez le mieux aujourd'hui. Cela comprend les
coûts des employés pour le temps qu'ils travaillent sur votre projet, les coûts du personnel contractuel,
des fournitures, etc.
En revanche, vous pouvez également être appelé à budgétiser les coûts indirects, ce qui n'est pas une
pratique commune. Ces coûts indirects sont d’autres coûts de fonctionnement de l’entreprise, comme
par exemple, l'eau, le chauffage et les coûts de climatisation. Vous pouvez constater que votre équipe
de projet utilise une partie de ces ressources, mais ils sont normalement budgétisés au niveau de
l'organisation dans son ensemble. Sur certains projets, cependant, il se peut que vous soyez
effectivement appelé à allouer une partie proportionnelle de ces coûts à votre projet. La combinaison
de tous les projets budgétiserait suffisamment pour payer ces dépenses communes.
154
2.2.1 Techniques d'estimation de l’échéancier et du budget
Techniques d’estimation (2.2.1. P1)
Il existe des sessions de formations d’une durée de cinq jours, centrées sur l’apprentissage de
techniques d’estimation. Certaines de ces techniques se basent sur des statistiques avancées et des
formules scientifiques et sont hors du contenu de la méthodologie TenStep. Plusieurs des techniques
d'estimation de base sont plus familières et plus faciles à comprendre.
Les techniques suivantes peuvent être utilisées au niveau du projet ou de l'activité, ou d'un travail
intermédiaire de n'importe quelle taille. Par exemple, l’avis d’un spécialiste peut servir à guider
l’estimation d’un projet entier ou d’un lot spécifique de travail. Les techniques d'estimation globale sont
connues sous le nom de « techniques descendantes ». Elles incluent les antécédents, l’analogie et les
ratios. Les estimations globales qui se fondent sur le découpage systématique du travail sont appelées
« techniques ascendantes ». La technique de la structure de découpage de projet (SDP) est, par
exemple, une technique ascendante.
Les techniques descendantes sont, en général, plus rapides et plus faciles à utiliser ensemble. Elles
sont, en général également, moins précises, excepté les estimations basées sur l’histoire et l’analogie
avec des projets précédents similaires. Si possible, vous devriez utiliser de multiples techniques
d’estimation pour un projet, en particulier si vous utilisez une technique descendante rapide.
 L’histoire antérieure. C’est de loin la meilleure manière d’estimer un travail. Si votre

entreprise garde trace des heures d'effort réelles de projets précédents, vous disposez alors
d’informations qui vous aideront à estimer la durée du nouveau travail. Dans cette méthode, les
caractéristiques du travail antérieur ainsi que le nombre des heures d'effort réelles sont
enregistrés dans un tableur, dans une base de données ou dans un autre média où on peut
aller les chercher pour un nouveau projet. Une personne qui doit estimer un nouveau travail,
introduira dans la base de données des informations sur les caractéristiques de son projet, pour
voir si un travail similaire a été réalisé par le passé. Si oui, elle peut examiner les résultats
antérieurs et ainsi avoir une idée précise de l'effort que le nouveau travail va demander.
 L’analogie. Même si vous ne gardez pas d’informations sur les heures réelles d'effort des
projets antérieurs, vous pouvez néanmoins tirer profit des projets précédents. L’analogie veut
dire que vous trouvez des projets similaires, même si l’équipe du projet n’a pas collecté
l’information sur le nombre réel d’heures de travail effectif. Le chef du projet antérieur a dû, au
moins, préparer une estimation initiale de l'effort de travail et de sa durée. Même s’il n’a pas
comptabilisé la quantité réelle d’heures de travail effectuées, il connaissait au moins la durée
effective. Si la durée réelle correspond à la durée estimée, vous pouvez faire l’hypothèse qu’il
en est de même pour l'effort de travail. D’autre part, si le projet s’est terminé avec un
dépassement de durée de 20%, vous pouvez penser que l'effort de travail aussi a connu un
dépassement de 20%.
Par exemple, disons qu’un projet antérieur a été estimé à six mois et à 2000 heures. Si le projet a été
effectué en six mois, il y a aussi de grandes chances qu’il ait demandé approximativement 2000 heures.
Mais si le projet disposait du personnel nécessaire et a duré sept mois, vous estimerez qu’il a nécessité
une somme de travail aux alentours de 2300 heures.
Il s'agit probablement de la technique la plus commune pour estimer le travail. Vous estimez le travail à
venir en vous basant sur les connaissances que vous avez acquises en effectuant un travail similaire
dans le passé.
 Le ratio. La méthode du ratio d’estimation est similaire à la méthode de l’analogie, sauf que
vous disposez d’éléments de comparaison de travaux présentant des caractéristiques similaires,
mais à plus grande ou plus petite échelle. Par exemple, vous avez constaté que l'effort de
travail nécessaire pour accomplir un audit financier dans le bureau de Lyon a représenté 500
heures et que l’un des éléments essentiels qui a influé sur le travail a été le nombre de
155
personnes employées dans ce bureau. S’il y a deux fois plus de personnes dans le bureau de
Bordeaux, vous pouvez en déduire que le travail prendra 1000 heures.
 L’avis du spécialiste. Dans beaucoup de cas, vous devez recourir à l’aide d’un spécialiste
interne ou externe pour procéder à l’estimation de l'effort de travail nécessaire. Par exemple, si
c’est la première fois que vous employez une nouvelle technologie, vous aurez peut-être besoin
de l’aide d’une institution de recherche pour obtenir des informations importantes susceptibles
d’affiner votre estimation. Bien souvent, ces estimations sont basées sur les expériences
d’autres entreprises. Il se peut aussi qu'il y ait un spécialiste interne qui peut vous aider. Alors
que c’est la première fois que vous estimez ce type de travail, peut-être que quelqu’un d’autre
l’a déjà fait de nombreuses fois.
 Delphi. La technique Delphi est similaire à la méthode d’utilisation de l’avis de spécialistes, si

ce n’est qu’avec Delphi, vous formez un panel de spécialistes et essayez d’atteindre un
consensus à partir de leurs différentes estimations. D’abord, repérez deux personnes ou plus
(de préférence trois) qui sont considérées comme des spécialistes pour le type de travail que
vous voulez estimer. Ensuite, envoyez-leur les informations pertinentes pour qu’ils puissent
comprendre le travail. Ils doivent vous retourner une estimation de l'effort de travail,
accompagnée des hypothèses, des risques, etc. qu’ils ont identifiés.
Si les estimations sont relativement proches, vous pourrez employer une moyenne de leurs estimations
pour votre estimation finale. Si, au contraire, elles sont éloignées les unes des autres ou que certaines
le sont, mais pas toutes, renvoyez la totalité des résultats de la première ronde d’estimations, avec les
hypothèses et les risques correspondants, à tous les spécialistes. Demandez alors aux spécialistes
d'examiner les estimations, les risques, les hypothèses, etc. de leurs collègues. Puis demandez à chacun
d’entre eux de fournir une deuxième estimation du travail. Si tout va bien, les diverses estimations
seront alors plus concordantes puisque les spécialistes ont pu constater le travail des autres experts. En
se basant sur un ensemble commun d’hypothèses et de risques, il est très probable que les spécialistes
arrivent à un consensus sur l’estimation. Si ce n’est toujours pas le cas, voyez si la majorité des
spécialistes ont quelques estimations qui soient similaires et utilisez celles-ci. Vous devez également
noter un risque lié à l’estimation, pour les experts qui n'étaient pas proches du consensus. Par exemple,
si le travail d’estimation de trois spécialistes se situe à 1000 heures, mais qu’un expert soutient que le
travail durera 2000 heures, vous suivrez le consensus de 1000 heures, en signalant le risque que ce
chiffre pourrait être jusqu’à deux fois plus élevé, en se basant au moins sur une opinion experte.
Une deuxième possibilité, si vous en avez le temps et l'envie, serait de faire appel à d’autres opinions
de spécialises. Ces opinions, si elles sont proches du chiffre consensuel, vous donneront plus de
confiance. Par contre, elles réduiront votre confiance (et augmenteront les risques) si elles sont
éloignées du chiffre consensuel.
Les scénarii qui précèdent sont des exemples de ce qui peut arriver quand vous demandez leur avis à
plusieurs spécialistes. La technique Delphi utilise de nombreux experts, puis donne des conseils pour
trouver la logique des estimations, si les experts ne sont pas d’accord.
 Structure de découpage du projet (SDP). Pour élaborer un échéancier du projet, la

méthodologie TenStep explique à l’étape 2.1A comment diviser le travail en des lots de plus en
plus petits. Une des raisons de cette division est de pouvoir estimer plus facilement le travail.
Vous pouvez examiner un grand lot de travail et avoir des difficultés à en estimer l'effort requis.
Cependant, lorsque le travail est découpé en de plus petits lots , il est plus facile d’estimer les
différents éléments. Quand vous avez estimé tous les lots de travail individuels, additionnez
toutes les estimations pour obtenir le volume total de travail. Si vous avez le temps de créer
une bonne structure de découpage de projet (SDP), vous finirez, généralement, par obtenir une
bonne estimation de l'effort global requis. Vous devriez employer la technique de la structure
de découpage du projet (SDP) chaque fois qu’il est possible de le faire dans un projet.
 PERT (Program Evaluation and Review Technique – Technique pour l’évaluation et la révision
de programmes). Le terme PERT est souvent employé en référence à un diagramme de réseau.
Cependant, il s’agit, en réalité, de la dénomination d’une technique d’estimation qui emploie la
moyenne pondérée de trois chiffres pour fournir une estimation finale.
156
Comment utiliser la technique PERT ? Si on vous demande d’estimer l'effort de travail d’un projet ou
d’une activité en utilisant cette technique, vous devez procéder à trois estimations au lieu d’une seule.
La première correspond au cas de figure le plus pessimiste, où tout tournerait mal (le cas « P ») ; une
autre estimation correspond au cas de figure le plus optimiste, où tout se déroulerait comme il faut (le
cas « O »); enfin, vous estimez les heures nécessaires pour réaliser le travail dans des circonstances
normales ou moyennes (le cas « M »). L’estimation résultant de la technique PERT sera par exemple (O
+ 4M + P)/6, en supposant que la totalité du déroulement normal du travail soit quatre fois supérieure
à celle où tout se déroule mal. Par exemple, supposons qu’après avoir estimé la réalisation d’un lot de
travail, vous arriviez à la conclusion qu’il prendra très probablement 10 heures; de plus, supposons que
l’estimation pour le meilleur cas de figure (tout va bien) soit de 6 heures. Si le plus mauvais cas de
figure (tout tourne mal) est de 26 heures, alors l’estimation de PERT serait de 12 heures = (6 + 4(10)
+ 26)/6 = 72/6. Remarquez que ce chiffre a été tiré vers l’estimation pessimiste, sans que cela soit
excessif, puisque le résultat est encore assez proche de la valeur la plus susceptible de se produire.
 Modélisation paramétrique. Dans cette technique, un modèle de travail doit exister et va

vous permettre d'utiliser un algorithme pour diriger l'ensemble des estimations. Par exemple, Si
vous savez que vous pouvez construire un kilomètre d'autoroute avec un cout d'un million
d'Euros par voie, vous devriez facilement être capable de calculer une estimation pour dix
kilomètres d'autoroute de 4 voies (40 millions d'Euros). Voici un autre exemple : si on vous
demande de créer 40 nouveaux rapports, estimez d'abord l'effort d'un rapport "moyen" (peut
être bien la moyenne d'un petit, moyen et grand rapport). Après multipliez l'effort moyen d'un
rapport par 40 et cela vous donnera une estimation finale.
 La technique du "coffret temps". C’est cette technique un ou plusieurs aspects de

l'estimation sont fixés à l'avance. On peut généralement le faire en se concentrant sur l’un des
autres aspects de la « triple contrainte » ou sur les deux à la fois. Généralement, lorsque vous
utilisez cette technique, vous essayez de contraindre le projet à s’achever à une date limite
donnée. Vous devez alors vous concentrer sur les aspects coûts et contenu de la triple
contrainte, pour être au rendez-vous de la date limite.
Par exemple, admettons que vous ayez élaboré un échéancier et qu’il semble que vous puissiez mener
le projet à terme en neuf mois. Cependant, votre commanditaire vous dit que le projet doit être achevé
en sept mois. Le délai limite de sept mois devient le « coffret - temps » à l’intérieur duquel le projet
doit être achevé. Pour respecter la date butoir, vous serez obligé de faire appel à des ressources
humaines plus tôt que prévu. Vous aurez aussi besoin d’un personnel plus nombreux afin que certaines
activités programmées pour être exécutées consécutivement puissent être réalisées en parallèle. Ce
sont là quelques exemples de situations qui tirent le coût du projet vers le haut. Si vous ne pouvez pas
dépenser plus d’argent pour être dans les délais, vous pouvez être amené à éliminer une partie du
travail (contenu). Vous pouvez augmenter les coûts, diminuer le contenu ou, peut-être combiner les
deux pour être dans les délais.
 Points de fonction (projets de développement TIC). Certaines organisations de

développement TIC utilisent des points de fonctions pour obtenir des estimations significatives
du travail requis pour réaliser un projet de développement de systèmes. Les points de fonction
fournissent un mécanisme pour déterminer la relative complexité d’une application. La
complexité peut être exprimée comme un compte de points de fonction. De cette manière, une
application de 1000 points de fonction est généralement dix fois plus grande et plus complexe
qu’une application de 100 points de fonction.
Sans trop se perdre dans les détails, les points de fonction considèrent la taille d’une application du
point de vue d’un utilisateur. Les utilisateurs voient des rapports, des écrans, et peut-être aussi des
fichiers de données. Ils voient également les fonctionnalités commerciales, les interfaces avec les autres
applications, des bases de données, des tableaux, etc. Il est logique qu’une application avec 80 écrans
et 20 rapports soit probablement plus importante qu’une application avec 20 écrans et 5 rapports. Cette
manière de considérer la taille est indépendante de la technologie sous-jacente et du langage de
développement. En fait, l’application avec le plus petit nombre d’écrans peut demander plus de lignes
de code. Cela n’est cependant pas pertinent dans les calculs de dimensions.
Vous ne pouvez pas procéder à des estimations avec des points de fonction au début du processus de
planification. Cependant, une fois que vous connaissez le nombre d’écrans, de rapports, de fichiers
157
d'interface, de transactions, etc., vous pouvez établir une estimation globale du total des points de
fonction. Une fois que vous avez compté les points de fonction pour un certain nombre de projets, vous
commencerez à évaluer l'effort de travail requis pour achever un point de fonction. Après cela, il ne
reste qu’à faire les calculs nécessaires pour déterminer l'effort de travail total requis, suivi de la durée
et du coût.
Estimer par phase (2.2.1. P2)
Un des aspects les plus difficiles dans l’estimation des projets est que vous ne savez pas exactement
quel travail ces projets nécessiteront dans un futur éloigné. Des travaux qui doivent être effectués dans
trois mois peuvent être difficiles à définir et à estimer. Il est plus difficile encore de faire des
estimations six mois à l’avance. C’est encore plus dur s’il s’agit de neuf mois, pour la simple raison que
les décisions prises et les livrables produits plus tôt dans le projet auront un impact sur ce à quoi le
travail ressemblera plus tard. Par conséquent, il y a de plus en plus de risques liés à l’estimation du
travail le plus éloigné dans l’avenir.
La meilleure approche pour de grands projets est de diviser le travail en une série de plus petits
projets, dont chacun peut être planifié, estimé et géré avec une probabilité de réussite beaucoup plus
élevée. (Un raisonnement similaire peut être trouvé à l’étape 1.0 Définir le travail, dans la partie sur la
division des grands projets en plusieurs projets et leur gestion en tant que programmes). Dans une
perspective d’estimation, le projet le plus proche peut être estimé avec plus de précision, les projets
suivants étant estimés avec un niveau plus élevé d’incertitude. Lorsqu’un projet est accompli, le suivant
peut être estimé avec un degré plus élevé de confiance dans l’estimation, et les estimations peuvent
être affinées pour les projets restants. Cette technique fournit également des points de contrôle à la fin
de chaque projet, de telle sorte que l'initiative entière peut être revalidée en se basant sur des
estimations courantes, permettant de s'assurer qu’elle est encore viable et intéressante à poursuivre.
Estimer les activités présentant une contrainte de date et une contrainte de personnel (2.2.1.
P3)
Des activités peuvent être classées comme présentant des contraintes de date ou de personnel si la
durée peut changer lors du recrutement d’un personnel supplémentaire. Une activité présente des
contraintes de personnel si la durée change en fonction du nombre de personnes recrutées. Par
exemple, vous pourriez estimer qu’une personne mettra 200 heures pour construire le toit d’une
maison. Si la personne travaille quarante heures par semaine, cela prendra cinq semaines pour
accomplir le travail. Si vous employez deux personnes pour ce travail, l'effort de travail total sera
toujours de 200 heures, mais le travail prendra seulement 2 semaines et demie. S’il y avait cinq
personnes affectées, le travail pourrait être fait en une semaine. (Naturellement, la durée peut ne pas
baisser aussi simplement que dans cet exemple). Une activité présente des contraintes de personnel si
la durée est basée sur le nombre de personnes qui peuvent être affectées à l’activité.
D’autre part, si une activité présente des contraintes de temps, la durée demeure la même,
indépendamment du nombre de personnes affectées à sa réalisation. Par exemple, si vous participez à
une classe d’une journée, l’activité prendra huit heures de temps. Si vous envoyez deux personnes à la
classe, la classe ne se fera pas plus rapidement. Elle durera toujours huit heures. De même, le temps
que prend le béton pour sécher, ou le temps pris pour expédier une lettre ne dépendent pas du nombre
de personnes impliquées. Cela demande juste un certain temps. Si vous voyez qu’affecter du personnel
n’a aucun impact sur la durée du projet (ou n’a qu’un impact très faible), c’est que l’activité subit une
contrainte de date.
Incluez dans l’estimation le temps lié aux réunions de projet et à la collaboration (2.2.1. P4)
Les réunions au sein du service et les réunions d’entreprise ne dépendent généralement pas de vous et
ne sont pas comptabilisées dans l'échéancier ou dans l’estimation. Si la date d’une réunion de service
est fixée de manière ad hoc, vous ne pouvez qu’y assister et vous arranger ensuite avec les délais de
l’échéancier. Ces réunions sont incluses dans l’estimation de la durée si vous avez appliqué un facteur
réducteur au nombre d’heures de disponibilité par jour pour chaque personne (généralement 6,5
heures par jour). Évidemment, si ces réunions de service sont programmées mensuellement ou
trimestriellement, vous pouvez les prendre en compte et leur réserver du temps dans votre échéancier.
158
Le temps ne jouera pas contre votre projet, mais assister aux réunions peut avoir un impact sur votre
échéancier.
D’autre part, les réunions qui sont liées au projet doivent être définitivement incluses dans l'échéancier
du projet et doivent être ajoutées à l’estimation de l'effort de travail et du coût, car les réunions de ce
type dépendent de l’équipe de projet. Le chef de projet peut programmer ces dernières pendant une
heure par semaine ou bien tous les jours.
De même, essayez d’inclure tout le temps requis de tous les participants pour prendre part à toutes les
réunions de collaboration connexes au projet. Par exemple, si vous planifiez une rapide présentation
des livrables, assurez-vous de prendre en compte le temps de tous les participants. Quand vous faites
circuler des documents pour approbation, prenez en compte un certain temps pour cette activité, pour
chaque personne qui sera impliquée. Si vous prévoyez ou organisez des réunions de revue à la fin de
chaque jalon de référence, soyez sûr de prendre en compte ce temps pour chaque participant.
Commencez par une fourchette d’estimation (2.2.1. P5)
On vous demande souvent de fournir une estimation approximative pour un projet ou une activité
spécifique. Habituellement, on vous demande de produire un chiffre, par exemple 1000 heures. Dans la
mesure du possible, ces estimations globales devraient être comprises dans une fourchette d’estimation
qui reflète le niveau d’incertitude de l’estimation. Par exemple, une estimation approximative pourrait
être précise à 50% seulement. Dans l’exemple précédent de 1000 heures, vous pouvez estimer que le
travail demandera entre 500 et 1500 heures. Une autre manière de dire la même chose est que vous
estimez le travail à 1000 heures, à plus ou moins 50%. S’il y a beaucoup d’incertitude sur l’estimation,
votre marge d’erreur pourrait être de 100% ou plus. Cependant, quand vous fournissez une fourchette
d’estimation, le but est d’aider à gérer les attentes. Si vous dites que vous estimez un lot de travail à
1000 heures, on attendra que vous l’accomplissiez avec ce nombre d’heures de travail. Étant donné les
informations dont vous disposez, ceci peut être un objectif difficile à réaliser. Si vous fournissez une
fourchette d’estimation, vous aurez une probabilité bien meilleure d’accomplir le travail conformément à
l’estimation, et vous disposerez d’un moyen de montrer le niveau d’incertitude de ces chiffres.
Plus l'estimation est précise, plus la fourchette est large
Utilisez la modélisation de Monte Carlo pour déterminer les risques de planification (2.2.1.
P6)
Une des manières d’évaluer l’incertitude dans votre estimation consiste à ajouter un facteur de
159
contingence. Ce facteur de contingence devient plus élevé pour refléter un degré d'incertitude pus
élevé de votre estimation. Pour la plupart des projets de taille moyenne ou petite, ajouter une
contingence raisonnable d'estimation ira parfaitement bien et devrait vous donner une estimation finale
que vous pouvez raisonnablement espérer atteindre.
Pour de plus grands projets, cependant, il existe des techniques plus puissantes pour reconnaître le
risque d’estimation. Le plus commun de ces modèles est celui de Monte Carlo. La modélisation de
Monte Carlo commence un peu comme la technique d’estimation PERT. Plutôt que de donner une
estimation sur la durée de l’activité, vous fournissez une série d’estimations qui représentent le meilleur
des cas, le cas le plus probable et le pire des cas. Pour chacun de ces cas, vous assignez également
une probabilité.
Par exemple, il peut y avoir 10% de chances que votre meilleur cas se produise, 80% de chances que
ce soit l’estimation la plus probable, et 10% de chances que le travail se déroule selon le plus mauvais
scénario. En d’autres termes, il y a 90% de chances cumulées pour que l’activité soit accomplies selon
le scénario le plus probable (10% + 80%) et une chance cumulative de 100% que le travail soit
effectué selon le pire des cas (10% + 80% + 10%). Vous n’avez pas besoin de déterminer les
pourcentages de probabilités pour les cas intermédiaires : ces trois cas suffisent. (Techniquement, vous
pouvez fournir des estimations pour toutes les probabilités).
Vous devez alors préparer ces trois estimations pour chacune des activités principales de votre
échéancier. Par exemple, vous pouvez estimer qu’une activité nécessitera probablement 60 heures,
dans le meilleur des cas 50 heures et dans le pire des cas, 90. Ces trois estimations pourraient devoir
être préparées pour des douzaines (voir des centaines) d’activités dans l'échéancier.
Cette opération accomplie, la plupart des logiciels d’établissement d’échéancier disposent de fonctions
pour effectuer une simulation de Monte Carlo. Fondamentalement, les modèles de simulation montrent
comment le projet progressera et atteindra une date de fin estimative. L'échéancier est alors tracé une
fois de plus, mais, cette fois en utilisant des probabilités différentes, et donc en calculant une date de
fin différente. Le modèle est simulé de nombreuses fois, de telle sorte que les pourcentages de risques
soient bien pris en compte. Dans l’exemple ci-dessus, si la simulation était effectuée 100 fois, vous
pourriez prévoir que chaque activité individuelle serait affectée selon la meilleure estimation : 10 fois
(10%), la pire: 10 fois (10%) et selon l'estimation la plus probable, 80 fois (80%). Comme les logiciels
de modélisation sélectionnent aléatoirement des valeurs basées sur les probabilités, beaucoup de
scénarios de projets différents vont apparaître. Certains montrent que le projet va être achevé plutôt
puisque les meilleures estimations sont choisies aléatoirement. Certains échéanciers montrent que le
projet va être achevé plus tard puisque plusieurs mauvais cas sont aussi choisis aléatoirement.
Cependant, après avoir tourné 100 fois le modèle de projet, un modèle de base commence à émerger
qui vous permet d’estimer la date la plus probable à laquelle votre projet prendra fin. Cette date est
généralement celle où la simulation Monte Carlo montre que le projet se termine dans 80% des cas. En
d'autres termes, la simulation montre que la fin du projet serait à cette date ou encore à 80% plus tôt.
Dans l’exemple ci-dessus, cette technique a été employée pour calculer les risques de planification,
mais vous pouvez également l’utiliser pour estimer les coûts et l'effort de travail. L’avantage de la
simulation de Monte Carlo c’est que si vous fournissez les estimations des activités avec des
fourchettes, la plupart des logiciels de gestion de projets exécuteront tous les calculs statistiques
automatiquement. Vous devrez seulement vous assurer que vous avez fourni des estimations valides et
raisonnables au sujet des activités. Comme vous pouvez le voir, le travail supplémentaire exigé par ce
processus d’estimation en fait un modèle à employer uniquement pour des projets de très grande taille
ou qui présentent beaucoup de risques. Les petits projets ou les projets moyens ne tireraient
probablement pas grand avantage à utiliser cette technique.
Prenez garde à ces erreurs d’estimation courantes (2.2.1. P7)
Le processus d’estimation est à la fois un art et une science. Cependant, une fois que vous avez appris
de bons processus et techniques d’estimation, vous serez, heureusement, plus attiré par le côté
"scientifique" de l’activité d’estimation que par son côté "artistique". Vous pouvez devenir plus fort en
matière d'estimation, mais, par nature, vous ne serez jamais parfait. Nous vous présentons ci-dessous
une liste de problèmes d’estimation courants qu’il est important d’éviter :
160
 Ne pas prendre la totalité du travail en compte. Il s’agit d’un problème très courant,
affectant surtout les premières estimations globales. Vous pouvez par exemple oublier un
travail important que vous n'aviez pas perçu comme faisant partie du projet, tel que la
documentation ou la formation. Généralement, cependant, vous sous-estimez la taille des
livrables à réaliser ou bien vous n’incluez pas toutes les activités requises pour réaliser les
livrables.
 Prendre ses désirs pour la réalité. Tous ceux qui ont effectué des estimations de travail
connaissent la pression que peut exercer le client pour obtenir les estimations les plus
modestes possibles. À la limite, le client souhaite obtenir ce qu'il veut avec le moins d'effort (et
de coût) possible. Assez souvent, l’estimateur a tendance à se laisser envahir par cet état
d’esprit. L'estimateur finit par « souhaiter » que le travail soit réalisé conformément aux
attentes du client.
 Ne considérer que le meilleur scénario possible. Le client insiste pour que tout soit
produit le plus rapidement possible. Votre manager le suit. Et vous aussi, et une réalisation
rapide vous semble possible. Cependant, vous rencontrez des difficultés, parce que vous ne
considérez que le temps nécessaire pour achever le travail si tout fonctionne adéquatement.
Vous essayez de penser au travail en termes de fourchette, mais vous finissez par vous
engager dans une estimation se situant au niveau le plus bas ou le plus optimiste de la
fourchette.
 Se croire, à tort, capable de livrer un travail de haute qualité. Ce problème est lié à une
estimation basée sur la confiance de pouvoir atteindre un certain niveau de qualité dès la
première fois. Cependant, lorsque le projet avance, vous comprenez que votre capacité de
produire à un haut niveau de qualité est limitée. Cela finit par entraîner encore plus de travail
de reprise, de résolution de petits problèmes, de nouveaux tests, etc.
 S’engager à se conformer au budget disponible. Dans ce cas, le client dispose d’une

somme fixe pour le budget. Le chef de projet pense qu’il y a une chance de terminer le travail
dans les limites du budget disponible et il s’engage donc à respecter cette somme. Ce problème
est similaire à celui exposé plus haut pour le meilleur scénario possible.
 Ne pas reconnaître les penchants qui influencent l’estimation. Il s’agit ici des préjugés
qui ont tendance à se glisser constamment dans vos estimations. Certains sont optimistes,
d’autres pessimistes.
Les penchants optimistes poussent à sous-estimer le travail et peuvent inclure les cas suivants:
 avoir tendance à penser que le travail sera aisé;
 avoir tendance à penser que votre équipe est en mesure de produire davantage de travail
qu’elle peut le faire en réalité;
 ne pas prendre en compte les risques du projet, les problèmes majeurs, les défauts de
communication, etc.;
 avoir tendance à adopter un point de vue optimiste au premier abord.
Les penchants pessimistes entraînent une surestimation du travail et peuvent inclure les cas
suivants:
 vous avez eu une mauvaise expérience avec un projet similaire dans le passé;
 vous ne voulez pas vraiment de ce projet : vous donnez des estimations fortes en espérant que
le projet soit annulé;
 avoir tendance à commencer à émettre un point de vue pessimiste.
Vos penchants sont toujours présents. La manière d’agir consiste à les reconnaître pour les combattre
là où vous les remarquez. Cela vous aidera à préparer des estimations aussi valides que possible.
161
Validez l’ancienne estimation lorsqu’une nouvelle équipe est mise en place (2.2.1. P8)
Parfois, une équipe de projet est formée pour définir le projet, élaborer l'échéancier et le budget, puis
exécuter le projet. Cependant, l'effort de travail et la durée d’un projet sont parfois estimés très tôt,
peut-être parce que l'information est nécessaire en tant qu’élément du cycle annuel de budget. Dans ce
cas, une équipe de projet pourra être réunie par la suite et sera chargée d’effectuer le travail sur la
base des estimations approximatives qui ont été réalisées jusque-là.
Si cela se produit, une des premières tâches de la nouvelle équipe de projet sera de valider les
estimations. Vous ne voulez pas être en position de devoir produire des estimations sur la base de
celles de quelqu’un d’autre. Par ailleurs, si vous ne prenez pas l’initiative de valider ou de contester les
estimations assez tôt, on supposera que vous les trouvez correctes. Le chef de projet devrait contester
les estimations antérieures suffisamment tôt. Si vous êtes d’accord avec les estimations, vous allez
démarrer sur la base de l’effort, du budget et de la date limite prévus. Si vous n’êtes pas d’accord, il est
temps d’agiter le drapeau rouge. Cela vaut mieux pour la compagnie aussi. Par exemple, si votre
estimation est trop haute, Vous pouvez découvrir que le rapport coût/bénéfice du projet n’a plus aucun
sens. Si c’est le cas, mieux vaut le découvrir tôt plutôt que tardivement.
Décidez si vous devez inclure les coûts et l'effort de travail du client (2.2.1. P9)
Tous les projets ont des clients qui profitent des bénéfices du projet. Souvent, ces clients travaillent
pour le compte d'une organisation différente ou d'une société différente que celle de l'équipe du projet.
Les chefs de projet doivent décider s'il faut inclure le temps pendant lequel le client devra être impliqué
dans le projet.
L'effort de travail du client inclut les heures passées à examiner et approuver les livrables, à fournir les
spécifications, à assister aux réunions, à participer à la formation, etc. Certaines entreprises tiennent à
connaître l'effort total de travail et le total des coûts d’un projet, y compris ceux de l’équipe directe du
projet, mais aussi les exigences du personnel relevant du client i. Dans d’autres entreprises, les coûts
du projet incluent seulement ceux en relation avec l’équipe du projet. Inclure les heures et le coût du
travail du client dans votre estimation est un point dont vous devez discuter avec votre manager et
votre commanditaire. Si votre estimation du projet inclut les heures et les coûts du client, ces heures
doivent être saisies séparément. Bien que le nombre combiné fournisse une meilleure estimation
globale, le chef de projet n’est normalement pas responsable des avis personnels du client et ainsi ne
peut être tenu pour responsable de ces objectifs particuliers.
Préparez-vous à ce qu’on vous dise que votre estimation est trop élevée (2.2.1. P10)
Après avoir préparé votre estimation, vous pouvez avoir besoin de la défendre si le client pense que les
chiffres sont trop élevés. Vous devez d’abord être en mesure de défendre votre estimation en
expliquant les techniques que vous avez employées, le processus que vous avez suivi et les hypothèses
que vous avez formulées. Si le client continue à penser que vos chiffres sont trop élevés, ou qu’il n’aura
pas les moyens de financer cette solution à ce coût, voici quelques options supplémentaires.
 Déterminez si le client dispose d’informations complémentaires qui pourraient vous permettre

de revoir vos hypothèses et de réviser votre estimation. Par exemple, si une date de fin
importante offre une certaine flexibilité, peut-être que l’estimation peut être révisée sur la base
de cette nouvelle information.
 Déterminez si des spécifications et des fonctionnalités de haut niveau peuvent être réduites.
Dans de nombreux cas, l’ensemble original des dispositifs et des fonctions n’est qu’une liste de
souhaits. Après avoir vu le prix, il est fort probable que le client pourra se passer de certains
éléments.
 Si vous avez inclus une contingence élevée pour refléter un risque d’estimation élevé,
demandez au client davantage de temps afin de recueillir plus de détails pour l’estimation. Cela
peut entraîner une réduction des incertitudes et des risques, qui se reflétera dans une
contingence plus faible.
162
 Restructurez le projet pour y inclure seulement la phase de réunion des exigences. Une fois que
l’analyse complète des exigences est réalisée, estimez à nouveau le reste du projet original, en
vous basant sur une confirmation de ce qui est exactement demandé. L'effort total de travail et
le coût total peuvent être inférieurs ou pas, mais, au moins, vous disposerez d’informations plus
détaillées pour soutenir votre estimation.
Appuyez votre estimation par un paquet entier d'informations (2.2.1. P11)
La prochaine fois que l’on vous demandera de fournir une estimation pour un grand lot de travail,
pensez à présenter un paquet d’informations. Ce ne doit pas être un document épais. Il est seulement
destiné à souligner la rigueur dont vous avez fait preuve. Vous devez surtout déterminer si le travail a
un caractère politique, et si vous pensez que votre estimation ne sera pas acceptée. Plutôt que de
fournir une estimation finale ou une fourchette d’estimation, fournissez les informations suivantes :
 Votre façon de voir le travail demandé
 Le processus que vous avez suivi pour préparer l'estimation
 La (es) technique (s) d’estimation que vous avez utilisée (s)
 L’estimation actuelle de l'effort de travail (ainsi que la durée et les coûts, le cas échéant)
 L'estimation détaillée, au cas où le destinataire voudrait la revoir. Par exemple, si vous avez
utilisé une structure de découpage du projet (SDP), vous pouvez inclure vos estimations des
activités détaillées
 Les hypothèses sur lesquelles vous vous êtes basé pour développer votre estimation
 Le niveau d’incertitude dans les chiffres qui reflètent la contingence et l’amplitude de la

fourchette d’estimation (une plus grande incertitude se reflète dans une fourchette plus large).
Cela représentera un solide paquet d’informations à fournir au destinataire. S’il y a des désaccords avec
votre estimation, cela vous donnera les moyens de répondre par des faits. Cela mettra fin à de
nombreuses critiques qu’on pourrait vous faire, car les gens auront du mal à discuter des faits. On
pourrait vous demander de modifier vos hypothèses d'estimation, ou d’essayer d’autres techniques
d’estimation. Ce sont des demandes légitimes, et vous pouvez faire de nouvelles estimations à partir de
nouveaux critères. Au moins, les remarques porteront sur le processus d’estimation, mais on ne vous
reprochera pas un travail faible en ce qui concerne l’estimation elle-même.
Estimation basée sur les niveaux de précision requis (2.2.1. P12)
Différents niveaux de précision d’une estimation sont normalement attendus du chef de projet (ou de
l’équipe de projet) suivant la date où l’estimation est demandée. Lorsque le projet est proposé pour la
première fois, par exemple, votre client peut vous demander une estimation globale de l'effort de
travail, du coût et de la durée. Le projet reste vague à ce stade, de même que l’estimation qui en est
faite. Dans de nombreux cas, l’estimation est uniquement effectuée dans le but de se faire une idée de
la taille afin que l'initiateur puisse savoir si le travail requiert 1000 ou 100.000 heures. Cette estimation
est un Ordre Approximatif de Magnitude (OAM) qui peut varier de -25% à 75%. En d’autres termes, si
l’estimation préliminaire est de 1000 heures, vous pouvez proposer un OAM de 750-1750 heures. En
fait, à ce stade, vous pouvez avoir une marge d’erreur de 100%, voire plus.
C’est quand le projet avance vers le processus d’approbation que l’estimateur devient plus compétent
en ce qui concerne les attentes et les livrables, et que ses estimations deviennent également plus
précises. Lorsqu’un projet est proposé pour le financement, vous devez pouvoir estimer le projet avec
plus de précision, disons avec une marge de -15% à +25%. En d’autres termes, si votre estimation est
de 1000 heures, vous pouvez proposer une marge de 850 à 1250 heures.
Lorsque le travail sur le projet commence réellement, le chef de projet et l’équipe devraient revalider
l’estimation après avoir formellement défini le travail et élaboré l'échéancier et le budget. Cette
estimation devrait, à ce stade, varier de -5% à +10%. En d’autres termes, si votre estimation finale est
de 1.000 heures, vous devriez vous sentir en mesure de livrer réellement le projet avec un effort de
163
l'ordre de 950 à 1.100 heures.
ESTIMATION PRÉCISION OBJECTIF
ORDRE DE MAGNITUDE
-50% ~ +100% Évaluation des projets ou des alternatives
(state de la conception)
Établir le budget initial, réserver des fonds pour le

PRÉLIMINAIRE (BUDGET) - 15% ~ +25%
projet
Établir le budget définitif du projet, après la charte

DÉFINITIVE - 10% ~ +15%
du projet
Si vous devez estimez l'effort requis avant de recueillir les exigences détaillées (2.2.1. P13)
Beaucoup de chefs de projets sont préoccupés par le fait qu’ils doivent présenter une estimation
détaillée du travail du projet au moment de l’élaboration de la charte et de l’échéancier. Cependant, les
exigences détaillées n’ont pas encore été collectées. Comment peut-on estimer le travail sans avoir pris
la mesure des exigences détaillées ? La question semble légitime. Cependant, lorsque vous parlez de
collecte des exigences détaillées, vous parlez généralement de la phase d’analyse du cycle de vie d’un
projet, et non du travail préalable de management du projet, qui consiste à planifier et définir ce
dernier.
Il est possible que vous pensiez de prime abord que vous devez connaître les exigences détaillées avant
de vous engager dans l’estimation du travail. Cependant, cette démarche est-elle pratique ? Supposons
que vous ayez un projet particulier d'amélioration de processus. Le projet devrait durer 6 mois et la
collecte des exigences de 6 à 8 semaines (ou plus) de la durée globale. Alors, devez-vous vraiment
suspendre l’estimation du projet jusqu’à ce que les exigences soient recueillies et approuvées ? Dans ce
cas, le tiers du projet aura été réalisé avant que vous ayez validé les coûts globaux du projet et le délai
nécessaire. Si le projet n’est pas raisonnable du point de vue coûts/bénéfices, vous auriez dépensé des
sommes importantes et il serait trop tard pour remédier à la situation. C’est pour cette raison que la
plupart des méthodologies de management de projet n’abordent pas la collecte des exigences
commerciales détaillées.
De plus, si vous utilisez ce même argument, vous pourrez dire que vous n’êtes pas sûr de pouvoir
estimer avant de procéder d’abord à la conception et ensuite que vous n’êtes pas sûr de pouvoir
estimer le travail avant que vous ayez terminé le travail de construction, etc. On voit bien où peut
mener cette logique, si elle était poussée à l’extrême.
Les trois approches suivantes vous permettront d’estimer le travail avant d’avoir collecté les exigences
commerciales. (Cela suppose que la collecte des exigences soit effectuée en tant que première étape de
l’exécution du projet. Ce procédé est aussi désigné par l’expression : le modèle de la cascade. Si vous
utilisez des techniques flexibles ou réutilisables, vous arriverez à recueillir les exigences d’une manière
itérative durant tout le projet).
 Estimer le travail avec une marge de 15% quand vous établissez la charte et
l’échéancier du projet. C’est là une approche traditionnelle, et elle est toujours viable dans la
plupart des cas. Cependant, cela suppose que le chef et/ou l’équipe du projet ont fait ce genre
de travail au préalable et qu’ils sont par conséquent capables de faire l’estimation du travail
avec une marge de 10%, en se basant sur les exigences recueillies à un niveau général et
intégrées dans l’élaboration de la charte du projet. Si vous découvrez que l’estimation est
incorrecte après avoir collecté les exigences, vous devez alors lever le drapeau et demander
plus d’argent. Bien évidement, ce même contrôle doit être effectué à la fin de chaque phase du
projet, indépendamment des techniques utilisées.
 Diviser le travail en plusieurs parties plus petites. Si vous sentez que vous n’êtes pas en
mesure de donner l’estimation globale du projet avec une marge de 10%, vous pouvez alors
deviser le grand projet en de multiples petits projets. En utilisant cette technique, vous
aboutirez généralement à définir un projet séparé qui recueillera les exigences et vous devriez
être capable d’estimer le projet de collecte des exigences avec une marge de 10%. Quand ce
projet des exigences est terminé, vous pourrez utiliser ses résultats pour élaborer la charte d’un
164
deuxième projet qui accomplira le reste du travail. Fort heureusement, vous êtes maintenant en
mesure d’estimer le reste du travail avec une marge de 10%. Quand vous aurez fini, les
livrables définitifs auront été créés à travers deux projets dont chacun a été estimé et géré
avec une marge de 15% par rapport au budget et à l’échéancier.
 Faire d’abord une estimation approximative de l’échéancier et le budget, puis les

consolider une fois les exigences collectées. C’est une variante de la première technique
exposée ci-dessus. Dans cette approche, le chef de projet avance l’estimation la plus «
plausible » du travail en même temps que la charte et l’échéancier sont créés. Toutefois, selon
les règles de l’organisation, le chef de projet n'est pas tenu pour responsable de cette
estimation (à la différence de la première option ci-dessus). Cette estimation n’est que la
meilleure hypothèse, étant donné les informations disponibles. Quand toutes les exigences sont
connues, le chef de projet fournit une estimation plus détaillée du travail avec une marge de
10%. C’est là le chiffre pour lequel le chef du projet est considéré comme responsable.
Beaucoup de chefs de projets pensent que la meilleure approche est de collecter les exigences de
manière itérative. Cependant, le cycle de vie itératif ne répond pas à la question de savoir comment
estimer le projet avec une marge de 10%. En fait, les approches itératives pourraient rendre ce niveau
de précision encore plus difficile à atteindre. Les trois solutions ci-dessus fournissent un ensemble de
techniques plus viables pour estimer le travail avec une marge de 1O% avant de démarrer.
165
2.3 Élaborer l'échéancier et le budget / Références rapides
Les Livrables (2.3. P1)
ayant une licence.)
 Échéancier du projet
 Coûts de base
 Résumé de l’estimation des coûts
 Estimation de l’effort et des coûts
 Résumé des jalons de l'échéancier
 Besoins en ressources humaines
 Plan de management des ressources humaines
 Plan de management de l'échéancier
 Plan de management des coûts
Il existe un modèle complet d’échéancier pour toutes les activités de management de projet dans la
bibliothèque de Modèles de base destinés aux utilisateurs qui détiennent une licence.
Taille Informations nécessaires
Petits Pour les petits projets, vous pouvez généralement élaborer l’échéancier au cas par cas
projets ou simplement en organisant le travail dans votre tête.
Réunir les documents de 1-2

base préexistants heures
Il est difficile de connaître le temps

Créer le premier niveau de
approximatif pour beaucoup de ces activités.
la structure de découpage Ouvert
Cela dépend de la taille et de la complexité de
du projet
la SDP.
Projets Estimer l’effort de travail

moyens et requis pour élaborer les Ouvert
grands livrables de ce niveau
Répéter cette activité et la précédente jusqu’à

Déterminer si le travail a
ce que tout le travail soit compris et que l’effort
besoin d’être découpé Ouvert
soit estimé à un niveau inférieur au seuil
davantage
d’estimation.
Estimer le travail pour Au cours des étapes précédentes, vous avez

toutes les activités Ouvert porté votre attention seulement sur le fait de
détaillées savoir si les activités sont plus importantes que
le seuil d’estimation. Vous devez maintenant
166
estimer réellement le travail requis par les
activités détaillées.
Élaborer un diagramme de
réseau en établissant
l'ordre d'exécution des Ouvert
éléments détaillés du
travail à un niveau global.
Examiner l'ordre
d'exécution, pour trouver
Ouvert
les liaisons entre les
activités détaillées
Chercher les contraintes de

Ouvert
dates
Affecter le personnel
Ouvert
spécifique et générique
Élaborer l’échéancier initial

Ouvert
du projet
“Niveler” les charges du

Ouvert
personnel
Continuez à modifier des éléments de

Adapter le plan, si l’échéancier, y compris les ressources
Ouvert
nécessaire humaines, jusqu’à ce que l'échéancier vous
semble réalisable.
Estimer le coût Ouvert
Réexaminer l’échéancier et Vous devez vous sentir en mesure de défendre

les dates et vérifier qu’ils Ouvert l’échéancier. Sinon, continuez à travailler
sont cohérents dessus.
Fixer les jalons et les

1-2
révisions à l'achèvement
heures
de chaque phase
Sauvegarder une copie en

cours de l’échéancier, 12 heures
comme base de travail
Créer le plan de
management de 4 heures
l'échéancier
Réviser le budget pour

2 heures
vérifier s'il est cohérent
Finaliser et affecter le
2 heures
budget
Créer le plan de
4 heures
management des coûts
167
______________________________________________________________________
Processus 3
Gérer l'échéancier et le
budget
168
3.0 Gérer l'échéancier et le budget
(3.0. P1)
Si vous avez suivi les processus 1 et 2,

vous avez dès lors défini le travail (la
charte du projet, le plan de management
de projet) et planifié comment vous allez
achever le travail (l'échéancier du projet, le
budget). Vous devez maintenant gérer
l'échéancier et le budget et vous assurer
que le projet se terminera en respectant
l’échéancier et en restant dans les limites
du budget.
Vous ne serez jamais un bon chef de projet si vous ne tenez pas l'échéancier du projet à jour.
Souvenez-vous que l'échéancier du projet est seulement un livrable. Il décrit le travail qui doit être
accompli, l'ordre des activités, l'effort de travail requis, les ressources humaines affectées, etc. Gérer
l’échéancier signifie que vous savez quel travail reste à accomplir, qui est chargé de le faire, et quand le
travail doit être fait, etc.
Diagramme de flux simplifié pour la gestion de l'échéancier

L’échéancier doit représenter votre meilleure hypothèse, à n’importe quel moment, sur la manière de
terminer le travail qui reste à faire. Plus votre projet est complexe, plus vous devrez effectuer, au fil du
temps, des changements dans votre « meilleure hypothèse ». C'est pourquoi la gestion de l’échéancier
du projet est une compétence si essentielle. Le chef de projet doit évaluer l'échéancier de manière
continue (généralement hebdomadaire) et déterminer l’état du projet. En vous basant sur cet état et
sur votre connaissance du travail qui reste à faire, vous devez tracer un programme qui permette de
terminer les travaux dans les limites du budget initial et des délais fixés.
169
Diagramme de flux simplifié pour la gestion du budget
Pour la plupart des projets, l'échéancier du projet doit être revu de façon hebdomadaire. Pendant cette
revue, le chef de projet fait concorder l'échéancier avec l’état actuel du travail accompli et celui en
cours. Le travail qui reste à faire doit être évalué, afin de vérifier si le projet pourra être accompli en
respectant les estimations initiales de l'effort de travail, du coût, et de la durée. Si cela est possible,
vous êtes sur la bonne voie. Sinon, le chef de projet doit entreprendre des actions correctives.
De toutes les qualifications exigées pour gérer un projet, la gestion de l'échéancier du projet est peut-
être la plus fondamentale. Suivant la dynamique du projet, le chef de projet peut être amené à utiliser
constamment son expérience et sa créativité pour réaliser le projet conformément aux attentes.
Pendant une semaine, tout peut bien se dérouler. Puis, la semaine suivante, vous pouvez avoir des
tâches qui sont en retard et des problèmes majeurs qui surgissent. Si une activité placée sur le chemin
critique accuse un retard d’une semaine, le chef de projet ne peut pas se permettre de se croiser les
bras et de laisser le projet entier prendre une semaine de retard. Il doit évaluer le personnel et les
options disponibles, et remettre le projet sur la bonne voie. Si vous êtes doué, la gestion de l'échéancier
du projet peut être un des aspects les plus motivants et les plus gratifiants du management de projet.
En revanche, si vous n’avez pas le goût du travail détaillé que cela demande, vous finirez par trouver
difficile de devenir un chef de projet qui réussit.
Début et clôture du projet (3.0. P2)
L’échéancier constitue le point de coordination central de la gestion et du contrôle du projet. Une fois le
projet défini et planifié, l’exécution effective du projet peut commencer et les livrables du projet
peuvent être créés. Cet ensemble d’activités est aussi appelé le cycle de vie du projet, qui est délimité
par deux événements : une réunion de lancement du projet qui marque le démarrage officiel du projet,
et un ensemble d’activités de clôture qui marquent la fin officielle du projet. Pour plus de détails voir
3.1A.3.1 Lancement du projet et 90.0 Clore le projet.
Intégrer le projet et les processus de management de projet (3.0. P3)
L’échéancier constitue le point focal de la gestion du projet, et tous les processus de gestion de projet
sont intégrés dans l’échéancier. Vous devez avoir des activités et du temps alloués dans votre
échéancier pour communiquer, gérer le contenu, mettre à jour l’échéancier et exécuter toutes les
autres activités de gestion du projet. L’intégration survient lorsque les processus de gestion de projet se
touchent, aussi bien que lorsque les activités du cycle de vie du projet s’entrecroisent.
170
3.0.1 Intégrer le projet et les processus de management de projet
3.1A Gérer l'échéancier / Processus
3.1B Gérer le budget / Processus
3.2A Gérer l'échéancier / Techniques
3.2B Gérer le budget / Techniques
3.3 Gérer l'échéancier et le budget / Références rapides
171
3.0.1 Intégrer le projet et les processus de management de projet
Lors du processus 1.0 Définir le travail, vous ne définissez pas seulement les caractéristiques du projet,
mais également votre plan global de management de projet. Cela inclut les processus pour la gestion
du contenu, des risques, des communications, de la qualité, etc.
Une fois le projet en cours, tous les processus de gestion du projet sont intégrés dans ce processus
réservé à la gestion de l’échéancier et du budget. L’intégration se fait à ce niveau en raison de la
philosophie primordiale de la méthodologie TenStep : « Ce qui figure dans l'échéancier du projet est à
accomplir ! » En d’autres termes, tout le travail du projet doit figurer dans l'échéancier du projet, et si
une activité n’y est pas, elle ne devrait pas être effectuée.
L'échéancier du projet est le point central du management de projet, et tous les processus de gestion
de projet y sont intégrés. Considérons les exemples suivants :
 Une grande modification du contenu est approuvée, ce qui implique un plus grand effort de
travail et plus de coûts. Il s’agit d'un exemple typique d'intégration du travail de management
de projet et du cycle de vie du projet. L’impact se reflète dans la mise à jour de l'échéancier du
projet et du budget.
 Vous identifiez des risques et vous élaborez un plan de gestion des risques pour les gérer. Vous
communiquez ce plan à toutes les parties prenantes intéressées pour une réaction en retour. Il
s’agit d’une intégration de la gestion des risques et de celle des communications. Étant donné
que tout ce travail demande du temps et de l’effort, les activités apparaissent dans l'échéancier
du projet et l’intégration a lieu durant l’exécution de ce processus.
 Vous avez un problème majeur concernant la mauvaise qualité. Vous activez le processus de
gestion des problèmes majeurs et toutes les activités appropriées sont intégrées à l'échéancier.
Pour résoudre ce problème, vous décidez de collecter plus métriques et les activités de collecte
des indicateurs sont ajoutées à l'échéancier du projet. L’analyse de ces indicateurs entraîne des
changements au niveau de vos processus de travail et entraîne des activités supplémentaires
de contrôle qualité. Vous communiquez les informations à toutes les parties prenantes
impliquées, afin de gérer leurs attentes. Tout ce travail doit apparaître dans votre échéancier et
dans votre budget.
Tout le travail du projet doit figurer dans l'échéancier et le budget. De ce fait, ce processus est celui où
le projet est géré et contrôlé; c'est le lieu où toutes les activités du cycle de vie et de la gestion du
projet sont planifiées, exécutées, suivies et intégrées.
Il ya un certain nombre d'aspects majeurs de ce travail d'intégration
3.0.1.1 Diriger et piloter l’exécution du projet
3.0.1.2 Surveiller et maîtriser le travail du projet
3.0.1.3 Mettre en œuvre la maîtrise intégrée des modifications
3.0.1.4 Gestion de la configuration
172
3.0.1.1 Diriger et piloter l’exécution du projet
Dès que le projet a été planifié, il est temps de commencer l’exécution de son cycle de vie. À ce niveau,
le chef de projet intègre deux groupes de processus de management de projet. Certains de ces
processus font partie du groupe de processus d'exécution et d’autres du groupe de processus de
surveillance et maîtrise. Cette section est consacrée au groupe de processus d'exécution.
Les processus de management de projet du groupe de processus d'exécution sont accomplis pro
activement par le chef de projet. Par exemple, la gestion des problèmes est un processus proactif de
gestion de projet. Il n’existe pas une référence de base pour les problèmes. Lorsqu’un problème
survient, le chef de projet doit l’affronter à l'aide d'un processus de gestion de problèmes. Les
processus de recrutement, de développement et de gestion de l'équipe de projet sont des processus de
management de projet d'exécution. Il n’existe pas une référence de base dans ces domaines. Le chef
de projet doit effectuer ce travail pro activement. L’assurance qualité (AQ) est aussi un exemple d’un
processus de management de projet d'exécution. L’assurance qualité s’assure que le projet a de bons
processus qualité en place. Il n’existe pas une référence de base pour cela et ce travail doit être fait à
l’avance et pro activement – pas en réaction à un événement.
Tout ce travail de management de projet du groupe de processus d'exécution se consigne dans

l’échéancier. Consigner ces activités de management de projet dans l’échéancier permet de s’assurer
que le travail d’exécution est intégré comme il se doit.
173
3.0.1.2 Surveiller et maîtriser le travail du projet
Dès que le projet a été planifié, il est temps de commencer l'exécution de son cycle de vie. À ce niveau,
le chef de projet intègre deux groupes de processus de management de projet. Certains de ces
processus font partie du groupe de processus d'exécution et d'autres du groupe de processus de
surveillance et maîtrise. Cette section est consacrée au groupe de processus de surveillance et maîtrise.
Les processus de management de projet de surveillance et maîtrise commencent de manière classique

par l'établissement d'une référence de base.
Le chef de projet suit les résultats réels du projet et compare lesdits résultats avec la référence de
base. S’il apparaît un écart inacceptable entre les résultats et la référence de base, le chef de projet
doit réagir pour ramener les résultats à un niveau conforme à la référence de base (ou alors obtenir
l’approbation pour modifier la référence de base).
Par exemple, la gestion du contenu est un processus de surveillance et maîtrise de la référence de base
du contenu du projet. Si le contenu produit diverge de ce qu'est établi dans la référence de base du
contenu, le chef de projet fait appel à la gestion des modifications de contenu. De même, dans le
processus de planification vous construisez une référence de base de l'échéancier. Vous avez besoin de
surveiller la progression réelle du projet par rapport à la référence de base de l’échéancier. Si vous
demeurez dans l’échéancier et votre échéancier réel continue de représenter l’itinéraire de réalisation
du projet tel qu'approuvé dans la référence de base, vous n'aurez pas besoin d'actions correctives. Mais
si vous détectez un écart par rapport à la référence de base de l'échéancier, des actions correctives
peuvent s’avérer nécessaires. D’autres processus de surveillance et maîtrise comprennent la gestion du
budget selon une référence de base, la gestion des risques selon une référence de base ainsi que la
gestion des fournisseurs selon les contrats.
Tout ce travail de management de projet du groupe de processus de surveillance et maîtrise se

consigne dans l’échéancier. Consigner ces activités de management de projet dans l'échéancier permet
de s'assurer que le travail de surveillance et maîtrise est intégré comme il se doit.
174
3.0.1.3 Mettre en œuvre la maîtrise intégrée des modifications
Effectuer la maîtrise intégrée des modifications (3.0.1.3. P1)
Les grands projets devraient appliquer plus de diligence tout au long du processus du management des
modifications. Les modifications n'arrivent pas toujours par ordre. Dans plusieurs cas, il peut être
difficile de comprendre la nature d'une modification et son impact sur les différents aspects du projet.
Par exemple une petite demande pourrait entrer dans le projet et occasionner une modification du
contenu. La demande de modification du contenu pourrait mener à une demande d'augmentation de
l'échéancier et du budget. La demande pourrait affecter les types de ressources nécessaires au projet
et cela pourrait affecter un contrat de fournisseur. Le chef de projet devrait comprendre la nature de la
modification et comment celle-ci pourrait affecter tous les autres aspects du projet.
Ceci constitue l'objectif de la maîtrise intégrée des modifications, un processus général qui contient les
modifications du contenu les plus spécifiques, les modifications de la configuration ainsi que les
processus de management des modifications générales. La maîtrise intégrée des modifications inclut les
activités suivantes :
 S'assurer de l'existence des références de base mises en place (contenu, budget, échéancier,
etc.) de manière à ce qu'il soit plus évident qu'une modification ait eu lieu.
 Observer les causes des modifications pour voir si celles-ci peuvent (ou doivent) être éliminées.
Par exemple, si vous croyez recevoir beaucoup trop de demandes de modification du contenu,
ceci pourrait refléter un faible processus de collecte des exigences.
 S'assurer qu'aucune modification n'est impliquée à moins qu'elle ait été approuvée.
 S'assurer de la mise en place de processus pour gérer le contenu. Le niveau de formalité du

processus d'approbation augmente suivant la taille du projet et celle de la modification
potentielle.
 S'assurer que toute l'équipe du projet, y compris le client, comprend les processus de
management des modifications et les respecte.
 S'assurer que la documentation appropriée est créée et enregistrée pour chaque modification.
 Comprendre comment les modifications affectent tous les aspects relatifs du projet et s'assurer
de la mise à jour de toute la documentation appropriée.
 S'assurer de la disponibilité d'une personne ou d'une entité qui approuve ou rejette toutes les
demandes de modifications.
 S'assurer que toutes les demandes de modifications sont clôturées soit par l'acceptation de la
modification soit par leur rejet.
 Communiquer les modifications et l'impact sur le projet aux parties prenantes appropriées.
175
3.0.1.4 Gestion de la configuration
Il existe deux définitions importantes de la gestion de la configuration.
1. Il peut s'agir d'une expression désignant l'identification, le suivi et la gestion de tout l'actif du projet.
Cette définition serait particulièrement pertinente lors des projets d'élaboration de logiciels, là où le
terme "configuration" se réfère à l'ensemble des artefacts, composants programmés, exécutables, etc.
Les éléments dont vous assurez le suivi dans le cadre de la gestion de la configuration sont appelés
"éléments de configuration" dans le modèle CMMI. Ces éléments de configuration peuvent être
interprétés de manière générale pour inclure, par exemple:
o La documentation et les livrables du projet
o Les descriptions de livrables et les modèles (gabarits)
o Les éléments de conception
o Le code source, et dans ce cas, votre processus de gestion de la configuration doit inclure votre
processus de gestion des modifications du logiciel (*)
o Les scénarii de tests, les plans de tests et les cas de tests, etc. (**)
o Le matériel et le logiciel
o Vos livrables finaux (c'est-à-dire le logiciel)
o D'autres biens physiques du projet, y compris les garnitures, les matériaux auxiliaires, les
machines, etc.
(*) Notes du traducteur:
o (*) Un "code source" est la version originale d'un programme, d'un logiciel écrit dans un
langage compréhensible par un humain, soit le ou les programmeur(s). Ce texte pourra soit
être interprété, soit compilé par ordinateur. En bref, ce sont les fichiers textes nécessaires à la
compilation.
o (**) Un "cas de test" (test case) dans le domaine de l'ingénierie des logiciels est un ensemble
de conditions ou variables pour déterminer si une exigence posée à la solution informatique est
pleinement ou partiellement remplie.
2. C'est aussi une expression désignant l'identification, le suivi et le management des métadonnées
(***) utilisées pour décrire les caractéristiques fonctionnelles et physiques du produit ou d'un
composant que le projet est en train de créer. Ceci est plus proche de la définition du management de
la configuration utilisée par l'Institut du Management de Projet (PMI). Dans cette définition, la
confirmation d'un actif se rapporte fondamentalement aux caractéristiques détaillées et fonctionnalités
associées avec l'actif. Par exemple, si le résultat de votre projet est la fabrication d'un ordinateur
portable, la configuration désignerait la taille du disque dur, sa rapidité, les spécifications du driver du
disque numérique polyvalent (aussi appelé "DVD"), etc.
Note du traducteur: (***) une métadonnée (mot composé du préfixe grec "meta" indiquant
l'autoréférence; le mot signifie donc proprement « donnée de/à propos de donnée ») est une donnée
servant à définir ou décrire une autre donnée quel que soit son support (papier ou électronique).
Beaucoup de projets, pour ne pas dire la plupart, ne tiennent pas compte de la gestion des biens
physiques utilisés par le projet, comme les équipements ou les matières premières. Ce type de gestion
est généralement fourni par des services centralisés de l'organisation. Ainsi, par exemple, le suivi et la
gestion des ordinateurs utilisés par un projet sont effectués, généralement, au niveau de l’entreprise ou
d'un département de celle-ci. Le chef de projet qui a besoin d'ordinateurs pour l'équipe, ne doit ni gérer
ni assurer le suivi de ces biens.
176
Si votre projet se soucie du suivi des biens, ce suivi est généralement effectué en dehors du domaine
du chef de projet; il est plutôt pris en charge par des spécialistes au sein de l'équipe. Par exemple, si
votre projet consiste à construire un avion, le suivi du matériel est vital. Cependant, des spécialistes au
sein de l'équipe sont chargés de gérer cet aspect du projet. Si vous travaillez sur un projet de
développement de logiciel, vous devez surveiller et maîtriser les modifications du logiciel. Cependant, il
existe des outils de gestion des modifications de logiciels qui peuvent effectuer cette gestion.
Tout cela étant dit, certains très grands projets ont besoin de gérer la configuration, et s'ils le font, le
processus peut être géré au moyen de plusieurs techniques qui figurent dans cette section de gestion
du contenu.
Les éléments suivants constituent le processus de gestion de la configuration:
 La planification. Vous devez planifier à l'avance l'élaboration de processus, de procédures,

d'outils, de fichiers et de bases de données pour gérer la configuration. Vous devez aussi
obtenir un accord sur l'importance qui doit leur être accordée, la manière de les définir, les
catégories qui doivent les regrouper, la manière de les classer, de les compter, de faire des
rapports à leur sujet, etc. Les résultats de cette planification préalable sont consignés dans le
plan de gestion de la configuration.
La est une part importante de la gestion de la configuration, du fait que les éléments en
question peuvent être définis de plusieurs manières. Il est possible que votre définition
comporte seulement des métadonnées ou des informations sur les actifs, et non les actifs réels
eux-mêmes.
Une partie de votre processus de planification consistera à attribuer des numéros de suivi dans
la configuration à chaque type d'élément de configuration.
 Le suivi. Il est important de comprendre l'état de départ pour tous les éléments de
configuration. En d'autres termes, pour chaque élément de configuration, vous devez savoir ce
que vous avez au commencement du projet. Dans de nombreux cas, vous ne disposez
d’aucune information pour commencer. L'objectif de vos processus de suivi est de vous assurer
que vous pouvez suivre toutes les modifications que subit un élément de configuration tout au
long du projet.
Vous avez besoin de processus et de systèmes conçus pour savoir à quel moment des biens
sont affectés à votre projet, où ils iront, ce qu'ils deviendront, qui en est responsable et
comment ils seront disposés. Comme un projet a concrètement un début et une fin, en
définitive, tous les biens doivent aller quelque part. Cela peut être dans un livrable, dans le
secteur opérationnel ou au support, à la casse , etc. Vous devez être capable de disséquer
chaque livrable du projet et de montrer d'où proviennent toutes les pièces et toutes les parties,
et où elles se retrouveront une fois le projet terminé.
Les mêmes idées s'appliquent si vous êtes en train d'effectuer le suivi des métadonnées de
l'actif à travers la gestion de la configuration. Vous devez comprendre le point de départ de la
configuration et effectuer le suivi des modifications qui sont survenues durant le projet. Ces
propos pourraient être plus détaillés. Par exemple, si vous êtes en train de fabriquer un
ordinateur portable, l'apparition d'une exigence supplémentaire, disons pour garantir la
compatibilité de l'ordinateur portable avec un nouveau matériel, peut entraîner des dizaines ou
encore des centaines de modifications par rapport à la configuration préalable de l'ordinateur
portable.
 La gestion. Gérer les biens signifie qu'ils sont en sécurité, qu'ils sont protégés et utilisés pour
des objectifs appropriés. Par exemple, il ne sert à rien d'assurer le suivi de biens acquis alors
que votre projet n'en a pas besoin en premier lieu. De même, votre système de suivi peut
démontrer que des éléments coûteux traînent dans un lieu de stockage non sécurisé, mais est-
ce vraiment le lieu qui leur convient? Gérer les biens revient à acquérir ce dont vous avez
besoin et seulement ce dont vous avez besoin. Vous devez aussi vous assurer que les biens
nécessaires se trouvent à la place l’endroit souhaitée, au moment voulu.
 Établir des rapports. Vous devez être capable de diffuser les informations concernant l'état
177
de la configuration, généralement pour déterminer quels éléments sont en votre possession, où
ils se situent et dans quel état; vous devez aussi établir des rapports financiers au sujet de leur
coût, de leur budget, de leur dépréciation, etc.
Si vous effectuez le suivi de la configuration au moyen de méta-données vous serez en mesure

de créer un rapport complet concernant les exigences du produit en question à n'importe quel
moment du projet.
 L'audit. L'audit, dans ce contexte, consiste à confirmer que les éléments de configuration réels
(quels qu'ils soient) à n'importe quel moment donné, correspondent à ce à quoi vous vous
attendiez. De nombreux projets connaissent des difficultés parce qu'ils commencent à ne plus
maîtriser le suivi des biens physiques (par exemple, du matériel, des provisions, le code ou
d'autres éléments de configuration), ou bien parce que les caractéristiques physiques
(métadonnées) des livrables sont différentes de ce qui était attendu. Le processus d'audit est
utilisé pour valider que les éléments de configuration correspondent à vos attentes. Ces
attentes sont fondées sur la ligne de base initiale, à quoi s'ajoute toute demande de
changement à laquelle vous avez procédé jusque-là. Si vos éléments de configuration
comportent des descriptions et d'autres métadonnées, vous devriez valider que les descriptions
et les caractéristiques sont compatibles avec la manière dont les livrables sont réellement
conçus.
Si les audits ne donnent pas les résultats escomptés, cela voudrait dire que votre processus de
suivi de la configuration est inadéquat et que vous devez améliorer vos processus pour prendre
en compte toutes les modifications. Vous devriez identifier les façons de changer votre
configuration, au fil du temps, et vérifier que vous êtes en train d'intégrer toutes ces
circonstances dans votre processus de suivi de la configuration.
Les audits de la configuration sont difficiles et coûteux en personnel et en temps. Cependant, ils
sont vitaux pour s'assurer que la solution définitive est complète et correcte et que vous avez
pris en considération tous les biens de la configuration qui ont été utilisés pour élaborer la
solution définitive.
Il est important que la totalité du processus de configuration soit validé périodiquement au

travers d’audits de situation des éléments de la configuration. Cela inclut le fait d'inspecter
physiquement, de compter et de comparer ces éléments avec les résultats attendus de votre
système de gestion de la configuration. Vous devriez aussi procéder à un audit du processus de
modification de la configuration pour vous assurer que les processus appropriés sont appliqués.
Si vous pratiquez la gestion de la configuration dans votre projet, nous vous suggérons d’affecter une
personne spécifique à la fonction de gestionnaire de configuration. Il peut s’agir d’un poste à temps
partiel, en fonction de la quantité des éléments à suivre et à gérer pour votre projet. Cette personne est
responsable du processus global, et doit se concentrer sur les responsabilités de planification, de
gestion et d'audit. Si votre projet est suffisamment important, vous pouvez également affecter un
responsable à la bibliothèque virtuelle de configuration. Il s’agit d’un poste administratif qui s’articule
autour du travail sur le terrain et de pointage nécessaire aux responsabilités de rapport et de suivi.
Selon la taille du projet, vous pouvez avoir besoin d’un comité de configuration spécifique composé de
responsables et d’employés haut placés. Ce comité de configuration sera amené à approuver le plan
global de configuration et les éléments de cette dernière. Il peut aussi approuver les grandes
modifications spécifiques des éléments qui se produisent dans le cadre de votre processus de gestion
de la configuration.
Naturellement, si votre projet (ou programme) est suffisamment important, par exemple la construction
d’un avion, un service entier devra vraisemblablement effectuer ce travail, peut-être sous la direction
du service des achats et approvisionnements.
178
3.1A Gérer l'échéancier / Processus
Vous devez accorder beaucoup d'intérêt à l’élaboration de l'échéancier du projet pour être sûr de
trouver la bonne voie pour l’exécution de votre projet. Une fois que vous avez élaboré l'échéancier, le
défi pour vous est de le gérer de telle sorte que vous soyez sûr qu'il reflète la réalité actuelle du projet
et qu'il continue à montrer un chemin clair qui mène vers la fin du projet. Le chef de projet devra
employer un des processus généraux suivants pour gérer l'échéancier et le budget, en fonction de la
taille du projet.
3.1A.1 Petits projets
3.1A.2 Projets moyens
3.1A.3 Grands projets
179
3.1A.1 Gérer l’échéancier / Petits projets
On ne trouve pas beaucoup d'activités dans l'échéancier des petits projets, et souvent le budget est très
petit. Il est probable que vous n'utilisiez pas un logiciel de planification mais plutôt un tableur ou une
simple liste de tâches. Ainsi, on ne requiert pas beaucoup de rigueur et de structure pour ce processus.
Cependant, vous devriez adopter comme discipline de vous assurer que votre échéancier est tenu à
jour et que vous pouvez gérer la situation s'il s'avère que votre échéancier a tendance à dépasser les
délais estimés.
Rôle Gérer l’échéancier (Petits projets)
1 Chef de projet Mettre à jour l'échéancier chaque semaine

Identifier les activités qui ont été accomplies pendant la semaine
précédente et mettre à jour l'échéancier du projet pour montrer qu’elles
sont terminées.
2 Chef de projet, Déterminer la situation de l’échéancier

membres de Déterminer s'il y a des activités qui devaient être accomplies mais qui ne
l’équipe l'ont pas été. Si une activité est en retard, travaillez avec les personnes qui
en ont la charge pour vérifier ce qui se passe.
3 Chef de projet Valider le travail en cours et assigner de nouvelles tâches

Validez l’état du travail qui est en cours pour chaque membre de l'équipe et
assignez un nouveau travail à chacun, comme il est indiqué dans
l’échéancier. Essayez d’obtenir un engagement de la part de chaque
membre de l'équipe pour mener à terme les travaux dans les délais, dans
la durée et dans la limite du budget fixé. Cela demande que chaque
membre de l'équipe consacre un certain temps à la tâche qui lui a été
assignée avant de pouvoir valider ou invalider les estimations. (Voir
3.1A.3.3 Valider l’estimation du travail avec l’équipe).
4 Chef de projet Déterminer si vous terminerez le travail conformément aux

attentes
Évaluez le travail qu’il reste à accomplir pour constater s’il sera terminé
conformément aux estimations initiales d'effort de travail, de durée et de
coût. Vous constaterez probablement que certaines activités sont en retard
alors que d’autres seront terminées plus tôt que prévu.
5 Chef de projet Valider le travail qu’il reste à faire

Mettez l’échéancier au point de manière à ce qu’il reflète le travail qu’il
reste à accomplir.
6 Chef de projet, Prendre des mesures correctives si nécessaire

commanditaire Comme il s’agit du processus pour un petit projet, il est peu probable que
vous ayez de gros problèmes concernant les délais. Si l’échéancier est
important, vous êtes dans l’obligation de vous y conformer. Vous pouvez
utiliser certaines des techniques de maîtrise de l’échéancier décrites pour
les grands projets. Dans le cas où vous deviez demander une prolongation
des délais originellement convenus, l'équipe doit absolument respecter les
nouvelles attentes.
180
3.1A.2 Gérer l’échéancier / Projets de taille moyenne
(3.1A.2. P1)
Rôle Gérer l’échéancier (Projet de taille moyenne)
1 Chef de Passer en revue l'échéancier du projet de façon régulière.

projet Pour un projet moyen, il s’agit probablement encore d’un processus
hebdomadaire. Pour de plus grands projets, la fréquence peut être de deux
semaines. Ne mettez pas à jour l'échéancier du projet moins fréquemment que
toutes les deux semaines. Une fréquence de revue mensuelle est trop longue.
Il y a trop de travail qui est effectué en un mois, et s'il y a des problèmes, trop
de temps sera passé avant qu’ils soient identifiés. Lors du passage en revue de
l'échéancier du projet, le chef de projet rassemble les informations sur la
situation auprès de chaque membre de l’équipe et met à jour l'échéancier du
projet pour faire apparaître les activités réalisées depuis le dernier point sur la
situation.
2 Chef de Saisir les heures réelles et les mettre à jour (facultatif).

projet, Si le Chef de projet procède à la saisie des heures et des coûts d'effort réels,
membres mettez à jour l’échéancier avec ces informations Les données concernant les
de l’équipe heures d'effort réelles et la situation du projet peuvent provenir des membres
de l’équipe, à travers des rapports et/ou des réunions d’examen de la situation.
Vous pouvez également automatiser le processus en utilisant un outil
d’établissement de l’échéancier, de sorte que les membres de l’équipe puissent
mettre à jour le programme directement avec leurs heures d'effort et l’état
d'avancement des travaux.
3 Chef de Reprogrammer le projet.

projet Après avoir mis l’échéancier à jour pour rendre compte de la réalité courante,
reprogrammez le travail pour voir si le projet sera accompli dans les limites
de l'effort, du coût et de la durée initialement prévus. Vous constaterez que
quelques activités se termineront plus tard que prévu, alors que d'autres seront
terminées plus tôt. Il peut également y avoir des activités qui prennent du
retard mais qui ne sont pas sur le chemin critique; dans ce cas on peut encore
prévoir que le projet sera achevé à temps.
4 Chef de Passer en revue la situation par rapport à votre échéancier.

projet, Vérifiez s'il y a d’autres activités qui devraient être accomplies, mais qui ne
membres l'ont pas été. Ces informations peuvent être recueillies en éditant le rapport
de l’équipe approprié du logiciel de gestion de projet. S’il y a des activités qui sont en
retard, travaillez avec les personnes qui en ont la charge pour voir ce qui se
passe. Il pourrait y avoir des problèmes qui devraient être résolus, ou bien
vous constaterez que la durée nécessaire pour accomplir l'activité a été sous-
estimée. Le chef de projet et les membres de l’équipe doivent savoir quel sera
l'effort de travail supplémentaire, et quelle durée sera nécessaire pour terminer
les travaux ; ensuite, le chef de projet devra mettre à jour l'échéancier du
projet en conséquence.
5 Chef de Rechercher d'autres signes montrant que le projet pourrait

projet rencontrer des difficultés.
Une fois que vous ayez rééchelonné votre projet, vous allez déterminer si vous
avez tendance à dépasser les délais, car il se peut que vous rencontriez
d'autres signes vous montrant que votre projet court des problèmes. Les
181
signes de difficultés peuvent être de différentes sortes :
 De petits écarts qui se font de plus en plus grands, en particulier au
début du projet.
 Vous découvrez que des activités que vous pensiez être déjà
accomplies sont toujours en cours d'exécution.
 Vous devez avoir recours à des heures supplémentaires non
programmées, pour respecter les délais, particulièrement au début du
projet.
 La qualité des livrables ou des services commence à se détériorer.
 Les étapes de contrôle qualité, les activités de tests et le temps
consacré au management de projet commencent à être raccourcis par
rapport au programme original.
Si ces situations commencent à se produire, améliorez la visibilité par la
gestion des risques. Mettez en place un plan des risques pour vous assurer de
manière proactive que le projet reste sur les rails. Si vous ne pouvez pas gérer
avec efficacité les problèmes, considérez que vous êtes face à un problème
majeur. (Voyez le chapitre 3.2 Gérer l'échéancier et le budget / Techniques
pour trouver des idées sur la façon de résoudre un dépassement de budget ou
de remettre sur les rails un projet qui a du retard).
6 Chef de Évaluer le chemin critique du projet.

projet Le chemin critique est la séquence d’activités qui doivent être accomplies à
temps pour que le projet entier puisse être réalisé à temps. (Pour plus
d'informations sur le chemin critique, lisez le paragraphe 2.1A.6 Le chemin
critique.) Si la date de fin dérape, ce sera parce qu'au moins une activité
placée sur le chemin critique n'a pas été accomplie à temps. Il est important de
comprendre le chemin critique pour savoir sur quelles activités il faut se
concentrer si le projet a tendance à dépasser sa date limite. Affecter du
personnel supplémentaires à des activités qui ne sont pas sur le chemin
critiques n'aura pas comme conséquence une exécution plus rapide du projet.
Même si vous croyez connaître le chemin critique, il est possible que ce
dernier change durant le projet. Vous pouvez essayer d’accélérer les activités
qui étaient sur le chemin critique pour ramener le projet dans les délais, mais
si celui-ci a changé, cela n'aura pas le résultat escompté.
7 Chef de Assigner le travail aux membres de l'équipe

projet Après avoir mis à jour l'échéancier et le budget, validé la situation du projet et
le chemin critique, et exécuté toutes les activités antérieures de gestion de
l'échéancier, vous devriez examiner l'échéancier pour voir quel travail doit être
effectué au cours des une à trois semaines qui suivent. Ce travail doit être
assigné aux membres appropriés de l’équipe, pour exécution. La mise à jour
des affectations des tâches peut se faire au cours des réunions de revue de
projet. Cependant, il est important que tous les membres de l'équipe sachent
quel travail leur est affecté et quand il doit être achevé. Demandez à chaque
membre de l'équipe l’engagement de terminer le travail dans le temps, la
durée et le budget alloués. Chaque membre de l'équipe consacrera un certain
temps à la tâche qui lui est assignée, avant de pouvoir valider ou invalider les
estimations. (Voyez 3.1A.3.4 Valider l'estimation du travail avec l'équipe).
8 Chef de Communiquer au sujet de tous les risques associés à l'échéancier

projet Dès que vous sentez qu’il y a un risque de dépassement de la date limite, vous
devriez le faire savoir au commanditaire et aux parties prenantes au niveau de
la hiérarchie. Vous ne devez pas déclarer que vous passerez à coup sûr à côté
de vos estimations. Cependant, commencez à communiquer sur le risque, de
telle sorte que vous puissiez mettre en application les actions correctives pour
remettre le projet sur la bonne voie. Si vous êtes sûr que les engagements en
182
cours ne pourront être tenus, de nouvelles estimations devront être préparées
et communiquées à votre direction et au commanditaire. Ce sont des
informations importantes parce qu'il peut y avoir des secteurs où elles
pourraient éventuellement servir. Par exemple, le commanditaire peut accepter
de réduire les exigences restantes pour permettre au projet d'être accompli
conformément aux estimations initiales.
Clôture des travaux (3.1A.2. P2)
Rôle Clore le cycle de vie du projet
9 Chef de Clore le travail

projet Lorsque le travail est achevé, il faut que vous incorporiez les activités liées à la
clôture officielle de votre projet dans votre échéancier. Le chef de projet ne
devrait pas considérer le projet comme entièrement finalisé jusqu’à ce que ces
activités de clôture de projet soient accomplies. Vous devriez montrer le même
niveau de discipline, en clôturant le projet, que lors de l'exécution du projet. Voir
90.0 Clore le projet, pour avoir plus de détails.
183
3.1A.3 Gérer l'échéancier / Grands projets
Lancer le cycle de vie du projet (3.1A.3. P1)
Rôle Lancer le cycle de vie du projet (exécution) (Grand projet)
Tenir une réunion de démarrage du projet

Chef de
1 projet, équipe Commencez l’exécution du cycle de vie du projet avec une réunion de lancement
du projet de projet. Voir 3.1A.3.1 Gérer l’échéancier / Lancement du projet pour avoir plus
de détails.
Maîtriser l’échéancier (3.1A.3. P2)
Rôle Gérer l’échéancier et le budget (projets de taille moyenne et grands

projets)
2 Chef de Passer en revue l'échéancier du projet de façon régulière

projet
Pour un projet moyen, il s’agit le plus souvent d’un processus hebdomadaire.
Pour de plus grands projets, la fréquence peut être de deux semaines. Ne
mettez pas à jour l'échéancier du projet moins fréquemment. Une fréquence
de revue mensuelle est trop longue. Il y a trop de travail qui a été effectué, et
s'il y a des problèmes, trop de temps sera écoulé avant qu’ils ne soient
identifiés. Lors du passage en revue de l'échéancier du projet, le chef de
projet rassemble les informations relatives à la situation auprès de chaque
membre de l’équipe et met à jour l'échéancier du projet pour mettre l’accent
sur les activités réalisées durant la période précédente.
3 Chef de Saisir les heures d'effort réelles et les mettre à jour (facultatif)
projet,
Si le Chef de projet procède à la saisie des heures et des coûts d'effort réels,
membres
mettez à jour l’échéancier avec ces informations. Les données sur les heures
de l’équipe
d'effort réelles et la situation du projet peuvent provenir des membres de
l’équipe. Elles sont consignées dans des rapports sur la situation et/ou des
réunions d’examen de la situation. Vous pouvez également automatiser le
processus en utilisant un outil d’établissement de l’échéancier, de sorte que les
membres de l'équipe puissent directement mettre à jour l'échéancier avec
leurs heures d'effort et l’état d'avancement des travaux.
4 Chef de Reprogrammer le projet

projet
Après que l'échéancier du projet ait été mis à jour pour mettre en évidence la
réalité en cours, planifiez à nouveau le travail afin de vérifier si le projet peut
être accompli dans le cadre de l'effort de travail, de coût et de durée initiaux.
Vous trouverez peut-être que certaines activités seront accomplies plus tard
que prévu, alors que d'autres peuvent être accomplies plus tôt. Il se peut qu’il
y ait des activités en retard qui ne sont pas sur le chemin critique. Dans ce
cas, on prévoit encore que le projet peut être accompli dans les délais.
5 Chef de Passer en revue la situation de l'échéancier

projet,
Vérifiez s'il y a d’autres activités qui devraient être accomplies, mais qui ne
membre de
l'ont pas été. Ces informations peuvent être recueillies en éditant le rapport
l’équipe
adéquat à partir du logiciel de gestion de projet. S’il y a des activités qui sont
en retard, travaillez avec les personnes qui y en ont la charge pour voir ce qui
184
se passe. Il pourrait y avoir des problèmes qui devraient être résolus ou bien
vous constaterez que la durée nécessaire pour accomplir l'activité a été sous-
estimée. Le chef de projet et les membres de l’équipe doivent savoir quel
effort de travail supplémentaire et quelle durée seront nécessaires pour mener
à terme les travaux ; ensuite, le chef de projet devra mettre à jour l'échéancier
du projet en conséquence.
6 Chef de Effectuer des analyses complémentaires de la gestion de l'échéancier

projet
Lancez, à l’aide de l’outil de gestion de projet, des rapports complémentaires
pour vous aider à savoir comment le projet est en train de progresser. Par
exemple, examinez l'affectation du personnel pour vous assurer que des
membres de l’équipe ne soient pas surchargés ou sous chargés. Le projet peut
sembler être dans les délais, par exemple, parce qu'une partie des membres
de l’équipe sont assignés durant 80 heures par semaine. Si vous avez
sauvegardé une version de base de l'échéancier du projet, vous pouvez
également faire des rapports comparatifs pour identifier les variations. Bien
qu’il y ait des centaines de rapports de planification disponibles, les chefs de
projets n'utilisent généralement qu'une poignée de rapports pour gérer
l'échéancier du projet avec succès.
Rechercher les signes de troubles (3.1A.3. P3)
7 Chef de Rechercher d'autres signes montrant que le projet pourrait

projet rencontrer des difficultés
Une fois que vous ayez rééchelonné votre projet, vous allez déterminer si vous
avez tendance à dépasser les délais, car il se peut que vous rencontriez
d'autres signes vous montrant que votre projet court des problèmes. Vous
devez surveiller et contrôler la totalité du projet pour vous assurer que vous
comprenez la situation en cours, le changement par rapport à la situation qui
prévalait auparavant et toutes les tendances qui risquent d’avoir
ultérieurement un impact sur votre projet. Vous cherchez, ainsi, à examiner
l’état de santé général du projet et à savoir s’il y a des secteurs qui méritent
plus d’attention.
Il y a différentes sortes de signes de difficultés :
 Des activités qui ont tendance à dépasser le budget ou à prendre du
retard par rapport à l’échéancier, dès le début du projet. Vous aurez
tendance à penser que vous pouvez redresser la situation, mais,
généralement, cette situation est un avertissement signifiant que vous
allez avoir de plus en plus de difficultés.
 De petits écarts qui se font de plus en plus grands, spécialement au
début du projet.
 Vous découvrez que des activités que vous pensiez être déjà
accomplies sont toujours en cours.
 Vous devez avoir recours à des heures supplémentaires non
programmées pour respecter les délais, particulièrement au début du
projet.
 Le moral de l'équipe est en baisse.
 La qualité des livrables ou des services commence à se détériorer.
 Les activités de contrôle qualité, les activités de tests et le temps
consacré au management de projet commencent à être raccourcis par
rapport au programme initial.
185
Si ces situations commencent à se produire, le chef de projet doit améliorer la
visibilité par la gestion des risques. Vous devriez en même temps mettre en
place un plan des risques pour vous assurer de manière proactive que le projet
demeure sur les rails. Si vous ne pouvez pas gérer avec efficacité les
problèmes, considérez que vous êtes face à un problème majeur. (Voyez le
chapitre 3.2A Gérer l'échéancier / Techniques pour trouver des idées sur la
façon de résoudre un dépassement de budget ou de remettre sur les rails un
projet qui a du retard).
L’état de santé courant du projet, les problèmes courants et les risques
doivent tous être intégrés à votre processus de rapport sur la situation.
8 Chef de Mettre au point l'échéancier et ajouter plus de détails lors des

projet prochains travaux
Mettez l'échéancier du projet à jour afin d’avoir une idée sur la manière avec
laquelle le reste du travail sera accompli. Une fois par mois, ajustez les
prochaines activités inscrites sur l'échéancier de manière à ce qu’il reflète les
informations supplémentaires dont vous avez maintenant connaissance.
Lorsque l'échéancier du projet a été élaboré, plusieurs activités appelées à se
dérouler dans le futur, sont restées vagues et placées sur l'échéancier avec
peu de précision. A une fréquence mensuelle, ce travail doit être défini avec
plus de détails. La planification pour le prochain trimestre ne devrait comporter
que des activités ou des tâches n’exigeant qu’un effort inférieur à 80 heures
chacune (et si possible, inférieur même à 40 heures d'effort). S'il y a, dans ce
créneau de trois mois, un travail d'un niveau supérieur à 80 heures d'effort,
découpez-le à un niveau de détail plus poussé.
Notez que le processus décrit ci-dessus se rapporte à un travail identifié dès le
début comme nécessitant des informations plus détaillées. Il n'y a pas lieu
d'ajouter un nouveau travail, car un tel ajout se fait en suivant le processus
5.0 Gérer le contenu.
9 Chef de Évaluer le chemin critique du projet

projet
Le chemin critique est la séquence d’activités qui doivent être accomplies à
temps pour que le projet entier puisse être réalisé dans les délais. (Pour plus
d'informations sur le chemin critique, lisez le paragraphe 2.1A.6 Chemin
critique). Si la date de la fin a dérapé, c'est parce qu'au moins une activité
placée sur le chemin critique n'a pas été accomplie à temps. Il est important
de comprendre le chemin critique pour savoir sur quelles activités il faut se
concentrer si le projet a tendance à dépasser sa date limite. Affecter du
personnel supplémentaire à des activités qui ne sont pas sur le chemin critique
n'aura pas comme conséquence une exécution plus rapide du projet. Même si
vous croyez connaître le chemin critique, il est possible que ce dernier dévie
durant le projet. Vous pouvez essayer d’accélérer les activités qui étaient sur le
chemin critique pour ramener le projet dans les délais, mais si celui-ci a dévié,
cela ne donnera pas le résultat escompté.
Affecter le travail aux membres de l’équipe (3.1A.3. P4)
10 Chef de Assigner le travail aux membres de l'équipe

projet Après avoir mis à jour l'échéancier et le budget, validé l’état du projet et le
chemin critique, et exécuté toutes les activités antérieures de management de
l'échéancier, vous devriez vérifier l'échéancier pour voir quel travail doit être
effectué au cours de l’une ou des trois semaines à venir. Ce travail doit être
assigné aux membres appropriés de l’équipe, pour exécution. La mise à jour
des affectations des tâches peut se faire au cours des réunions de revue de
186
projet. Cependant, il est important que tous les membres de l'équipe sachent
quel travail leur est assigné et la date de son achèvement. Demandez à
chaque membre de l'équipe de s’engager de finir le travail dans les délais, de
respecter la durée, de ne pas dépasser les limites du budget alloué. Chaque
membre de l'équipe consacrera un certain temps à la tâche qui lui est assignée
avant de pouvoir valider ou invalider les estimations. (Voyez 3.1A.3.4 Valider
l'estimation du travail avec l'équipe).
11 Chef de Communiquer au sujet de n'importe quel risque de l’échéancier

projet Dès que vous sentez qu’il y a un risque de dépassement de la date limite, vous
devriez le faire savoir au commanditaire et aux parties prenantes au niveau de
la hiérarchie. Vous ne devez pas déclarer que vous allez passer à coup sûr à
côté de vos estimations. Cependant, commencez à communiquer sur le risque,
de telle sorte que vous puissiez mettre en application les dispositions
nécessaires pour remettre le projet sur la bonne voie. Si vous êtes sûr que les
engagements ne pourront être tenus, de nouvelles estimations devront être
préparées et communiquées à votre direction et au commanditaire. Ce sont
des informations importantes parce qu'il peut y avoir des secteurs où elles
pourraient éventuellement servir. Par exemple, le commanditaire peut
accepter de réduire les exigences restantes pour permettre au projet d'être
accompli dans les délais initialement prévus.
Jalons de l'échéancier / Révision à l'achèvement de chaque phase (3.1A.3. P5)
12 Chef de Valider la situation globale du projet à l'achèvement de chaque jalon

projet majeur
Lors de l'arrivée à un jalon de l'échéancier ou de l’achèvement d’une phase
principale, l’équipe devrait effectuer une courte pause pour s’assurer que le
travail précédent a bien été accompli avec succès et que l’équipe et le client
sont prêts à passer à la phase majeure suivante. Ces critères sont parfois
appelés critères d’entrée et sortie, ou « barrières ». Ces événements
fournissent une opportunité pour valider la situation du projet et vérifier que
tout le monde est prêt à entamer la phase suivante. Voir 3.1A.3.2 Jalons de
l’échéancier/ Révisions à l'achèvement de chaque phase, pour de plus amples
informations.
Clôture du projet (3.1A.3. P6)
13 Chef de Clore le travail

projet
Quand le travail est terminé, il faut que vous incorporiez les activités liées à la
clôture officielle de votre projet dans votre échéancier. Le chef de projet ne
devrait considérer le projet comme entièrement finalisé qu’une fois que ces
activités de clôture de projet seront accomplies. Vous devriez montrer le même
niveau de discipline en clôturant le projet que celui dont vous aviez fait preuve
en le gérant. Voir 90.0 Clore le projet pour avoir plus de détails.
187
3.1A.3.1 Lancement du projet
Les projets ne passent pas toujours par une séquence organisée de planification, d’approbation et
d'exécution. Parfois, un projet se situe à différents stades à la fois. Avant que vous ne vous en
aperceviez, vous pouvez vous retrouver au cœur d’un projet avec des membres de l'équipe et des
parties prenantes qui possèdent divers niveaux de compréhension des objectifs et du statut du projet.
De même qu’un projet doit faire l’objet d’une réunion officielle de fin de projet qui signifie qu'il est
achevé, il est logique de tenir une réunion formelle de démarrage pour le lancement effectif du projet.
Le but de la réunion de démarrage est d’informer formellement toutes les parties prenantes que le
projet a commencé et de s’assurer que chacun a une bonne compréhension du projet et du rôle qui lui
sera attribué. La réunion de démarrage est l’occasion de réunir tous les membres de l'équipe, les clients
et les parties prenantes et de définir précisément l'étape de lancement du projet. Comme toutes les
réunions formelles, elle comportera un ordre du jour. Un certain nombre de points spécifiques devront
être abordés lors de cette réunion :
 Présentation des participants à la réunion
 Récapitulation des informations contenues dans la charte du projet, y compris :
o Le but et les objectifs du projet
o Le contenu
o Les principaux livrables
o Les risques
o Les hypothèses
o L'estimation de l'effort de travail et du budget
o Les délais prévus
 Discussion des rôles et des responsabilités importantes de l’équipe du projet, des clients et des
parties prenantes. La plupart, voire toutes les personnes qui travailleront sur le projet doivent
être présentes. S'il y a confusion au sujet du rôle dévolu à une personne ou à une organisation,
elle devra être discutée et clarifiée sur le champ.
 Survol de l'approche et de la chronologie générale du projet. Cela donne aux gens un aperçu de
la façon dont le projet pourra se dérouler. Il faudra, plus particulièrement, vous assurer que les
personnes impliquées comprennent ce qu'elles doivent faire à court terme pour soutenir le
projet.
 Discussion de toutes les questions importantes et les réponses à ces interrogations. L’objectif
de la discussion n'est pas de rediscuter le but du projet, mais de permettre aux personnes
d'exprimer leurs préoccupations ou soucis spécifiques au moment où le projet démarre.
 Confirmer que le projet est maintenant en cours. Si le projet n'est pas encore amorcé, il devrait
être prêt à commencer immédiatement.
 Parmi les autres éléments à considérer lors de la réunion de démarrage, on peut citer:
o Les participants. En général, l’équipe du projet, le client et les parties prenantes

devront être présents. Si cela n’est pas possible, par exemple pour des raisons de
disponibilité, vous pouvez ne réunir que les principaux acteurs. Vous pourrez aussi
rencontrer les autres participants lors de mini-réunions de lancement, ou envoyer les
informations recueillies lors de la réunion aux personnes qui ne pouvaient pas être
présentes.
188
o La durée. Bien que la plupart des réunions de lancement puissent être bouclées en
une heure ou deux, certaines peuvent durer un jour ou deux. Les plus longues réunions
de démarrage sont particulièrement importantes si le projet est très complexe ou très
controversé. Dans certains cas, une longue réunion de démarrage permet de recueillir
les exigences initiales, bien que ce ne soit pas le but premier de la réunion.
o La préparation. On dit souvent que l’on a qu’une seule chance de faire une bonne
première impression. Cela se vérifie dans le cadre de la réunion de lancement. Cette
réunion sert à établir les objectifs du projet. Si la réunion est mal organisée, chaotique
ou représente une perte de temps, les participants transposeront probablement cette
image sur le projet. Le chef de projet doit être sûr qu’il s'est bien préparé pour cette
réunion et qu'elle se déroulera sans problèmes. Il doit également s’entretenir à l’avance
avec le commanditaire pour s’assurer qu’il est d’accord avec lui sur la façon dont la
réunion se déroulera.
189
3.1A.3.2 Jalons / Revues de points de passage
Lorsqu’un jalon majeur de l'échéancier est atteint ou qu’une phase principale est terminée, l’équipe
devrait marquer une courte pause pour s’assurer que le travail précédent a bien été accompli avec
succès et que l’équipe du projet et le client sont prêts à passer à la phase suivante. Voici quelques
activités proposées dans le cadre de la réunion relative à la révision, chaque fois qu’une phase du
projet a été achevée.
Regarder vers l'arrière
 L’approbation des livrables. Vous devriez vous assurer que tous les livrables qui ont besoin
d'être approuvés l’ont été en fait. Parfois, cette approbation finale pourrait même avoir lieu lors
de la réunion de la révision de l'achèvement de chaque phase. Si les livrables de la phase
précédente ne sont pas approuvés, alors le projet pourrait ne pas être encore prêt pour entrer
dans la phase suivante.
 Révision du budget et de l'échéancier. Le budget du projet devrait être révisé pour valider
votre situation par rapport aux estimations totales relatives au budget. De même, vous devriez
regarder votre échéancier pour connaître votre situation et prendre certaines dispositions
correctives si c'est nécessaire.
 Réviser les problèmes du projet. Vous devriez valider le fait que tous les problèmes
majeurs en suspens ont été résolus ou qu'il y a au moins un plan en place pour les résoudre.
 Réviser les risques du projet. Il s'agit du bon timing pour une réunion de contrôle des
risques. Vous devriez confirmer que vos risques précédents sont en train d'être gérés avec
succès ou que vous auriez besoin de réviser votre plan de risques. Vous devriez aussi
rechercher s'il y a de nouveaux risques pour votre projet.
Regarder vers l'avant
 Valider les estimations relatives à l'échéancier et au budget. Vous devriez vous projeter
dès maintenant jusqu'à la fin du projet pour vous assurer de vos estimations actuelles si les
dépenses finales et les délais sont encore valides. Sinon, vous pouvez établir la mise à jour
dans l’immédiat.
 Valider l'évaluation économique. C'est le moment de vérifier que l'évaluation économique

est encore valide. Il est possible qu'une prolongation dans les délais du projet ou ceux relatifs
au budget puisse vouloir dire que l'évaluation économique n'est plus utile. Il est également
possible que l'évaluation économique du projet ait changé.
La revue de fin de phase est une bonne occasion pour annuler un projet qui n'a plus d'intérêt.
 Vérifier que les ressources sont disponibles. Dans plusieurs projets, les types de
ressources et les compétences de ces dernières changent d'une phase à l'autre. C’est l’occasion
de confirmer le fait que vous disposez encore de ressources nécessaires pour achever le
reliquat du projet.
 Valider votre sponsoring. Il est possible que l'intérêt et l'engagement du commanditaire

aient diminué depuis le démarrage du projet. Il est possible également que le commanditaire
ne soit plus le même. Utilisez ce timing pour valider la priorité du projet vis-à-vis du
commanditaire et annulez le projet si le commanditaire n'est plus engagé.
 Obtenir une approbation officielle pour avancer. Celle-ci veut dire que tout le travail fait
jusque là est effectué et que l'équipe pourrait dès lors se concentrer sur le travail en rapport
avec la phase suivante ou le jalon suivant. Quand vous auriez confirmé que tout le travail
préalable a été achevé correctement, et que l’on pourra procéder à l'engagement , vous devriez
obtenir une approbation formelle pour passer à la phase suivante. En d'autres termes, la phase
"gâté" est maintenant prête à entrer et à être utilisée.
190
Si le projet se trouve dans les termes de l'échéancier et du budget, et s'il maintient le bon niveau de
qualité, il est probable que la réunion de révision ne constitue pas un véritable obstacle. Cependant,
dans plusieurs scénarios cette réunion de révision pourrait engendrer certaines décisions sévères
concernant la manière selon laquelle le projet devrait continuer, si jamais il a la chance de continuer.
Certains points importants se présentent de la manière suivante:
 Le projet est projeté pour dépasser le budget autorisé. Le commanditaire et les autres
parties prenantes ont besoin de déterminer si le projet devrait continuer avec un budget
supplémentaire ou si le travail restant devrait être abrégé pour faire face au risque de dépasser
le budget affecté. Ceci pourrait être l’objet d’une décision selon laquelle le commanditaire aurait
besoin de faire appel à un comité directeur de l'organisation pour plus de financement. Si le
dépassement du budget d'un projet est peu important et marginal, le comité de direction a
probablement besoin d'avancer et d'approuver l'excès. Par contre, si le dépassement des coûts
est substantiel, ceci pourrait nécessiter de nouveau la validation économique. Un projet qui
semblait convenable, quand il attendait un certain niveau d'investissement, peut ne plus l'être
si les coûts sont supérieurs. Le fait d'annuler un projet qui est en progrès constitue toujours
une étape dramatique mais si l'évaluation économique ne soutient plus l'investissement,
l'annulation pourrait être considérée comme étant la décision la plus correcte.
L'argent qui est déjà dépensé est mis en décharge. Toute la question est de savoir s'il vaut mieux
dépenser le financement supplémentaire sur le projet actuel ou plutôt sur le projet prioritaire suivant.
 Le projet est projeté pour dépasser ses délais. Certains projets pourraient ne pas
dépasser leur budget, mais ils pourraient quand même ne pas respecter les délais exigés. Cette
situation est d'autant plus compliquée que les ressources sont liées à ce projet et sont donc
incapables de servir à d'autres nouveaux projets. Ceci constitue un problème pour tous les
projets subséquemment établis en échéanciers parce qu'ils ont été retardés non pas à cause
d'un manque de budget mais parce qu’ ils ne disposaient pas de ressources nécessaires.
 Le projet est prolongé à cause des modifications du contenu. Certains projets

dépassent leur budget à cause des modifications du contenu. Si un projet est prolongé à cause
des demandes de modification du contenu, un autre projet qui était planifié pour démarrer
pourrait être retardé parce que les ressources ne sont pas disponibles. Si la modification du
contenu est substantielle, tout le dossier commercial pourrait exiger une revalidation.
191
3.1A.3.3 Valider l’estimation du travail avec l’équipe
Une des responsabilités fondamentales d'un chef de projet est d’élaborer un échéancier de projet et
d’assigner des activités de l’échéancier aux membres de l’équipe pour exécution. Après avoir réparti le
travail aux membres de l'équipe, vous devez leur faire porter la responsabilité de la réalisation du travail
conformément aux attentes.
En surface, cela sonne très sévère et très sec. Cependant, est-ce vraiment juste? Montons d’un cran.
Supposons que vous êtes le chef de projet et que vous êtes affecté à un projet une fois que l'estimation
de l’échéancier et du budget a déjà été réalisée. Cela ne vous paraît pas juste, puisque vous n’avez pas
pris part à l’élaboration des estimations. Vous pensez probablement que si vous êtes tenu responsable
de l’échéancier et du budget, vous devriez être impliqué dans leur élaboration.
Voyez maintenant le problème qui se pose à l’occasion de l’assignation du travail aux membres de
l'équipe. Est-il juste de leur faire porter la responsabilité du travail s’ils n’ont pas participé au processus
d’estimation? La réponse est également "non".
Il y a deux manières de s'assurer de la confiance des membres de l'équipe dans le cadre des
estimations relatives à l’échéancier et au budget. La première est de voir si vous pouvez mobiliser les
membres de l'équipe autour du processus d’estimation préalable. Ce n'est pas toujours réalisable, mais
c’est parfois possible. (En fait, vous pouvez avoir besoin de l'aide des membres de l’équipe du projet
pour élaborer réellement le budget et l’échéancier avec lesquels vous allez démarrer). Si les membres
de l'équipe prennent part au processus d’estimation, ils peuvent être tenus pour responsables de la
réalisation des travaux conformément à ces estimations. (Si les membres de l'équipe sentent qu'ils ne
peuvent pas être tenus responsables des estimations qu'ils ont aidé à mettre au point, alors vous
devriez vous demander si les chiffres sont vraiment valides).
D’autre part, dans beaucoup de projets, les membres de l’équipe ne sont affectés que lorsque
l’échéancier du projet est déjà en place. La personne qui a élaboré les estimations initiales doit émettre
quelques hypothèses au sujet du rendement « moyen » des membres de l'équipe et faire des
estimations fondées sur ces hypothèses.
Dans ce cas, il est judicieux de charger un membre de l'équipe de vérifier si l'estimation semble
raisonnable. Vous ne recherchez pas une estimation avec un facteur de confiance de 100%. Vous êtes
juste en train de voir si l'estimation de l’échéancier, de l'effort et du budget semblent raisonnables. Si le
membre de l'équipe répond par l’affirmative, alors vous pouvez faire assumer à l’équipe la
responsabilité de terminer les travaux conformément à ces estimations.
Naturellement, si vous assignez d'abord le travail, les membres de l'équipe ne sont pas assez informés
pour juger si l'estimation est raisonnable ou pas. Cela peut prendre un peu de temps, alors qu’ils
doivent réellement commencer à travailler sur l'activité. Et c’est aussi bien ainsi. Dans ce cas, vous
assignez le travail en donnant des indications sur l'effort, le budget et le délai estimatifs. Vous
demandez alors aux membres de l'équipe de confirmer si le travail peut être accompli selon ces
estimations. Si les membres de l'équipe considèrent que les estimations sont incorrectes, ils doivent
vous le communiquer AUSSI TÔT QUE POSSIBLE. Dans ce cas, le membre de l'équipe est obligé de
fournir une estimation plus réaliste. Le chef de projet peut refuser d’admettre que la nouvelle
évaluation est plus précise que l’ancienne. Une certaine négociation peut avoir lieu. Cependant, quand
le membre de l'équipe et le chef de projet sont d'accord, le chef de projet peut tenir le membre de
l'équipe responsable de son estimation.
L’essentiel dans ce scénario est que le membre de l'équipe, dès qu’il en est convaincu, doit notifier au
chef de projet que le délai initial ne permet pas de mener le travail à terme. Il n'est pas acceptable que
le membre de l'équipe attende que le délai d’origine soit dépassé avant d’affirmer que les estimations
étaient mauvaises.
Ces approches sont une façon de faire porter aux membres de l'équipe la responsabilité du travail, tout
en étant juste envers eux, en leur permettant de prendre part aux estimations et d’y adhérer. Une fois
cette adhésion acquise, ils peuvent légitimement être considérés comme responsables du travail.
192
3.1B Gérer le budget / Processus
Le budget est-il important pour vous? (3.1B. P1)
Beaucoup de chefs de projets ne sont pas tenus responsables des budgets des projets. Les raisons sont
détaillées dans la section 2.1B Élaborer le budget. Évidemment, si le chef de projet ne dispose pas des
processus, des outils ou des rapports nécessaires pour élaborer et gérer le budget, il ne pourra pas être
tenu responsable de la gestion du budget. Dans ce cas, cette section ne serait pas applicable. (La
gestion de l’échéancier est toujours applicable alors que la gestion du budget ne l’est pas toujours).
Dans le reste de cette section, on suppose que le gestionnaire de projet est tenu responsable de gérer
le budget en accord avec les attentes de celui-ci.
La gestion du budget (3.1B. P2)
Vous devez effectuer un bon travail lors du processus d’élaboration du budget pour être en mesure de
le gérer de manière efficace. Si les estimations du budget ne sont pas exactes, il sera extrêmement
difficile de gérer le projet pour atteindre les chiffres du budget. Le chef de projet doit utiliser l'un des
procédés ci-dessous pour gérer le budget en fonction de la taille du projet.
3.1B.1 Petit projets
3.1B.2 Projets de taille moyenne
3.1B.3 Grands projets
193
3.1B.1 Gérer le budget / Petit projet
Les petits projets ont généralement un très petit budget. Par conséquent, vous avez besoin d’un
procédé informel et de techniques simples pour le gérer. S’il s’agit d’un de ces rares projets qui sont
considérés comme «petits» et que vous avez pourtant un gros budget, vous devez utiliser le procédé de
gestion budgétaire d'un projet moyen ou d’un grand projet.
Rôle Gérer le budget (Petit projet)
1 Chef de projet Faites une liste de toutes les dépenses prévues

Identifiez les éléments spécifiques pour lesquels vous prévoyez dépenser de
l'argent au cours du projet. S’il s’agit d’un petit projet, la liste sera brève.
2 Chef de Enregistrez toutes les dépenses

projet, équipe Comme vous dépensez de l'argent sur des articles au cours du projet,
du projet compilez ces dépenses et comparez-les avec les coûts estimés.
3 Chef de projet Évaluez si vous terminerez les travaux à l’intérieur des paramètres
fixés pour le budget
Évaluez les coûts restants pour vérifier si le projet sera achevé dans les
limites du budget établi. Vous pouvez constater que même si certains articles
peuvent coûter plus cher que prévu, d’autres éléments seront d'un coût
inférieur. C'est généralement le coût total que vous avez à gérer.
4 Chef de Prenez des mesures correctives si nécessaire

projet, Comme il s'agit du procédé pour un petit projet, il est rare de rencontrer des
commanditaire problèmes majeurs au niveau du budget. Si le budget est important, vous
êtes obligé de vous y conformer. Vous pouvez utiliser certaines techniques de
maîtrise des coûts décrites pour les grands projets. Il est possible que vous
deviez demander un budget plus important que celui originellement convenu.
Dans cette éventualité, l'équipe doit absolument respecter les nouvelles
attentes.
194
3.1B.2 Gérer le budget / Projets de taille moyenne
Rôle Gérer le budget (Projets de taille moyenne)
1 Chef de projet Gérer de budget

Suivez continuellement l’évolution de votre projet par rapport au budget. En
raison de la façon dont les rapports financiers sont établis, vous devez peut-
être contrôler le budget mensuellement, même si vous mettez à jour
l'échéancier du projet à un rythme hebdomadaire ou bihebdomadaire.
2 Chef de projet Mettez à jour les prévisions budgétaires de votre projet

Après avoir mis à jour votre échéancier pour mettre en évidence le travail
qu’il reste à faire pour terminer le projet, vous devriez estimer le coût du
travail restant. On appelle cette phase la « prévision ». Il s’agit du processus
qui vous permet de connaître vos coûts courants, vos coûts en évolution et
les coûts estimatifs nécessaires à la réalisation du restant du projet. Ces trois
catégories de coûts devraient être comparées au budget du projet pour vous
assurer que vous pouvez toujours terminer le projet en répondant aux
attentes. Si votre prévision révèle que vous risquez de dépasser le budget,
vous devez mettre en place quelques activités proactives pour respecter les
limites de votre budget.
3 Chef de projet, Communiquez tous les risques associés au budget

commanditaire, Dès que vous avez l’impression qu’il existe un risque de dépassement du
parties budget, vous devriez le communiquer au commanditaire et aux parties
prenantes prenantes selon la hiérarchie. Vous ne devez pas déclarer que vous passerez
à coup sûr à côté de vos estimations. Cependant, amorcez la discussion au
sujet du risque de telle sorte que vous puissiez mettre en application les
actions correctives nécessaires pour remettre le projet sur la bonne voie. Si
vous êtes sûr que les engagements en cours ne pourront être tenus, de
nouvelles estimations devront être préparées et communiquées à votre
direction et au commanditaire. Ce sont des renseignements importants pour
ces parties prenantes, parce qu'elles pourraient devoir intervenir. Par
exemple, le commanditaire peut accepter de réduire les exigences restantes
pour permettre au projet d'être accompli conformément aux estimations
initiales.
4 Chef de projet Gérez les écarts des coûts

S'il y a un écart entre les coûts réels et les coûts estimés, assurez-vous de
les enregistrer par écrit. Vous devez également déterminer si la variante est
importante et les conséquences de dépasser le budget. Si le dépassement du
budget n’est pas acceptable, vous devrez chercher des moyens pour
compenser le dépassement par une réduction des coûts dans d'autres
domaines. Dans ce cas, vous utiliseriez une gestion des coûts rigoureuse
comme celle applicable aux grands projets.
5 Chef de projet Prévoyez si vous terminerez les travaux conformément au budget

Évaluez les coûts restants pour vérifier si le projet sera achevé dans les
limites du budget établi. Vous constaterez que même si certains articles
peuvent coûter plus cher que prévu, d’autres éléments sont d'un coût
inférieur. C'est généralement le coût total que vous avez à gérer.
6 Chef de projet, Prenez des mesures correctives si nécessaire

commanditaire Si le budget est important, vous êtes obligé d'essayer de vous y conformer.
Vous pouvez utiliser certaines des techniques de maîtrise des coûts décrites
195
pour les grands projets. Il est possible que vous deviez demander un budget
plus important. Dans l’éventualité où vous deviez demander une
augmentation du budget originellement convenu, l'équipe doit absolument
respecter les nouvelles attentes.
196
3.1B.3 Gérer le budget / Grands projets
Maîtrise des coûts (3.1B.3. P1)
Rôle Gérer de budget (Grands projets)
1 Chef de projet Gérez le budget

Suivez continuellement l’évolution de votre projet par rapport au budget. En
raison de la façon dont les rapports financiers sont établis, vous devez peut-
être gérer le budget mensuellement, même si vous mettez à jour l'échéancier
du projet à un rythme hebdomadaire ou bihebdomadaire. Pour plus de détails
sur les problèmes potentiels du budget, voir 3.1B.3.1 Signes d’alarme pour le
budget.
2 Chef de projet Mettez à jour les prévisions budgétaires de votre projet

Après avoir mis à jour votre échéancier pour visualiser le travail qu’il reste à
accomplir pour terminer le projet, vous devriez aussi estimer le coût de ce
travail restant. Généralement, on désigne cette phase par le terme « prévision
». Il s’agit du processus qui vous permet de connaître vos coûts courants, vos
coûts en évolution et le coût estimatif nécessaire à la réalisation du restant du
projet. Ces trois coûts devraient être comparés au budget du projet pour vous
assurer que vous pouvez toujours mener à terme le projet conformément aux
attentes. Si votre prévision révèle que vous risquez de dépasser le budget,
vous devez mettre en place quelques activités proactives pour revenir à
l'intérieur des limites de votre budget.
3 Chef de Communiquez tous les risques associés au budget

projet, Dès que vous sentez qu’il y a un risque de dépassement du budget, vous
commanditaire devriez le faire savoir au commanditaire et aux parties prenantes au niveau de
et parties la hiérarchie. Vous ne devez pas déclarer que vous passerez à coup sûr à côté
prenantes de vos estimations. Cependant, commencez à discuter à propos du risque, de
telle sorte que vous puissiez mettre en application les actions correctives
nécessaires pour remettre le projet sur la bonne voie. Si vous êtes sûr que les
engagements ne pourront être tenus, de nouvelles estimations devront être
préparées et communiquées à votre direction et au commanditaire. Ce sont
des renseignements importants pour ces parties prenantes, parce qu'elles
peuvent devoir intervenir. Par exemple, le commanditaire peut accepter de
réduire les exigences qu’il reste à exécuter pour permettre au projet d'être
accompli conformément aux estimations initiales.
4 Chef de projet Gérez les écarts de coûts

Le chef de projet doit maîtriser les dépenses réelles du projet par rapport aux
dépenses budgétées. Pour cela, il ne suffit pas d’affirmer simplement que le
projet est à moitié écoulé et le budget à moitié dépensé, et que tout est donc
bien. Ces renseignements ne sont pas suffisants pour maîtriser les coûts. Pour
mettre en œuvre la maîtrise des coûts du projet par rapport au budget, le chef
de projet doit comprendre le rythme des dépenses du projet et la charge de
travail accomplie en contrepartie du budget dépensé. Cette liaison des
dépenses et des activités de l’échéancier permettra au chef de projet de
maîtriser les coûts lors de l’exécution du projet.
Enregistrez par écrit les écarts entre les coûts réels et les coûts estimés par
rapport au travail accompli. Vous devez également déterminer si la variante
est importante ainsi que les conséquences de dépasser le budget. Si le
dépassement du budget n’est pas acceptable, vous devrez chercher des
197
moyens pour le compenser par une réduction des coûts dans d'autres
domaines.
5 Chef de projet Prévoyez si les travaux seront achevés conformément au budget

Évaluez les coûts restants pour voir si le projet sera achevé dans les limites du
budget établi. Vous constaterez que même si certains articles peuvent coûter
plus d'argent que prévu, d’autres éléments sont d'un coût inférieur. C'est
généralement le coût total que vous avez à gérer.
6 Chef de projet Recherchez d'autres signes pouvant démontrer que le projet pourrait
dépasser son budget
Après avoir déterminé si le projet a une tendance au dépassement du budget,
vous devriez aussi analyser s’il y a d'autres signes de risque pour le budget.
Pour plus d'informations sur les problèmes potentiels de dépassement
budgétaire, voir 3.1B.3.1 Signes d’alarme pour le budget.
7 Chef de Prenez des mesures correctives si nécessaire

projet, Si le budget est important, vous êtes obligé de vous y conformer. Vous pouvez
commanditaire utiliser certaines techniques de maîtrise des coûts décrites pour les grands
projets. Il est possible que vous deviez demander un budget plus important
que celui originellement convenu. Dans cette éventualité, l'équipe doit
absolument respecter les nouvelles attentes.
8 Chef de Maîtrisez le rythme de la mise à disposition des fonds du budget

projet, Lorsque vous démarrez le projet, il est possible que l'ensemble du budget soit
Finance mis à votre disposition pour dépenser au besoin. Toutefois, si le projet dure
un certain temps, il est plus probable que le budget soit mis à disposition par
tranches.
Il est important de connaître le rythme de mise à disposition des fonds du
budget car il peut y avoir un procédé spécifique pour demander la libération
de la prochaine tranche de financement. Si votre projet a tendance à dépasser
le budget prévu, peut-être la libération de cette prochaine tranche sera
nécessaire plus tôt que prévu.
Vous ne voulez pas vous engager dans une situation où les paiements du
projet ne pourront être réglés comme convenu.
198
3.1B.3.1 Signes d’alarme pour le budget
Si vous comptabilisez toutes vos dépenses dans votre logiciel de gestion de projet, le passage en revue
du budget sera aussi simple que l’édition d’un rapport comparatif des dépenses effectives et des
dépenses prévues. Si vous avez de la chance, vos systèmes financiers et vos applications de suivi du
projet seront intégrés, de telle sorte que toutes les informations financières se trouveront dans un
même endroit. Mais il est plus que probable que vous suiviez votre budget sur une feuille de calcul
séparée ou que vous employiez vos propres systèmes de rapports financiers.
Vous devriez utiliser n'importe quel outil disponible pour comptabiliser toutes les dépenses effectuées
jusque-là, y compris la totalité des dépenses reliées au travail, à l'équipement et au matériel. Comparez
alors ces chiffres avec votre budget (le terme " budget " peut renvoyer soit au budget global de votre
projet, soit aux divers comptes de coûts actifs à ce stade du projet). Vous pouvez aboutir (ou pas
aboutir) à une comparaison pertinente. Il y a plusieurs raisons qui font que le projet peut sembler
présenter des problèmes de budget, alors que cela n’est pas vraiment le cas.
 Certaines dépenses peuvent être prévues, mais pour une autre période. Si vous payez un achat
important durant une période, alors qu’il était, à l'origine, programmé pour la période suivante,
il ne faut pas vous étonner de constater que vous êtes techniquement « en dépassement du
budget ». Ce type de dépenses en excès aura tendance à s’aplanir avec le temps.
 Vous pouvez sembler être en dépassement de budget mais cela ne sera pas le cas si vous êtes
en avance sur l'échéancier. Si votre projet est dans les délais, mais qu’il dépasse le budget,
alors il peut y avoir un problème. Cependant, si votre projet est en avance par rapport à
l'échéancier, cela peut sembler normal que vous ayez aussi tendance à dépasser votre budget.
Par exemple, si vous avez réglé des heures supplémentaires à un contractuel et afin d'être en
avance sur l'échéancier, votre budget estimatif final vous montrera que le projet sera accompli
conformément au budget assigné à l’origine.
Les scénarii suivants montrent des situations de dépassement de budget où le projet est vraiment
en péril. Si une tendance au dépassement de budget correspond à l’une de ces situations, des
mesures correctives doivent être prises.
 Le projet peut avoir tendance à dépasser le budget parce que certaines activités demandent
plus d'effort que prévu. Cela peut être dû à des heures supplémentaires non programmées ou
au recrutement de plus de personnel que prévu. Dans ce cas, si la tendance persiste, le budget
du projet sera en péril. Ceci doit être considéré comme un risque pour le budget, à moins que
d’autres facteurs ne permettent de l’atténuer et de renverser la tendance.
 Vos projections des coûts estimés commencent à mal tourner parce que vous avez peut-être
sous-estimé les coûts du travail ou du non-travail. Si vous disposez d’un budget de contingence
d’estimation, vous pouvez y piocher pour compenser les erreurs d’estimation. Si vous n’en avez
pas, vous devez, à la place, mener des actions correctives proactives.
 Il est fort possible que des activités obligatoires ou des dépenses de projet aient été oubliées
lors des estimations initiales. Au cas où du travail ou des dépenses s'avèrent nécessaires mais
n'ont pas été prévus durant le processus d’estimation, vous ne pouvez pas avoir recours au
processus de gestion de modification de contenu. Dans ce cas, un risque au niveau du budget
devra être évoqué, à moins que d’autres facteurs ne vous permettent d'atténuer les dépenses
additionnelles, au moyen d’économies sur les coûts, réalisées quelque part ailleurs.
 Il est possible que vous soyez en train d'exécuter des activités qui sont en dehors de la charte
du projet approuvée ou des exigences commerciales. Si tel est le cas, le nouveau travail devra
être suspendu jusqu'à ce que l’on fasse appel à la gestion des modifications du contenu. Même
si le dépassement de budget peut être récupéré quelque part ailleurs par des économies sur les
coûts, les demandes de modification du contenu ne devraient pas avoir d’impact sur le projet, à
moins qu'elles n’aient été approuvées en même temps que l'approbation correspondante du
budget révisé et des délais de livraison, également révisés.
199
Lorsque ce type de situation se présente, le chef de projet doit pousser loin les investigations afin de
déterminer s’il y a un problème réel, un problème potentiel ou encore aucun problème.
200
3.2A Gérer l'échéancier / Techniques
Techniques pour ramener un projet dans les délais (3.2A. P1)
Le fait de surveiller votre projet de manière continue ne signifie pas que vous ne pouvez jamais
dépasser vos dates limites. L’avantage de la gestion proactive de l'échéancier du projet est que vous
saurez très rapidement si vous tendez à dépasser votre date de fin. Cela vous donne l’occasion de
mettre en place un plan proactif pour revenir dans les délais. Il n’y a pas de processus simple qui fera
l’affaire dans tous les cas. Cependant, il y a quelques techniques que vous pouvez appliquer en fonction
du problème qui se pose avec l’échéancier. Voyez la section 3.2A.2 pour de plus amples
renseignements sur les techniques pour ramener un projet dans les délais convenus.
Assurez-vous que les membres de l'équipe sachent quelles tâches leur sont assignées (3.2A.
P2)
Une des responsabilités primaires du chef de projet est d’assigner le travail aux membres de l'équipe.
Cependant, certains chefs de projet ne sont pas toujours précis quant au travail à exécuter et sur les
responsabilités de chacun. Cela peut occasionner des doutes au sein de l'équipe et peut retarder
certaines activités. En fait, si vous avez une certaine expérience en management de projet, vous avez
probablement déjà vécu cette situation. Vous pouvez demander à un membre de l'équipe de faire le
point sur la situation d'une tâche critique, et il vous répondra qu'il ne savait pas qu’il était assigné à
cette tâche. Un bon test pour savoir si vos directives et vos affectations sont claires, est de demander à
des membres de l'équipe de vous décrire leurs responsabilités pour les deux semaines à venir. Ce n'est
toutefois pas une chose à faire à toutes les semaines avec chaque membre de l'équipe. Cependant, il
peut être intéressant de le demander de temps à autre, ou lorsqu’une activité critique doit être
effectuée, juste pour vous assurer que vous assignez le travail de façon précise. Si les membres de
l'équipe savent ce qu’on attend d’eux, il y a des chances que vous ayez assigné clairement le travail.
S'ils vous donnent des réponses différentes de celles auxquelles vous vous attendiez, cela signifie que
vous devriez être plus précis.
Si les membres de l'équipe comprennent parfaitement le travail mais ne le livrent pas à temps, c’est
que vous avez un problème de rendement. S’ils fournissent un travail de mauvaise qualité mais à
l’intérieur du délai prescrit, vous avez également un problème. Cependant, si le membre de l’équipe
n'est pas certain du travail ou de la date qui lui ont été assignés, c'est que le chef de projet a peut-être
un problème de communication.
Quand vous assignez le travail aux membres de l'équipe, soyez très clair au sujet des points suivants:
 Nom(s) de l’activité, tel qu’il figure dans l'échéancier du projet.
 Une explication, si nécessaire, de ce que le travail implique.
 Dates de début et de fin. Le chef de projet doit être clair au sujet de la date à laquelle
l'activité peut débuter (probablement dans l’immédiat) et de la date à laquelle l'activité doit
prendre fin. Si un membre de l’équipe ne peut pas respecter la date limite, il doit en informer le
chef de projet aussi tôt que possible.
 Effort de travail estimé (facultatif). Le chef de projet peut communiquer l'estimation des
heures requises pour l’achèvement de l’activité. Cela est toutefois d’importance secondaire par
rapport à la date d'achèvement. Si un membre de l'équipe ne peut pas réaliser l’activité dans
les heures d'effort prévues, il doit en informer le chef de projet dès que possible. Cependant,
dans la plupart des projets, si l’activité est terminée dans les délais, il importe peu que le travail
ait requis un peu plus ou un peu moins d'heures d'effort.
 Coûts estimés (facultatif). Si un membre de l'équipe ne peut pas terminer le travail dans les
limites de l'estimation du coût, il doit en informer le chef de projet aussi tôt que possible. Si
l’activité inclut uniquement l'effort de travail, le coût supplémentaire sera directement lié à un
201
dépassement des heures de travail. Cependant, s’il y a des frais de non travail compris dans
l’activité, il est possible que ces coûts de non travail entraînent un dépassement de budget.
 Livrable. Le membre de l'équipe se doit de comprendre le livrable ou la composante (une

partie du livrable) qu’il est chargé de réaliser. S’il faut répondre à des critères de qualité, les
membres de l’équipe devraient en être informés.
 Dépendances. Assurez-vous que le membre de l'équipe connaît la relation de dépendance de

son activité avec celles des autres : il y a des activités qui attendent que la sienne soit terminée
ou qui doivent prendre fin avant que la sienne puisse commencer.
 Autre personnel. Si de multiples compétences externes sont utilisées pour les mêmes
activités, la personne en charge doit comprendre qui est globalement responsable de chacune
des activités.
Gérez l’échéancier dans le cadre des tolérances (3.2A. P3)
Quand vous gérez l'échéancier, vous n'avez pas besoin d'être précis à la minute près. Vous n’allez
également pas en faire un drame si votre projet est en retard d’un jour cette semaine-là, ou en avance
d’un jour la semaine suivante. Votre client n’attend pas un tel niveau d'exactitude et n’est pas intéressé
de savoir, à tout moment, si votre projet est en avance ou en retard d'une heure.
En tant que chef de projet, vous devriez comprendre le niveau de tolérance aux dépassements pour
votre projet. Par exemple, disons que vous mettez à jour votre échéancier et vous réalisez que vous
avez deux semaines de retard. Allez-vous évoquer un problème majeur ou déclarer un risque
d’échéancier? Devriez-vous informer votre client? Cela dépend du niveau de tolérance. Si vous avez un
projet de trois mois, vous devriez probablement être concerné, parce que dans ce cas, deux semaines
représentent près de 20% de dépassement de la date limite. D'autre part, si votre projet est de deux
ans, deux semaines de retard ne sont pas graves (en fait, vous serez probablement perçu en héros si
vous livrez deux semaines plus tard que ce qui était originellement convenu).
Certains projets n'ont pas de tolérance et doivent être strictement achevés dans les délais. Cela peut
être le cas pour des projets qui reçoivent un financement du gouvernement ou des projets qui doivent
être achevés jusqu’à la fin de l’année fiscale.
Usez de votre bon sens et travaillez avec votre client sur les niveaux de tolérance concernant le budget
et la date limite. Si vous restez en dessous des tolérances, c’est très bien. Si vous dépassez ces limites,
vous devriez vous inquiéter.
Validez qui peut mettre à jour l'échéancier du projet (3.2A. P4)
Dans la plupart des projets, le chef de projet est responsable des mises à jour hebdomadaires de
l'échéancier du projet. Il est le seul à avoir le droit de mettre à jour l'échéancier du projet. Mais il existe
d’autres options, notamment pour les projets de plus grande envergure.
Dans certains cas, le chef de projet peut demander à chaque membre de l’équipe de mettre à jour
l'échéancier du projet à partir de l’état courant et de l'effort de travail (si leur suivi est assuré). Dans ce
cas, les membres de l’équipe indiquent normalement si les travaux qui leur ont été assignés sont
terminés. Si ce n’est pas le cas, ils ajustent la date limite pour prévoir le moment ou l'activité sera
terminée. Ils peuvent également indiquer l'effort de travail jusque-là réellement effectué par activité.
Dans la plupart des cas, on ne permet pas à des membres de l’équipe de s'assigner eux-mêmes de
nouveaux travaux, de se charger de nouvelles activités ou de modifier l'échéancier du projet. Une fois
que les membres de l’équipe ont mis à jour le plan à partir de la situation en cours, le chef de projet
peut commencer à faire le point sur la situation globale du projet.
Pour de très grands projets, il est également courant qu’une ou plusieurs personnes soient assignées à
la mise à jour de l'échéancier du projet à la place du chef de projet. On appelle parfois ces personnes
des administrateurs de projet. Ces derniers peuvent obtenir les renseignements auprès des membres
de l’équipe et mettre à jour la situation courante et le nombre réel d'heures de travail effectuées. Ils
peuvent en outre établir un ensemble standard de rapports pour le chef de projet, et recueillir de
202
l’information complémentaire de la part des membres de l’équipe concernant tout ce qui semble
inhabituel. Ils soumettent tout cela au chef de projet pour une analyse et une évaluation finales. Les
administrateurs de projet exécutent une grande partie de la logistique liée à l'échéancier du projet,
mais la responsabilité de comprendre tout ce qui se passe et de prendre les décisions appropriées pour
réaliser le projet avec succès, relève toujours du chef de projet.
Ne gérez pas en fonction du pourcentage accompli (3.2A. P5)
La plupart des outils de programmation de projet ont un champ destiné à la saisie du pourcentage
accompli pour chaque activité. Avant qu’une activité ne débute, son taux d’accomplissement est de 0%.
Lorsqu’elle est terminée, il est de 100%. Cependant, un pourcentage compris entre les deux peut
occasionner des problèmes. Apparemment, si un membre de l’équipe a effectué 20 heures d’une
activité qui demande 40 heures, vous direz que le travail a été accompli à 50%. Est-ce vraiment le cas?
Il peut soit avoir presque terminé le travail, soit en avoir accompli seulement 10%.
Le chef de projet peut demander aux membres de l’équipe de déclarer eux-mêmes leurs pourcentages
d’accomplissement mais dans beaucoup de cas, vous obtiendrez une réponse imprécise. Si l’activité est
en retard, le membre de l’équipe répondra que 90% du travail a été effectué. Cela signifie qu'au cours
de la première semaine où l'activité est en retard, le membre de l'équipe affirme qu'elle est effectuée à
9o%, la semaine suivante à 95%, la semaine d’après à 99%, etc.
Une meilleure manière d'obtenir les renseignements dont vous avez besoin est de demander : « quand
le travail sera-t-il terminé ? ». Si l'échéancier révèle qu’une activité devait être accomplie le dernier jour
de la semaine et que le travail n'est pas fait, ne demandez pas au membre de l’équipe le pourcentage
accompli. Demandez-lui plutôt « quand le travail sera-t-il terminé ? ». Le fait de formuler une telle
demande vous fournit de l’information concrète que vous pouvez inclure dans votre échéancier, tout en
obligeant le membre de l’équipe à s’engager à nouveau sur une nouvelle date de fin.
Gérez l’échéancier en fonction des délais (3.2A. P6)
Dans beaucoup d'organisations, lorsque le projet commence, l'équipe ne produit pas le relevé des
heures d'effort réelles pour chaque activité. À moins que le suivi des heures d'effort ne soit important
pour votre entreprise, le chef de projet ne devrait pas avoir de problème à gérer l'échéancier du projet
en se basant sur les dates d'accomplissement et non sur les heures de travail.
Supposez, par exemple, que vous ayez une activité programmée pour 40 heures de travail sur une
durée de deux semaines. Si le travail est effectué dans les deux semaines, il n'est pas vraiment
important de savoir si le travail a réellement demandé 35 ou 50 heures. Cela ne serait important que si
la différence en heures de travail entraînait le dépassement de date d’une autre activité. L'effort de
travail est important dans le processus d’estimation puisqu'il aide à fixer les dates d’achèvement et à
équilibrer les charges de travail. Mais une fois les activités assignées, le plus important est que le travail
soit effectué dans les délais.
Il y a néanmoins une exception notable : Si le travail est accompli par une personne que vous
rémunérez sur une base horaire, il est important de gérer à la fois les heures d'effort et la date
d'achèvement. Dans ce cas, il importe de savoir si l'activité a demandé réellement 40 ou 50 heures,
puisque cela entraîne un coût pour votre projet.
Utilisez les jalons comme points de contrôle et de validation de la situation (3.2A. P7)
Un jalon est un événement de l'échéancier du projet qui signifie l'accomplissement d'un livrable
important ou d’un ensemble de livrables reliés entre eux. Un jalon, par définition, présente une durée
nulle et aucun effort de travail ne lui est associé. Les jalons sont importants pour les managers et le
commanditaire, dans la mesure où ils fournissent une occasion de valider l'état du projet et ses
développements futurs.
Si le jalon est assez important, vous pouvez l’utiliser pour effectuer une revue de fin de phase.
Toutefois, de nombreux jalons soulignent l'aboutissement de livrables mineurs ou encore de
composantes de livrables, et ne justifient pas la tenue d'une révision complète de fin de phase.
203
Vous pouvez effectuer les activités suivantes à l’achèvement des jalons majeurs de l’échéancier:
 Confirmez que le travail effectué jusqu'à ce stade est correct et précis. Le client doit avoir
approuvé tous les livrables externes créés jusqu'alors.
 Assurez-vous que le reste de l'échéancier du projet inclut toutes les activités nécessaires pour
accomplir le projet.
 Vérifiez une deuxième fois les estimations des coûts, de l'effort et de la durée du travail restant.
En vous basant sur les travaux antérieurs déjà réalisés, vous pouvez noter une sensible
amélioration de la précision de vos estimations restantes. Si ce n'est pas le cas, vous devez
modifier l'échéancier du projet. S'il s'avère que votre budget ou la date limite ne soient pas
respectés, considérez que vous êtes face à un problème majeur que vous devriez résoudre sur
le champ.
 Publiez un rapport formel et mis à jour sur la situation et effectuez toute autre action spécifiée
dans le plan de management des communications.
 Évaluez le plan de gestion des risques pour ceux précédemment identifiés, et assurez-vous
qu’ils sont gérés avec succès. Vous devriez également effectuer une nouvelle estimation des
risques pour en identifier de nouveaux.
 Mettez à jour tous autres registres et rapports de management de projet.
Ces activités devraient être accomplies de façon régulière, mais la date d’un jalon de l'échéancier est le
bon moment pour rattraper un retard, valider où vous en êtes, clarifier et préparer ce qui va suivre.
Utilisez l'audit de projet pour valider l’état de votre échéancier (3.2A. P8)
Parfois, le chef de projet peut se sentir trop confiant (ou pas suffisamment) à propos de la façon dont
le projet progresse. Dans de nombreux cas, il peut être intéressant de faire intervenir une personne
extérieure pour évaluer les processus de management de projet qui sont utilisés et effectuer une
seconde vérification pour s’assurer que le projet progresse comme prévu. Cette « partie extérieure »
peut être n’importe quelle personne qualifiée, mis à part le chef de projet. Dans certains cas, votre
organisation dispose d'un spécialiste interne de l'audit de projet. Le directeur de projet ou le
commanditaire peuvent également effectuer cet audit. La « partie externe » peut être un contractuel ou
un consultant externe, mais pas forcément.
Le chef de projet ou son supérieur hiérarchique peut réclamer l’audit du projet qui fait partie d’un
programme de management de la qualité globale. Dans certains cas, comme pour un projet
gouvernemental, des audits périodiques peuvent être réclamés parce qu’ils font partie du contrat
global. Quoi qu'il arrive, l'audit externe devrait fournir aux parties prenantes du projet l’assurance que
les processus de management de projet utilisés sont efficaces et que le projet est sur la bonne voie.
L’audit d’un projet se concentre sur l’assurance qualité par des questions sur les processus utilisés pour
élaborer les livrables. Vous trouverez plus d’information sur les techniques d’assurance qualité dans la
partie 9.2.4 Questions d’assurance qualité.
Menez une investigation plus attentive lorsque les activités "réalisées" ne sont pas vraiment
accomplies (3.2A. P9)
Parfois, un membre de l’équipe prétend qu'une activité est achevée alors qu’en réalité, elle ne l'est pas
encore. Cela peut se produire pour les raisons suivantes :
 L'activité devait avoir déjà pris fin, mais le membre de l’équipe pense qu’il a juste besoin d’un
petit nombre d’heures pour la terminer. Il pourrait dire qu'elle est terminée, puis la terminer
rapidement, plutôt que d’assumer les conséquences du retard de son activité.
 Un livrable est « terminé » par le membre de l’équipe mais n’a pas été approuvé. Le membre
de l’équipe peut prétendre que le travail est accompli, mais quand le produit livrable est vérifié,
on découvre qu'il est inachevé ou qu’il nécessite un travail complémentaire par la suite.
204
Pour éviter cela, veillez à ce qu’il y ait un processus d’approbation pour tous les livrables principaux, et
à ce que l'échéancier du projet prévoie assez de temps pour le processus d'approbation et pour le
travail de reprise basé sur le feedback. Dans ce cas, il n'y a plus de doute au sujet de la réalisation du
livrable, parce qu'il a été ou non approuvé. Si une activité n’engendre pas la réalisation totale d'un
livrable, vous supposerez que lorsqu’un membre de l’équipe présume qu’une activité est accomplie, elle
l’est probablement. Si vous trouvez des exemples où ce n’est pas le cas, le membre de l’équipe pourrait
avoir besoin de conseils sur la façon d’améliorer les rapports d'avancement de son travail, ou bien vous
avez un problème de performance à traiter.
Gérer les éléments de suivi de votre échéancier (3.2A. P10)
Les éléments de suivi ne sont rien d’autre que le travail qui doit être accompli pour produire une
activité, répondre à une question exceptionnelle, etc. Le travail est habituellement ad hoc (par exemple,
le résultat d'une réunion) et il est limité dans le temps car il doit généralement être réalisé pour la
prochaine réunion. Or, une technique pour s’assurer que les éléments de suivi sont accomplis, consiste
à les placer dans l'échéancier du projet. Pour des renseignements complémentaires, référez-vous à la
section 3.2A.1 Éléments de suivi.
Utiliser le concept de la triple contrainte pour gérer le coût, l’échéancier et le contenu (3.2A.
P11)
À la fin du processus de Définition et de planification (processus 1 et 2), vous devez avoir conclu un
accord avec votre commanditaire sur le travail à effectuer, le coût et la durée nécessaires pour
effectuer le travail. Ces trois éléments constituent la « triple contrainte ». L’aspect principal de cette
triple contrainte est que si au moins un des éléments est modifié, alors les deux autres doivent l’être
également.
Cette question est plus qu’un débat philosophique. Le concept est d’une grande pertinence pour le
management du projet. La triple contrainte a une signification logique et peut aussi être facilement
expliquée à vos clients.
Ce concept peut être visualisé aisément. Pensez

à la triple contrainte comme à un triangle dont
les côtés représentent le coût, la durée et le
contenu du travail.
Si le contenu du travail augmente, le coût et/ou

la durée doivent augmenter en conséquence.
Cela est logique. Si vous avez plus de travail à
faire, cela nécessitera davantage de coûts (effort
de travail), et peut- être plus de temps. [De
même, si vous réduisez le contenu, le coût
(effort de travail) et/ou la durée baisseront à leur
tour].
Si on vous demande d’accélérer le projet et de le

terminer plus tôt que prévu, il est logique
d’exiger moins de travail. Cependant, si on vous
demande de livrer le même travail sur une
période de temps plus restreinte, la troisième
partie de la triple contrainte augmentera pour
maintenir un équilibre. C’est encore une fois
logique. Vous devez augmenter vos coûts (effort
de travail), soit en exigeant des heures
supplémentaires, soit en affectant des
205
travailleurs additionnels pour effectuer la même
quantité de travail plus rapidement et pour
terminer plus tôt.
Lorsque le chef de projet constate cette relation de triple contrainte, il s’apercevra automatiquement
que si l’un des côtés change, il cherchera instantanément à faire en sorte que les autres côtés aussi se
modifient, afin de maintenir l’équilibre de la triple contrainte.
Gérer le travail à un niveau général ou détaillé en fonction de la situation (3.2A. P12)
Une des responsabilités communes pour tous les managers est la gestion du personnel et du travail. (Si
vous n’assumez ni l’une ni l’autre, vous n’êtes pas vraiment un manager). Tous les managers ont besoin
d’information pertinente et précise afin de gérer leur travail et leur personnel d’une manière efficace. Il
faut, bien sûr, savoir quelle quantité de renseignements vous avez besoin et à quel niveau.
Certains managers préfèrent éviter les détails. Ils seront sûrement capables de vous affirmer si le travail
est globalement dans les délais, mais pas ce que les membres de l'équipe du projet sont en train de
faire à un moment donné. Vous pouvez parfois vous en sortir avec une telle approche. Cependant, dans
certains cas, on vous jugera nonchalant et déphasé. Le problème, c’est que quelquefois, ces managers
tentent de s’engager dans les détails du projet pour savoir en quoi il consiste, mais n’y parviennent pas.
Parfois, les managers préfèrent s’en tenir à une vue globale, même quand le projet est conçu dans le
désordre.
D’autre part, vous pouvez être amené à être constamment derrière votre personnel en lui demandant si
les travaux avancent, à aider ces gens à résoudre des problèmes mineurs, à redistribuer le travail en
cas de retard. On appelle ces managers les « micro managers » car ils sont amenés à passer
effectivement tellement de temps sur les détails, qu’il leur faut deux fois plus de temps pour accomplir
n'importe quelle tâche. Ils provoquent aussi un sentiment de frustration chez les membres de l’équipe
parce qu'ils semblent ne pas leur faire confiance pour accomplir quoi que ce soit.
De nombreux managers appréhendent être classés dans la catégorie des «micro managers» en raison
de la connotation négative de cette appellation. Cependant, il y a des moments où vous devez assigner
du travail et recevoir fréquemment du feedback. C’est souvent le cas si vous avez beaucoup de travail à
accomplir en peu de temps. Cela est particulièrement valable si votre équipe de projet ne fournit pas
rapidement le feedback nécessaire pour suivre exactement le développement du projet.
Une bonne approche de la gestion d’une grande quantité de travail est celle d’un « manager en
situation ». Ce type de manager prodigue à l'équipe conseils et soutien moral et essaie d'éliminer tous
les obstacles. Cependant, lorsqu’un projet accuse du retard ou atteint un point où de nombreuses
mesures doivent être prises en un court laps de temps, il peut replonger rapidement dans la gestion
des détails.
Soyez proactif et voyez à communiquer fréquemment lorsque vous gérez des projets avec
des dates limites irréalistes (3.2A. P13)
Si vous êtes un chef de projet aux prises avec ce que vous pensez être une date limite irréalisable, la
première chose à faire est d’en discuter avec votre commanditaire pour évaluer quels sont les facteurs
qui imposent cette date limite. Par exemple, il peut y avoir une raison commerciale ou un événement
qui doit se produire et que le projet doit soutenir. D’autre part, les managers fixent parfois des dates
limites arbitraires uniquement dans le but de fixer ce qu'ils appellent des objectifs extensibles. Cela ne
rend pas nécessairement les choses plus simples pour vous, mais vous constaterez peut-être qu'en
comprenant mieux la raison du choix de la date limite, il vous sera plus facile, à vous et à votre équipe,
de vous motiver pour achever le projet.
Une fois que vous avez compris les motivations qui se cachent derrière la date limite, des techniques de
management de projet peuvent être utilisées pour augmenter les chances de succès et mieux gérer les
attentes.
206
 Essayez d’accroitre l’équipe de personnel. Tous les projets requièrent du temps et des
moyens pour créer les livrables convenus pour un projet. Si vous jugez que la contrainte de
temps ne correspond pas aux coûts et au contenu, demandez à votre manager d’accroitre
l’équipe de personnel disponible pour le projet. Le fait d’ajouter du personnel au projet est
susceptible d’augmenter son coût mais garantit sa réalisation dans les délais.
 Réduisez le contenu. Parlez à votre commanditaire d’une réduction du contenu. Voyez s’il y a
des caractéristiques et des fonctionnalités dont vous pouvez vous passer pour le moment afin
de pouvoir livrer le projet à temps.
 Identifiez et gérez la date limite comme un risque du projet. Le fait d’utiliser le

management des risques du projet vous aidera à gérer à temps les attentes en ce qui concerne
le projet. Cela vous aidera également à trouver de meilleures idées sur les moyens qui vous
permettraient de respecter les délais.
 Gérez le contenu avec une tolérance zéro. Dans plusieurs projets, vous débutez avec une
date de livraison agressive, puis la situation s’aggrave parce que le chef de projet ne peut pas
gérer le contenu efficacement. Si vous êtes en train de travailler sur un projet qui a démarré
avec une date de fin irréaliste, il est absolument impératif que vous gériez le contenu très
efficacement et que vous ne pensiez pas à accroitre la teneur sans une demande de
modification de contenu approuvée. Une gestion disciplinée du contenu constitue la meilleure
garantie que vous n'avez à livrer que ce qui a été promis initialement et que chaque
modification approuvée sera accompagnée d’une augmentation correspondante, en termes de
temps et de budget.
 Gérez l'échéancier du projet de manière agressive. Dans beaucoup de projets, il se peut

que vous ayez un peu de retard tout en sachant que vous pourrez le rattraper plus tard.
Cependant, lorsque vous commencez un projet avec une date limite à risque, assurez-vous que
vous gérez l’échéancier avec vigilance. Vous n’avez pas droit à l’erreur. Lorsque vous surveillez
l'échéancier du projet, traitez les échéances manquées comme des problèmes majeurs et
travaillez consciencieusement pour résoudre les causes de ces échecs.
 Cherchez des opportunités pour améliorer le processus. En fin de compte, jetez un

regard objectif sur votre échéancier de projet et sur votre approche de l’exécution du projet.
Discutez avec votre équipe, vos clients et vos managers au sujet de toute idée susceptible
d’accélérer le projet. Cela amènera chacun à penser qu'il prend part à la solution. Par exemple,
vous pourriez utiliser une session du type « JAD »* pour rassembler des exigences plus
rapidement qu’avec des techniques traditionnelles d’entretien. (*Note du traducteur : JAD est
un type d'organisation pour le développement d'applications, défini par IBM en 1977 et mettant
en œuvre des groupes de travail composés de programmeurs et d'utilisateurs. JAD est
l'acronyme de « Joint Application Development »).
Bien que vous soyez tenu responsable d’évènements et de circonstances qui ne dépendent pas de vous,
vous contrôlez néanmoins les processus que vous utilisez pour gérer le projet. D’abord, regardez si
vous pouvez équilibrer la première échéance en augmentant le personnel ou en réduisant le contenu.
Ensuite, gérez de manière proactive les risques, le contenu et l'échéancier du projet. Troisièmement,
travaillez avec votre manager, votre client et votre équipe de projet pour trouver des idées et des
techniques qui vous permettront de livrer le projet plus tôt que vous ne l’auriez cru possible.
Les chefs de projet doivent établir des dates limites, même si le client ne le fait pas (3.2A.
P14)
De nombreux projets comportent des dates limites fermes qui résultent en des contraintes
commerciales, un échéancier fiscal ou des liens avec d’autres projets. Cependant, de nombreux projets
n’ont pas de dates limites externes fermes. En fait, votre commanditaire peut vouloir que le projet soit
terminé le plus rapidement possible sans donner de date précise.
Tous les projets, par définition, requièrent une date de fin. Lorsque vous gérez des projets qui n’ont pas
de date limite ferme, il est important d’en fixer une avec l’équipe de projet. Vous devez encore élaborer
une charte et un échéancier du projet basés sur l’hypothèse la plus favorable au sujet du personnel
207
disponible et de l'effort de travail requis. De même, impliquez l’équipe dans le processus de planification
afin que chaque membre sache quelles sont les cibles à atteindre. Une fois que l’équipe est d’accord sur
les délais, vous disposez d’une date limite ferme que vous devez gérer comme si un impératif
commercial en dépendait.
Une équipe de projet sans date limite ferme aura du mal à se concentrer et aura besoin de plus de
temps pour livrer son travail. Le chef de projet doit travailler avec son équipe pour établir une date
limite raisonnable puis responsabiliser tous les membres de l’équipe. Cela leur permet d’avoir un
objectif et de s’assurer que le projet ne va pas s’éterniser. Même si le client ne ressent pas une urgence
particulière quant à la réalisation du projet, vous voulez néanmoins vous assurer que l’équipe du projet
n’ait pas la même attitude.
S’assurer que l’équipe de projet respecte les dates limites, même si le client ne respecte pas
les siennes (3.2A. P15)
Beaucoup de chefs de projets font face à des situations où ils sont invités à répondre à des dates fixes
avec très peu ou sans aucune marge de dérapage par rapport aux délais. Il est déjà difficile de gérer
les dates de votre propre équipe, mais parfois ce sont les clients qui augmentent le défi en ne
respectant pas leurs engagements. Par exemple, ils peuvent ne pas être disponibles lorsque vous en
avez besoin ou ils peuvent ne pas approuver des livrables critiques quand ils disent qu'ils le feront. Cela
peut conduire à plus de retards pour le projet.
Pour faire face à ce type de situation, vous devez utiliser de manière proactive la gestion des risques,
des problèmes majeurs, du contenu et des communications.
 Gérez les délais du client comme un risque. Si le client manifeste une tendance aux
retards et vous le traitez comme un risque, vous pourrez communiquer vos préoccupations et
maintenir l'accent sur ce risque tout au long du projet. Cela vous permet également d'identifier
des activités de réponse au risque qui vous aideront à mieux le gérer.
 Gérez la communication et les attentes. Une communication proactive vous permettra de

vous assurer que vos clients ont compris ce qu'on attend d'eux et les conséquences de leur
manque de respect des délais.
 Gérez les délais non respectés comme un problème majeur. Si les clients finissent par
ne pas respecter leurs délais en dépit de vos plans de gestion des risques, alors vous avez un
problème majeur qui doit être traité. Vous devez mettre en œuvre le procédé de gestion des
problèmes majeurs (le processus d’identification et de résolution de ce type de problème). Vous
n'avez pas d'autorité directe sur les clients, de sorte que le processus de gestion des problèmes
majeurs vous permet de gagner plus de visibilité de la part de votre supérieur hiérarchique et
de la hiérarchie du client afin d’obtenir son engagement pour résoudre les problèmes de
ressources du projet.
Bien que vous soyez responsable d’évènements et de circonstances qui ne dépendent pas de vous,
vous contrôlez néanmoins les processus que vous utilisez pour gérer le projet. Appliquez la gestion des
risques, des communications et des problèmes majeurs de manière proactive et impliquez votre
hiérarchie et le commanditaire pour faire en sorte que toutes les personnes concernées s’habituent à
respecter les délais.
208
3.2A.1 Éléments de suivi
Un « élément de suivi » est un travail qui requiert un suivi au niveau de l’exécution. De par leur nature,
les éléments de suivi ne peuvent normalement pas être planifiés à l'avance. Ils apparaissent sur une
base ad hoc au cours de réunions ou comme des sous-produits d'un travail sur autre chose. Un élément
de suivi est assigné parce qu'il n'y a pas assez de connaissances, d'expertise ou de temps pour
résoudre l’élément au moment où il surgit.
Dans beaucoup de cas, les éléments de suivi sont insignifiants par nature, mais dans d'autres cas, ils
peuvent exiger un travail substantiel. Les éléments de suivi doivent être assignés puis effectués
ultérieurement et terminés. (S’ils ne devaient pas être exécutés, ils ne devraient pas être appelés
éléments de suivi. Dans ce cas, notez simplement que l’élément ne sera pas suivi). Des exemples
d’éléments de suivi peuvent être des informations spécifiques à envoyer à quelqu'un, l’organisation
d’une réunion, ou une estimation rapide sur un lot de travail.
Parfois, un élément de suivi est établi pour étudier un secteur qui peut renfermer des problèmes
potentiels. C’est pour cette raison que les éléments de suivi sont parfois associés aux problèmes
majeurs. Ce n'est cependant pas juste: un élément de suivi ne devrait pas être confondu avec un
problème majeur. Un problème majeur est un problème qui aura un impact nuisible sur le projet s’il
n’est pas résolu. Un élément de suivi peut mener à la découverte d’un problème majeur ou d’un risque
(un problème majeur potentiel), mais il n’est pas en lui-même un problème majeur.
La meilleure approche pour gérer les éléments de suivi est d'ajouter des éléments d'une importance à
l'échéancier du projet. L'activité est alors gérée et suivie comme une activité normale. En général, c'est
la meilleure approche à adopter, parce qu'elle permet de garder les éléments de travail en un même
endroit et permet au chef de projet d'imposer sa discipline qui est de se dire : « si ce n'est pas sur
l'échéancier du projet, on ne travaillera pas dessus ». Cette approche permet aussi au chef de projet de
mesurer l’impact de ces éléments de suivi sur l’échéancier. Vous pouvez, par exemple, avoir un élément
de suivi d’une durée de trois heures. Si vous chargez quelqu’un qui travaille sur le chemin critique
d’exécuter cette action, il en découle un retard pour votre projet. Vous êtes alors amené à assigner
l’élément de suivi à une autre personne.
Plusieurs éléments de suivi, sont en effet insignifiants quant aux délais et à la durée. Vous pouvez créer
une section dans vos procès verbaux de réunions pour traiter les éléments de suivi. Ces derniers sont
inscrits là s’ils sont très petits et que vous vouiez les planifier pour la réunion suivante. Si vous
employez cette technique, vous pouvez commencer chaque réunion par un passage en revue des
éléments de suivi précédents pour valider leur exécution et les effacer de la liste. Si l'élément de suivi
provient d'un forum plutôt que d'une réunion, il peut être ajouté et suivi à travers le registre des
éléments de suivi.
209
3.2A.2 Ramener un projet dans les délais convenus
(3.2A.2. P1)
Les gens qui ont travaillé dans des équipes de projet savent que plusieurs choses peuvent mal tourner
et entraîner le projet au-delà de sa date limite. Par exemple, une partie du travail peut s’avérer plus
difficile que prévu. Parfois, vous pouvez avoir un grand roulement de personnel qui vous oblige à
trouver de nouvelles personnes rapidement. D’autres fois, vous découvrez que des activités ont été
sous-estimées.
Indépendamment de la manière dont cela survient, vous constaterez à plusieurs reprises que vous
tendez vers un dépassement de la date limite. Si vous découvrez que cela risque de se produire, la
première obligation du chef de projet est d’en déterminer la cause. Si vous cherchez des remèdes sans
connaître la cause, il est fort probable que la situation se reproduise à l’avenir.
Que devez-vous faire une fois que vous découvrez la cause? Devez-vous informer le client et repousser
la date limite du projet? Pas encore. L'obligation du chef de projet et de l’équipe de projet est de
procéder aux corrections qui permettront de remettre le projet sur la bonne voie. Si vous tendez à
dépasser votre date limite dès le début d'un long projet, vous disposez de multiples options. Si vous
êtes plutôt vers la fin du projet, vous disposerez peut-être d’un peu moins d'options. Les techniques
suivantes peuvent s'appliquer à votre situation. Notez que cette liste n'est pas établie par ordre de
priorité. Quelques techniques peuvent mieux fonctionner dans certaines situations, tandis que d'autres
peuvent avoir plus d’efficacité ailleurs.
Effectuez des heures supplémentaires (3.2A.2. P2)
Tout le monde déteste ça, mais il s’agit d’une solution logique à envisager. Si les gens travaillent plus
d'heures, ils peuvent effectuer davantage de travail dans les mêmes délais. Les heures supplémentaires
peuvent être la meilleure option si vous êtes près de la fin du projet et que vous avez juste besoin
d’une poussée finale pour respecter les délais. Si vous êtes près de la fin du projet, vous pourrez
également compenser le temps supplémentaire (par des congés comparables) une fois le projet
terminé. Si, en revanche, vous êtes toujours au début du projet, il y a probablement d’autres options
plus efficaces à envisager.
Il peut y avoir des implications de coûts associées à cette option, si vous avez besoin de faire appel à
des contractuels pour effectuer des heures supplémentaires.
Réaffectez les ressources sur le chemin critique (3.2A.2. P3)
Le chef de projet doit d'abord comprendre quelles activités sont sur le chemin critique. Après tout, si le
projet accuse du retard, c’est que le chemin critique est en retard. Une fois que le chemin critique a été
assimilé, vous devriez essayer de déplacer vos ressources les plus productives dans des activités du
chemin critique. Lorsque le projet a commencé, il se peut que vous ne connaissiez pas vraiment les
membres de l’équipe les plus productifs. Cependant, pendant la progression de votre projet, vous
devriez tenter d’affecter votre personnel plus performant dans des activités du chemin critique. Après
tout, il s'agit d'activités qui doivent être achevées à temps. Si vous disposez de membres d'équipe
moins productifs, il se peut qu'ils passent plus de temps pour achever leurs activités, mais ceci pourrait
ne pas causer de problème s'ils sont en train de travailler hors du chemin critique. Soyez prudent, car
un retard des activités qui ne sont pas sur le chemin critique peut finir par changer le chemin critique.
Vérifiez toujours le chemin critique chaque fois que vous changez l'échéancier.
Procédez à des changements de personnel sur le chemin critique (3.2A.2. P4)
Vous avez vu auparavant que la première chose que vous devriez faire, quand vous commencez à avoir
tendance à dépasser l’échéancier, est de déterminer la cause. L’une des causes peut être le fait qu’une
personne ou plus, parmi celles que vous employez, n’est pas aussi productive que vous ne l’aviez
envisagé. Peut-être ces personnes n’ont-elles pas les compétences requises. Il se peut aussi que ces
210
personnes ne soient pas aussi productives dans ce secteur particulier que dans d’autres secteurs.
Indépendamment de tout, il y a probablement des possibilités de remplacer du personnel. Changer le
personnel signifie congédier un membre de l’équipe et mettre une personne extérieure à l’équipe à sa
place. (Cela diffère de la réaffectation des membres du personnel à l’intérieur de l’équipe.) Il est
probable que lorsque votre projet a commencé, vous avez reçu les meilleures ressources disponibles.
Cependant, pendant la progression de votre projet, vous pourriez réaliser que d'autres ressources sont
devenues disponibles. Ces gens pourraient mieux convenir pour votre projet.
Vérifiez deux fois toutes les liaisons entre les activités (3.2A.2. P5)
Les liaisons entre les activités de l’échéancier représentent l’ordre dans lequel ces activités doivent être
accomplies. Par exemple, si vous construisez une maison, vous ne pouvez pas commencer à installer le
toit tant que les structures n’ont pas été érigées et ne sont pas déjà sèches. Si vous tendez à dépasser
votre date limite, ces liaisons devraient être validées à nouveau, puisqu'il est possible que l'échéancier
risque d’être prolongé par des liaisons entre des activités qui ne sont pas valides. Les liaisons non
valides peuvent amener à croire que des activités doivent être exécutées séquentiellement, alors
qu’elles peuvent en réalité être réalisées en parallèle. Parfois, le logiciel de gestion de l’échéancier
ajoute accidentellement un type de liaison non voulu en raison d’une erreur lors de la saisie des
activités. Parfois, c’est le chef de projet qui ajoute intentionnellement une liaison. Mais il s’avère, après
un examen ultérieur, que celle-ci n'existe pas vraiment. Il pourrait être pertinent de faire passer en
revue l'échéancier par les membres de l’équipe pour vérifier s'ils trouvent des liaisons entre les activités
de l’échéancier que le chef de projet pense être valides mais qui ne le sont pas en réalité.
Les liaisons entre les activités de l’échéancier devraient toutes être vérifiées une deuxième fois pour
s'assurer que tous les faits sont corrects, avant de penser à des mesures plus drastiques pour ramener
le projet dans les délais.
Vérifiez les activités présentant des contraintes de temps (3.2A.2. P6)
Les activités présentant des contraintes de temps sont celles qui ont des durées qui ne varient pas en
fonction du nombre de personnes affectées à leur réalisation. Par exemple, vous pouvez assigner des
membres de l’équipe à une formation de cinq jours. La formation dure cinq jours, peu importe le
nombre de personnes présentes. Toutes ces activités présentant des contraintes de temps doivent être
vérifiées pour valider l'échéancier. Des hypothèses émises pourraient peut-être être modifiées avec une
approche différente. Par exemple, si vous avez fixé un délai de trois jours pour qu'un produit soit livré à
un client, peut-être que ce délai pourrait être réduit à un jour, en payant davantage pour que la
livraison continue durant la nuit. Si vous devez attendre deux jours pour que le béton sèche, vous
pourriez abréger cette durée en louant une machine soufflant de l'air sur le béton.
Comprimez l’échéancier (crashing) (3.2A.2. P7)
Comprimer l’échéancier signifie que la date limite est tellement critique que vous voulez ajouter du
personnel au chemin critique, même si ce personnel supplémentaire n’est pas utilisé aussi efficacement
qu’il le devrait. Bien sûr, vous voulez essayer d’être astucieux et de prendre la plus grande avance
possible sur l’échéancier pour un accroissement minimum des coûts. Cependant, vous êtes seulement
en train d’essayer de réaliser l’avance qu’il vous est possible de prendre.
Par exemple, si une personne a été chargée de réaliser une activité en dix jours, vous voulez savoir si
deux personnes peuvent la compléter plus tôt. Cependant, il est possible que la deuxième personne
n’ait pas les compétences appropriées, et que si vous l’affectez à plein temps, cela ne vous fera gagner
que deux jours sur l’échéancier. Normalement, il n’est pas logique d’affecter une deuxième personne
pendant huit jours juste pour terminer le travail deux jours plus tôt. Toutefois, si l’échéancier est si
impérieux que vous vous trouvez dans un état de stress important, peut-être accepterez-vous cette
solution.
Le personnel complémentaire peut provenir de l’équipe de projet ou, temporairement, de l'extérieur de

l’équipe. Un des buts de la compression du programme est de réduire au minimum l’accroissement du
coût. Cependant, en échange de la réalisation de quelques travaux en avance par rapport à
l’échéancier, le crashing entraîne habituellement un certain accroissement complémentaire des coûts du
211
projet. Si le coût n’est pas aussi important que la date limite, « comprimer » un ensemble d’activités
peut être une alternative intéressante.
Exécution accélérée par chevauchement (fast tracking) (3.2A.2. P8)
L'exécution accélérée par chevauchement signifie que vous recherchez les activités qui doivent
normalement être accomplies dans un certain ordre, et que vous les faites exécuter partiellement en
parallèle. Par exemple, quand vous construisez une maison, vous ne pouvez pas ériger les murs tant
que les fondations ne sont pas déjà sèches. Cependant, si la maison est assez grande, une option
pourrait être de commencer à ériger l'armature du côté de la maison où les fondations ont d’abord été
coulées. La fondation durcira, ce qui vous permettra d’ériger les murs de ce côté, tandis que la base de
l’autre côté de la maison prendra le temps de sécher. Un autre moyen d’accélérer le travail par
chevauchement des activités serait de commencer à construire les murs qui reposent sur le sol alors
que les fondations sont en train de sécher, si bien que les murs pourront être érigés plus vite quand les
fondations seront sèches.
Un autre exemple concerne la conception d’une application techno-informatique. Habituellement, vous

ne commencez pas à élaborer la solution tant que la conception n’a pas été achevée. Cependant, si
vous utilisez la technique d'exécution accélérée par chevauchement, vous commencez à élaborer la
solution dans les domaines où vous avez l’impression que la conception est suffisamment aboutie, sans
attendre que celle-ci soit entièrement terminée.
L'exécution accélérée par chevauchement implique habituellement un risque d’accroissement des coûts
et des travaux ultérieurs de correction. Par exemple, dans l'exemple de la conception et de la
construction d’une application techno-informatique, il est possible que la conception puisse changer
avant qu'elle ne soit finalisée. Ces changements finaux peuvent avoir pour conséquence de devoir
reprendre une partie du travail déjà réalisé.
Les activités séquentielles peuvent parfois être accélérées de plus de 33%. En d’autres termes, si vous
utilisez la technique d'exécution accélérée par chevauchement, vous pouvez commencer la deuxième
activité lorsque la première est accomplie à 67%. Cela implique un risque, mais ce degré de risque est
généralement acceptable pour l'exécution accélérée par chevauchement.
Imposez la tolérance zéro pour les modifications du contenu (3.2A.2. P9)
Beaucoup de projets commencent à accuser du retard parce qu'ils requièrent plus de travail que prévu.
Cela peut être le résultat d’une mauvaise gestion des modifications du contenu. Cependant, s’il y a un
risque de dépasser la date limite, le chef de projet doit travailler avec les membres de l’équipe et le
client pour s’assurer qu’il n’y a absolument aucun travail non planifié qui soit demandé ou effectué, ne
serait-ce d’une heure, sans passer par les procédures appropriées de modification du contenu. Toute
l'énergie doit être dépensée pour accélérer le noyau de travail qui était convenu, et tout travail
additionnel doit entraîner un financement supplémentaire.
Améliorez les processus (3.2A.2. P10)
Quand vous cherchez la cause du retard d’un projet, vous constatez qu'une partie des procédés
internes de travail peuvent être améliorés. Le chef de projet devrait solliciter les réactions en retour des
membres de l’équipe et rechercher différentes façons d’améliorer la dynamique du processus sous le
contrôle de l'équipe. Par exemple, peut-être tenez-vous des réunions quotidiennes pour faire le point
sur la situation et qui sont sans grande utilité. Ces réunions pourraient plutôt se tenir une fois par
semaine. Vous pouvez également constater qu'il y a des goulets d'étranglement au niveau de
l’obtention de l’approbation des livrables.
Si vous trouvez que les retards sont occasionnés par des processus externes, essayez de négocier des
changements de processus, au moins provisoirement. Par exemple, vous constatez que des activités
sont retardées parce que les gens doivent travailler à l’évaluation de leurs performances annuelles. Bien
que ce soit important, l'exécution de ces évaluations peut probablement être modifiée pour permettre à
des activités critiques du projet d’être accomplies dans les délais.
212
Ceci représente une bonne technique pour les projets en cours de plus longue haleine quand vous avez
la chance d'optimiser les processus de votre projet, d'observer les résultats et de les optimiser.
Cependant, ceci pourrait ne pas être le cas pour les plus petits projets. D'autant plus qu'il est difficile
d'effectuer des améliorations dans un projet de 30 jours. Au moment où vous auriez l’intention
d'effectuer quelques améliorations de processus, le projet serait probablement terminé.
Obtenez de nouveaux les engagements (3.2A.2. P11)
Parfois, les dates limites sont si souvent dépassées que l’équipe n’est plus mobilisée au niveau du
temps ou du budget pour la réalisation du travail. Cela se produit notamment si des membres de
l’équipe dépassent constamment les dates limites sans que l’on prenne aucune disposition à leur
encontre. D’autres commencent alors à se demander pourquoi ils doivent travailler aussi dur pour
respecter les délais et les limites du budget, quand leurs collègues ne se sentent nullement concernés.
Si cela se produit, le chef de projet doit discuter avec les membres de l’équipe pour obtenir des
engagements afin de terminer le travail dans les délais. Il s’agit d’essayer de focaliser à nouveau
l'équipe sur les engagements concernant le respect des délais. Le chef de projet doit demander à
chaque membre un engagement à titre personnel afin qu’il fasse ce qu’il faut pour être en phase avec
les engagements concernant le budget et l’échéancier.
Remontez le moral des troupes (3.2A.2. P12)
Il se peut que votre équipe soit démoralisée, mais que les membres de votre équipe respectent encore
leurs délais. Cela pourrait être bien en ce moment, mais probablement pas pour longtemps. Le fait
d'être démoralisé finira par vous causer des problèmes au niveau de votre échéancier. Lorsque les
membres de l'équipe sont démoralisés, cela a un impact sur votre échéancier de différentes façons :
 Le personnel n'est pas engagé à respecter les délais. Même si les membres de l'équipe
sont encore dans les délais en ce moment, il y a peu de chances que cela puisse continuer si
l'équipe est démoralisée.
 La qualité en souffrira. Les personnes démoralisées ne se soucient pas vraiment de la

qualité de leur travail et il se peut même qu'ils commencent à être négligents ou insouciants.
Cela pourrait donner l'impression qu'ils sont en train de respecter les délais mais en fait,
beaucoup de travail devra être refait.
 Ils pourraient démissionner. Quand le moral va mal, les gens pourraient commencer à
rechercher de nouvelles opportunités. Si c’est le cas, cela vous causera des problèmes quant à
votre projet.
 Ils passent beaucoup trop de temps à se plaindre. Quand les membres de l'équipe sont
démoralisés, ils ont souvent tendance à compatir avec les autres. Vous finirez par avoir une
équipe dont les membres passent leur temps à se plaindre au lieu de l'utiliser pour achever les
livrables.
L'équipe travaillera plus efficacement et sera plus performante si elle ne passe pas son temps à se
plaindre et à se prendre la tête. Le chef de projet doit fixer des objectifs partagés, favoriser un climat
de camaraderie et détendre l’ambiance afin de rendre les gens de nouveau heureux et passionnés par
leur travail. Pour plus d'information sur la gestion d'une équipe démoralisée, voir 8.2.3. P6 Attaquer les
problèmes liés au moral de l’équipe sur tous les fronts.
Vérifiez les dépendances optionnelles (3.2A.2. P13)
Lorsque vous établissez les liaisons entre toutes les activités, vous pouvez remarquer que certaines
d’entre elles ont une dépendance ferme, et d’autres une dépendance souple. Cela signifie que dans de
nombreux cas, une activité doit succéder à une autre. Toutefois, dans bien des cas, vous constaterez
que certaines activités sont placées dans un certain ordre pour plus de commodité ou même
arbitrairement. Dans le premier cas, il s’agit d'une dépendance obligatoire (on parle souvent de «
logique forte » pour les dépendances obligatoires) et dans le second, d'une dépendance optionnelle (les
dépendances optionnelles s'appellent également « liens logiques préférés », « liens logiques préconisés
213
» ou « liens logiques faibles »). Il est important de distinguer ces deux types de relations d’antériorité.
Les dépendances optionnelles devraient être réexaminées pour vérifier si on peut déplacer certaines
d’entre elles plus tôt dans l’échéancier. Cela peut permettre de commencer et de terminer les activités
dépendantes plus tôt, ce qui permet d’avancer plus vite dans l’échéancier global. Bien sûr, pour obtenir
un résultat, on doit identifier des activités discrétionnaires qui sont sur le chemin critique ou qui
peuvent avoir une influence sur lui.
Il est également possible que vous ayez quelques activités qui ont des dépendances externes. Ces
dernières sont imposées soit par des personnes n'appartenant pas à votre projet, soit par d'autres
projets. Ces dépendances externes devraient être vérifiées à partir du moment où il est possible qu'elles
soient modifiées, et affecter par le fait même votre projet.
Réduire le contenu pour ramener le projet selon les délais convenus (3.2A.2. P14)
Une dernière option habituellement disponible est d’analyser le reste des travaux et de négocier avec le
commanditaire la suppression de certains lots de travail. Si les travaux qui restent sont tous des
éléments essentiels pour le livrable final, cette discussion pourrait être justifiée en tant que dernier
recours pour respecter l’échéancier. Peut-être sera-t-il possible de terminer le projet dans les délais
mais avec moins de 100% des fonctionnalités, puis réaliser un projet de suivi pour achever les travaux
restants.
L'autre solution de dernier recours est de demander l’autorisation d’un dérapage de votre date
d'échéance et de compléter le contenu tel que convenu mais en plus de temps.
Le point essentiel est que vous n’ayez pas recours à cette alternative immédiatement après avoir
constaté une tendance au dépassement des délais. Vous devriez premièrement essayer les autres
options disponibles mentionnées ci-dessus pour tenter de rattraper le temps perdu. Vous ne devriez
demander une réduction du contenu que si toutes les autres techniques n’aboutissent pas.
214
3.2B Gérer le budget / Techniques
Techniques pour ramener le projet dans le budget (3.2B. P1)
Tout comme vous pouvez accuser un retard, il est possible que vous ayez tendance à excéder votre
budget. Si vous surveillez les coûts régulièrement, vous devriez savoir très rapidement si vous avez
tendance à dépasser votre budget. Ce procédé de contrôle est sensiblement plus difficile que la gestion
des délais, car de nombreuses raisons pourraient faire en sorte que vos informations financières ne
soient pas assez bonnes ou suffisamment précises. Voir la partie 3.2B.1 pour plus de renseignements.
S’assurer que les membres de l'équipe comprennent leurs budgets (3.2B. P2)
Le chef de projet doit s'assurer que les membres de l'équipe comprennent en quoi consistent les coûts
liés à leurs activités. Cela résulte du coût de la main-d’œuvre et des coûts non salariaux.
Les coûts de la main-d’œuvre varient en fonction du nombre d'heures travaillées et du coût horaire des
ressources humaines utilisées. Le calcul peut être aussi simple que de multiplier le nombre d’heures
pour lesquelles chaque personne est affectée à des travaux avec le taux horaire. Si l'équipe signale plus
d'heures que le total des heures estimées, il peut y avoir des incidences budgétaires. De même, s'il y a
plusieurs personnes affectées à une activité et si elles ont des taux horaires différents (par exemple, les
contractuels par rapport aux employés), le nombre d'heures que chaque personne travaille a un impact
différent sur le budget.
Certaines activités ont aussi une composante non salariale. Le chef de projet doit s’assurer que les
membres de l'équipe comprennent en quoi consistent les attentes par rapport aux coûts. Par exemple,
une équipe peut avoir besoin d'acheter de l'équipement dans le cadre de son travail. Le budget de
l'équipement doit être connu par les membres de l'équipe. Ils doivent travailler avec le chef de projet si
le coût de l'équipement diffère sensiblement des estimations.
Gérez dans le cadre des tolérances (3.2B. P3)
Quand vous gérez le budget, vous n'avez pas besoin d'être précis à l’euro près. Vous n’allez pas en faire
un drame si votre projet dépasse le budget d’un petit montant pour une certaine semaine et est en
dessous du budget la semaine suivante. Votre client n’attend pas un tel niveau d'exactitude.
En tant que chef de projet, vous devriez avoir une certaine idée du niveau de tolérance requis pour
votre projet. Par exemple, en mettant à jour votre échéancier, vous réalisez que vous avez dépensé
1.000 € de plus que votre budget. Devriez-vous considérer cela comme un problème majeur ou un
risque? Devez-vous en informer votre client? Cela dépend de votre niveau de tolérance. Si vous avez un
budget de 10.000 €, vous devriez probablement porter attention, car vous risquez maintenant de
dépasser votre budget de 10%. Si votre projet a un budget d’un million d’euros, alors les mille euros ne
représentent pas grand-chose. (En fait, vous seriez considéré en héros si vous livrez avec un
dépassement de seulement 1.000 €).
Certains projets n'ont pas de tolérance et doivent être achevés strictement à l’intérieur du budget. Cela
peut être le cas pour des projets qui reçoivent un financement du gouvernement ou de ceux qui
doivent être achevés jusqu’à la fin de l’année fiscale.
Usez de votre bon sens et travaillez avec votre client sur les niveaux de tolérance concernant le budget
et la date limite. Si vous restez en dessous des tolérances, c’est très bien. Si vous dépassez ces limites,
vous devriez vous inquiéter.
Tenez compte de la valeur acquise pour comprendre l’état de l’échéancier et du budget

(3.2B. P4)
Certain projets, particulièrement les plus grands, ne sont jamais exécutés exactement comme prévu.
Certaines activités finissent tôt. D’autres arrivent à terme avec du retard. Parfois, il n'est pas facile de
215
savoir si vous êtes en avance ou en retard par rapport à l’échéancier. De même, il est parfois difficile de
savoir si vous vous situez dans les limites du budget ou pas.
Examinons un exemple simple. Vous avez un projet d’une durée de six mois et vous en êtes à trois
mois. Votre échéancier de projet indique que vous devriez avoir dépensé 50% de votre budget, mais
vous réalisez que vous avez déjà dépensé 65% du budget. Éprouvez-vous des difficultés?
C’est possible mais pas certain. Si vous avez effectué seulement la moitié du travail, vous pourriez avoir
des ennuis. Mais si vous êtes, en fait, en avance par rapport au programme, il peut être normal que
vous soyez en dépassement de budget à ce stade du projet. Si vous avez accompli 90% du travail et
que votre budget en est à 65% du total, vous êtes plutôt en bonne position.
Voilà l'objet des calculs de la valeur acquise. Cette valeur est une méthode pour déterminer la
progression d'un projet et indiquer où vous vous situez par rapport à vos prévisions. Pour en apprendre
plus sur la valeur acquise, voyez le paragraphe 3.2B.2 Valeur acquise.
Soyez proactif et communiquez fréquemment quand vous gérez des projets avec des budgets
irréalistes (3.2B. P5)
Si vous êtes un chef de projet aux prises avec ce que vous pensez être un budget irréalisable, la
première chose à faire est d’en discuter avec votre commanditaire pour voir quels sont les facteurs qui
imposent ce budget. Par exemple, il peut y avoir des restrictions budgétaires. Si vous êtes un
fournisseur il est possible que votre équipe commerciale se soit engagée à un prix fixe pour le projet.
Dans certains cas, il se peut que votre supérieur hiérarchique ou votre commanditaire ait établi un
budget arbitraire sans justification. Cela ne rend pas nécessairement les choses plus simples pour vous,
mais vous trouverez peut-être qu'en saisissant mieux la raison de la restriction budgétaire, il vous sera
plus facile, à vous et à votre équipe, de vous motiver pour achever le projet.
Voici quelques réponses possibles d’un budget irréaliste :
 Réduire le contenu. Parlez à votre commanditaire d’une réduction du contenu. Voyez s’il y a
des caractéristiques et des fonctionnalités dont vous pouvez vous passer pour le moment afin
de pouvoir livrer le projet dans les limites du budget établi.
 Identifier et gérer le budget comme un risque du projet. Utiliser le management des

risques du projet vous aidera à gérer à temps les attentes en ce qui concerne le projet. Cela
vous sera également utile pour trouver de meilleures idées sur les moyens qui vous
permettraient de respecter le budget.
 Gérer le contenu avec une tolérance zéro. Dans beaucoup de projets, vous débutez avec
un budget agressif, puis la situation s’aggrave parce que le chef de projet ne peut pas gérer le
contenu efficacement. Si vous êtes en train de travailler sur un projet qui a démarré avec un
budget irréaliste, il est absolument impératif que vous gériez le contenu très efficacement et
que vous ne pensiez pas à en accroître la teneur sans une demande de modification de contenu
approuvée. Une gestion disciplinée du contenu constitue la meilleure garantie afin que vous
n'ayez à livrer que ce qui a été promis initialement, et que chaque modification approuvée sera
accompagnée d’une augmentation correspondante en termes de temps et de budget.
 Chercher des opportunités pour améliorer le processus. En fin de compte, jetez un

regard objectif sur votre budget et sur votre approche de l’exécution du projet. Discutez avec
votre équipe, vos clients et vos supérieurs au sujet de toute idée pouvant faire en sorte
d’exécuter le projet à moindre coût. Cela amènera chacun à penser qu'il prend part à la
solution. Par exemple, vous pourriez acheter du matériel usagé au lieu d’un nouvel équipement
et cela pourrait quand même répondre à vos besoins.
Bien que vous soyez tenu responsable d’évènements et de circonstances qui ne dépendent pas de vous,
vous contrôlez néanmoins les processus que vous suivez pour gérer le projet.
216
3.2B.1 Techniques pour ramener le projet à l’intérieur du budget
(3.2B.1. P1)
Les chefs de projets doivent gérer les délais et les coûts de leurs projets. Le commanditaire a convenu
de payer une certaine somme d'argent pour une solution donnée. Si la solution finit par coûter plus
cher que prévu, elle peut ne plus avoir de sens commercial.
La gestion du budget varie considérablement d’une compagnie à l’autre. Dans de nombreuses

entreprises, les budgets des projets sont convenus préalablement, et les chefs de projets ont très peu
de flexibilité pour introduire des changements dans ces budgets. Une fois le budget alloué, cela
demandera beaucoup plus de travail d'essayer de l’augmenter, si le travail se révèle plus coûteux que
prévu. Cependant, dans certaines entreprises (voire plusieurs d’entre elles), le budget n’a aucune
importance pour le chef de projet. Ces organisations utilisent généralement un personnel interne pour
les projets et elles ne sont pas du tout organisées pour gérer les coûts des projets. Les chefs de projet
essaient de gérer les délais pour boucler le projet à la date limite, mais ils n’ont aucune responsabilité
dans l’estimation et le management des coûts du projet.
Si vous surveillez les coûts régulièrement, vous devriez savoir très rapidement si vous avez tendance à
dépasser votre budget. Ce procédé de contrôle est légèrement plus difficile que la gestion des délais,
parce qu'il pourrait y avoir de nombreuses raisons pour lesquelles vos informations financières ne
seraient pas assez bonnes ou suffisamment précises. Grâce à l’échéancier, vous savez tout de suite si
vous dépassez une date limite. Avec seulement le budget qui vous est alloué, vous ne pouvez pas
toujours le savoir.
Plusieurs facteurs font en sorte que la gestion du budget soit plus complexe :
1. D'abord, vous dépensez rarement l'argent à un taux constant. Ainsi, vous devez savoir à la fois
ce que vous comptez dépenser pendant une certaine période et ce que vous avez réellement
dépensé. Dans la plupart des entreprises, les informations financières arrivent également avec
du retard. Par exemple, vous ne connaîtrez pas la situation financière de votre projet pour le
mois en cours avant la deuxième semaine du mois suivant, lorsque les rapports de budget
seront livrés.
2. Le timing est un autre problème. Vous devez savoir à quel moment votre entreprise identifie les
dépenses dans vos systèmes financiers. Vous pouvez identifier les dépenses quand vous
recevez une facture ou, peut-être, pas avant de la payer, chose qui peut être réalisé beaucoup
plus tard. Si votre entreprise utilise des ordres d’achats, les dépenses de votre projet pourraient
être combinées avec celles d’un autre projet lorsque l'ordre d'achat est rédigé, même si la
facture réelle n'est pas payée avant des semaines. Selon votre budget, ceci peut occasionner
des dépenses plus tôt que prévu et vous faire croire que vous êtes en train de dépasser votre
budget, alors que ce n’est pas le cas. Les dépenses arrivent seulement plus tôt que vous ne
l’aviez planifié dans votre budget.
3. Un autre problème potentiel avec les budgets est que les charges peuvent être mal distribuées
d’un projet à l’autre. Une des activités d’un chef de projet, lorsqu’il reçoit les derniers chiffres
du budget, est de vérifier si tous les détails sont corrects. Il (ou une personne désignée) doit
alors passer en revue chaque item. Selon vos contrôles financiers, il y a souvent plusieurs
occasions où une mauvaise distribution des charges a lieu. Vous possédez peut-être un logiciel
de comptabilité performant, mais si quelqu’un saisit un code de projet incorrect, on vous
facturera les dépenses d’un autre projet. Cet effort de vérification n’est généralement pas long
si vous l’effectuez chaque mois. Dans la plupart des organisations, si le chef de projet détecte
un problème potentiel, celui-ci peut être communiqué à une personne de la comptabilité pour
correction; le chef de projet doit s’assurer que la dépense est créditée convenablement le mois
suivant.
Bien sûr, il y a aussi des cas où vos dépenses de projet peuvent se retrouver sur un autre projet. Donc,
si vous vous apercevez qu’il vous manque des dépenses prévues pour votre projet, il est important que
217
la comptabilité les retrouve. Si vous vous dites qu’elles ne vous seront pas imputées, vous risquez d’être
surpris quand l’autre chef de projet s’en apercevra et rectifiera les erreurs.
Ainsi, après vous être assuré que toutes les dépenses du projet sont valides, si vous pensez que vous
êtes en train de dépasser votre budget, vous devez d’abord trouver la cause. Si vous parvenez à la
déterminer, vous aurez une meilleure idée des options disponibles pour revenir sur la bonne voie. Il
existe un certain nombre de techniques que vous pouvez appliquer pour essayer de réduire les
dépenses et de revenir dans les limites de votre budget.
Effectuez des heures supplémentaires non payées (3.2B.1. P2)
Cette option est avantageuse lorsque votre personnel n’est pas payé pour les heures supplémentaires.
C'est habituellement la première chose à vérifier, et une équipe peut effectuer des heures
supplémentaires pour ramener à court terme un projet à l’intérieur du budget. La logique est que vous
pouvez obtenir plus de travail effectué pour le même coût, puisque vous ne devez pas payer vos
ressources humaines internes pour des heures supplémentaires. Si vous êtes près de la fin du projet,
vous pouvez également compenser ce temps une fois le projet accompli. Cependant, ce n'est
habituellement pas une bonne solution sur une longue période.
Échangez le personnel (3.2B.1. P3)
Si vous avez tendance à dépasser votre date limite, vous pourriez permuter des membres du personnel
pour ramener votre projet dans les délais. Généralement, vous permuterez des personnes
inexpérimentées et moins productives contre d’autres plus productives et plus expérimentées.
Cependant, lorsque vous êtes en situation de dépassement de budget, vous avez des motivations
différentes. Vous avez besoin de savoir s'il y a des membres du personnel qui reviennent moins cher et
qui pourraient être affectés aux activités au lieu de faire appel à un personnel plus coûteux. En fait, si la
maîtrise des coûts est plus importante que la date limite, vous pouvez être disposé à consacrer plus de
temps pour effectuer le travail s’il peut être, en fin de compte, mené à terme et avec succès pour un
coût réduit. Cette technique peut également être utilisée pour remplacer un contractuel par un
employé, si ce dernier revient moins cher dans le cadre du projet.
Diminuez et remplacez les coûts de non travail (3.2B.1. P4)
Tout comme avec les personnes, il peut être possible d'utiliser du matériel, des fournisseurs ou des
services moins coûteux que ce qui ont été prévus au départ. Par exemple, vous pouvez demander aux
personnes devant voyager, dans le cadre du projet, de séjourner dans des hôtels moins dispendieux.
Vous pouvez vérifier si des membres de l’équipe peuvent utiliser le matériel existant, après son
amélioration, plutôt que d’acheter de nouvelles machines. Vous pouvez remplacer des sessions
formelles de formations onéreuses par des formations au moyen de l'informatique ou de formations
internes moins chères. Vous pouvez n’envoyer qu’une personne en déplacement de travail pour réaliser
une activité, au lieu de deux, comme prévu au départ. Dans chacun de ces cas, vous tentez de
satisfaire les besoins initiaux, mais en employant des alternatives moins coûteuses.
Imposez la tolérance zéro pour les modifications du contenu (3.2B.1. P5)
Cette technique peut être utilisée pour remédier au dépassement du budget ou de la date limite d’un
projet. Beaucoup de projets commencent à dépasser leur budget parce qu'ils requièrent davantage de
travail que ce qui était prévu en raison d'une faible gestion des modifications du contenu. S’il risque de
dépasser son budget, le chef de projet doit travailler de concert avec les membres de l’équipe et le
client pour s’assurer qu’il n’y a absolument aucun travail non planifié demandé ou effectué, ne serait-ce
qu’une heure, à moins qu’une gestion formelle de modification du contenu ne soit invoquée. Toute
autre énergie doit être utilisée pour réduire les coûts et achever le noyau de travail convenu, à moins
que vous n'obteniez un financement supplémentaire pour les modifications de contenu.
Employez la réserve pour aléas (si vous en avez) (3.2B.1. P6)
218
Si vous avez de la chance, votre budget initial inclura une réserve pour aléas qui prend en compte
l'incertitude et le risque associés à votre estimation. Par exemple, il est commun pour un projet
d'inclure une réserve pour aléas de 10%. Cette réserve est séparée du budget du projet. Si vous
pouvez réaliser le projet dans les limites de votre budget initial, l’intégralité de la réserve devra être
retournée à l’entreprise. Si vous constatez que votre situation de dépassement de budget est due à des
activités plus coûteuses que prévu, le budget de réserve pour aléas pourra être utilisé. Quand vous
l’utilisez, assurez-vous que votre commanditaire et les parties prenantes principales sont au courant;
vous pourrez ainsi gérer les attentes en fonction du fond de contingence restant.
Améliorez les processus (3.2B.1. P7)
Il peut y avoir des dépassements de coûts engendrés par des processus internes inefficaces. Veillez à
obtenir en retour les réactions des membres de l’équipe et recherchez avec eux des moyens internes
dont ils ont le contrôle en vue d’améliorer les processus. Si les implications de coûts sont occasionnées
par des processus externes, essayez de négocier des changements de processus à long terme, ou au
moins provisoirement.
Il s’agit d’une bonne technique pour les projets de plus longue durée, puisque vous avez la chance
d'optimiser les processus du projet, constater les résultats et les optimiser encore plus. Cependant, ceci
pourrait ne pas être le cas pour les plus petits projets. Il est difficile d'effectuer plusieurs améliorations
de processus au sein d'un projet de 30 jours. Au moment où vous aurez l’intention d'effectuer des
améliorations au niveau du processus, le projet serait probablement terminé.
Renouvelez les engagements (3.2B.1. P8)
Travaillez avec les membres de l’équipe pour évaluer le travail à venir et revalider les estimations, et
obtenez d’eux des engagements pour terminer le travail dans les délais. (Voir la partie 3.2A.2 Ramener
un projet dans les délais convenus pour plus d’informations.)
Renégociez les contrats externes (3.2B.1. P9)
Lors des techniques précédentes (ci-dessus) vous avez examiné les possibilités de remplacer des
ressources humaines et d'éliminer ou de remplacer des éléments de non travail. Cependant, les
membres du personnel d’une tierce partie peuvent ne pas avoir besoin d’être intervertis ou remplacés.
Il doit simplement être possible de renégocier le processus et les termes du contrat. Si vous avez des
tâches contractuelles, vous pouvez peut-être négocier une réduction des frais. Peut-être que votre
fournisseur de logiciels acceptera de vous vendre son produit moins cher. Tous vos coûts externes
devraient être évalués pour vérifier où vous pourriez réaliser des économies. Dans de nombreux cas, le
fournisseur acceptera de baisser ses prix, surtout si l’autre option est d’abandonner complètement ses
services ou ses produits. Cependant, dans d’autres cas, le fournisseur peut vouloir échanger un
bénéfice contre un autre. Par exemple, il se peut qu’un contractuel accepte une réduction de salaire
horaire en échange de plus d’heures de travail. Peut-être qu’un fournisseur demandera moins d’argent
mais voudra être payé plus tôt. Plus la valeur de vos contrats externes est élevée, plus vous disposez
de flexibilité pour en négocier les différents termes. Si vous êtes au-dessus de votre budget, surtout
dans le cas d’un grand projet, tous les fournisseurs devraient être passés en revue pour des économies
de coûts potentielles.
Créez des comptes de contrôle plus détaillés (3.2B.1. P10)
Tout comme il est difficile de gérer des activités dont la durée est très longue, il peut être difficile de
gérer le budget si tous les fonds sont réunis dans une seule rubrique. Dans les deux cas, le problème se
pose parce qu’on a du mal à savoir où on en est, à un moment donné. Une des techniques permettant
de mieux contrôler le budget consiste à multiplier les comptes de contrôle détaillés.
219
Les comptes de contrôle sont un moyen d’allouer des fonds à votre projet de telle manière que vous
puissiez exercer un contrôle plus précis. Au lieu d’avoir un grand budget regroupant tous vos coûts,
vous pouvez répartir votre budget global en plusieurs comptes de contrôle de tailles plus réduites. Par
exemple, vous pouvez mettre en place un compte de contrôle pour chaque phase de votre projet. Vous
pouvez aussi ouvrir un compte de contrôle pour chaque livrable. Comme ces budgets sont alloués à un
niveau plus réduit, vous êtes en mesure de savoir plus tôt si vous avez des problèmes de budget.
Ainsi, par exemple, vous pouvez mettre en place un compte de contrôle pour la phase d’analyse d’un
projet. Lorsque cette phase est terminée, vous pouvez comparer vos dépenses réelles avec le budget
qui lui était alloué. Si vous avez dépassé le budget, cela peut vous indiquer que vous avez tendance à
dépasser votre budget entier. Si vous n’aviez pas réparti votre budget sur ces comptes de contrôle plus
réduits, il n’aurait pas été évident de savoir combien vous pensiez dépenser pour cette phase d’analyse
ni combien vous avez réellement déboursé.
Réduire le contenu pour ramener le projet selon les délais convenus (3.2B.1. P11)
Une dernière option qui est habituellement disponible pour faire face soit à un dépassement du budget,
soit à un dépassement des délais, est d’analyser le reste des travaux et de négocier avec le
commanditaire la suppression de certains lots de travail. Si les travaux comportent des éléments
essentiels pour le livrable final, cette discussion pourrait encore être justifiée en tant que dernier
recours pour respecter l’échéancier. Peut-être est-il possible de terminer le projet dans les délais mais
avec moins de 100% des fonctionnalités, puis réaliser un projet de suivi pour achever les travaux
restants.
L'autre solution de dernier recours est de demander l’autorisation d’un budget supplémentaire et de
compléter le contenu tel que convenu mais avec un budget plus important.
Le point essentiel est de ne pas recourir à cette alternative immédiatement après avoir constaté une
tendance au dépassement du budget. Vous devriez d'abord essayer les autres options disponibles
mentionnées ci-dessus pour tenter de ramener le projet à l’intérieur du budget. Vous ne devriez
demander une réduction du contenu que si toutes les autres techniques n’aboutissent pas.
220
3.2B.2 Valeur acquise
(3.2B.2. P1)
Si vous êtes un chef de projet, vous a-t-on déjà demandé où vous en étiez dans un projet ? C’est plus
que sûr. Cette question est vague, et votre réponse est tout aussi vague : « nous sommes dans les
délais » semble être une réponse convenable. Vous avez même pu donner comme réponse : « nous en
sommes à la moitié » ou : « nous avons terminé à 90% ».
Si vous n’avez pas un échéancier valide, ou si vous ne le tenez pas à jour, vous savez que vos réponses
sont plus ou moins des suppositions. Si vous avez un bon échéancier du projet que vous tenez à jour,
vous devriez savoir combien de travail il vous reste à faire et quelle sera la date de fin de projet. Mais
en avez-vous accompli 50% ou 90% ? Qui sait ?!
Saisir la valeur acquise (3.2B.2. P2)
Les métriques de la valeur acquise ont été établis pour faire en sorte que votre projet ne soit plus
déterminé par des suppositions. En théorie, ce concept est très élégant et très intéressant. Son
utilisation permet à un chef de projet de savoir précisément où il en est dans un projet, combien de
travail il reste à faire, quels seront le coût attendu et la date limite, en plus de toutes sortes d’autres
informations intéressantes.
Histoire (3.2B.2. P3)
La valeur acquise est une idée plutôt récente. On la trouve vers la fin du XIXème et le début du XXème,
alors que des managers tentaient d’avoir des locaux et des chaînes de production aussi productifs que
possibles. La conduite vers l’efficacité requiert une base constituée de métriques et la valeur acquise
servait alors de moyen permettant de mesurer d’une manière plus précise.
Dans les années 1960, le ministère de la Défense américain commença à exiger l’emploi de la valeur
acquise sur des projets liés à la défense. Comme on peut s’y attendre, si le gouvernement établit des
contrats pour des projets qui valent des millions, voire des milliards de dollars, il s’attend à recevoir des
comptes-rendus qui disent autre chose que « tout a l’air d’aller bien ». Le calcul de la valeur acquise
donne une meilleure idée de la situation exacte du projet; il donne très tôt l'alerte si les tendances
indiquent que le projet risque de dépasser le budget ou la date limite.
Concepts de base de la valeur acquise (3.2B.2. P4)
La valeur acquise est une manière de mesurer le développement.
Dans n’importe quel projet, la valeur à acquérir est basée sur l’achèvement du travail. Du point de vue
consommateur, la valeur commerciale est acquise quand le projet est terminé. Si un projet est annulé à
90% de sa réalisation, la valeur commerciale sera nulle. Cependant, la valeur acquise considère cela
différemment. Avec celle-ci vous acquérez la valeur du projet sur une échelle qui augmente avec ce
dernier. Lorsque 50% du travail est effectué, vous pouvez également considérer que vous avez aussi
réalisé 50% de la valeur du projet.
L’idée générale derrière la valeur acquise est que vous désirez comparer la position où vous vous
trouvez par rapport à celle où vous avez prévu d’être. Cela vous permet également de quantifier le
travail qui aurait dû être accompli au cours la même période. Ensuite, vous pouvez comparer le travail
qui a été exécuté par rapport à celui qui aurait dû l’être, pour voir si vous êtes dans les délais, en
avance ou en retard.
De même, étant donné votre position actuelle, les calculs de valeur acquise vous permettent de
déterminer le coût total du travail accompli ainsi que les estimations pour le travail que vous devriez
avoir accompli. La comparaison de ces deux chiffres vous indique si vous allez dépasser votre budget
ou pas.
221
L’utilisation de l'échéancier et des métriques vous apporte encore plus d’informations. Vous êtes peut-
être bien en train de dépenser votre budget plus vite que prévu, mais vous êtes peut-être aussi en
avance sur l'échéancier. Si c’est le cas, vous dépensez plus parce que votre équipe travaille plus
rapidement que prévu. Cela peut être une bonne chose. De même, si votre projet est en retard mais
que vos dépenses ont été moindres, cela va encore. Peut être n’avez-vous pas pu rassembler toutes les
compétences aussi vite que vous le souhaitiez. Donc, votre projet est en retard, mais vos dépenses
aussi. Si vous avez une date limite critique, cela peut être un problème. Si votre date limite est plutôt
flexible, tout ira bien, tant que vous ne dépassez pas votre budget.
La valeur acquise vous donne l’information dont vous avez besoin pour prendre les bonnes décisions.
Selon la source à laquelle vous vous référez, il y a des dizaines (voire des centaines) de manières de
calculer la valeur acquise. Cependant, la plupart combinent quelques métriques de la valeur acquise de
base en les permutant de manières diverses.
On compte trois métriques qui forment le bloc constitutif de la valeur acquise : la Valeur Acquise, le
Coût Réel et la Valeur prévue. Considérons-les plus en détail.
Valeur acquise (VA) (3.2B.2. P5)
La valeur acquise est calculée en additionnant le coût budgétisé de chaque activité accomplie.
(Rappelez-vous : il ne s’agit pas du coût réel des activités de travail, mais du coût budgétisé du travail
accompli). Voyez l’exemple suivant :
Date d’aujourd’hui: le 31 Mars
Activité terminée A B C D
Date butoir 10 Mars 15 Mars 31 Mars 5 Avril
Coût budgétisé 20 10 15 5
Coût réel 20 5 20 10
Admettons que vous ayez achevé les activités A, B, C, et D. Pouvez-vous deviner la formule simple pour
trouver la Valeur Acquise ? La voici : (20+10+15+5), ce qui revient au chiffre rond 50.
Vous vous demandez sûrement comment calculer une activité en cours. En fait, il vous incombe
d’établir au préalable quelques règles de départ. L’une des options est de considérer l’activité à 0 % de
sa réalisation jusqu’à son terme puis de débloquer 100% du crédit. En d’autres termes, lorsque l’activité
B commence, la VA est de zéro, lorsqu’elle se termine, elle est de 10.
Une autre option est d’accorder un crédit partiel. Par exemple, quand l’activité B commence, la VA est
de zéro. Quand elle est en cours, vous pouvez accorder un crédit de 50%, ou une VA de 5. Quand
l’activité est terminée, vous lui accordez la VA complète de 10.
Vous pouvez être plus précis (disons, en augmentant le crédit par tranches de 10%), mais chaque
niveau de précision entraîne plus de travail pour une précision plus marginale.
La VA est la mesure de base de la valeur du travail accompli par le projet à un instant donné. Prise à
part, elle a peu de signification. Elle est souvent utilisée avec d’autres calculs pour déterminer votre
situation.
Coût réel (CR) (3.2B.2. P6)
Pour calculer ce chiffre, ajoutez le coût effectif de tout le travail exécuté jusque-là dans le cadre du
projet. Cela peut inclure les coûts de travail et de non-travail, de même que les factures réglées (ou les
ordres d’achat approuvés). Si vous avez un système financier automatique qui vous fournit ces chiffres,
la tâche n'est pas très ardue. Par contre, si vous ne pouvez pas procéder à la saisie de tous ces coûts
automatiquement, cette tâche vous prendra beaucoup de temps. Si votre budget comporte uniquement
les coûts de travail, le coût et l'effort de travail suivront les mêmes lignes. Si les coûts de non travail
222
dans votre budget sont importants, les coûts du projet ne sont pas directement attachés au travail
utilisé.
Reprenons notre exemple :

Date d’aujourd’hui : le 31 Mars
Le coût réel des activités de A à D est de (20+5+20+10=) 55. Vous pouvez voir que les coûts réels
pour le travail accompli sont plus importants que les coûts budgétisés. Cela peut poser un problème.
Encore une fois, si une activité est en cours, vous pourriez utiliser les options considérées dans le
paragraphe sur la VA pour déterminer si vous devez inclure le coût réel ou des pourcentages (de 0% à
100%)
Valeur planifiée (VP) (3.2B.2. P7)
C’est la somme de toutes les prévisions budgétaires pour tout le travail qui a été programmé pour être
accompli aujourd'hui (ou à toute date spécifique).
Nous disposons de plus d’information à ce stade. Puisque nous sommes le 31 mars, la Valeur Planifié
est A+B+C (20+10+15=) 45. On ne compte pas l’activité D puisqu’il n'est pas prévu qu'elle soit
terminée le 31 mars.
Rassemblons les indicateurs dont nous disposons.

Travail
restant
Date butoir 10 Mars 15 Mars 31 Mars 5 Avril 31 Juillet
Coût budgétisé 20 10 15 5 500
Coût réel 20 5 20 10 ?
Écart de délais (ED) (3.2B.2. P8)
Il vous indique si vous êtes en avance ou en retard sur l'échéancier. Il est mesuré par la formule : VA –
VP. Dans l’exemple ci–dessus, la VA est de 50 (20+10+15+5) et la VP est de 45. Notez que la
différence est constituée par l’activité D. Puisque du travail a été effectué sur cette activité, elle est
223
incluse dans la valeur acquise. Cependant comme elle ne doit pas être terminée avant le 31 mars, elle
n’est pas incluse dans la valeur planifiée.
L'écart de délais est de 5 (50-45). Si le résultat est positif, vous avez accompli plus de travail que prévu
à ce stade. Vous êtes probablement en avance. De même, si (ED) est négatif, le projet est
probablement en retard.
Écart de coûts (EC) (3.2B.2. P9)
C’est le résultat de VA – CR. Cela vous donne une idée de la façon dont vous êtes positionné par
rapport au budget. Si l'EC est positif, cela signifie que le coût budgété du travail accompli (VA) est
supérieur à ce qui a été dépensé réellement pour la même quantité du travail (CR). Cela signifie que
vous êtes bien placé par rapport au budget. Si l'EC est négatif, il est possible que vous soyez
actuellement en dépassement de budget. Dans notre exemple, la VA est de 50, le coût réel est de 55.
Donc l’Écart de Coûts est de –5 (50-55), ce qui signifie que vous êtes en dépassement par rapport à
votre budget.
Indice de performance des délais (IPD) (3.2B.2. P10)
C'est le rapport calculé en prenant VA / VP. Cela montre le rapport entre le coût budgétisé du travail qui
a réellement été exécuté et le coût des travaux qui ont été programmés pour être terminés à la même
date. Il donne le taux d’avancement du projet. Si le résultat est supérieur à 1.0., le projet est en avance
sur l'échéancier. Par exemple, si l’IPD est de 1,1. Cela signifie que votre projet a accompli
approximativement 10% de travail en plus (VA) que ce qui a été programmé (VP) pour le même
moment. Si cette tendance continue, vous finirez par être en avance d’au moins 11% par rapport au
temps prévu pour accomplir le projet.
Indice de performance des coûts (IPC) (3.2B.2. P11)
C'est le rapport VA / CR. Il montre le rapport entre le coût budgétisé du travail exécuté et le coût réel
de ce travail. Si le résultat est inférieur à 1,0, le projet est en dépassement de budget. Par exemple, un
IPC de 0.90 signifie que pour chaque dépense prévue de 90 (VA), votre projet a réellement coûté 100
(CR) pour le même travail effectué. Si cette tendance continue, vous finirez par dépasser votre budget
d’au moins 10% à la fin du projet.
Budget à l'achèvement (3.2B.2. P12)
Ce calcul peut être fait en termes d'argent ou d’heures. Il s’agit de la valeur acquise à laquelle on
ajoute le coût estimé pour le travail restant. Si l’IPC n'est pas de 1.0, cela signifie que le rythme de vos
dépenses est différent de ce qui a été planifié, et que cet élément doit aussi être pris en compte. Ainsi,
si l’IPC n'est pas 1.0, le BA est égal au CR + (coût estimé pour le travail restant / IPC). En d’autres
termes, si vous dépassez le budget de 10% pour accomplir le travail jusqu’à la date en cours, il n’y a
aucune raison de penser que le travail restant ne coûtera pas aussi 10% de plus pour être accompli.
Votre budget final sera alors en dépassement de 10% à la fin du projet.
Dans l'exemple ci-dessus, le CR est de 55 et le coût estimé pour l’achèvement de 500. Le budget à
l'achèvement sera de 55+ (500/0,91) soit approximativement 604,5. Comme notre budget total est de
550, cela montre que vous dépasserez le budget de 10% à peu près.
224
3.3 Gérer l'échéancier et le budget / Références rapides
Les livrables (3.3. P1)
ayant une licence.)
 Échéancier de projet, mis à jour
 Journal des éléments de suivi
 Journal des actions correctives
 Journal de variation de l'estimation détaillée des coûts
 Leçons apprises
 Procès-verbaux des réunions
 Liste de contrôle de fin de projet
 Projet d’ordre du jour de la réunion de démarrage
 Demande de révision de coût.
Il est à noter que cette section inclut seulement l’activité associée à la gestion de l’échéancier. Une
partie de la gestion de l’échéancier inclut la mise à jour de la situation par rapport aux problèmes
majeurs, aux risques, aux demandes de changement de contenu, etc. Cependant, ces activités seront
décrites au cours des processus en relation avec ces fonctions du management de projet.
Taille Informations requises
Les petits projets n’ont pas besoin d’activités spécifiques concernant la gestion et la mise
Petits à jour de l’échéancier. Cependant, après avoir passé en revue les activités des projets
projets de plus grande taille, vous pouvez ajouter des éléments complémentaires, si ces
éléments s’avèrent appropriés.
Chaque semaine. Activité toujours assignée au chef

du projet, bien que certaines mises à jour puissent
être assignées aux membres de l’équipe. A lieu,
d’ordinaire, le vendredi ou le lundi.
Mettre à jour Beaucoup de tâches de détail constituent cette
1-4 heures
l’échéancier activité, telles que la mise à jour de l’échéancier, la
Projets reprogrammation du projet, le contrôle du chemin
moyens critique, etc. Cependant, toutes ces tâches peuvent
être résumées par l’activité unique : ‘‘mettre à jour
l’échéancier’’.
Mettre à jour et Chaque semaine ou chaque mois, selon la

valider les disponibilité des informations relatives au budget.
dépenses courantes 1-4 heures Les dépenses réelles doivent être comparées avec le
par rapport au budget estimatif qui aurait dû être dépensé jusque-
budget là. Si le projet semble avoir tendance à dépasser le
budget, des actions correctives doivent être
225
entamées.
Tenir une réunion

Démarrage d'un projet. Y compris l'effort de
de lancement du 8 heures
préparation et de récapitulation.
projet
Hebdomadaire ou bihebdomadaire. Activité toujours

assignée au chef du projet, même si certaines mises
à jour peuvent être confiées aux membres de
l’équipe. Il devrait y avoir une (des) personne(s)
chargée(s) de réaliser une partie de la logistique liée
à la mise à jour de l’échéancier. (Cette personne est
parfois appelée administrateur de projet). Dans ce
Mettre à jour cas, prévoyez une activité dans l’échéancier pour le
3-6 heures travail de cette personne. Cette action a lieu,
l’échéancier
d’ordinaire, le vendredi ou le lundi.
Beaucoup de tâches de détail constituent cette
activité, telles que la mise à jour de l’échéancier, la
reprogrammation du projet, le contrôle du chemin
critique, etc. Toutes ces tâches peuvent être
résumées par l’activité unique : ‘‘mettre à jour
l’échéancier’’.
Effectuer des
rapports 1 heure
supplémentaires
sur l'état de
l'échéancier
Grands
projets Rechercher
d'autres signes
montrant que le 1 heure Prendre un pas en arrière et évaluer le cours du
projet pourrait projet.
rencontrer des
difficultés.
Ajuster l'échéancier 4 heures Effectuer cette opération mensuellement. S'assurer

et ajouter plus de que vous avez toujours trois mois d'activités
détails détaillées. L'échéancier pourrait rester plus vague.
Affecter le travail 1 heure

aux membres de
l'équipe
Chaque semaine ou chaque mois, selon la

Mettre à jour et disponibilité des informations relatives au budget.
valider les Les dépenses réelles doivent être comparées avec le
dépenses courantes 2-4 heures budget estimatif qui aurait dû être dépensé jusque-
par rapport au là. Si le projet semble avoir tendance à dépasser le
budget budget, des actions correctives doivent être
entamées.
Valider l'état de Mettre en œuvre les révisions à l'achèvement de

4 heures
tout le projet chaque phase.
Vérifier l'état des 1 heure Chaque mois ou lors des révisions à l'achèvement de
contrats des
chaque phase.
fournisseurs
226
Clôturer le projet 8 heures À la fin du projet.
Clôturer les Fin du projet. S'assurer que tous les contrats sont
4 heures
contrats clôturés.
227
______________________________________________________________________
Processus 4
Gérer les problèmes majeurs
228
4.0 Gérer les problèmes majeurs
Un problème majeur est formellement

défini comme un gros problème qui
empêchera la progression du projet et qui
ne peut être résolu par le chef de projet ou
l’équipe du projet sans une aide extérieure.
Problème formellement défini. Vous
devez être en mesure de documenter un
problème si vous espérez le résoudre. Si le
problème est informe et vague, il ne peut
pas être résolu. En outre, vous devez être
en mesure de communiquer la nature des
problèmes majeurs, ce qui exige qu'ils
soient aussi documentés.
Entraver la progression du projet. Il
existe de nombreux problèmes dans
l'organisation, mais n'ont pas d'impact sur
votre projet. De même, il ya aussi des
problèmes qui se posent tout le temps sur
votre projet mais qui ne sont pas aussi
importants pour avoir un impact sur votre
progression. Les problèmes majeurs ont
cette caractéristique. Ils doivent être résolus, car ils entravent l'avancement de votre projet.
Ne peut être totalement résolu ... sans aide extérieure. C'est également un point clé. Si l'équipe
du projet peut résoudre un problème, il n'atteindra pas le niveau d'un problème majeur. L'équipe du
projet peut avoir une certaine influence sur la résolution d'un problème majeur, mais la résolution
n'est pas totalement à sous leur contrôle.

Si un « problème » surgit et que le chef de projet et l'équipe peuvent le résoudre, il s’agit juste d’un
des nombreux incendies qui vont s’allumer et qui seront circonscrits au cours d’une semaine donnée.
On se trouve en face d'un « problème majeur » si une aide extérieure est nécessaire. C'est le moment
de s'assurer qu'un processus adéquat est en place pour avertir les personnes appropriées, et résoudre
le problème aussi rapidement que possible.
La gestion des problèmes majeurs est l'un des processus fondamentaux de la méthodologie TenStep de
management de projet. C’est là une des qualifications que tout chef de projet devrait posséder. La
plupart des projets de n'importe quelle taille doivent traiter ce genre de problèmes, lesquels ne peuvent
être ignorés et leur résolution ne peut être reportée à une date ultérieure. Les problèmes majeurs
doivent donc être résolus rapidement, et efficacement.
229
4.1 Gérer les problèmes majeurs / Processus
4.2 Gérer les problèmes majeurs / Techniques
4.3 Gérer les problèmes majeurs / Références rapides
230
4.1 Gérer les problèmes majeurs / Processus
Les processus utilisés pour gérer les problèmes majeurs sont décrits dans cette partie. Ces processus
peuvent être modifiés, si nécessaire, en fonction de votre projet, puis insérés dans le document de Plan
de Management de Projet, créé lors du processus 1.0 Définir le travail.
Rappelez-vous qu’un problème majeur est un problème « formellement défini » qui empêchera la
progression favorable du projet et qui ne peut pas être complètement résolu par le chef de projet ni par
l’équipe de projet sans une aide extérieure. L’expression « formellement défini » veut dire que vous
comprenez suffisamment bien le problème pour qu’il puisse être documenté. Autrement dit, si vous
n’avez pas atteint un degré de compréhension suffisant pour documenter le problème, vous n’êtes pas
encore en mesure de le résoudre.
Les documents utilisés pour définir formellement le problème majeur sont le formulaire de soumission
de problème majeur et le journal des problèmes majeurs.
4.1.1 Petits projets
4.1.2 Projets moyens
4.1.3 Grands projets
231
4.1.1. Gérer les problèmes / Petits projets
Vous ne vous attendez pas à rencontrer un grand nombre de véritables problèmes majeurs sur de
petits projets. Des problèmes peuvent surgir, mais ils peuvent généralement être résolus rapidement.
Cependant, le processus suivant devrait être employé si un problème majeur, ne pouvant être
facilement résolu, venait à apparaître.
Rôle Gérer les problèmes / Petits projets
1 Chef de projet, Identifier le problème

membres de
Les problèmes peuvent être découverts par n'importe quel membre de
l’équipe
l’équipe du projet. Ils devraient être portés à la connaissance du chef de
projet sous forme de note sur une simple feuille de papier, d'e-mail, etc.
Aucun formulaire spécifique n'est nécessaire.
2 Chef de projet Déterminer si le problème est vraiment majeur

Le Chef de projet détermine si le problème peut être résolu par l'équipe du
projet ou s'il doit être classé parmi les problèmes majeurs.
3 Chef de projet Analyser le problème et préparer des solutions alternatives

Le chef de projet doit préparer un plan pour résoudre le problème majeur
et déterminer les options, si des actions multiples sont possibles à
entreprendre. L'impact sur l’échéancier du projet doit être identifié.
4 Chef de projet, Obtenir l’accord sur la solution

commanditaire,
Le chef de projet doit présenter l'analyse, l'impact et les solutions de
parties
rechange appropriées aux preneurs de décision pour discussion et
prenantes
résolution. Le chef de projet peut prendre l’initiative de recommander
particulièrement certaines des alternatives.
5 Chef de projet Ajouter un plan d’action à l’échéancier

Une fois qu'une solution est adoptée, les activités correctives appropriées
sont ajoutées à l’échéancier du projet pour s’assurer que le problème
majeur sera résolu.
6 Chef de projet Documenter le problème majeur dans votre rapport sur la

situation
Le problème majeur, la situation en cours et la résolution doivent être
consignés dans les rapports d'avancement du projet élaborés pendant cette
période.
232
4.1.2 Gérer les problèmes / Projets de taille moyenne
Rôle Gérer les problèmes / Projets moyens
1 Chef de projet Identifier le problème.

Demander à toutes les parties prenantes du projet, y compris l’équipe du
projet, les clients, le commanditaire, etc., d'identifier les problèmes
majeurs potentiels. Ces derniers doivent être documentés par écrit dans un
court formulaire de problème majeur (facultatif) ou par e-mail.

Le chef de projet détermine si le problème peut être résolu par l’équipe ou
s'il doit être classé parmi les problèmes majeurs.
3 Chef de projet Saisir le problème dans le journal des problèmes majeurs

S’il s’agit vraiment d’un problème majeur, le chef de projet l'inscrira dans
le journal des problèmes majeurs, dans une perspective de suivi.
4 Chef de projet, Déterminer qui doit être impliqué dans la solution

commanditaire
Le chef de projet détermine qui devra être impliqué dans la résolution du
problème. Il se peut que le commanditaire doive être impliqué, mais il est
aussi possible que le commanditaire n’ait pas l’expertise nécessaire pour
apporter de l’aide dans le processus de résolution, comme dans le cas où
celle-ci nécessiterait les services de personnes compétentes dans les
domaines techniques ou légaux. Le problème pourrait aussi être lié au
contrat et donc avoir besoin d’être résolu par la division des achats.
Cependant, quel que soit le cas de figure, c’est une occasion de discuter
les alternatives et de trouver une solution. Il est donc important de
déterminer, dès le début, qui sera impliqué dans cette dernière phase de
résolution du problème majeur.
5 Chef de projet, Charger un membre de l’équipe de faire l’analyse et de trouver les

membres de alternatives
l’équipe
Le chef de projet peut charger un membre de l’équipe de mener une
enquête au sujet du problème majeur. (Le chef de projet peut également
s'en charger lui-même). Le membre de l’équipe cherchera les options
disponibles pour résoudre le problème majeur. Pour chaque option, il
devra également estimer l’impact sur le projet en termes de budget, de
délais et de contenu.

commanditaire,
parties Le chef de projet doit présenter l'analyse, l'impact et les solutions de
prenantes rechange appropriées au commanditaire du projet et aux autres parties
prenantes, en vue de la discussion et de la résolution du problème. Le chef
de projet peut aussi prendre l’initiative de recommander particulièrement
certaines des alternatives.
7 Chef de projet Documenter la solution

Le chef de projet inscrit la solution et la ligne de conduite dans le journal
des problèmes majeurs. S’il y a un formulaire de soumission de problème
majeur ouvert, celui-ci devra être, à présent, fermé et archivé.
233
8 Chef de projet Ajouter un plan d’action à l’échéancier
Une fois qu'une résolution est adoptée, les activités correctives appropriées
9 Chef de projet Mettre à jour la charte abrégée du projet, si nécessaire

Si la résolution d'un problème majeur affecte le budget, l'effort de travail
ou la durée du projet, la charte du projet doivent être mis à jour.
10 Chef de projet Communiquer à travers le rapport d'avancement

Le chef de projet communique la situation du problème majeur et sa
résolution aux membres de l’équipe du projet et à toutes les autres parties
prenantes concernées, en recourant aux processus établis dans le Plan de
management des communications du projet, y compris le rapport de son
avancement.
234
4.1.3 Gérer les problèmes / Grands projets
Rôle Gérer les problèmes / Grands projets
1 Chef de projet Identifier le problème et le documenter dans un formulaire de

soumission de problème
Demander à toutes les parties prenantes du projet, y compris l’équipe du
projet, les clients, le commanditaire, etc., d'identifier les problèmes
majeurs potentiels. Ces derniers devraient être identifiés verbalement ou
par écrit, mais ils doivent être formellement documentés par écrit dans un
formulaire de problème majeur.

Le chef de projet détermine si le problème peut être résolu par l’équipe ou
s’il doit être classé comme un problème majeur.
3 Chef de projet Consigner le problème dans le journal des problèmes majeurs

S’il s’agit vraiment d’un problème majeur, le chef de projet l'inscrira dans
le journal des problèmes majeurs.
4 Chef de projet, Déterminer qui doit être impliqué dans la résolution du problème
commanditaire
Le chef de projet détermine qui doit être impliqué dans la résolution du
problème. Il se peut que le commanditaire doive être impliqué, mais il est
aussi possible qu'il n’ait pas l’expertise nécessaire pour apporter de l’aide
dans le processus de résolution, comme dans le cas où celle-ci
nécessiterait les services de personnes compétentes dans des domaines
techniques ou légaux. Le problème pourrait aussi être lié au contrat et
donc avoir besoin d’être résolu par la division des achats. Cependant, à un
certain moment, des alternatives doivent être discutées et une solution
doit être trouvée. Il est donc important de déterminer à l'avance qui sera
impliqué dans cette dernière phase de résolution du problème majeur.
5 Chef de projet, Charger un membre de l’équipe de faire l’analyse et de trouver les

membres de alternatives
l’équipe
Le chef de projet peut charger un membre de l’équipe de mener une
enquête au sujet du problème majeur. (Le chef de projet pourrait
également s'en charger lui-même). Le membre de l’équipe cherchera les
options disponibles pour résoudre le problème majeur. Pour chaque
option, il devra également estimer l’impact sur le projet en termes de
budget, de délais et de contenu.

commanditaire,
Les diverses alternatives et leur impact sur les délais et le budget sont
parties
consignés dans le formulaire de soumission de problème majeur. Le chef
prenantes
de projet doit présenter l'analyse, l'impact et les solutions de rechange
appropriées, au commanditaire du projet et aux autres parties prenantes,
pour la résolution du problème majeur. Le chef de projet peut aussi
prendre l’initiative de recommander particulièrement certaines des
alternatives.
7 Chef de projet Fermer le journal des problèmes majeurs

Le chef de projet documente la résolution ou la ligne de conduite dans le
235
journal des problèmes majeurs.
8 Chef de projet Clore le formulaire de problème majeur

Le chef de projet documente la résolution du problème majeur dans le
formulaire de problème majeur, et ensuite il clôt et archive le document.
9 Chef de projet Ajouter le plan d’action à l’échéancier

Une fois qu'une solution est adoptée, les activités correctives appropriées
10 Chef de projet Mettre la charte à jour, si nécessaire

Si la résolution d'un problème majeur affecte le budget, l'effort de travail
ou la durée du projet, la charte du projet doit être mise à jour.
11 Chef de projet Communiquer à travers le rapport d'avancement

Le chef de projet communique la situation du problème majeur et sa
résolution aux membres de l’équipe du projet et à toutes les autres parties
prenantes concernées, à travers les processus établis dans le plan de
management des communications du projet, y compris le rapport
d'avancement du projet.
236
4.2 Gérer les problèmes / Techniques
Techniques de résolution des problèmes (4.2. P1)
Les gens créent et résolvent des problèmes depuis des millénaires. Au cours des dernières décennies,
des techniques formelles ont été développées pour améliorer les processus de résolution des
problèmes. Des douzaines de techniques de résolution de différents problèmes sont disponibles, y
compris les trois suivantes:
4.2.1 Gérer les problèmes / Analyse des cause et des effets
4.2.2 Gérer les problèmes / Analyse des causes profondes
4.2.3 Gérer les problèmes / Analyse de Pareto
Résolvez les problèmes majeurs aussi vite que possible (4.2. P2)
Un problème majeur est défini en tant que problème qui entravera le progrès du projet et qui ne peut
pas être totalement résolu par l'équipe projet. Cette définition démontre que les problèmes majeurs
doivent être pris en main rapidement. Si un problème est effectivement classé en tant que problème
majeur, le chef de projet doit prendre la responsabilité de le résoudre. Le chef de projet prévoira,
toutes les semaines, dans l'échéancier du projet, une activité pour suivre les problèmes majeurs
soulevés, et s’assurer qu’ils sont résolus rapidement.
Dans la même logique, si le problème majeur se pose depuis un certain temps, vous devriez y regarder
de plus près, afin de vérifier s’il s’agit réellement d’un problème majeur. Il s’agit peut-être d’un
problème potentiel (risque) ou d’un élément de suivi qui peut être résolu plus tard. Les problèmes
majeurs doivent, étant donné leur nature, être réglés de manière urgente.
Essayez de résoudre la cause profonde, pas seulement les symptômes (4.2. P3)
Quand les problèmes surgissent, ils doivent être résolus aussi rapidement que possible. Assurez-vous,
cependant, de bien résoudre la cause profonde du problème majeur, et pas simplement le symptôme.
Résoudre la cause profonde vous permettra de vous assurer que le problème ne refera pas surface plus
tard dans le projet. La cause profonde peut habituellement être trouvée en se posant une série de
questions « pourquoi ? ». Pourquoi le problème majeur est-il apparu? Lorsque vous avez répondu à la
question, demandez-vous « pourquoi » encore et encore. Quand vous ne pouvez plus répondre à la
question « pourquoi », vous êtes alors probablement tout près de trouver la cause profonde. Voyez le
paragraphe 4.2.2 Gérer les problèmes / Analyse des causes profondes pour plus d'informations.
Parfois, vous devez choisir parmi de mauvaises alternatives (4.2. P4)
Après avoir passé en revue le processus et les techniques pour la gestion des problèmes majeurs, vous
pensez peut-être que vous pouvez résoudre chaque problème, si seulement vous êtes en possession de
la technique appropriée. En fait, vous pouvez rencontrer quelques problèmes majeurs pour lesquels il
n’existe aucune solution claire et précise. Il est difficile, dans certains cas, de déterminer toutes les
bonnes options pour la résolution d’un problème. D'autres fois, on peut se trouver face à des problèmes
majeurs qu’il est difficile de résoudre, non pas en raison d’un manque d'options, mais en raison de la
difficulté d'obtenir l'approbation d’une méthode de résolution parmi un certain nombre d'alternatives.
Dans d'autres cas, vous pouvez avoir des options qui ne sont pas optimales, et la résolution finale sera
celle qui s'avèrera être la moins déplaisante.
Comme exemple de ce dilemme, prenons un problème majeur qui implique la politique interne.
Généralement, quand un problème commence à concerner la politique interne, vous constatez que sa
résolution est difficile, parce que le processus décisionnel nécessite plus qu'un simple examen des faits.
En fait, quand un problème devient politique, une résolution, qui est loin d'être réellement optimale
237
pour l’équipe du projet, peut être approuvée. Cependant, cette solution imparfaite peut être préférable
à l'impasse ou à la perspective de voir approuver une alternative encore plus mauvaise.
Dans ces situations, essayez de faire comprendre aux personnes chargées de l’approbation qu'un retard
dans le choix de la solution ne la rend pas, généralement, plus appréciable. Le chef de projet devrait
tâcher d’obtenir une solution aussi rapidement que possible, de sorte que le projet puisse avancer.
Si le problème majeur est politique, le chef de projet devra, généralement, compter fortement sur le
commanditaire et les autres parties prenantes pour l’aider à le résoudre.
Indiquez quand des membres de l’équipe peuvent prendre des décisions (4.2. P5)
Après avoir souligné l'importance de porter les problèmes majeurs éventuels et les modifications
potentielles du contenu à la connaissance du chef de projet, certains membres de l’équipe peuvent
avoir le sentiment qu'ils n'ont la capacité de ne prendre aucune décision. Vous ne voulez certainement
pas donner cette impression. En tant que chef de projet, vous avez besoin d’encourager le personnel à
accepter des responsabilités et à prendre des décisions lorsqu'il le faut. Cela peut aider l'équipe à
fonctionner plus efficacement, et permet aux individus de mûrir professionnellement.
En tant que chef de projet, vous avez besoin que les membres de votre équipe gèrent les problèmes du
quotidien et qu’ils ne vous les soumettent qu’exceptionnellement. En même temps, vous résolvez
autant de problèmes que vous pouvez, et ne soumettez que les vrais problèmes majeurs au
commanditaire, pour lui demander de l'aide. En général, les membres de l’équipe doivent se poser
quelques questions clés avant de décider s’ils ont besoin d'aide ou s’ils peuvent prendre par eux-mêmes
une décision.
 Y a-t-il un impact sur l'effort de travail, la durée ou le coût? Si oui, le chef de projet doit être
impliqué.
 La décision exige-t-elle de sortir du contenu ou de dévier par rapport aux spécifications

précédemment convenues? Si oui, le chef de projet doit être impliqué.
 La décision est-elle politiquement sensible? Si oui, le chef de projet doit être impliqué.
 La décision exige-t-elle que vous ne teniez pas un engagement pris précédemment? Si oui, le
chef de projet doit être impliqué.
 La décision expose-t-elle le projet à de nouveaux risques? Si oui, le chef de projet doit être
impliqué.
Si ces conditions ne sont pas réunies, les membres de l’équipe peuvent alors prendre une décision. Il
peut sembler qu’il n’en reste aucune à prendre. En fait, la plupart des décisions qui doivent être prises
au quotidien ne réunissent pas ces critères, et peuvent être prises par l'équipe ou les différents
membres de l’équipe.
Faire la différence entre problèmes majeurs et éléments de suivi (4.2. P6)
Dans de nombreux cas, les chefs de projets n’utilisent pas le journal des problèmes majeurs pour
identifier et localiser les vrais problèmes majeurs. Beaucoup de questions sont classées comme des
problèmes majeurs alors qu’il s’agit, en réalité, de risques (problèmes potentiels) ou tout simplement
d’éléments de suivi. Les éléments de suivi sont des activités qui doivent retenir l'attention pendant un
certain temps. Elles peuvent ne pas impliquer de problèmes pour le projet. Si vous constatez que votre
journal des problèmes majeurs contient des douzaines d’éléments de ce genre, c’est que vous suivez
probablement un grand nombre de ces éléments. Puisque les problèmes majeurs sont de gros
problèmes, il ne devrait pas y en avoir beaucoup au même moment. Pour plus d'informations sur les
éléments de suivi, prenez connaissance du paragraphe 3.2A.1 Éléments de suivi.
Demandez aux membres de l’équipe d’identifier les problèmes et les solutions (4.2. P7)
238
Les problèmes majeurs peuvent être signalés par des membres de l’équipe, des clients ou n’importe
quelle partie prenante du projet. C’est une bonne habitude que d'encourager les gens à participer à
l'identification des solutions en même temps que les problèmes majeurs. Quand un membre de l’équipe
identifie un problème majeur potentiel, demandez-lui de fournir une ou plusieurs solutions possibles. Ce
processus aidera à responsabiliser les membres de l’équipe, mais également à déterminer les lignes de
conduite possibles. En fait, si un membre de l’équipe propose une ou plusieurs solutions viables, le
problème pourra être résolu avec l'aide du chef de projet et n'atteindra pas du tout le niveau de
problème majeur.
Impliquez le client très tôt dans la gestion des problèmes majeurs (4.2. P8)
La gestion des problèmes majeurs tend à se dérouler sans à-coups lorsque toute l’équipe de projet se
sent à l’aise lorsqu’elle utilise dès le début le processus de gestion des problèmes majeurs. Si les
problèmes majeurs surgissent tôt dans un projet, assurez-vous de suivre votre processus de gestion de
ce genre de problèmes et impliquez le client dans la solution. Les problèmes majeurs deviennent de
plus en plus pressants lorsque vous vous rapprochez de votre date limite. Ne laissez pas les problèmes
relatifs à ce stade final devenir les premiers auxquels le client se trouvera confronté. Des expériences
de gestion de ce genre de problèmes vécus plus tôt donneront, par la suite, l’impression au client de se
trouver seulement face à des obstacles provisoires qui peuvent être surmontés. Si vous n'avez pas
impliqué le client plus tôt dans le processus de gestion des problèmes majeurs, il peut causer plus de
mal que de bien lorsque vous aurez absolument besoin de lui, à la fin, puisqu'il ne sera pas familiarisé
avec ce processus.
Divisez les très gros problèmes en problèmes plus petits (4.2. P9)
Si un gros problème majeur semble difficilement résolu de manière satisfaisante, divisez-le en une suite
logique de sous-problèmes majeurs. Dans de nombreux cas, la résolution d'un premier sous-problème
majeur facilitera la solution pour le reste du problème majeur. Sinon, cela permet au moins aux gens de
comprendre les différentes composantes du problème majeur, qui pourraient ainsi être abordées et
résolues au cas par cas.
Cherchez la cause commune si vous rencontrez beaucoup de problèmes majeurs en peu de

temps (4.2. P10)
Parfois, vous pouvez rencontrer un certain nombre de problèmes majeurs en un court laps de temps. Si
cela arrive dans votre projet, regardez voir si certains de ces problèmes sont reliés. Si oui, essayez de
résoudre le problème qui ressemble le plus à une cause profonde. La résolution de ce problème majeur
permettra d’en résoudre d'autres.
Si les problèmes majeurs semblent indépendants les uns des autres, essayez de résoudre en priorité
ceux qui ont l'impact le plus négatif sur le projet.
239
4.2.1 Analyse des causes et des effets
(4.2.1. P1)
Cette technique de résolution de problèmes est une manière d'analyser les problèmes complexes qui
semblent avoir beaucoup de causes corrélées. L’un des aspects principaux de cette technique est
l'utilisation d’un diagramme de cause à effet. En raison de l'aspect du diagramme, cette technique
s'appelle également un diagramme en arête de poisson. (Un autre nom que vous pourriez rencontrer
pour cette technique est celui de diagramme d'Ishikawa. C’est le nom du professeur japonais Kaoru
Ishikawa, qui a l’a utilisée pour la première fois en 1943.) Les avantages de cette technique sont les
suivants :
 Elle permet d’explorer diverses catégories de causes.
 Elle encourage la créativité au moyen d'un processus de brassage d'idées (brainstorming).
 Elle fournit une image visuelle du problème et des catégories potentielles de causes.
Développer un diagramme en arête de poisson (4.2.1. P2)
Utilisez le processus suivant pour créer un diagramme en arête de poisson:
Rôle Développer un diagramme en arête de poisson
1 Chef de Décrire le problème

projet,
Décrivez le problème dans une boîte que vous placez du côté droit du
membres
diagramme. Cela peut être soit le problème réel soit un symptôme. À ce stade,
de l’équipe
vous n'en êtes pas très sûr.
2 Chef de Créer ‘‘l’arête’’

projet,
Dessinez une longue flèche horizontale pointant vers la boîte. Cette flèche
membres
servira d'épine dorsale à laquelle seront reliées, par catégorie, de nombreuses
de l’équipe
causes principales et mineures à la fois.
3 Chef de Identifier les catégories principales de causes et les classer le long de

projet, l’arête
membres
Identifiez les causes potentielles et regroupez-les par catégories principales.
de l’équipe
Exemples de catégories principales: le personnel, les processus, le matériel,
l'équipement, l'environnement, etc. Les catégories principales sont identifiées
en utilisant des techniques du brainstorming. À ce stade, ne vous inquiétez pas
s'il y a des désaccords à propos de la question de savoir si une catégorie
particulière contiendra la cause potentielle ou pas. Incluez-les toutes, sans
distinction. Veillez à laisser assez d'espace entre les catégories principales sur
le diagramme, de sorte que vous puissiez ajouter les causes mineures
détaillées ultérieurement. Chacune de ces catégories principales sera explorée
plus en détail.
240
4 Chef de Chercher des causes plus détaillées pour chaque catégorie
projet,
Continuez le brassage d'idées au sujet des causes, en cherchant des
membres
explications plus détaillées pour chacune des catégories principales de causes
de l’équipe
identifiées. Inscrivez les causes plus détaillées sur des lignes horizontales
reliées aux lignes inclinées des catégories principales appropriées.
5 Chef de (Facultatif) Chercher des causes additionnelles pour les détails

projet,
Parfois, les causes détaillées ont d’autres causes, plus granulaires, qui
membres
apparaissent à ce stade. Si c’est le cas, créez des lignes complémentaires
de l’équipe
reliées aux lignes détaillées. Trois niveaux de détails constituent la limite
pratique habituelle pour ce diagramme.
6 Chef de Analyser les causes et les classer par ordre de priorité

projet,
Quand le brainstorming pour déterminer les catégories principales et les
membres
causes potentielles détaillées est terminé, commencez à analyser les
de l’équipe
informations que vous venez de compiler. Évaluez chaque cause principale et
les causes potentielles détaillées associées. Souvenez-vous que la liste de
départ a été compilée par une séance de brassage d'idées où toutes les idées
ont été incluses. Maintenant, vous devez déterminer lesquelles sont les plus
susceptibles d’être la cause (ou l’une des causes). Entourez celles qui semblent
les plus prometteuses et qui devraient être étudiées plus en détail.
7 Chef de Déterminer quel secteur a le plus d’impact et la meilleure chance de

projet, succès
membres
S’il n’y a pas un consensus évident sur les secteurs les plus importants à
de l’équipe
étudier, employez une sorte de système de vote pour rapprocher formellement
les choix les plus importants avec ceux qui ont les plus grandes chances de
réussite.
241
8 Chef de Élaborez un plan d’action pour remédier aux causes encerclées
projet,
Rappelez-vous qu'il peut y avoir bon nombre de causes potentielles qui
membres
interagissent les unes sur les autres pour créer le problème. Le plan d’action
de l’équipe
doit tenir compte de ces interdépendances. S'il y a encore des causes
détaillées qui sont toujours trop complexes, ou si les informations connues
sont insuffisantes, elles peuvent alors être assignées à une ou plusieurs
personnes pour une analyse plus poussée en dehors de la réunion.
D'autres règles pour une session d'analyse des causes et des effets (4.2.1. P3)
Employez ces règles et techniques complémentaires au cours de votre session.
 Assurez-vous que tout le monde est d’accord sur le problème que vous essayez de résoudre. Le
processus de brassage d'idées peut devenir chaotique et confus si les gens essayent de
résoudre différents problèmes à la fois.
 Employez les techniques formelles de brainstorming pour recueillir les listes initiales des
catégories principales et des causes détaillées. Toutes les idées doivent être prises en compte.
Les discussions doivent se limiter à la compréhension des idées, pas à la décision concernant
leur validité éventuelle.
 Il peut y avoir une tendance à passer directement des catégories principales aux solutions.
Assurez-vous que vous explorez toutes les causes, principales et détaillées, avant de vous
orienter vers la résolution des problèmes.
 Assurez-vous que le groupe entier peut observer le diagramme en arête de poisson afin que les
connexions et les relations soient visuellement évidentes pour tous.
 Ne laissez pas le diagramme devenir trop encombré. Si une catégorie commence à dominer le
diagramme, elle peut être déplacée vers un deuxième diagramme.
Faites attention aux causes détaillées qui apparaissent à plusieurs reprises dans différentes catégories
principales. Cela peut indiquer qu'il s'agit peut-être d'une cause profonde.
242
4.2.2 Analyse des causes profondes
Parfois, lorsque vous essayez de résoudre un problème, vous constatez que ce que vous prenez pour
une cause n’est vraiment qu’un symptôme qui s’y rapporte, et non la cause réelle du problème lui-
même. Considérez l'exemple classique suivant :
Un directeur d’usine se déplace près d’une chaîne de montage et remarque une flaque d'eau
sur le sol. Sachant que l'eau est un risque en matière de sécurité, il demande au surveillant la
faire nettoyer par quelqu'un. Le directeur est fier de lui-même pour avoir résolu un problème
potentiel de sécurité. Le surveillant recherche la cause profonde en se demandant 'pourquoi?',
et il découvre que la mare d’eau est provoquée par une fuite dans une canalisation aérienne.
Il se demande encore 'pourquoi ', et découvre que la canalisation fuit parce que la pression de
l'eau est trop forte. Il se demande encore 'pourquoi?', et découvre que la soupape de
refoulement de l'eau est défectueuse. Il se demande encore 'pourquoi?', et n'obtient pas
d’autre réponse. Ainsi, la valve est remplacée, ce qui résout le symptôme constitué par la
présence de l'eau sur le sol de l’usine.
L'analyse des causes profondes est une manière d'identifier
la cause ultime d'un problème. Dans l'exemple ci-dessus, il
était question de diverses solutions qui ne peuvent en
aucune façon résoudre le problème d’une manière radicale.
D'abord, le directeur aurait pu commander plus de
serpillières pour nettoyer le sol de l'usine. Le surveillant
aurait également pu remplacer la canalisation aérienne.
Cependant, ces solutions auraient finalement été inutiles et
elles n'auraient pas résolu le problème puisqu’elles ne
s’adressaient qu’aux symptômes, pas au problème lui-
même.
L'analyse des causes profondes est habituellement réalisée

en se posant une série de questions. Comme l'exemple ci-
dessus l’illustre, vous vous demandez " pourquoi " un
problème existe. Puis vous remontez dans la chaine des
causes. À chacune de ces causes, vous vous demandez une
nouvelle fois " pourquoi? ". Si vous pouvez de nouveau
répondre à cette question, alors la première réponse est probablement un symptôme provoqué par une
cause plus fondamentale. Continuez à vous demander " pourquoi? " à la suite de chaque réponse,
jusqu'à ce que vous ne puissiez plus produire de réponse logique. Ce niveau le plus bas est susceptible
d'être une cause profonde, celle qui est à l’origine de ces symptômes observés. Vous pouvez découvrir
plus d'une cause profonde au moyen de cette analyse.
Quand vous avez identifié les causes profondes, mettez en place un plan d’action pour résoudre le
problème. Les symptômes devraient logiquement disparaître.
243
4.2.3 Analyse de Pareto
L’analyse de Pareto peut être employée quand vous rencontrez de multiples problèmes connexes ou un
problème commun avec des causes multiples. Avec cette technique, vous pouvez également rassembler
des indicateurs sur le nombre de fois où chaque problème ou cause se produit. Le but de l'analyse de
Pareto est d’observer les problèmes et de déterminer leur fréquence d'apparition. Ceci, en retour, vous
fournit les informations dont vous avez besoin pour classer les problèmes par ordre de priorité afin de
vous assurer que vous investissez votre temps là où il aura l'impact le plus positif.
L’analyse de Pareto est basée sur la règle classique du 80/20. Cela veut dire que dans plusieurs cas,
20% des problèmes entraînent 80% des occurrences. Admettons que vous ayez un problème avec un
défaut sur un produit en raison d’un certain nombre de facteurs. Par l'observation et la collecte
d’indicateurs, vous déterminez qu’il y a huit causes. Plutôt que de s’attaquer aux causes de façon
aléatoire, une analyse de Pareto prouvera que 80% des problèmes sont dus à trois facteurs principaux.
Cela vous fournit les informations nécessaires pour savoir quelle cause vous devez d'abord affronter.
L'outil associé à cette technique de résolution des problèmes est le diagramme de Pareto. Il s’agit d’un
diagramme, graphique ou histogramme, montrant chaque problème et sa fréquence d’apparition. Il est
créé de la façon suivante:
Rôle Développer un diagramme de Pareto
Créez une liste de tous les problèmes ou causes observés.

Pour chacun des problèmes ou causes, identifiez le nombre d'apparitions sur
une période fixe.
Problème Occurrences
Problème 1 115 fois

Chef de projet, Problème 2 25 fois
1 membres de
l’équipe Problème 3 50 fois
Problème 4 5 fois
Problème 5 5 fois
Problème 6 15 fois
Chef de projet,
Classez les problèmes dans un ordre dégressif, en vous basant sur la
2 membres de
fréquence.
l’équipe
Créez une nouvelle colonne pour le total cumulatif.
Problème Occurrences Total cumulatif
Chef de projet, Problème 1 115 fois 53%

3 membres de
l’équipe Problème 3 50 fois 77%
Problème 2 25 fois 88%
244
Vous pouvez ajouter d'autres colonnes relatives à l'importance des problèmes

et les coûts et efforts à déployer pour les résoudre.
Notez que ce travail vous fournit des informations importantes. Bien qu'il y ait six problèmes identifiés,
vous devez résoudre d’abord les problèmes #1 et #3 (toutes choses étant par ailleurs égales). C’est
avec eux que vous obtiendrez le plus d’impact. Si, au lieu de cela, vous décidez de travailler sur les
problèmes #4 et #5, le résultat de votre effort sera presque insignifiant. Cela ne signifie pas que vous
ne voulez pas résoudre les autres problèmes. Cependant, cette analyse de Pareto vous fournit les
informations pour savoir quels sont les problèmes à résoudre en priorité. Elle vous fournit également
des informations quant à la valeur relative que vous obtiendrez en résolvant chaque problème. Vous ne
voudriez certainement pas allouer le même effort de travail à la résolution du problème #5 plutôt qu’à
celle du problème # 1. Cela n’en vaut tout simplement pas la peine. (Vous pourriez aussi conclure que
le problème #6 est facile à résoudre et que vous voulez y remédier plus tôt. Le diagramme de Pareto
ne vous indique pas quelle approche vous devez suivre. Son seul but est de vous informer pour vous
permettre de prendre les meilleures décisions)..
Bien souvent, vous verrez les résultats du diagramme de Pareto présentés selon un histogramme ou un
diagramme à barres. Cela donne plus d’emphase visuelle aux données que vous avez observées.
245
4.3 Gérer les problèmes majeurs / Références rapides
Livrables (4.3. P1)
ayant une licence.)
 Formulaire de soumission de problèmes majeurs
 Journal des problèmes majeurs
Taille Information requise
Les petits projets n’ont pas besoin de processus spécifiques de l’échéancier axés
Petits autour du management des problèmes majeurs. Cependant, après avoir passé en revue
projets les activités pour projets de taille moyenne, vous pouvez ajouter des éléments à votre
échéancier, s’ils s’avèrent appropriés.
Passer en revue Chaque semaine. Tâche toujours assignée au chef de

l’état des projet. Utiliser ce temps pour s’assurer qu’il y a des
1-2 heures
problèmes progrès sur tous les problèmes majeurs et que le
majeurs journal des problèmes majeurs est à jour.
Projets
moyens Analyser les Ajouter une activité pour l’analyse de tout problème en
problèmes ouvert cours dont l’analyse a été confiée à un membre de
majeurs l’équipe.
Résoudre les Si la résolution d’un problème majeur requiert des

problèmes Ouvert activités de travail supplémentaires, ces dernières
majeurs doivent être ajoutées à l’échéancier.
Passer en revue Chaque semaine. Tâche toujours assignée au chef de

l’état des projet. Utiliser ce temps pour s’assurer qu’il y a des
1-2 heures
problèmes progrès sur tous les problèmes majeurs et que le
majeurs journal consacré à ce genre de problèmes est à jour.
Analyser les Ajouter une activité pour l’analyse de tout problème en

problèmes ouvert cours dont l’analyse a été confiée à un membre de
Grands
majeurs l’équipe.
projets
Résoudre les Si la résolution d’un problème majeur requiert des
problèmes ouvert activités de travail supplémentaires, ces dernières
majeurs doivent être ajoutées à l’échéancier.
Ajouter une activité pour mettre à jour la charte du

Mettre à jour la projet afin qu’elle reflète les changements de coût,
ouvert
charte du projet d’effort ou de durée, générés par la résolution d’un
problème majeur.
246
______________________________________________________________________
Processus 5
Gérer le contenu
247
5.0 Gérer le contenu
(5.0. P1)
Tout le monde en convient : la seule

constante dans le monde, c’est le «
Changement ». Vous pouvez concevoir des
plans parfaits, mais ils ne représentent rien
face à n’importe quel changement potentiel
qui viendrait à survenir. Plus la durée de
votre projet est longue, plus vous aurez
probablement affaire à des changements.
C’est la raison pour laquelle le processus
TenStep conçoit très bien que les
processus de définition initiale (processus
1) et de planification (processus 2) ne
soient pas parfaits. Votre équipe et vous-
même devez accomplir le meilleur travail
que vous pouvez, étant donné l’état de vos
connaissances au moment où vous
l’effectuez. Et c’est déjà bien ainsi. Par la
suite, vous devez gérer le contenu.
Modifications du contenu (5.0. P2)
« Contenu » est le terme utilisé pour désigner la totalité du travail ainsi que les limites du projet. Le
contenu est utilisé pour définir ce que le projet livrera et ce qu'il ne livrera pas. Pour les plus grands
projets, la définition du contenu peut inclure les livrables importants qui sont créées, les organisations
concernées, les transactions affectées, les types de données incluses, etc.
Si vous regardez les raisons pour lesquelles les projets échouent, vous vous trouvez habituellement
confronté à deux problèmes : Soit que l'équipe n'a pas passé assez de temps à définir le travail, soit qu’
il y avait un manque de management du contenu du projet. Même si le chef de projet a réalisé du bon
travail au niveau de la définition du contenu, la partie difficile est de gérer le projet à l’intérieur de ce
contenu, tel qu’il a été convenu au départ.
Le but du management du contenu du projet est de protéger la viabilité de la charte du projet

approuvée et celle des exigences commerciales, elles aussi approuvées. En d’autres termes, la charte
du projet définit le contenu global du projet, alors que les exigences commerciales définissent les
248
livrables dans le détail. L’équipe du projet s’est engagée pour une date limite et un budget, sur la base
de cette définition, à la fois générale et détaillée, du contenu du projet. Si un changement des livrables
est effectué pendant le projet (et habituellement cela signifie que le client réclame des éléments
supplémentaires), les estimations initiales du coût, de l'effort de travail, et de la durée peuvent ne plus
être valides. Si le commanditaire accepte d'inclure le nouveau travail dans le contenu du projet, le chef
de projet a le droit d’exiger que les coûts, l'effort de travail et/ou la durée soient modifiés
(habituellement, ils s’accroissent) pour justifier ce travail supplémentaire. Ces nouvelles estimations de
coût, d'effort de travail et de durée deviennent alors le nouvel objectif approuvé.
Parfois le chef de projet pense que la gestion du contenu revient à dire « non » au client. Cela peut
rendre le chef de projet nerveux et le mettre mal à l’aise.
Ce qu’il faut garder à l’esprit, c’est qu’une gestion efficace du contenu n’a d’autre intérêt
que d’amener le commanditaire à prendre des décisions qui entraîneront des modifications
du contenu.
Cela est très important. Peu de clients peuvent voir et exprimer chaque spécification à l'avance. Par
conséquent, il y a habituellement des changements qui doivent être introduits dans le projet. Ces
changements peuvent s’avérer tout à fait nécessaires pour la solution et il peut y avoir des raisons
commerciales valides pour lesquelles ils devront être pris en compte. Le chef de projet et l’équipe de
projet doivent savoir quand ces changements deviennent incontournables. Ils doivent alors suivre un
processus prédéfini de modification du contenu. Ce processus fournit, en fin de compte, les
informations appropriées au commanditaire du projet et lui permet de décider si la modification doit
être approuvée, en se basant sur la valeur marchande ainsi que sur l'impact pour le projet, en termes
de coûts et de délais.
5.0.1 Définir le contenu
5.0.2 Créer le plan de management du contenu
5.0.3 Créer un plan de management des exigences
5.0.4 Réunir les exigences
5.0.5 Assurer la traçabilité
5.0.6 Vérifier le contenu
5.1 Gérer le contenu / Processus
5.2 Gérer le contenu / Techniques
5.3 Gérer le contenu / Références rapides
249
5.0.1 Définir le contenu
(5.0.1. P1)
Définir le contenu est peut-être la partie la plus importante de la définition et du procédé de

planification initiaux. Si vous ne savez pas ce que vous devez livrer et où se situe le périmètre du
projet, vous n’avez aucune chance de le mener à bien. Si vous n’avez pas fait un bon travail de
définition du contenu, la gestion de celui-ci sera presque impossible.
L’objectif de la définition du contenu est de décrire clairement les frontières logiques de votre projet et
d’obtenir un accord à leur sujet. L’énoncé du contenu sert à définir ce qui est situé ou non à l'intérieur
du périmètre du projet. Plus vous pouvez identifier des aspects du contenu, plus votre projet aura de
chances de bien se dérouler. Définir le contenu de votre projet comporte deux aspects importants : les
livrables et les limites.
 Les livrables. Même si vous n'êtes pas encore sûr de savoir ce que vous devez incorporer
dans la définition de votre contenu, vous devez toujours inclure vos livrables. Le fait de
comprendre les livrables que vous produisez concorde avec la compréhension du contenu du
projet.
Tous vos livrables finaux doivent évidemment être listés. Il s’agit des livrables que vous
produisez pour votre client. En outre, vous pouvez lister les livrables internes axés sur le client,
tel que le rapport sur les exigences commerciales ainsi que l'évaluation de la situation courante.
Ces livrables doivent être approuvés par le client. Il sera ainsi raisonnable de les mentionner.
D'autre part, vous n’aurez pas besoin de faire référence à d’autres documents internes au
projet, tels que l'échéancier du projet, les spécifications de la conception technique ou les
protocoles de tests. Le commanditaire ne comprend pas ces livrables. De toute façon, il n’y
prêtera pas attention.
 Limites du projet. Les énoncés relatifs

aux limites sont utilisés pour décrire les
aspects de l'environnement inclus dans le
contenu versus ceux qui ne le sont pas.
Vous n'aurez pas besoin de mentionner
qu'un certain aspect du projet était dans le
contenu à moins que vous puissiez aussi
indiquer, en contrepartie, qu'un certain autre aspect n'est pas inclus dans le contenu. La nature
d'un véritable énoncé de limite est qu'il y a une contrepartie dans le contenu et une autre
contrepartie pertinente qui ne l'est pas. Par exemple :
o Les principaux processus du cycle de vie qui sont dans le contenu ou hors de
celui-ci. Votre projet peut inclure seulement la phase d'analyse, et pas celles de
conception, de construction, d’essais, etc.
o Les types de données qui sont dans le contenu et hors du contenu.

L’expression « types de données » se rapporte à des livrables tels que des «données
financières », des « données concernant les ventes » ou des « données concernant les
employés ». Il se peut que votre projet utilise certains types de données et pas
d’autres.
o Les sources de données (ou bases de données) qui sont dans le contenu et
hors de celui-ci. Il y a des similitudes avec les types de données, excepté le fait que
vous fassiez référence à des agrégats de données, tels que la base de données des
clients, le grand livre, le système de facturation, etc. (ces sources de données peuvent
comporter plus d’un type de données).
o Les organisations qui sont dans le contenu et hors de celui-ci : Dans certains
cas, les organisations concernées par le projet peuvent aider à délimiter le périmètre
250
du projet. Par exemple, le produit de votre projet peut être applicable aux directions «
ressources humaines » ou « comptabilité », alors que la division « fabrication » serait
en dehors du contenu.
o Les fonctionnalités principales qui sont dans le contenu et celles qui sont
hors du contenu. Par exemple, la fonctionnalité qui aide à la décision et à la gestion
des rapports d'avancement. Les fonctionnalités peuvent être incluses dans le contenu,
alors que la fonctionnalité concernant le traitement des données, effectué la nuit, serait
en dehors du contenu.
Les objectifs généraux comme point de départ (5.0.1. P2)
Quand le projet a été initialement proposé en vue de son financement, il doit y avoir un ensemble
d’objectifs généraux et des livrables initiaux définis. Il pouvait aussi y avoir un énoncé général du
contenu. Toutes les informations qui ont été rassemblées précédemment devraient être utilisées
comme point de départ pour une formulation plus détaillée du contenu, en vue de l’élaboration de la
charte du projet. Si vous constatez que vous n'avez pas assez d'information pour aboutir à un énoncé
clair et compréhensible du contenu, vous devez travailler avec le commanditaire pour recueillir des
renseignements complémentaires. C'est l'un des principaux objectifs des processus de définition et de
planification.
S’il existe des objectifs ayant été définis pour le projet, consultez-les pour en tirer profit dans
l’élaboration de l’énoncé du contenu. Par définition, il faut créer un ou plusieurs livrables pour réaliser
chaque objectif. Définir les livrables du projet est l’un des aspects fondamentaux de la définition du
contenu du projet. Après avoir déterminé les principaux livrables que le projet produira, commencez à
poser d'autres questions pour déterminer de nouveaux aspects du contenu. Les livrables décrivent ce
que le projet doit livrer. Vous pouvez également identifier quelles organisations seront concernées,
quels types de données et quels dispositifs et fonctionnalités fondamentaux seront nécessaires, etc.
Pour plus de clarté et de précision, vous pouvez également identifier ce qui n’est pas compris dans le
projet en décrivant des livrables possibles mais qui ne seront quand même pas créés, quelles
organisations ne seront pas impliquées, quels dispositifs et fonctions ne seront pas inclus, etc.
Naturellement, il existe un nombre infini d’éléments en dehors du contenu. Dans le cadre de la
définition du contenu, vous inclurez seulement ceux qui aident à définir le périmètre du projet et qui
abordent des domaines connexes pour lesquels le lecteur pourrait se poser des questions. Par exemple,
si vous installez un progiciel financier, vous pouvez déclarer que le progiciel de comptabilité de
paiement se trouve « dans le contenu », mais que le système connexe des achats est « hors du
contenu ». Cependant, vous ne devez pas énumérer tous les autres systèmes comme étant hors du
contenu, mais seulement ceux à propos desquels le lecteur pourrait se poser des questions.
Une bonne pratique de gestion de projet consiste à lister les organisations comprises dans le contenu et
celles qui ne le sont pas. Les parties prenantes peuvent alors savoir plus facilement si elles sont
impliquées et si l’on attend qu’elles apportent leur concours au projet. Par ailleurs, une autre raison très
importante pour identifier les organisations qui sont dans le contenu, réside dans la possibilité d’avoir
besoin de personnel ou d’autres compétences provenant de ces organisations, soit en tant que
membres de l’équipe, soit pour participer au comité de pilotage, pour ne citer que ces deux exemples.
Alignez les objectifs et le contenu (5.0.1. P3)
Quand vous avez terminé l’élaboration de vos énoncés d’objectifs et de contenu, revenez en arrière
pour vous assurer qu'ils soient cohérents. Tous les objectifs doivent aboutir à un livrable qui matérialise
leur réalisation. Si vous ne faites rien pour atteindre un objectif, vous ne pourrez jamais le réaliser.
De même, tous les livrables listés dans l’énoncé du contenu doivent être nécessaires pour satisfaire les
objectifs énoncés. Vous ne voulez pas produire des éléments non essentiels à l’atteinte des objectifs du
projet. Puisque les objectifs décrivent le but du projet et qu'ils sont utilisés pour valider le succès de ce
dernier, pourquoi voudriez-vous concevoir des livrables qui ne vous permettent pas de réaliser vos
objectifs?
251
Si les livrables listés dans l’énoncé du contenu ne sont pas concordants avec les objectifs du projet,
vous devez les « aligner ». Voici comment procéder:
 S’il manque un livrable pour réaliser un objectif, vous devez vérifier si l’objectif est réellement
important. S’il l’est, vous devez alors ajouter un livrable pour l’atteindre.
 Si vous trouvez un livrable qui semble ne répondre à aucun objectif, vous devez vous demander
s’il est vraiment important. S’il ne l’est pas, écartez-le du projet. Si le livrable semble vraiment
important, vous devez travailler avec le commanditaire pour vérifier l’énoncé des objectifs du
projet où la définition d’un objectif important semble manquer. Peut-être cet objectif est-il
valable mais qu’il n’a pas encore été énoncé explicitement.
252
5.0.2 Créer le plan de management du contenu
Le plan de management du contenu est utilisé pour décrire la manière avec laquelle le contenu va être
défini, vérifié, et subséquemment géré. Les composants du plan de management du contenu incluent
les éléments suivants:
 Les rôles et les responsabilités. Vous pourriez décrire qui est responsable de l'établissement
et de la gestion du contenu du projet, qui va participer à sa définition , qui peut l’approuver, qui
peut en demander des modifications, qui peut en approuver les demandes de modification, etc.
 Définition du contenu. Cette section décrit comment vous pouvez établir le contenu du
projet. Il existe probablement un ensemble d'activités à exécuter, mais dans cette section vous
résumeriez l'approche générale.
 Processus de révision et d'approbation des modifications du contenu. Cette section

décrit le processus à suivre pour traiter les demandes de modification du contenu. Elle définit
l'autorité habilitée à accepter et à approuver les modifications du contenu. Le processus
d'évaluation devrait inclure aussi une évaluation de l'impact des modifications proposées du
contenu, sur le projet ainsi que les avantages du changement. Les impacts sur les coûts,
l'échéancier, les risques et la qualité devraient être évalués dans le but de fournir un fondement
pour accepter et approuver une modification.
 Outils. Cette section décrit n'importe quelle gestion de contenu ou n'importe quel outil de
gestion de changement de contenu, qui aura accès à l'outil ainsi que les différentes personnes
qui peuvent le manipuler.
 Modèles. Il est courant que dans la définition du contenu il y ait un ou plusieurs modèles
(gabarits) à utiliser durant le processus de gestion du contenu et des modifications de celui-ci.
Un annexe du plan de management du contenu devrait inclure un exemplaire de chaque
modèle à utiliser.
 Rapports. Commentez ici les types et les noms des rapports que vous êtes en train d'utiliser
pour définir le contenu et le gérer, qui va les recevoir, la fréquence, etc.
 Stabilité attendue du contenu. Cette section décrit les attentes vis-à-vis de la stabilité du
contenu, c'est à dire si le contenu est supposé changer d’une manière significative au cours du
projet ou bien se maintenir au niveau dans lequel il a été défini initialement. Par exemple, si la
définition du contenu est ambiguë et si une clarification n'a pas été apportée durant la
définition du projet, vous pourriez énoncer dans cette section que vous vous attendiez à ce que
le contenu défini fasse objet de plusieurs révisions, ce qui entraîne plus de risques pour le
projet.
253
5.0.3 Créer un plan de management des exigences
Le plan de management des exigences décrit la manière avec laquelle vous allez révéler, analyser,
documenter et gérer les exigences du projet. Ce plan va couvrir la réunion, à l’avance, des exigences
relatives au projet et au produit, ainsi que celles que vous allez réunir durant le cycle de vie du projet
d’une manière plus détaillée. Ce plan devrait surtout se concentrer sur la manière selon laquelle vous
allez gérer le contenus modifications apportées aux exigences surtout quand ces dernières ont déjà été
approuvées. Le fait d'adopter un processus de management des exigences aide l'équipe du projet à se
concentrer sur les exigences qui ont déjà été développées et à maintenir l'intégrité de ces exigences
durant le cycle de vie du projet. Des sections du plan pourraient comprendre les informations suivantes
:
 Le processus de réunion des exigences. Dans cette section vous allez décrire le processus
que vous allez utiliser pour révéler, analyser et documenter les exigences.
 Rôles et responsabilités. Cette section répartit les rôles des personnes qui seront impliquées
dans la gestion des exigences à travers le cycle de vie du projet. Ces rôles peuvent inclure le
chef de projet, le chef analyste, les clients, etc. Le chef de projet, par exemple, devrait être
entièrement responsable du management des modifications du contenu relatives aux
exigences. Une autre personne, qui pourrait bien être le chef analyste, devrait être entièrement
responsable de l'intégrité des exigences durant le cycle de vie du projet.
 Outils. Décrire tous les outils automatisés qui vont être utilisés pour gérer les exigences.
Plusieurs outils ont pour rôle de documenter les exigences, les gérer et assurer leur suivi durant
le cycle de vie du projet.
 La maîtrise des modifications. Il est nécessaire d'établir un processus formel pour gérer les
modifications des exigences. Heureusement, tout le projet utilise un processus formel de
modifications de contenu. Dans ce cas, ce dernier devrait être appliqué aux modifications
apportées aux exigences. Au cas où il n’y a pas un processus formel de modifications de
contenu, un processus spécifique de maîtrise de modifications devrait être documenté ici.
 Le suivi des exigences. Si votre équipe de projet est entrain d'assurer le suivi des exigences
à partir de l'analyse jusqu'au Design et durant le reste du cycle de vie du projet, l'ensemble du
processus devrait être décrit dans cette section. Ce processus devrait alors être ajouté à
l'échéancier pour assurer un suivi approprié des exigences à travers le reste du projet.
254
5.0.4 Réunir les exigences
La majorité des membres de l’équipe du projet préfèrent suivre la foi de "Nike" – Juste fais-le! Le client
se trouve sous l’emprise d’un besoin commercial et l’équipe veut immédiatement entamer la résolution
des problèmes. Le fait de trouver la solution et de la présenter au client vous procure une joie sans
égale, sauf, bien sûr si le client vous informe que ce n’était pas ce qu’il voulait.
Il vaut mieux éviter de s’emballer et de se mettre en première ligne! Avant de commencer, vous devez
être sûr de ce que vous faites. Pour cela il faut établir, à l’avance, un processus pour définir les
exigences du projet. Ces dernières vous aident à comprendre les objectifs, les livrables, le contenu et
toute autre information relative au projet. Vous devez également réunir quelques informations
préliminaires de haut niveau concernant les livrables du projet. Il s’agit des exigences relatives au
produit. Vous n’auriez pas le temps de rassembler tous les détails relatifs aux exigences du produit mais
vous devriez quand même bien les assimiler. Ces connaissances de haut niveau vous aideront à établir
une meilleure structure de découpage du travail ainsi qu’à mieux comprendre l’effort, le coût et la durée
estimés.
Le processus d'obtention d’exigences consiste dans la réunion d’exigences de haut niveau par le client
en premier lieu. Pour obtenir des exigences précises, le chef de projet doit poser les bonnes questions
et écouter attentivement les réponses. Quand vous dites que vous allez commencer à réunir les
exigences de votre client, la première chose qui nous vient à l’esprit est que vous allez poser des
questions et documenter les réponses.
Le fait de rassembler les exigences à l’aide d’une interview est probablement la technique la plus
commune. Cependant, il existe plusieurs autres techniques dans ce domaine, et dans plusieurs projets
l’équipe aurait besoin d’utiliser certaines d’entre elles au lieu, ou en plus, de la technique d’interview.
Par exemple, si vous voulez réunir des données d’entrée de la part de 100 utilisateurs, vous ne seriez
probablement pas capable de les interroger un à un. En effet, même si vous commencez à le faire, vous
allez vite vous apercevoir qu’en fait il n’y a pas beaucoup d’informations à réunir. Une meilleure
approche, moins coûteuse et plus rapide, serait d’interviewer quelques personnes parmi ce groupe et
d’envoyer des enquêtes aux autres.
Il existe certaines techniques propres à obtenir les exigences, et votre projet pourrait avoir besoin d’en
utiliser plusieurs, cela dépend des circonstances.
 Interviews face à face. La technique la plus commune pour réunir les exigences est de
s’adresser directement aux clients et de leur demander ce dont ils ont besoin. La discussion
devrait être planifiée à l’avance en se basant sur les types d’exigences que vous recherchez.
 Interviews de groupe. Ils ressemblent aux interviews Face à face sauf qu’il y a plusieurs
personnes à interviewer. Les interviews de Groupe exigent plus de préparation et plus de
formalités pour réussir à réunir les informations dont vous avez besoin de la part de tous les
participants. Vous pouvez réussir à réunir beaucoup plus d’exigences dans une période plus
courte si vous arrivez à obtenir toute la concentration du groupe.
 Sessions facilitées. Dans une session facilitée, vous réunissez un groupe plus large et ce
pour un objectif commun. Suivant cette méthode, vous allez essayer de réunir un ensemble
d’exigences du groupe et ce d’une manière plus rapide que si vous aviez à interviewer chacun à
part.
 Les sessions JAD (Joint Application Development = développement d’applications à l’aide de

sessions de travail participatives). Les sessions JAD ressemblent à d’autres sessions facilitées.
Cependant, le groupe doit systématiquement rester dans la session jusqu’à ce que les objectifs
soient atteints. Dans ce cas, les participants ne devraient pas quitter la session jusqu’à ce qu’un
ensemble d’exigences soient réunies, documentées et consenties. (NdT : La méthode JAD
permet de concevoir des systèmes d'information dans des sessions de travail participatives (les
sessions associent décideurs, informaticiens et utilisateurs) et accélérées (en 3 à 5 jours, on a
réalisé le cahier des charges d'une application informatique. Un facilitateur dirige ces sessions
qui doivent permettre de définir tout ce qui est nécessaire, des plans stratégiques jusqu'aux
255
spécifications du système. Les produits de ces sessions peuvent inclure la description des
processus métiers, les prototypes, les modèles de données, etc.).
 Questionnaires. Il s’agit d’une technique beaucoup plus informelle, ce sont de bons

instruments pour réunir les exigences des parties prenantes travaillant à distance ou bien ceux
qui auraient moins de données d’entrées relativement à l’ensemble des exigences. Un
questionnaire peut constituer une bonne méthode pour réunir des statistiques, tel que le
nombre de personnes qui pourraient utiliser certains aspects, ou pour avoir une idée sur les
exigences prioritaires.
 Prototypage. Il s’agit d’une technique qui est relativement moderne pour réunir les exigences.
Dans cette approche, vous réunissez des exigences préliminaires que vous utilisez pour établir
une version initiale de la solution – un prototype. Vous le montrez au client, qui vous fournit
des exigences supplémentaires. Vous modifiez l'application et la revoyez avec le client à
nouveau. Ce processus va se répéter jusqu’à ce que le produit atteint les besoins commerciaux,
ou un certain nombre d’interactions.
 Suivre les gens là où ils sont. Ceci est surtout utile quand il s’agit de réunir les informations
sur les processus en cours. Vous pourrez découvrir, par exemple, que certaines personnes se
sont tellement habituées à leur travail qu’il leur est devenu difficile d’en parler. Vous pourrez
avoir besoin des regarder travailler pour arriver à vous faire une idée complète du tableau.
Dans certains cas, vous pourriez aussi participer au processus actuel du travail pour avoir une
idée plus réaliste sur le fonctionnement actuel de l’entreprise.
Le fait de bien connaître votre audience vous aidera à déterminer les bonnes techniques qu’il faut
utiliser pour mieux faire face à vos besoins. Vous devriez choisir des techniques qui vous assurent de
réunir les informations les plus adéquates et qui conviennent mieux à l’audience.
256
5.0.5 Assurer la traçabilité
(5.0.5. P1)
La traçabilité est la capacité de retracer, d'effectuer le suivi des exigences pendant le cycle de vie du
projet jusqu'à la solution finale. Le fait d'effectuer le suivi des exigences pendant le projet consiste à
veiller à ce que ces dernières font partie de la conception, que toutes les exigences sont établies dans
le cadre de la solution, qu'elles sont testées et qu'elles sont prises en compte dans la solution finale. De
même, Le processus assure également que les caractéristiques et les fonctions ne soient pas conçues et
établies dans la solution finale s'il s'avère qu'elles ne font pas partie des exigences acceptées d'un
commun accord.
La méthode la plus facile pour créer un lien entre vos exigences et les autres éléments de
développement (telles que les cas d'utilisation, les éléments de conception et les cas d'évaluation)
consiste à développer une matrice de traçabilité. La matrice de traçabilité fournit un aperçu rapide sur
toutes les exigences et assure qu'elles soient prises en compte pendant le cycle de vie du projet.
Le suivi des exigences n'est pas une nécessité pour tous les projets, surtout pour les petits projets. Si
vous avez un lot de dix exigences pour un projet d'amélioration, par exemple, il serait probablement
plus facile de valider qu’elles sont toutes prises en compte pendant le cycle de vie du projet. Cependant
s'il y a plusieurs exigences à suivre, vous pourriez même envisager l'utilisation d'un outil automatisé.
Avant de commencer le suivi, vous devriez considérer le type de numéros de suivi que vous allez
utiliser. Le système de suivi utilisé va vous permettra de pister les exigences à travers le reste du cycle
de vie. Vous pouvez seulement numéroter les exigences comme "1", "2", "3", etc. Cependant, vous
pouvez avoir envie de créer plus de raffinement dans le système de numérotation. Par exemple, il se
peut que les exigences puissent être regroupées dans des sections logiques, et que chaque section
puisse avoir un identifiant unique. Dans ce cas, les numéros de suivi des exigences pourraient être les
suivants: "TAB-001", "TAB-002", "DIS-001", "DIS-002", etc.
Une fois les exigences identifiées, leur suivi peut être effectué de deux manières. L'une des méthodes,
probablement la plus simple, consiste seulement à valider que chaque exigence est prise en compte
dans les phases ultérieures du projet. Le tableau suivant pourrait illustrer un exemple.
Exigence Conception Construction Évaluation

TAB-001 X X X
TAB-002 X X
TAB-003 X X
Le "X" dans chaque case valide que chaque exigence particulière a été prise en compte dans chaque
phase. Dans l'exemple ci-dessus, la première exigence a été conçue, établie et testée. La deuxième et
la troisième exigence n'ont pas encore été testées. De même, la phase du projet pourrait être
subdivisée ultérieurement. Par exemple, la phase de l'évaluation pourrait être subdivisée en une
évaluation unitaire, une évaluation de l'intégration, une évaluation du système et une évaluation de
l'acceptation de l'utilisateur.
Un exemple plus élaboré est exposé ci-dessous. Dans ce cas, les exigences sont suivies pendant chaque
phase du projet, cependant, les composants relatifs aux exigences sont aussi identifiés.
Élément de Composant de
Exigence Cas d'évaluation
conception construction
TAB-001 D-APR607P C-APR607P T-004-01
TAB-002 D-ARX607P C-ARX607P T-004-09, T-004-15
257
D-APC103D C-APC103D
TAB-003 T-004-22
D-APC103E C-APC103E
Ce suivi exige que l'équipe continue à garder plus de détails que les exigences se poursuivent pendant
le cycle de vie du projet. Cependant, vous disposez également de plus de contrôlabilité. Si vous voulez
pister la manière avec laquelle une exigence se poursuit pendant le cycle de vie du projet, vous pouvez
identifier l'exigence initiale, l'élément de conception, le composant qui contient le code de l'exigence et
le cas d'évaluation particulière qui a permis d'assurer que l'exigence a fonctionné correctement.
Ce qu'il faut retenir concernant la traçabilité est le fait qu'elle doit être effectuée tout au long du cycle
de vie du projet sinon elle n'aura pas de sens. Si l'équipe affecte les numéros de suivi aux exigences
dans la phase de l'analyse, mais que les numéros ne sont pas utilisés dans la phase de la conception,
tout le système de suivi va s'effondrer. De même si l'équipe de la conception continue à effectuer le
suivi, mais que les exigences ne sont pas suivies selon les composants actuels, il serait difficile des
pister si elles ont été ou non évaluées et le système va également s'effondrer. Si vous voulez effectuer
le suivi des exigences, vous avez besoin d'avoir un processus de suivi et de le documenter pendant le
projet.
Une fois que vous avez défini le processus de traçabilité, vous pouvez établir des repères pour votre
projet de deux manières. D'abord, vous pouvez valider que toutes les exigences sont en train d'être
reportées dans les phases ultérieures du projet. Si vous trouvez que plusieurs composants dans la
même phase sont liés à une seule exigence, cela pourrait signifier que vous avez un travail en double et
redondant en cours. De même, vous pouvez analyser vos composants ultérieurs pour vérifier s'ils
respectent les exigences ou non. Par exemple, si vous êtes en train d'effectuer des évaluations qui
n'ont rien à voir avec une exigence, vous pouvez vous retrouver en train d'évaluer des caractéristiques
qui ne sont pas nécessaires. D'autres bénéfices du suivi des exigences incluent les éléments suivants:
 Documentation des améliorations. Avec le temps, les augmentations seront probablement

appliquées aux caractéristiques commerciales et à la fonctionnalité de la solution. Les
améliorations seront typiquement achevées plus tôt si le développeur peut facilement effectuer
le suivi des caractéristiques modifiées et des fonctions aux composants appropriés qui
pourraient être affectés.
 Documentation de l'équipe de soutien. L'équipe de soutien ne sera pas bien tenue au

courant de la manière avec laquelle les exigences sont mises en œuvre dans la solution finale.
La matrice de traçabilité va particulièrement être utile lorsque l'équipe de soutien est entrain
d'effectuer le suivi les défauts, puisqu'il leur serait plus facile d'isoler les composants affectés.
 Réutiliser. Accéder aux informations qui assurent le suivi des exigences, la conception, le
codage et l'évaluation peut dans le futur permettre dans d'autres situations similaires la
réutilisation de composants à partir de cette solution.
Cependant, un simple avertissement s'impose, - si l'équipe de soutien n'assure pas la mise à jour de la
matrice de la traçabilité des exigences, elle deviendra rapidement inutile. L'équipe de soutien ne va pas
utiliser la matrice si cette dernière n'est pas fiable pour être utilisée dès le début.
Identifier la source des exigences (5.0.5. P2)
En plus d'effectuer le suivi de chaque exigence en aval pendant le reste du cycle de vie du projet, vous
pouvez vouloir effectuer le suivi de l'exigence pour remonter à sa source. Dans la plupart des cas, il
s'agira d'une personne particulière ou d'un groupe, mais il se peut qu'il soit aussi un fournisseur ou un
client. Si vous avez tiré les exigences des processus actuels, ceci peut renvoyer à un système, un
processus commercial, ou simplement "une situation actuelle". L'identification de la source serait utile
s'il se posait plus tard des exigences pendant le cycle de vie du projet. L'équipe du projet pourrait
retourner voir l'origine de l'exigence. Si une personne ou un groupe a été identifié, l'équipe de projet,
pourrait revenir à cette source spécifique pour plus d'informations et de clarté. Lorsque ceci peut
s'avérer important et si l'exigence ne peut pas être adaptée, l'équipe peut retourner à la source pour
mieux se rendre compte de l’impact qui pourrait avoir lieu.
258
5.0.6 Vérifier le contenu
Rappelez-vous qu’il existe deux éléments majeurs de contenu global : les livrables du projet et les
limites du projet. Les livrables sont construits pendant le projet. Plusieurs (peut-être la majorité) des
livrables finaux sont approuvés par le commanditaire du projet. Ce processus d’approbation est appelé
“vérification du contenu”. En d'autres termes, les livrables, qui sont un élément majeur du contenu,
sont revus par le commanditaire du projet et certifiés acceptables. Le contenu a donc été vérifié et
accepté par le commanditaire.
La vérification du contenu se réfère au processus d'approbation effectif des livrables. Ce processus est
étroitement lié au contrôle qualité (CQ). Le contrôle qualité comprend un processus d'inspection au sein
du projet afin de s'assurer que les livrables sont conformes aux exigences et aux critères de qualité. La
vérification de contenu constitue l’approbation et l’acceptation subséquentes du livrable par le
commanditaire.
259
5.1 Gérer le contenu / Processus
Les processus utilisés pour gérer le contenu sont décrits dans cette partie. Ces processus peuvent être
modifiés en fonction des besoins de votre projet, puis insérés dans le Plan de Management de Projet,
créé lors du processus 1.0 Définition du travail.
5.1.1 Gérer le contenu dans les petits projets
 Modifications du contenu
5.1.2 Gérer le contenu dans les projets moyens
5.1.3 Gérer le contenu dans les grands projets
260
5.1.1 Gérer le contenu / Petits projets
Gestion des modifications du contenu (5.1.1. P1)
Du fait que les petits projets sont plus faciles à définir et qu’ils sont réalisés rapidement, ils connaissent
généralement peu de demandes de modification de contenu, et lorsqu’il y en a, elles sont souvent
minimes. Le processus suivant devrait pouvoir être exécuté rapidement.
Rôle Gestion des modifications du contenu (Petits projets)
Identifier la demande de modification du contenu

Chef de projet,
1 membres de Les modifications du contenu peuvent être identifiées par n'importe qui dans
l’équipe l’équipe de projet. Elles doivent être présentées au chef de projet par écrit,
sous forme papier, par e-mail, etc. Aucune autre formalité n'est nécessaire.
La valider comme une modification du contenu

2 Chef de projet Le chef de projet valide la demande comme étant, en fait, une modification du
contenu.
Déterminer l'impact de la demande
3 Chef de projet Le chef de projet détermine l'impact de la demande de modification de contenu

en termes de coût, d'effort et de durée. S'il y a plusieurs options valables, le
chef de projet détermine aussi leur impact.
(Facultatif) Traiter les demandes de petites modifications, si elles

n’ont aucun impact sur l’échéancier et le budget
Chef de projet, Si la modification du contenu peut être effectuée sans augmenter ni le coût, ni
4 manager du l'effort, ni la durée approuvés dans la charte du projet, le chef de projet et le
client manager du client, sont libres de décider de l'approuver ou non. Cependant, le
commanditaire doit avoir accepté de leur déléguer cette responsabilité.
Généralement, il le fera jusqu'à un certain seuil de coût ou d’effort de travail.
Informer le commanditaire
L'analyse, l'impact et les alternatives sont transmis au commanditaire pour qu’il
5 Commanditaire prenne une décision (si la demande n'a pas déjà été approuvée lors de l’étape
4 ci-dessus). Si le commanditaire n'approuve pas la demande et l'impact
correspondant, il ne sera pas donné suite à la demande de modification.
Ajouter le travail supplémentaire à l’échéancier
6 Chef de projet Si la demande de modification est approuvée, les activités appropriées sont
ajoutées à l'échéancier du projet pour s'assurer que la modification sera
effectuée.
Ajouter le surcoût pour le budget

7 Chef de projet Si la demande de modification est approuvée, les coûts supplémentaires (le cas
échéant) doivent être ajoutés au budget.
Communiquer à travers votre rapport d’avancement du projet

8 Chef de projet La demande, le point sur la situation en cours et la résolution doivent être
consignés dans le rapport d'avancement du projet.
261
5.1.2 Gérer le contenu / Projets de taille moyenne
Gestion des modifications du contenu (5.1.2. P1)
Les projets moyens connaissent des demandes de modification du contenu.
Rôle Gestion des modifications du contenu

(Projets de taille moyenne)
1 Chef de projet Identifier la demande de modification du contenu

Demander à toutes les parties prenantes, telles que l’équipe du projet, les
clients, le commanditaire, etc. de formuler des demandes de modification du
contenu. Ces demandes peuvent être notifiées par écrit au chef de projet au
moyen d’un bref formulaire de demande de modification du contenu (facultatif)
ou d’un e-mail.
2 Chef de projet La valider comme une modification du contenu

Le chef de projet valide la demande comme étant, en fait, une modification du
contenu.
3 Chef de projet Saisir la demande dans le journal des modifications du contenu

Saisir cet élément dans le journal des modifications du contenu, aux fins de
suivi.
4 (La personne S’enquérir de la valeur commerciale de la modification

formulant la La personne formulant la demande de modification du contenu doit déterminer
demande) l’intérêt commercial de cette modification pour le projet. Le commanditaire a
besoin de cette information pour prendre une décision finale.
5 Chef de projet, Charger un membre de l’équipe du projet de mener des investigations

membres de sur la modification du contenu
l’équipe Le chef de projet peut s’en charger lui-même.
6 Chef de projet, (Facultatif) Traiter les demandes de petites modifications, si elles

manager du n’ont aucun impact sur l’échéancier et le budget
client Si l’impact sur le coût du projet, l’effort et la durée est en dessous d’un seuil
(disons moins de 20 heures) et que le projet peut être achevé dans les limites
du coût, de l'effort et de la durée initialement convenus, le chef de projet et le
manager du client peuvent approuver la demande. Le seuil doit être identifié et
approuvé à l’avance par le commanditaire du projet. L’objectif de cette étape
est d’éviter de soumettre de nombreuses petites modifications au
commanditaire, pour approbation. Cependant, le commanditaire doit avoir
accepté de déléguer cette responsabilité. Généralement, il le fera jusqu'à un
certain seuil de coût ou d’effort.
7 Commanditaire Informer le commanditaire

Transmettre la demande de modification de contenu, les alternatives, la valeur
commerciale et l'impact sur le projet au commanditaire, pour qu’il prenne une
décision (si la demande n'a pas déjà été approuvée par le chef de projet et le
manager du client, comme indiqué ci-dessus).
8 Chef de projet Inscrire la décision dans le journal des modifications du contenu

Si le commanditaire n’accepte pas la demande de modification, celle-ci doit être
262
close et figurer sur le journal des modifications du contenu, avec la mention «
Non approuvée ».
9 Chef de projet Ajouter le supplément de travail à l’échéancier

Si la demande de modification du contenu est approuvée, les activités
correspondantes sont ajoutées à l’échéancier pour s’assurer de la mise en
œuvre de la modification. Le budget et les délais seront mis à jour, si
nécessaire.
10 Chef de projet Ajouter le surcoût pour le budget

Si la demande de modification est approuvée, les coûts supplémentaires (le cas
échéant) doivent être ajoutés au budget.
11 Chef de projet Mettre à jour la charte abrégée de projet, si nécessaire

La charte abrégée de projet doit être mise à jour, si la modification de contenu
approuvée entraîne une modification substantielle du contenu du projet.
12 Chef de projet Communiquer à travers votre rapport d’avancement du projet

Communiquer la situation de la modification du contenu et la voie de résolution
aux membres de l’équipe et aux autres parties prenantes concernées, à travers
les méthodes préconisées par le Plan de management des Communications, y
compris le rapport d’avancement du projet.
263
5.1.3 Gérer le contenu / Grands projets
Le management du contenu à un niveau général est documenté dans le plan de management du

contenu. Voir 5.0.2 Créer le plan de management du contenu, pour plus de détails.
Maîtrise du contenu (5.1.3. P1)
Rôle Gestion des modifications du contenu (Grands projets)
1 Chef de projet Identifier la demande de modification du contenu à l'aide d'un

formulaire de modification de contenu
Demandez à toutes les parties prenantes, telles que l’équipe du projet, les
clients, le commanditaire, etc., de formuler des demandes de modifications
potentielles du contenu. Celles-ci doivent être notifiées par écrit au chef de
projet, au moyen d’un bref formulaire de demande de modification du
contenu ou par e-mail.
2 Chef de projet La valider comme une modification du contenu

Le chef de projet valide la demande comme étant, en fait, une modification du
contenu.
3 Chef de projet Saisir la demande dans le journal des modifications du contenu

Saisir cet élément dans le journal des modifications du contenu, aux fins de
suivi.
4 (La personne S’enquérir de la valeur commerciale de la modification

formulant la
La personne formulant la demande de modification du contenu doit
demande)
déterminer l’intérêt commercial de cette modification pour le projet. Le
commanditaire a besoin de cette information pour prendre une décision finale.
5 Chef de projet, Déterminer l’impact de l’investigation sur le projet

commanditaire
Le chef de projet doit estimer l’impact de l’investigation sur le projet en
termes d’effort, de coût et de durée. Si l’investigation demande peu de temps,
le chef de projet doit y procéder.
Si le temps requis par l’investigation risque de provoquer du retard au niveau
des livrables, la demande doit d’abord être présentée au commanditaire pour
déterminer si elle peut faire l’objet d’une enquête. Si le commanditaire donne
l’approbation initiale de continuer, l’échéancier et le budget pourraient avoir
besoin d’être mis à jour pour refléter l’impact de cette enquête au sujet de la
nouvelle modification de contenu. Si le commanditaire n’accepte pas de faire
procéder à l’enquête liée à la demande de modification, cette dernière doit
être inscrite dans le journal des modifications du contenu avec la mention «
Non approuvée ».
6 Chef de projet, Charger un membre de l’équipe du projet de mener des

membres de investigations
l’équipe
Le chef de projet charge un membre de l'équipe de mener des investigations
concernant l'impact de la demande sur le projet. Si le chef de projet
comprend la demande et les implications, il peut s'en charger lui-même.
7 Chef de projet, (Facultatif) Traiter les demandes de petites modifications si elles
264
manager du n’ont aucun impact sur l’échéancier et le budget
client
Si l’impact sur le coût, l’effort et la durée du projet est en dessous d’un seuil
déterminé (disons moins de 20 heures) et que le projet peut être achevé au
prix convenu, avec le même effort et la même durée, le chef de projet et le
manager du client peuvent approuver la demande. Le seuil doit être
déterminé et approuvé à l’avance par le commanditaire. L’objectif de cette
étape est d’éviter de soumettre de nombreuses petites modifications au
commanditaire pour approbation. Cependant, ce dernier doit avoir accepté de
leur déléguer cette responsabilité. Généralement, il le fait jusqu'à un certain
seuil de coût ou d’effort de travail.
8 Commanditaire Informer le commanditaire

La demande de modification du contenu, les alternatives, la valeur
commerciale et l'impact sur le projet sont soumis au commanditaire pour qu’il
prenne une décision (si la demande n'a pas déjà été approuvée par le chef de
projet et le manager du client, comme indiqué ci-dessus).
9 Chef de projet Inscrire la décision dans le journal de modifications du contenu

Consigner la demande de modification du contenu dans le journal approprié
en mentionnant la décision finale.
10 Chef de projet Clore le formulaire de demande de modification du contenu

Le chef de projet doit mettre à jour le formulaire de demande de modification
du contenu, puis clore ce document et l’archiver.
11 Chef de projet Ajouter le travail supplémentaire à l'échéancier

Si la demande de modification est approuvée, les activités correspondantes
sont ajoutées à l’échéancier pour s’assurer de la mise en œuvre de la
modification. Le budget et les délais seront mis à jour si nécessaire.
12 Chef de projet Ajouter les coûts supplémentaires au budget

Si la demande de modification du contenu est approuvée, les coûts
supplémentaires (s'il y en a) doivent être ajoutés au budget de votre projet.
13 Chef de projet Mettre à jour la charte du projet si nécessaire

la charte du projet doit être mise à jour si une modification substantielle du
contenu du projet est approuvée.
14 Chef de projet Communiquer à travers votre rapport d’avancement du projet

La charte actuelle du projet doit être mise à jour si une modification
approuvée du contenu entraîne une modification substantielle du contenu du
projet.
265
5.2 Gérer le contenu / Techniques
Gérer de manière proactive les petites demandes de modification de contenu au moyen de

processus alternatifs (5.2. P1)
Il est facile de se rendre compte et de reconnaître qu'un processus de gestion des modifications du
contenu doit être invoqué lorsque de grands changements doivent être apportés à un projet.
Cependant, pour de petites demandes, vous pouvez rencontrer une certaine résistance à une gestion
formelle des modifications du contenu. Le client ainsi que des membres de l’équipe du projet peuvent
considérer que ce sont des frais inutiles pour de si petites décisions. Ils pourraient avoir raison.
Il y a trois techniques à utiliser qui peuvent vous aider à apporter des petites modifications. Notez
qu'aucune de ces options n’implique que vous n'êtes pas en train de gérer les modifications du contenu
et d'en assurer le suivi. Ce sont juste des techniques complémentaires. Elles peuvent se révéler
particulièrement utiles pour la gestion de petites modifications du contenu. Si aucune de ces options
n'est mise en œuvre, le chef de projet devra utiliser le processus normal de manque de gestion des
modifications de contenu pour toutes les modifications.
 Grouper les petites demandes (5.2. P2)

Il n'est pas toujours pratique de solliciter le commanditaire pour lui faire approuver une à une chaque
petite demande de modification du contenu. D’habitude, l’équipe de projet n'a pas facilement accès, au
jour le jour, au commanditaire, et il est difficile d’obtenir son attention pour de nombreuses petites
demandes. Grouper les petits changements par paquets permet de mieux utiliser le temps disponible.
Cela signifie que vous gardez une trace des petites demandes de modification du contenu, de leur
valeur marchande et de leur impact sur le projet. Puis, quand elles atteignent un certain seuil, vous les
communiquez toutes au commanditaire pour obtenir son approbation. Au lieu de rendre visite au
commanditaire à plusieurs reprises pour des petites demandes de modification, vous les groupez toutes
ensemble et ne rencontrez le commanditaire qu’une seule fois. Lors de la rencontre avec le client, vous
discutez de tous les changements et modifications proposés (ou, peut- être, des plus importants du lot)
et obtenez la réponse du commanditaire au sujet de leur éventuelle exécution. Même s’il s’agit de
demandes pour des petites modifications, elles doivent tout de même passer par un processus de
gestion des modifications du contenu. Autrement, vous êtes susceptible d’avoir à faire à des
modifications incontrôlées. L'avantage d'obtenir l’approbation du commanditaire pour les petites
modifications, c’est que celles-ci soient approuvées par lui ainsi que le budget et l’allongement de
l’échéancier nécessaires pour effectuer le travail.
 Discrétion (5.2. P3)

D'un point de vue pratique, on laisse habituellement l’approbation des modifications du contenu dont la
valeur est en dessous d’un certain seuil de coût et d'effort de travail, à la discrétion du chef de projet et
du manager du client. Cette autorité ne doit pas être autoproclamée. Elle doit faire l’objet d’une
délégation de pouvoir explicite de la part du commanditaire. Cependant, cela suppose que le projet est
dans les temps ou en avance par rapport à l’échéancier, et que les modifications n’occasionnent pas de
dépassement en termes de coût, d’effort de travail ou de durée convenus. Si cela risque de se produire,
ce pouvoir de décision ne devra pas être utilisé, même pour une demande de modification d'une heure.
Si le projet risque de dépasser sa date limite ou ses engagements au sujet du budget, toutes les
demandes de modification de contenu devront être communiquées au commanditaire pour approbation,
que ce soit séparément ou par paquets. Si le commanditaire approuve les changements, le projet doit
recevoir le supplément de budget correspondant et l’échéancier doit être allongé.
 Réserve pour aléas destinée aux modifications du contenu (5.2. P4)

Dans certaines entreprises, il est courant d’instituer une réserve pour aléas, pour prendre en compte les
petites modifications de contenu. Habituellement, aucune justification n’est exigée. Votre entreprise
peut constater que quelques modifications de contenu sont inévitables et elle peut assigner un
pourcentage du budget du projet pour les prendre en compte. Par exemple, vous pouvez avoir une
réserve supplémentaire de 5% de votre budget, destinée aux modifications du contenu. Si le budget
266
total de votre projet est de 500.000 €, votre budget de contingence pour les modifications du contenu
sera de 25.000 €. Cependant, cela implique que ce budget de contingence sera assigné entièrement
aux petites demandes de modification de contenu. Le client doit gérer le budget afin de s'assurer que
toutes les petites demandes de modification puissent être effectuées. Si le client épuise le budget dès la
première petite modification de contenu, rien ne sera prévu pour les demandes ultérieures de
modification, ce qui oblige le client à rationner ses demandes de modification pour s’assurer qu’il pourra
introduire quelques modifications importantes durant tout le cycle de vie du projet et pas seulement au
début. Ce budget est employé pour des demandes de modification inférieures à un certain seuil de coût
ou d’heures de travail. De plus grandes demandes peuvent encore être faites, mais elles passeront par
la gestion normale des modifications du contenu et seront évaluées par le commanditaire.
N'utilisez pas la contingence d’estimation pour les modifications de contenu (5.2. P5)
Une des étapes dans le processus d’estimation est de prévoir des heures de réserve pour aléas de
manière qu’elles reflètent le niveau d'incertitude lié à l’estimation. (Par exemple, si l'effort de travail est
estimé à 5.000 heures, vous pourriez ajouter 500 heures de réserve pour aléas, ce qui représenterait
un facteur de confiance de 90% et un facteur d’incertitude de 10%.) Une fois la réserve approuvée, on
fera pression sur le chef de projet pour qu’il l’emploie afin de répondre à des exigences
supplémentaires. Le client pourra dire : « Pourquoi avoir recours au management de modification du
contenu pour ce perfectionnement de 100 heures? Vous disposez de 500 heures de marge dans votre
estimation ! »
Le chef de projet doit résister à la tentation et à la pression. Le but de la réserve pour aléas est de
refléter l’incertitude des estimations. Il y aura de nombreuses occasions d'utiliser cette réserve lorsque
des activités prendront plus de temps que prévu. N'employez pas la réserve pour aléas pour effectuer
du travail supplémentaire. Si les estimations s’avèrent précises, vous devez restituer la réserve inutilisée
au client au terme du projet (ou la considérer comme un bénéfice complémentaire, si vous avez un
client externe).
Gelez des demandes de modification de contenu vers la fin du projet (5.2. P6)
Pensez-vous que tant que vous gérez des demandes de modification du contenu de façon diligente, le
client est libre d’opérer des changements tout au long du projet ? Il est vrai que les modifications vers
la fin du projet tendent à prendre plus de temps et de travail. Cependant, vous pourriez penser que,
tant que le commanditaire est disposé à approuver des augmentations de budget et de temps pour
faire ces modifications, le client doit pouvoir les demander.
Cela est habituellement vrai, mais seulement jusqu'à un certain point. Il arrive un moment, dans un
projet, où il ne suffit pas de payer pour effectuer des modifications complémentaires ou intégrer plus
d’exigences. Le moment est venu d’obtenir un accord pour le « gel des modifications ». Non seulement
la mise en œuvre de nouvelles modifications est onéreuse, mais elle est également source de
distraction pour l’équipe du projet.
Selon la nature du projet, ce « gel » peut être mis en application après l’approbation des tests des
utilisateurs, donc au moment où l’équipe se prépare pour « piloter la mise en œuvre ». À ce stade,
l’équipe se focalise uniquement sur la mise en œuvre de la solution. Elle pourrait être en train de faire
des heures supplémentaires et le chef de projet pourrait être totalement absorbé par le micro-
management du projet pour s’assurer que toutes les tâches sont effectuées à temps dans les moindres
détails. À ce moment précis, toute demande de modification du contenu pourrait entraîner des coûts
importants, et en plus entrainer un effet extrêmement perturbateur, causant une perte de
concentration et une baisse du moral de l’équipe. Le résultat sera évident lorsque l’équipe essayera de
retrouver son élan pour « démarrer la mise en œuvre » et sera perturbée au point de commettre des
erreurs, puisque c’est la seconde fois qu’elle vit ces activités de mise en œuvre.
La meilleure approche est de placer ces changements sur la liste des « travaux en attente », puis des
traiter ensuite comme des demandes de perfectionnement, une fois la solution mise en œuvre et
stabilisée. (Ceci concerne les demandes de modification, pas les bogues. Les utilisateurs peuvent
découvrir des erreurs et des bogues au cours des tests, mais ces erreurs n'ont pas besoin d'être
corrigées avant la mise en œuvre).
267
Si vous obtenez un accord sur une date pour geler les demandes de modification, votre équipe pourra
se concentrer sur la livraison de la solution en cours. Naturellement, comme dans tous les processus,
s'il y a une demande de modification qui doit absolument être effectuée, vous céderez à l’appel du
commanditaire. Cependant, le fait d’obtenir un accord sur une date pour geler les modifications
écartera le besoin de modifications complémentaires dans la plupart des projets.
Assurez-vous que les demandes de modification soient approuvées exclusivement par le

commanditaire, et non par les utilisateurs ou le manager du client (5.2. P7)
Un des problèmes courants, lors d’un projet, c'est que l'équipe ne comprend pas les rôles qui incombent
au commanditaire, au client et aux utilisateurs finaux dans le domaine de la gestion des modifications.
En général, le commanditaire du projet est la personne qui fournit les fonds nécessaires au projet. Si le
client est une seule personne, il est alors le commanditaire du projet. Les commanditaires sont
habituellement haut placés dans l'entreprise et difficiles à joindre tous les jours. Dans la plupart des
cas, le commanditaire désigne une personne de son entreprise pour prendre la plupart des décisions
quotidiennes.
Les es personnes avec qui l’équipe de projet risque de travailler davantage sont le plus souvent les
clients ordinaires et utilisateurs finaux. Ces derniers sont ceux qui vont utiliser la solution élaborée dans
le cadre du projet. Ce sont généralement eux qui effectueront des demandes de modifications des
livrables. Peu importe l’intérêt d’un changement pour les utilisateurs : ces derniers ne peuvent pas
prendre des décisions de modification du contenu du projet, et ne sont pas habilités non plus à donner
à votre équipe l'approbation pour apporter ces modifications.
Dans le cadre d’une bonne gestion du contenu, le commanditaire (ou la personne qu’il a désignée) doit
donner son approbation. L'utilisateur final peut demander ou proposer des modifications au contenu,
mais il ne peut pas les approuver. Il ne peut pas assigner des fonds supplémentaires pour couvrir les
modifications et il ne peut pas savoir si l'impact sur le projet est acceptable. Si la modification proposée
est suffisamment importante pour le commanditaire, il l’approuvera, de même que les modifications
correspondantes du budget et des délais. Si la modification n'est pas assez importante, elle ne sera pas
approuvée. Il faut toujours garder à l'esprit que c’est au commanditaire de prendre la décision, pas au
chef de projet, ni au manager du client, ni à l’équipe de projet ou aux utilisateurs.
N’allez surtout pas penser qu’un "oui" aux demandes de changement de contenu du projet,
est le signe d’un grand intérêt pour le client (5.2. P8)
Le chef de projet et l'équipe de projet pensent parfois qu'ils font preuve d’un grand intérêt pour le
client, en essayant d'incorporer les modifications de contenu qu’il demande, tout en essayant de
maintenir le projet dans les limites des engagements originaux. Cependant, si le projet est livré en
retard ou avec un dépassement de budget, il ne suffit généralement pas d’invoquer tout le travail
complémentaire effectué en raison de cette prétendue « focalisation sur le client ». Ni le
commanditaire, ni votre direction ne voudront en entendre parler. Dans la plupart des cas, le projet ne
sera pas considéré comme réussi, puisqu'il n'aura pas été effectué conformément à la date et au
budget convenus.
Le commanditaire est le représentant principal des clients. Si on veut être à l’écoute de la clientèle, il
faut permettre au commanditaire (ou la personne qu’il a désignée) de prendre les décisions concernant
les modifications de son propre projet. Si l’équipe de projet ou son chef approuvent les modifications à
sa place, cela n’est pas un bon signe de focalisation sur la clientèle du point de vue du commanditaire.
Incluez le report des bénéfices dans le coût d'une modification du contenu (5.2. P9)
Le commanditaire de projet ne peut pas prendre une décision en connaissance de cause, concernant
une demande de modification du contenu, sans connaître la valeur commerciale de la modification et
son impact sur le projet. Généralement, le chef de projet fournit des informations concernant l'impact
sur le projet en termes d'effort de travail, de coût et de durée. Cependant, une insuffisance courante
dans l’estimation de l’impact tient au fait que des coûts liés au report des bénéfices du projet ne sont
pas pris en compte dans ces estimations.
268
En d’autres termes, le projet génère habituellement un bénéfice pour l’entreprise. Le bénéfice
commence en général juste après (ou peu après) le moment où la solution est mise en application. Si
une demande de modification du contenu entraîne un retard pour le projet, le coût de la modification
du contenu devrait inclure non seulement le coût de la modification elle-même, mais également le coût
du bénéfice différé.
Voyons l’exemple suivant.
Supposons que votre projet coûte 100.000 €. Le bénéfice commercial est de 5.000 € par mois en
accroissement de recettes (ou baisse des coûts). Au cours de l’avancement du projet, le client émet une
demande de modification qui coûtera 5.000 € et ajoutera un mois supplémentaire à la durée du projet.
Le remboursement de ce changement s’élève à 1.000 € par mois.
Vous pouvez présenter au commanditaire une demande de modification qui se réfère au coût des 5.000
€ et à la durée de remboursement sur cinq mois, à raison de 1.000 € par mois. Cependant, il manque le
coût d'opportunité lié au retard d’un mois dans la mise en œuvre. Dans ce cas, le fait d’effectuer la
mise en œuvre avec un mois de retard par rapport à la date prévue coûte également à la société 5.000
€ de bénéfices différés. Cela porte le coût total de la modification du contenu à 10.000 €. Le
commanditaire peut alors approuver ou non cette modification. Cependant, la prise en compte de la
valeur perdue associée au retard du projet devra faire partie de l'impact de la modification du contenu,
afin que le commanditaire puisse prendre une décision en parfaite connaissance de cause.
Laissez au commanditaire le soin de prendre les décisions. Un commanditaire impliqué aura

généralement tendance à dire « non » (5.2. P10)
Un des avantages du fait d’imposer l’approbation des modifications du contenu par le commanditaire
est qu'il aura généralement tendance à dire « non », à moins que la modification ne soit très
importante. Le commanditaire est habituellement quelqu'un de haut placé dans l'entreprise. Il ne veut
normalement pas entendre parler des demandes de petites modifications. Il désire que le projet original
soit réalisé dans les engagements initiaux en termes de coût, d'effort de travail, et de durée. Même s’il
peut être difficile pour le chef de projet de dire non, le commanditaire du projet n'a généralement
aucun inconvénient à ce sujet.
Considérez chacun comme responsable du processus de gestion du contenu (5.2. P11)
Beaucoup de processus de gestion du contenu fonctionnent bien au niveau du chef du projet, mais se
trouvent compromis au niveau des membres de l'équipe. Si le chef de projet veille à consolider les
règles de maîtrise du contenu, quelques membres de l’organisation du client peuvent alors essayer de
s’adresser directement aux membres de l’équipe pour apporter des modifications. Par exemple,
lorsqu'un rapport convenu d'avance est livré pour qu'il soit examiné, le client peut demander un second
rapport pour rendre les choses plus claires. Le membre de l’équipe peut accepter le travail (pour
manifester de l'intérêt pour le client). Le résultat est que l'activité prendra trop de temps, ou que du
personnel qui aurait pu être affecté à un autre travail de grande priorité sera absorbé par un travail
dans un domaine qui se situe hors du contenu.
Le minimum serait que tout le monde soit tenu pour responsable du processus de gestion du contenu.
Les membres de l’équipe doivent comprendre le processus et son importance, de même que les gens
de l’organisation cliente. N'allez pas penser que ces procédures n'ont d'intérêt que pour le chef de
projet et pour le commanditaire. Assurez-vous que les procédures soient communiquées à toute
l'équipe.
Quand des clients demandent des modifications au contenu directement à des membres de l'équipe,
signalez ce fait à l’attention du manager du client ou du commanditaire. Quand des membres de
l’équipe prennent des engagements pour effectuer un travail qui est hors du contenu, réagissez avec
promptitude. La première fois que cela arrive, cela peut être considéré comme un problème de
formation. La fois suivante, il s’agit d’un problème de rendement.
Utilisez le comité de maîtrise des modifications pour les grands projets trans-fonctionnels
(5.2. P12)
269
Parfois, sur des projets très grands, le commanditaire du projet peut ne pas se sentir à l’aise pour
assumer seul les décisions de modification du contenu. C’est particulièrement le cas si les modifications
influent sur d’autres organisations. Il peut également arriver que des organisations multiples participent
au financement du projet ou y contribuent et veulent avoir leur mot à dire au sujet de l’estimation des
demandes de modification du contenu. Dans de pareils cas, il peut s’avérer nécessaire d’avoir un
groupe de personnes pour gérer l’approbation des modifications de contenu.
Le nom le plus répandu pour désigner ce groupe est : « comité de maîtrise des modifications ». Si un
comité existe, il peut s’avérer un peu encombrant de travailler avec. Cependant, le processus général
de gestion des modifications du contenu n'a pas besoin de changer considérablement. Par exemple, il y
a toujours un document qui introduit la demande de modification. L’équipe de projet doit toujours
déterminer l'impact et le coût sur le projet. Le comité doit prendre en considération l'impact, la valeur
pour le projet, le timing, etc., et déterminer ensuite si la demande est acceptée.
Les procédures de modification du contenu doivent être légèrement plus sophistiquées, compte tenu de
l'existence d'un comité. Par exemple, vous devez clarifier qui est membre du comité, la fréquence des
réunions, les procédures de convocation en cas d’urgence, les modalités de prise de décision
(consensus, majorité, unanimité, etc.), et comment la surcharge de travail sera rémunérée, etc.
Créez une liste des demandes de modification en attente qui ne seront pas exécutées au
cours du projet (5.2. P13)
Il est possible que le commanditaire n’approuve pas certaines demandes de modification du contenu
pendant le projet, mais qu'il s’agisse quand même de demandes justifiées qui pourront être réalisées
ultérieurement. Ce type de demandes de modification devra être mentionné sur la liste des travaux en
attente. Lorsque le projet sera accompli et que la solution sera remise à l’organisation de soutien, il y
aura des opportunités de perfectionnement, par exemple par le biais d’un projet de deuxième phase.
Bien entendu, même à une date ultérieure, ces modifications ne seront mises en œuvre que si elles
sont approuvées et que le financement est disponible.
270
5.3 Gérer le contenu / Références rapides
Livrables (5.3. P1)
ayant une licence.)
 Formulaire de demande de modification
 Journal des modifications du contenu
 Plan de management du contenu
Les petits projets n'ont pas besoin d'un véritable plan de travail pour la gestion du
Petits contenu. Cependant, après avoir passé en revue les activités destinées aux projets de plus
projets grande taille, vous pouvez joindre certaines de ces activités à votre échéancier du projet, si
nécessaire.
Passez en revue la Tâche hebdomadaire toujours assignée au chef de

situation des projet. Utilisez ce temps pour vous assurer que des
1-2
demandes de progrès sont réalisés pour toutes les demandes de
heures
modification du modification du contenu, et que le journal des
contenu modifications du contenu est bien à jour.
Projets
Analysez les
moyens Ajoutez une activité pour l'analyse de n’importe quelle
demandes de
ouvert demande de modification du contenu encore ouverte
modification du
et qui est assignée à un membre de l’équipe.
contenu
Résolvez les
Si la résolution d'une demande de modification du
demandes de
ouvert contenu exige des activités supplémentaires, celles-ci
modification du
devront être ajoutées à l'échéancier du projet.
contenu
Passez en revue la Tâche hebdomadaire toujours assignée au chef de

situation des projet. Utilisez ce temps pour vous assurer que des
1-2
demandes de progrès sont faits sur toutes les demandes de
heures
modification du modification du contenu, et que le journal des
Grands contenu modifications du contenu est bien à jour.
projets
Analysez les
Ajoutez une activité pour l'analyse de n’importe quelle
demandes de
ouvert demande de modification du contenu, assignée à un
modification du
membre de l’équipe.
contenu
Résolvez la demande ouvert Si la résolution d'une demande de modification du
271
de modification du contenu exige des activités supplémentaires de
contenu travail, celles-ci devront être ajoutées à l'échéancier
du projet.
Ajoutez une activité pour mettre à jour la charte du

projet pour refléter toute demande majeure de
Mise à jour de la
ouvert modification du contenu approuvée, et voir si un
charte du projet
certain nombre de petits changements approuvés
rendent la définition actuelle du projet invalide.
272
______________________________________________________________________
Processus 6
Gérer les communications
273
6.0 Gérer les communications
Communiquer de façon appropriée sur un

projet représente un facteur d’efficacité
important pour la gestion des attentes du
commanditaire et des parties prenantes.
Si ces personnes ne sont pas
correctement tenues au courant des
progrès du projet, il y aura beaucoup de
chances que vous ayez à faire face à des
problèmes dus à des attentes différentes
et aux surprises. En fait, dans les
nombreux cas où des conflits surgissent,
ces conflits ne tiennent pas au problème
réel, mais à l’étonnement de la personne
concernée.
Tous les projets doivent informer sur leur situation. Ces informations incluent des rapports de l’équipe
de projet au chef de projet et du chef de projet au commanditaire et aux parties prenantes. Les
réunions de revue du projet et les rapports d'avancement constituent deux forums importants pour les
communications sur la situation. Les projets de grande taille ou ceux qui exigent des modifications
d'ordre culturel doivent être plus sophistiqués dans leur façon de communiquer avec les différentes
parties prenantes. Cette approche à facettes multiples est définie dans un plan de management des
communications.
6.1 Gérer les communications / Processus
6.2 Gérer les communications / Techniques
6.3 Gérer les communications / Références rapides
274
6.1 Gérer les communications / Processus
Les processus utilisés pour gérer la communication sont décrits dans cette partie. Ces processus
peuvent être modifiés selon les besoins de votre projet, puis insérés dans le document des procédures
de gestion du projet, créé à l’étape 1.0 Définir le travail.
Le processus que vous utilisez pour gérer la communication varie en fonction du projet. Les petits
projets ont tendance à avoir des méthodes de communication simples et claires. Les méthodes des
projets moyens sont un peu plus sophistiquées et nécessitent parfois l’utilisation d’un plan de
management des communications. Les projets moyens peuvent aussi parfois être assez grands pour
envisager d’utiliser des documents de base de management. Les grands projets doivent utiliser des
plans de management des communications pour s’assurer que leur communication est proactive et à
facettes multiples. Par ailleurs, les grands projets doivent aussi envisager d’utiliser des techniques de
base, mais aussi des techniques plus sophistiquées pour gérer la documentation du projet.
6.1.1 Exemples de plans de communication - Petits projets

6.1.2 Gérer les communications / Projets de taille moyenne
 6.1.2.1 Eléments de base
6.1.3 Gérer les communications / Grands projets
 6.1.3.1 Gestion avancée de la documentation du projet
275
6.1.1 Exemples de plans de communication / Petits projets
Les petits projets ne nécessitent, habituellement, qu’un rapport d'avancement simple. Si le chef de
projet travaille directement sur les livrables, il a probablement une idée approfondie de la situation
globale. Cependant, le commanditaire et les autres parties prenantes ont toujours besoin de connaître
si la situation est à jour.
Si le chef de projet ne travaille pas sur les détails du projet (il peut par exemple, avoir un certain
nombre de projets en cours de gestion), il aura besoin d'un processus formel de rapports d'avancement
de la part de l’équipe du projet et devra lui-même adresser un rapport aux parties prenantes. Le
processus qui suit est un modèle du genre.
Rôle Rapports d’avancement (Petits projets)
Présenter des rapports d’avancement de l’équipe au chef de projet

Membres de
1 Chaque semaine, les membres de l’équipe du projet envoient une mise à jour du
l’équipe
point sur la situation au chef de projet.
Elaborer des rapports d’avancement destinés au commanditaire et aux

parties prenantes
Il est important que le chef de projet utilise des rapports d’avancement et
d’autres méthodes de communication pour gérer les attentes. Voir 6.1.1.1 pour
plus d’informations à ce sujet.
Chef de
2 Le chef de projet envoie une mise à jour sur la situation au commanditaire du
projet
projet et aux parties prenantes toutes les deux semaines ou une fois par mois.
Cependant, soyez prudent avec les rapports mensuels. Si le projet est très petit,
le client peut n'obtenir aucune mise à jour avant que celui-ci ne soit achevé (en
tout cas pas plus d’une seule). Cela ne lui donne pas le temps de réagir s’il
s’aperçoit de quelque chose d’anormal. Dans de tels cas, le chef de projet est
tenu de faire un rapport sur la situation une ou deux fois par semaine.
Planifier et assister aux réunions de revue du projet

L’équipe du projet toute entière doit assister aux réunions de revue du projet.
Chef de Les réunions doivent se concentrer sur le point actuel de la situation par rapport
projet, à l'échéancier du projet et s’intéresser aux problèmes majeurs qui se posent, aux
3 membres de demandes de modification du contenu ou aux risques potentiels. Le client doit
l’équipe, être invité à y assister, mais cela n'est toutefois pas obligatoire. La fréquence des
clients réunions dépend de l’agenda du projet et de la nécessité d’obtenir les
informations de façon opportune. Par exemple, si le projet date de trois
semaines, l'équipe devrait se réunir deux fois par semaine. S’il dure huit
semaines, une fois par semaine conviendra mieux.
276
6.1.1.1 Gérer les attentes des parties prenantes
Vous avez déjà effectué une analyse initiale des parties prenantes au cours du processus d’identification
des parties prenantes (voir 0.0.1 Identifier et gérer les parties prenantes). L'analyse des parties
prenantes devrait être mise à jour périodiquement pour assurer qu'elles soient engagées avec succès.
Cela inclut la validation de l'importance des groupes de parties prenantes ainsi que l'intérêt que vous
portez à chaque groupe. Si les parties prenantes ne sont pas engagées comme vous l'espérez, vous
devriez effectuer une mise à jour ou modifier vos activités. Il est possible que vous découvriez de
nouvelles parties prenantes pendant que le projet progresse. Elles doivent être prises en considération
dans ce processus.
Vous devez exécuter les activités relatives au management des parties prenantes à partir de votre plan
original. Les communications dans votre analyse des parties prenantes seront effectuées en tant que
partie de votre plan de management des communications. Cependant, il se peut que d'autres éléments
dans votre analyse des parties prenantes doivent également être exécutés.
La gestion des attentes des parties prenantes est importante pour tous les projets, mais
particulièrement lorsque le projet est important, qu’il présente une forte visibilité, qu’il est politique
et/ou traite d’affaires essentielles. Quand les attentes sont correctement gérées, toutes les parties sont
satisfaites des résultats, même si le projet rencontre un certain nombre de modifications et de défis.
Quand les attentes ne sont pas aussi bien gérées, même un projet qui respecte le budget et les délais
pourrait être considéré comme non réussi, du point de vue du client.
Gérer les attentes signifie tenir les parties prenantes au courant du déroulement du projet et des
modifications qui, le cas échéant, sont apportées à ce qui avait été initialement prévu et approuvé. De
grandes surprises peuvent être fatales pour un projet. Le chef de projet devra s'assurer que les parties
prenantes soient impliquées dans le projet et que les attentes de ces dernières soient toujours
conformes aux siennes. Le minimum est que vous cherchiez à donner des informations exhaustives
pour que vos parties prenantes sachent de quoi il s’agit et ce qui se passera. Vous devez vous assurer
que vous fournissez à vos clients toutes les informations importantes (bonnes ou mauvaises) avant
qu’elles ne proviennent d’autres sources.
Le processus suivant constitue un cadre global qui permettra de gérer efficacement les attentes.
Rôle Gérer les attentes
1 Chef de Établir un accord

projet, client
C'est probablement la partie la plus négligée, et pourtant la plus évidente. Il est
difficile, voire impossible, de répondre aux attentes du client si vous ne
commencez pas par établir un accord avec lui. Il existe deux lieux où se règle
l'accord original. Le premier est la charte du projet. L’un des buts de cette
dernière est de s’assurer qu'il y a accord sur son contenu, les livrables, les
hypothèses, les risques, le budget, les délais, etc. L’autre point évident pour
obtenir un accord se situe au niveau des spécifications. Documenter les
spécifications et obtenir leur approbation par le client constituent une étape
majeure dans l’établissement de l'accord initial.
2 Chef de Gérer le contenu

projet
Si vous ne commencez pas par établir un accord, vous n'aurez aucune chance de
gérer efficacement les attentes. En plus, une fois l'accord conclu, les
modifications de ce qui a été convenu doivent être traitées par le processus de
gestion des modifications. Cela permet au client d’approuver toutes les
modifications touchant l’accord préétabli et permet de maintenir la cohésion entre
les attentes et le déroulement du projet, malgré ces changements.
3 Chef de Communiquer de manière proactive
277
projet Lorsque l'accord a été conclu, continuez à communiquer de manière proactive
grâce au processus de rapport d’avancement, ou par l’entremise d’un plan de
management des communications plus vaste. Cela permet au client d’être au
courant de la progression, des problèmes majeurs, des risques, etc. La principale
motivation est d’éviter les surprises. Vous voulez éviter que votre client vous
appelle parce qu’il a appris d’une autre source une nouvelle importante
concernant le projet. Vous devez préalablement avoir communiqué avec le client.
4 Chef de Évaluer périodiquement les performances

projet
Le chef de projet doit évaluer les attentes à intervalles réguliers. Cela s’effectue
normalement en gérant l’échéancier et le budget, ce qui vous aidera à déterminer
rapidement si les attentes du projet risquent de ne pas être satisfaites. Si une
évaluation indique qu'il est peu vraisemblable que les attentes soient comblées,
des mesures correctives immédiates devront être prises pour remettre le projet
sur la bonne voie.
5 Chef de Livrer ce qui était attendu

projet
À nouveau, ceci peut sembler évident. Cependant, une fois qu'un accord a été
mis en place, vous devez vous assurer que vous fournissez le travail prévu. Une
des faiblesses de la communication sur beaucoup de projets est que les délais et
autres attentes ne sont pas respectés, et qu’il y a donc absence d’information au
niveau du client sur la situation et sur les raisons de ces défaillances.
6 Chef de Remettre à plat les attentes, si nécessaire

projet
Si vous pensez que l'accord original ne peut être satisfait, il devra alors être
renégocié. Ce processus inclut la collecte des faits entourant l'incapacité à réaliser
l'accord original. De plus, il faut trouver une nouvelle approche afin de livrer une
solution aussi proche que possible de l'accord original et d’une manière qui
satisfera les deux parties. Cela peut inclure plus de temps, un budget plus
important, ou encore de livrer une solution qui ne correspond pas exactement à
ce que le client attendait initialement. La conclusion d’un nouvel accord modifié
ramène le chef de projet au début du processus décrit ci-dessus; il faut accomplir
le travail nécessaire pour répondre aux nouvelles attentes.
7 Chef de Accomplir l'accord.

projet, client
Passez en revue les travaux accomplis avec le client pour vous assurer que les
objectifs de l'accord ont été entièrement atteints. Si ce n’est pas le cas, négociez
ce qui sera nécessaire pour le réaliser pleinement.
278
6.1.2 Gérer les communications / Projets de taille moyenne
Au début du projet
Planification des communications (6.1.2. P1)
Rôle Gérer la communication (Projets moyens)
Envisager la création d’un plan de management des communications

Plus le projet est grand, plus il a besoin d’un plan formel de management des
1 Chef de projet communications. Cela est encore plus important si le projet entraîne un
changement culturel. Si le projet a besoin d’un plan de management des
communications, référez-vous au processus utilisé pour les grands projets.
Envisager l’utilisation d’un processus simple de gestion

des documents
2 Chef de projet Si le projet moyen devient grand, le chef de projet doit envisager la gestion de
la documentation du projet afin qu’une documentation copieuse soit bien
organisée et structurée. Une planification préalable de cette activité vous
permettra d’éviter les problèmes au cours du projet.
Lors de tout le cycle de vie du projet
Rapport de performance (6.1.2. P2)
Planifier des réunions de revue du projet et y assister

L'équipe devrait tenir des réunions de revue du projet à un rythme
Chef de hebdomadaire ou bihebdomadaire. Si le chef de projet le préfère, il peut
projet, organiser une réunion de revue du projet avec l’équipe de projet et une réunion
3 membres de séparée avec le client. Il doit y avoir un ordre du jour standard pour les réunions
l’équipe, et celles-ci ne doivent pas durer plus d’une heure. En général, le but de ces
client réunions est d’informer sur la situation, pas de résoudre des problèmes. (Un
modèle d’ordre du jour pour une réunion de revue du projet est inclus dans la
partie des livrables).
Elaborer des rapports d’avancement destinés au commanditaire et aux

parties prenantes
Il est important pour le chef de projet d’utiliser des rapports d’avancement et
Chef de d’autres méthodes de communication pour gérer les attentes. Voir la partie
4 6.1.1.1 pour plus d’informations sur la gestion des attentes des parties
projet
prenantes. Le chef de projet envoie le rapport d’avancement du projet à toutes
les parties prenantes, toutes les deux semaines ou une fois par mois. En
fonction du cycle d’établissement des rapports financiers de l’institution, le
rapport d’avancement du projet peut comporter aussi un rapport financier.
Créer le rapport d’avancement pour le chef de projet

Les membres de l’équipe du projet doivent envoyer un rapport d'avancement
Membres de hebdomadaire ou bihebdomadaire au chef de projet, détaillant leurs progrès
5
l’équipe pendant la période couverte par le rapport. Ces informations sont employées
par le chef de projet pour mettre à jour chaque activité assignée par
l'échéancier du projet. Ce rapport est un complément de la réunion de revue du
279
projet. Si le chef de projet est au courant des détails de la situation en cours
concernant chaque membre de l’équipe, le rapport d’avancement peut ne pas
être demandé. Cela peut être le cas si le chef de projet, à côté de ses fonctions
de chef de projet, est aussi engagé directement dans l’élaboration des livrables
du projet.
On peut coordonner les rapports d’avancement avec les réunions de revue du
projet de la manière suivante : l’équipe soumet ses rapports d’avancement au
chef de projet le dernier jour ouvrable de la semaine. Ce dernier met à jour
l’échéancier et le budget le premier jour ouvrable de la semaine suivante et
envoie son rapport d’avancement au commanditaire et aux parties prenantes le
jour même. Le chef de projet et l’équipe tiennent une réunion de revue du
projet le second jour ouvrable de la semaine pour examiner la situation du
projet et assigner du travail. Cette séquence permet au chef de projet d’être au
courant des activités à la fin de la semaine et de préparer une réunion
performante avec l’équipe et le client, au début de la semaine suivante.
280
6.1.2.1 Éléments de base
(6.1.2.1. P1)
Plus un projet est grand, plus il devient difficile de partager efficacement les informations entre tous les
membres de l’équipe et les parties prenantes. C’est particulièrement le cas lorsque plus d'une personne
travaille à de grands livrables. Si le chef de projet n’établit pas un bon processus de gestion des
documents en amont, l’équipe aura des difficultés à trouver les informations dont elle a besoin. Il y
aura donc de la confusion et du travail superflu, y compris la réélaboration de travaux déjà existants.
En général, l'idée du management des documents est semblable à ce qui se fait en matière de gestion
des codes sources en informatique. La gestion du code source doit être réalisée sous la direction d’un
outil logiciel de gestion des changements ou à l’aide d’une base de données qui permet d’assurer le
suivi du droit de propriété et des copies. Sans ce type d'outil, il est très difficile de développer et de
soutenir des grands projets de logiciel. Suivant le même principe, les documents liés au projet doivent
être gérés et maîtrisés, particulièrement sur de grands projets.
Quelques exemples aideront à mieux comprendre ce concept. Supposons que votre projet va générer
de nombreux de documents qui devront être stockés et partagés, par exemple : la charte du projet, le
journal des problèmes majeurs, les spécifications, le plan de tests, etc. Après la création d’un
document, les membres de l’équipe doivent savoir où il devra être stocké. Selon votre degré de
sophistication, le document ira dans un dossier du réseau, un dossier figurant sur votre disque dur, un
package d’un logiciel de gestion de documents, etc. Après la création du document, vous devez savoir
qui peut y avoir accès. La plupart des documents seront accessibles à toute l'équipe sans que ses
membres puissent les modifier. Vous devez instaurer une convention d'appellation commune pour le
document original et toutes ses révisions. Par exemple, si vous mettez à jour la charte du projet, le
document modifié devra-t-il remplacer la version plus ancienne ? Peut-être devriez-vous sauvegarder le
document original, et appeler le nouveau document version 2. Tout ceci fait partie de votre procédure
de gestion des documents.
Regardons également les rapports d'avancement. Vous devriez considérer, en amont, la convention
d'appellation de ces rapports. Si chaque membre de l’équipe envoie un rapport d'avancement au chef
de projet, il s’écoulera peu de temps avant que le chef de projet ait accumulé des dizaines, voire des
centaines de rapports d'avancement. Si le format du document est le suivant "Date Nom Rapport"
d'avancement, alors ils seront classés dans un ordre chronologique. Si vous les recevez avec les
indications suivantes "Nom Rapport d'avancement Date", ils seront classés par personne. Peut-être le
chef de projet devra-t-il simplement supprimer les rapports d'avancement après les avoir passés en
revue. Toutes ces questions sont des composantes du management des documents.
Les considérations de gestion des documents sont insignifiantes pour de petits projets. Pour les grands,
ce processus devra être prévu en amont, sans quoi une certaine confusion ajoutée à de l'incertitude et
du travail supplémentaire, entraveront la progression du projet.
Données structurées et non structurées (6.1.2.1. P2)
Les données peuvent être stockées dans un de ces deux états : structuré et non structuré. Les données
structurées se rapportent aux informations qui sont stockées dans un format répétitif et structuré. Les
données structurées se rapportent à des dossiers, à des tables, à des bases de données, à des dépôts
de données, etc. Des programmes informatiques permettent de stocker ce type de données afin d’y
accéder facilement.
D’autre part, les données non structurées sont généralement présentées dans un format plus facile à
comprendre pour un cerveau humain (par opposition à une machine). Les données non structurées
incluent des documents, des images, des graphiques, des vidéos, des fichiers audio, etc. Ces données
non structurées peuvent également être traitées par un ordinateur; c’est de plus en plus souvent le cas.
Cependant, le traitement de base de ces contenus est toujours mieux exécuté par le personnel.
Bien que les documents soient une préoccupation principale pour la plupart des équipes de projet, le
281
terme peut être élargi, dans le cadre de votre projet, à tous types de données non structurées comme
celles décrites ci-dessus. En d'autres termes, si votre projet produit des fichiers audio et vidéo, vous
pourrez employer ces mêmes techniques concernant les conventions d’appellation, d’indexation, de
stockage, etc.
Le tableau qui suit présente quelques exemples de données structurées et non structurées.
Données structurées Données non structurées
Champs, archives, fichiers, tables Documents, photos, graphiques, textes, vidéos,

Codes, modèles, scripts chat
Reposent sur des outils, des bases de données Difficile de trouver des outils, bien qu’il en existe
un grand nombre aujourd’hui
Outils de gestion de code source
Outils de gestion des documents
Difficile à organiser sans outil informatique ou
structure Peuvent être organisés sans outil informatique
Les fondements de la gestion de documents (6.1.2.1. P3)
Cette partie décrit les composantes du processus de gestion des documents. Ces processus peuvent
être modifiés, si nécessaire, en fonction de votre projet, puis insérés dans le document Plan de
Management de Projet, créé lors du processus 1.0 Définir le travail. Plusieurs de ces composantes sont
nécessaires pour soutenir le processus d’un document, depuis sa création jusqu’à son approbation. Ceci
est expliqué au paragraphe 6.1.2.2 Le cycle de vie d’un document. Le processus de gestion des
ébauches est décrit au paragraphe 6.1.2.3 Ébauches.
En fait, la gestion de la documentation n’est pas tant un processus séquentiel : elle est plutôt une
approche et un ensemble de techniques pour gérer les documents.
Plus le projet sera grand, plus un effort de rigueur et de structuration sera nécessaire pour gérer les
documents. Vous rencontrerez toujours de gros problèmes en essayant de sauvegarder et de trouver
des documents si vous ne pensez pas, préalablement, à l’élaboration d’un bon plan de gestion des
documents. Les parties suivantes devront faire partie d'un plan global de gestion des documents. Elles
ne reflètent pas un processus en tant que tel, puisque plusieurs de ces éléments peuvent être
considérés et mis en application dans n’importe quel ordre
 Déterminer où stocker les documents. L’équipe de projet doit avoir un secteur commun,
un dépôt, pour stocker des documents. Cela peut être un chemin de fichier, un logiciel de
gestion de documents, un dossier papier, etc. Le chef de projet devra s’assurer que des
documents ne sont pas stockés n’importe où, selon les préférences de chaque membre de
l’équipe. Si cela se produit, l'équipe aura des difficultés à trouver des documents importants
quand elle en aura besoin, particulièrement s’il y a une grande fluctuation de personnel parmi
les membres de l’équipe.
 Déterminer quels types de documents seront ajoutés au dépôt. L'équipe doit

également déterminer quels types de documents seront ajoutés au dépôt. Il est possible que ce
dernier reçoive chaque document à chaque étape d'accomplissement, y compris les versions
préliminaires et les documents des secteurs de chaque membre de l’équipe. Cependant, il est
également courant que chaque membre de l’équipe ait une zone de travail pour ses propres
documents afin que le dépôt des documents ne stocke que les versions finales et les livrables
approuvés.
 Définir la structure logique du dépôt. Une fois que vous savez où vous stockerez les
documents, vous devriez également déterminer la structure du dépôt. Cela indiquera aux
membres de l’équipe le lieu où les documents doivent être stockés et les aidera à les retrouver
quand ils en auront besoin. La première étape est de concevoir et diffuser une ébauche de la
282
structure du dépôt pour obtenir de la rétroaction. Une fois un accord conclu sur la structure du
dépôt, vous devriez la mettre en application. La structure devra être facile à comprendre et à
employer pour trouver les informations appropriées. Après avoir créé cette structure pour
plusieurs projets, vous commencerez à voir des similitudes et vous vous rendrez compte des
bénéfices inhérents à la création d’une structure normalisée pour sauvegarder les documents
de n’importe quel projet de l’entreprise. Un exemple de structure du dépôt est disponible au
paragraphe 6.1.2.4 Modèle de structure du dépôt de documents.
 Définir une norme d’appellation des documents. Il peut être difficile de trouver des
documents, même si vous comptez sur une bonne structure pour le dépôt des documents. Une
norme commune d’appellation des documents facilitera la recherche d'informations. Un
exemple a été décrit précédemment pour les conventions d’appellation des rapports
d'avancement. Une convention pourrait s’appeler « 20081201 Pierre Dupont rapport
d'avancement ». Avec cette convention, tous les rapports d'avancement seront classés par
date. Par contre, une convention de type « Pierre Dupont rapport d'avancement 20081201 »
permettra de regrouper les rapports en fonction du personnel. Le chef de projet doit être sûr
que chacun emploie la même norme d'appellation. Bien que cet exercice puisse sembler
fastidieux, avoir une convention commune d’appellation des documents sera d’un grand apport,
surtout parce que votre équipe de projet peut produire des centaines de documents en cours
de route.
 Déterminer si certains documents ont besoin d’être stockés en plusieurs versions. Le

chef de projet devra déterminer si des versions multiples des documents doivent être
sauvegardées ou seulement la dernière version. Beaucoup de documents, tels que la charte du
projet par exemple, nécessiteront la sauvegarde de toutes les versions approuvées. Pour ces
documents, la convention d'appellation aura besoin d'un chiffre pour identifier la version. Par
exemple, le document original pourrait être appelé « Charte du projet ABC v1 ». Le nom du
document sera modifié en « Charte du projet ABC v2 » s’il est mis à jour ultérieurement. Le
personnel pourra alors revenir aux versions antérieures si besoin. D’autre part, des documents
tels que le journal des problèmes majeurs, qui ont seulement une version courante,
rassemblent toutes les questions actuelles et antérieures sauvegardées dans le même
document. La version courante du journal des problèmes majeurs remplace toujours la version
antérieure, et il n'y a aucune raison de garder des versions séparées. Si vous disposez d'un
système de management de document cela vous fournit probablement un outil de gestion des
versions.
 Déterminer si (et comment) il faut suivre le point sur la situation d'approbation des
documents. Quand des documents doivent être approuvés, particulièrement quand le
processus d'approbation est relativement long, il est important de faire le point sur la situation
d'approbation du document. Par exemple, il est important de savoir, à la lecture d’un
document, s’il s’agit d’une version finale approuvée ou d’une version préliminaire, c’est à dire
d’une ébauche. Sauvegarder les versions approuvées, séparées des ébauches s’avère utile. On
peut utiliser la nomenclature suivante : « ébauche », « en cours » et « version finale ». Quand
un document est créé, il est classé dans la zone « ébauche ». Quand le document sort du poste
de travail individuel de l’auteur et qu’il est en voie d’approbation, il est déplacé dans le dossier
« travail en cours ». Quand il est approuvé, il est déplacé dans le dossier « final ».
 Définir des formats standardisés pour les documents. Il est plus facile, à long terme, de
lire et de créer des documents s'ils suivent tous un format standard. En outre, l'équipe peut
créer des en-têtes et des titres de bas de page standard, des pages de couverture et des
sommaires. Ceci donnera à toute la documentation un aspect homogène.
 Utiliser des logiciels standard pour le traitement des documents (facultatif). L'équipe
doit avoir un ensemble standard d’outils de traitement des documents. Normalement, ce n'est
pas un problème si toute l'équipe est dans le même secteur. Cependant, le manque d'outils
communs peut être un problème si votre équipe de projet inclut des personnes de différents
organismes, de différents pays ou de différentes entreprises. Par exemple, une chose aussi
simple qu'un logiciel de traitement de texte standard n'est normalement pas un problème.
Cependant, si vous avez des fournisseurs différents pour votre équipe, vous pouvez avoir
certains membres de l’équipe qui utiliseront MS Word, et d’autres qui utiliseront WordPerfect.
283
Tous les membres de l’équipe devront utiliser le même tableur. Une fois que le logiciel standard
est identifié, vous devez également vous assurer que l'équipe entière est sur la même version.
En d'autres termes, si vous voulez employer MS Word sur votre projet, assurez-vous que tous
les membres de l’équipe possèdent cette version du MS Word. Parfois, vos documents ne
pourront pas être facilement partagés si le créateur et le lecteur ne sont pas sur la même
version du logiciel.
284
6.1.2.2 Le cycle de vie d'un document
Il est important que le chef de projet définisse les étapes par lesquelles un document doit passer, de sa
première ébauche à son accomplissement. Cette définition permet au chef de projet de reconnaître
l’état d’avancement d’un document ainsi que l’aide à évaluer l’effort encore requis pour le terminer. Par
exemple, quand un membre de l’équipe mentionne qu'il peut achever un document en deux semaines,
veut-il exprimer que dans deux semaines le document sera achevé et définitivement approuvé? Tous
les documents ne doivent pas passer par toutes les étapes d’élaboration et d'approbation. Cependant,
suivant le document, une ou plusieurs étapes seront exigées.
Certaines des étapes de passage en revue définies ci-dessous peuvent également être considérées
comme faisant partie du processus de contrôle qualité pour les documents.
Rôle Cycle de vie du document
1 Auteur du Planifier le document

document
Parfois, on est tellement inspiré que la rédaction correcte d’un document se
déroule spontanément; d'autres fois, il faut se préparer et planifier, organiser
la conception et structurer le contenu de ce qui doit être exprimé dans le
document. Ce dernier cas est plus probable si le document en question est
long et complexe. Ce travail préalable – comme à tout moment de la gestion
de projet - vous aidera à mieux rédiger le document.
2 Auteur du Créer l’ébauche initiale du document.

document
Au cours de cette étape, le document est initialement élaboré. Dans le cas où
ni des révisions ni des approbations ne seront nécessaires, cette étape aura
pour conséquence la création du produit livrable final. La plus grande partie de
l'effort de travail associé au document est employée lors de cette étape. Les
étapes suivantes peuvent représenter une longue durée, mais elles ne
demandent pas autant d'effort de travail.
3 Auteur du Diffuser le document en vue de recueillir un feedback puis procéder à

document des modifications.
Ces deux étapes impliquent la circulation du document pour sa révision et
pour obtenir les premières réactions en retour. Le document est mis à jour en
fonction des commentaires de révision. Suivant la nature du document, cela
peut être une étape itérative. Un document peut être passé par une révision
interne suivie d'une révision des parties prenantes, ensuite d'une révision de la
part de la direction. Après chacune de ces révisions, le document est modifié
en fonction de la rétroaction, puis transmis à l’étape suivante.
4 Auteur du Obtenir l’approbation du document

document
Quand le document a été diffusé pour la rétroaction, puis mis à jour, il est prêt
pour l’approbation finale. Quelques documents devront être formellement
approuvés par écrit. D'autres sont simplement considérés comme complets
après la réception du processus final de rétroaction.
Comme tous les livrables réalisés, des mises à jour ultérieures auront leur propre cycle de vie.
285
6.1.2.3 Ébauches
Les documents à l’état d’ébauche sont des documents qui se trouvent en processus de révision après
avoir été rédigés par l’auteur. Pour les projets moyens, ces ébauches peuvent être sauvegardées dans
la zone de travail personnelle de l'auteur. Pour les grands projets – du fait de la rigueur nécessaire dans
la gestion des documents – il convient de prévoir un dossier particulier pour les ébauches dans le dépôt
de documents. Le processus de mises à jour est le suivant :
Rôle Processus d’approbation du document
1 Auteur du document Un document sera toujours créé et édité dans la zone de travail de
l'auteur.
2 Auteur du document Une fois l’ébauche achevée, le document est déplacé de la zone de
travail vers le dossier virtuel des ébauches. Le document y demeure
jusqu'à ce que l'auteur le mette à jour, ou jusqu’à ce qu’il soit prêt à
être transposé dans le dossier des versions finales du dépôt.
3 Auteur du document Lorsque le document est dans le dossier des ébauches, il peut être mis
en circulation pour être revu et enrichi.
4 Auteur du document Si l’ébauche doit être mise à jour une nouvelle fois (disons, en raison de
nouvelles révisions), le document sera copié de nouveau dans la zone
de travail pour que cette mise à jour y soit effectuée. On devra laisser
une copie des ébauches préliminaires dans le dossier.
5 Auteur du Ce processus est répété jusqu'à ce que le document soit totalement

document, achevé. Alors, le document peut être déplacé du dossier des ébauches
documentaliste vers son emplacement dans le dossier des versions finales du dépôt des
documents.
L’intérêt de cette approche réside dans le fait que l’équipe de projet dispose toujours d’une ébauche
officielle de chaque document ainsi que d’une version approuvée.
286
6.1.2.4 Modèle de structure du dépôt de documents
Globalement, le dépôt de documents devra compter trois zones principales : livrables du projet,
livrables de management du projet, et références. Un quatrième secteur peut également être défini
pour la zone de travail des membres de l’équipe.
 Livrables du projet : Un dossier qui sert à stocker tous les livrables relatifs au projet. Il est
composé de sous-dossiers servant à fournir plus de précision sur l’emplacement où des
documents spécifiques doivent être stockés.
 Livrables de management de projet : Un dossier servant à stocker tous les livrables relatifs
au management de projet. Il est décomposé en sous-dossiers fournissant plus de précision sur
l’emplacement où des documents spécifiques doivent être stockés.
 Références : Un dossier réservé à tous les documents qui servent de données d’entrée pour
l’élaboration des livrables. Exemples : la définition de l'architecture, l’organigramme du client,
du matériel de formation, des graphiques sources, etc. (Attention : les livrables créés par le
projet ne sont pas classés dans ce dossier).
 Zone de travail (facultatif) : dossier utilisé par chaque membre de l’équipe pour la création
des produits de travail.
Un exemple de structure simple pour un dépôt de documents est présenté ci-dessous :
\Nom du projet
\Livrables du projet
\Final
\Ebauches
\Travail en cours
\Livrables de management de projet
\Charte du projet
\Communications (e-mails, faxes, etc.)
\Présentations
\Informations financières
\Journaux
\Divers
\Echéanciers
\Points sur la situation
\ Procès verbaux de réunions
\Rapports
\Références
\Supports pédagogiques
\Modèles
\Autres documents de référence
287
\Zone de travail
\Membre de l’équipe 1
\Membre de l’équipe 2
\(etc.)
288
6.1.3 Gérer les communications / Grands projets
Grands projets (6.1.3. P1)
Dans un grand projet, toute la communication a lieu dans le cadre d’un plan global de gestion des
communications. Des réunions de revue du projet et des rapports d'avancement sont exigés, de la
même façon que pour un projet de taille moyenne. En outre, il y a beaucoup d'autres types de
communication proactive qui doivent être envisagés. Ces communications créatives et proactives sont
présentées dans un plan de management des communications qui est créé de la manière suivante :
Au début du projet
Planifier les communications (6.1.3. P2)
Rôle Rapports d’avancement (Grands projets)
1 Chef de projet Déterminer les parties prenantes du projet.

Dans certains cas, ce sont des groupes de parties prenantes tel qu'un comité de
pilotage de projet, par exemple. Dans d'autres cas, il peut s’agir d’une seule
personne, tel qu'un commanditaire.
2 Chef de projet Analyser les besoins de communication de chaque partie prenante.

Le chef de projet peut classer les besoins de communication de chaque partie
prenante dans l’une des trois catégories suivantes concernant les types de
mesures de communication :
 Mesures de communication statutaire. Ceci inclut généralement les

rapports d'avancement du projet, les exigences légales, les rapports
financiers, etc. Ces informations sont présentées aux destinataires.
 Mesures de communication informative. Ce sont les informations

que les gens veulent avoir ou dont ils peuvent avoir besoin pour leurs
travaux. Ces informations sont mises à la disposition des parties
prenantes, mais exigent qu’elles prennent des initiatives pour les
recueillir.
 Mesures de communication marketing. Cette forme de

communication est conçue pour susciter de l’envie et de l’enthousiasme
pour le projet et ses livrables. Ce type d’information est envoyé de
manière proactive aux parties prenantes. Il est également possible d’aller
plus loin et de développer une vraie « marque » pour un grand projet,
par exemple s’il faut effectuer un « changement de paradigme » ou un «
changement de culture » de l’entreprise (voyez le paragraphe 6.1.3.3
Construire une marque pour un projet pour de plus amples
renseignements à ce sujet).
3 Chef de projet Déterminer les mesures de communication les plus appropriées pour
satisfaire les besoins en communication de chaque partie prenante.
Il est important pour le chef de projet d’utiliser les rapports d’avancement et
d’autres méthodes de communication pour gérer les attentes. Voir 6.1.1.1 Gérer
les attentes des parties prenantes pour de plus amples renseignements sur la
gestion des attentes des parties prenantes.
Cependant, ce n'est généralement pas suffisant pour bien gérer la
289
communication dans les grands projets.
Déterminez les informations que chaque partie prenante doit connaître, la
fréquence des mises à jour, et la meilleure façon de communiquer ces
informations. Soyez créatif dans la recherche des moyens de communication
avec ces parties prenantes. Par exemple, celles-ci ont toujours besoin d’une
mise à jour sur la situation du projet. Le Comité de Pilotage peut décider de se
réunir un mois sur deux pour un briefing exécutif et axer le projet sur la
stratégie désirée. Le commanditaire du projet peut avoir besoin d'un briefing
personnel à un rythme mensuel. Un bulletin trimestriel peut être nécessaire pour
informer les divers départements du client et aussi pour faire du marketing. Pour
d'autres exemples de mécanismes de communication, voyez le paragraphe
6.1.3.2 Exemples de plan de management des communications.
4 Chef de projet Déterminer l’effort requis.

Estimez l'effort requis pour créer et diffuser chacune des options de
communication identifiées au cours du processus 3. Déterminez aussi les
bénéfices de la communication pour le destinataire et l’équipe de projet.
5 Chef de projet Classer les options de communication par ordre de priorité.

Décantez les options qui ne rendront qu’un bénéfice marginal, bien qu’elles
n’exigent que peu de travail de la part de l’équipe.
Sélectionnez en priorité les options de communication qui présentent un impact
important et qui exigent peu de travail de la part de l’équipe.
Évaluez également les options de communication présentant un impact
important mais qui exigent beaucoup de travail de la part de l’équipe. Certaines
de ces options pourront être mises en œuvre.
6 Chef de projet Mettre en œuvre les mesures obligatoires de communication.

Indépendamment du niveau de priorité, mettez en œuvre toutes les mesures de
communication obligatoires pour le projet ou pour son environnement. Cela
inclut impérativement les rapports d'avancement, des rapports exigés par le
gouvernement, par la direction de l’entreprise, etc.
7 Chef de projet Ajouter à l’échéancier les activités nécessaires pour exécuter les
options de communication choisies.
Pour chaque mesure de communication qui doit être mise en œuvre, déterminez
la fréquence, les délais, l’effort de travail et la personne responsable et ajoutez
ces informations à l’échéancier.
Plan de gestion de la documentation (6.1.3. P3)
8 Chef de Planifier et gérer la documentation

projet
Les grands projets peuvent susciter une grande quantité de documentation.
Celle-ci peut alors échapper au contrôle au point que les informations
s’éparpillent et deviennent difficiles à trouver et à organiser. Le processus de
gestion de la documentation devient plus facile si le chef de projet planifie la
forme des documents, les emplacements où ils seront stockés et la manière dont
ils seront contrôlés. Ce processus est décrit en 6.1.2.1 Eléments de base et
6.1.3.1 Gestion avancée de la documentation du projet.
290
Diffuser l'information (6.1.3. P4)
9 Chef de Exécuter le plan de management des communications

projet
Le plan de management des communications établit la liste des parties
prenantes, détermine leurs besoins en matière de communication, le rythme de
celle-ci, les meilleurs canaux, etc. Le chef de projet doit exécuter le plan de
management des communications, pour le traduire dans la réalité. Cela inclut
également le fait de répondre aux demandes ponctuelles d’information.
Rapports de performance (6.1.3. P5)
10 Chef de Planifier et assister aux réunions de revue du projet

projet,
L'équipe devrait tenir des réunions de revue du projet à un rythme
membres de
hebdomadaire ou bihebdomadaire. Si le chef de projet le désire, il peut
l’équipe,
organiser une réunion de revue du projet pour l’équipe de projet et une réunion
client
séparée avec le client. Il doit y avoir un ordre du jour standard pour les
réunions et celles-ci ne doivent pas durer plus d’une heure. En général, le but
de ces réunions est d’informer l’équipe sur la situation, et non de résoudre des
problèmes. (Un modèle d’ordre du jour pour une réunion de revue du projet est
inclus dans la partie).
11 Chef de projet Élaborer des rapports d’avancement destinés au commanditaire et

aux parties prenantes
Le chef de projet envoie le rapport d’avancement du projet à toutes les parties
prenantes, toutes les deux semaines ou une fois par mois. En fonction du cycle
d’établissement des rapports financiers de l’institution, le rapport d’avancement
du projet peut aussi comporter un rapport financier.
12 Membres de Élaborer le rapport d’avancement pour le chef de projet

l’équipe
Les membres de l’équipe de projet doivent envoyer un rapport d'avancement
hebdomadaire ou bihebdomadaire au chef de projet, détaillant leurs progrès
pendant la période couverte par le rapport. Ces informations sont fournies par
le chef de projet afin de mettre à jour chaque activité assignée par l'échéancier
du projet. Ce rapport est un complément de la réunion de revue du projet. Si le
chef de projet est au courant des détails de la situation en cours concernant
chaque membre de l’équipe, le rapport d’avancement peut ne pas être
demandé. Cela peut être le cas si le chef de projet, en plus de ses fonctions en
tant que chef de projet, est aussi engagé directement dans l’élaboration des
livrables du projet.
On peut coordonner les rapports d’avancement avec les réunions de revue du
projet de la manière suivante : l’équipe soumet ses rapports d’avancement au
chef de projet le dernier jour ouvrable de la semaine. Ce dernier met à jour
l’échéancier et le budget le premier jour ouvrable de la semaine suivante et
envoie son rapport d’avancement au commanditaire et aux parties prenantes le
jour même. Le chef de projet et l’équipe tiennent une réunion de revue du
projet le second jour ouvrable de la semaine pour examiner la situation du
projet et assigner du travail. Cette séquence permet au chef de projet d’être au
courant des activités à la fin de la semaine et de préparer une réunion
performante avec l’équipe et le client, au début de la semaine suivante.
291
6.1.3.1 Gestion avancée de la documentation du projet
Les grands projets devraient d'abord examiner le processus pour des projets moyens puisque toutes
ces étapes leur sont également applicables. Les règles pour les structures des dossiers et les
conventions d'appellation y sont encore plus importantes. En plus des éléments pour des projets
moyens, les grands projets devront examiner les points suivants :
 Affecter un responsable au dépôt des documents. Une fois votre dépôt de documents
établi, vous voudriez que quelqu'un soit responsable de sa gestion. Ce n'est pas un travail
difficile si le projet est d’une taille petite à moyenne. Cependant, si votre projet produit
beaucoup de documents, cela peut demander beaucoup de temps, peut-être même exiger un
membre de l’équipe à temps plein. Vous devriez également assigner un remplaçant pour
effectuer ce travail lorsque le responsable principal n’est pas là. Ce rôle peut être assigné à un
ou plusieurs des membres de l’équipe. Il peut toutefois être rempli par une personne du
secrétariat du projet qui s’y consacre à temps plein. Les responsabilités sont les suivantes:
o Coordonner les activités autour du dépôt de documents.
o Établir, maintenir, et imposer les normes du dépôt de documents et en contrôler la

conformité.
o Identifier et résoudre les problèmes concernant le dépôt de documents.
o Surveiller les accès au dépôt des documents et les mises à jour de ces documents.
o Déterminer les règles d'archivage des vieux documents, et exécuter les activités
d’archivage et de purge.
 Définir les règles d'accès. Les règles d'accès concernent, par exemple, la personne qui peut
passer en revue les documents et qui peut les mettre à jour. La plupart des documents sont
accessibles à la lecture pour toute l'équipe. Certains documents pourront avoir un accès plus
limité. Cependant, vous devriez également être clair sur les documents que les membres de
l’équipe peuvent mettre à jour. En général, la règle est que la personne qui crée le document
est la seule à pouvoir le mettre à jour.
Si vous employez un outil informatique de gestion de documents, ces règles d'accès peuvent être
établies et imposées. Même si vous n’employez qu’une simple structure hiérarchique dans votre
serveur, vous devriez également établir des règles claires. Par exemple, vous pourriez consacrer un
dossier particulier pour les versions finales et personne ne devra y toucher. Vous pouvez également
établir des dossiers de travail pour tous les membres de l’équipe, où ils pourront mettre tous leurs
documents personnels, ainsi que les livrables du projet qui sont en cours.
 Créer un schéma d'indexation pour les recherches postérieures. Selon la technologie

employée pour votre dépôt de documents, il devrait être possible de rechercher des documents
puis d’y accéder. La recherche peut habituellement être exécutée suivant le nom du document
(rendant les normes d’appellation encore plus importantes) et / ou par mot-clé. Les mots-clés
sont des mots descriptifs qui sont associés au document de telle sorte qu’on puisse le retrouver
plus tard par une simple recherche par mot-clé, si on ne connaît ni le nom, ni l’endroit où il est
placé. Ces mots-clés sont des métadonnées sur le document, c'est-à-dire qu’ils fournissent des
moyens de décrire le document tel quel. La structure des mots-clés devra être définie à
l’avance. Par exemple, un schéma simple d’indexation de documents inclura son titre, son sujet,
l'auteur ou la personne à contacter, sa date de soumission et une liste de mots-clés. Le
document pourra alors être trouvé en employant une recherche avec n'importe quel mot
associé au schéma des mots-clés.
 Définir des procédures de mise à jour du dépôt. Tous les membres de l’équipe auront
besoin d’un accès complet à n'importe lequel de leurs documents en cours. Cependant, l’équipe
de projet doit décider si n'importe qui peut également effectuer des mises à jour sur les
documents des autres membres de l’équipe. Par exemple, il serait cohérent que n'importe quel
membre puisse ajouter des documents à la partie du dépôt contenant les livrables finaux et
292
approuvés. D'un autre côté, vous pourriez vouloir que l'accès à ces secteurs soit réservé
uniquement au responsable et permettre uniquement à ce dernier de procéder aux mises à jour
finales. Les règles de mise à jour sont l’un des aspects de gestion de projet que l’équipe doit
mettre en place dès le début du projet. La procédure à appliquer pourrait être la suivante :
o Les membres de l’équipe soumettent les documents au responsable du dépôt de

documents une fois qu’ils ont reçu l’approbation finale ou à la fin de chaque phase,
ainsi qu’à la fin du projet. Le membre de l’équipe remplit un formulaire qui décrit le
produit livrable, les mots-clés, la date d'approbation, le dossier de stockage, etc.
o Le responsable du dépôt s'assure que le document est bien à sa place dans le dépôt et
qu’il suit les normes du projet. Si le document ne remplit pas les conditions formelles
pour les versions finales, le responsable du dépôt peut refuser de l’y ajouter. Dans ce
cas-là, le document sera retourné au membre de l’équipe pour correction. Si le
responsable du dépôt ne possède pas les connaissances nécessaires pour évaluer le
contenu du document, il peut assigner un autre membre de l’équipe à la révision et à la
rétroaction sur le document.
o Si le document est pertinent et suit les normes, le responsable du dépôt le place dans
le dossier approprié et met à jour les mots-clés, si nécessaire. Le responsable emploie
le formulaire de document pour ajouter les métadonnées appropriées au document, y
compris les mots-clés, les dates d’approbation, la description, etc.
 Déterminer la conservation et les fréquences de purge. La purge des vieux documents

permet de s’assurer que les informations contenues dans le dépôt sont pertinentes. Les
différents rapports d'avancement individuels hebdomadaires, par exemple, peuvent ne plus être
nécessaires après trois mois. En revanche, le document de charte du projet est nécessaire
pendant toute la durée de vie du projet, même s’il s’agit de 12 mois. Durant le projet, le
responsable du dépôt archivera, à des périodes régulières, les informations qui ne sont plus
appropriées et évacuera ces documents hors du dépôt.
 Déterminer les méthodes de sauvegarde du dépôt et les conditions de récupération.

Si le dépôt de documents n'est pas sauvegardé automatiquement, le chef de projet doit
rajouter des activités sur l'échéancier du projet afin de s’assurer qu’une protection a bien eu
lieu. Si l'entreprise utilise déjà des processus systématiques de sauvegarde du dépôt, assurez-
vous que la fréquence des sauvegardes est convenable pour permettre une récupération des
documents qui vous ramène à la mise à jour la plus récente. Le chef de projet doit connaître le
lieu où la sauvegarde est stockée et pour combien de temps. Au moins une sauvegarde
récupérable du dépôt des documents devrait être envoyée sur un autre site, afin de pouvoir la
retrouver en cas de désastre.
 Examinez périodiquement le dépôt des documents. Si votre projet est très grand et que
le dépôt de documents est très vaste, il peut être judicieux de réaliser l’examen du dépôt et de
l’ensemble du processus de gestion de la documentation avec une périodicité préétablie. Le
bibliothécaire sera chargé de coordonner cet examen. L'examen aura pour but d’évaluer les
points suivants:
o Si le dépôt est correctement sauvegardé et a subi une purge
o Si la documentation a été stockée au bon endroit
o Si les documents sont indexés et classés correctement afin qu'ils puissent être
consultés au besoin
293
6.1.3.2 Exemples de plans de management des communications
(6.1.3.2. P1)
Les points suivants sont des exemples des mesures de communication qui peuvent être employées
dans le cadre d’un plan global de management des communications.
Mesures de communication statutaire (6.1.3.2. P2)
Il s’agit de mesures de communication qui sont exigées par votre entreprise, par votre industrie ou par
la loi. Ces informations sont fournies directement aux destinataires.
 Rapports d’avancement du projet
 Rapports d’avancement du projet
 Voice-mails sur l’avancement
 Réunions de revue du projet
 Réunions avec le comité de pilotage
 Conférences téléphoniques et vidéoconférences régulières avec des parties prenantes situées à

longue distance
 Rapports requis destinés aux actionnaires ou à votre conseil d'administration
 Rapports requis par le gouvernement et toute autre information qui lui est destinée
 Rapports financiers requis, tels que les déviations de budget, etc.
Mesures de communication informative (6.1.3.2. P3)
Ce sont les informations que les gens veulent y avoir accès ou dont ils peuvent avoir besoin pour leurs
travaux. Ces informations sont mises à la disposition des parties prenantes, mais ce sont les parties
prenantes qui doivent prendre l’initiative pour les recueillir.
 Des sessions de prise de conscience auxquelles les gens sont invités à assister de manière
facultative. (Il ne s’agit pas de formation, juste de prise de conscience.)
 Le placement de livrables du projet dans un dossier, un annuaire ou un site web auxquels les
gens peuvent accéder
 Les questions fréquemment posées
Mesures de communication marketing (6.1.3.2. P4)
Elle est conçue pour susciter de l’envie et de l’enthousiasme pour le projet et ses livrables. Ce type de
communication est « livré » aux lecteurs.
 Newsletters de projet avec une tournure marketing positive
 Rencontrer régulièrement les parties prenantes principales une à une
 Des expositions itinérantes en divers endroits et services, pour expliquer le projet et ses
avantages
 Témoignages, provenant d'autres personnes, et qui décrivent la valeur fournie par les livrables
du projet
294
 Des concours avec des prix simples pour provoquer une émulation
 Des acronymes et des slogans pour donner des images positives du projet
 Un compte à rebours jusqu'à la date finale du projet
 Des tournées informelles (mais délibérées), pour susciter des discussions concernant les
réalisations positives du projet
 Des réjouissances pour apporter de la visibilité à l'accomplissement des étapes importantes, des
jalons de l'échéancier
 Des produits dérivés avec le nom ou l'image du projet, tels que des badges, des stylos, des
frisbees, des tasses, des T-shirt, etc.
 Rendre publiques les réussites
Le but de ces exemples est de montrer que la communication de projet peut prendre beaucoup de
formes. Pour les grands projets tout particulièrement, l’équipe de projet devra être créative pour
déterminer comment, pourquoi, pour qui, et à quelle fréquence la communication doit avoir lieu. Si le
projet est controversé, s’il requiert des changements culturels, ou s’il est de nature politique, les
aspects positifs des techniques de communication marketing deviendront de plus en plus
incontournables. Dans ce genre de cas, vous pouvez également mettre en place un plan proactif pour
donner une marque au projet. (Voyez 6.1.3.3 Construire une marque pour le projet).
295
6.1.3.3 Construire une marque pour un projet
Il y a trois catégories principales de mesures de communication à l’intérieur d’un plan de management

des communications : statutaire, informative et marketing. Votre projet nécessitera probablement
toujours des mesures de communication statutaire, et vous voudriez aussi ajouter quelques mesures de
communication informative s’il est assez important. Les mesures de communication marketing sont
celles où la créativité entre en jeu. La plupart des projets n'ont pas besoin de ce type de
communication, laquelle est plus appropriée dans certains cas que dans d’autres. Cependant, si votre
projet est controversé ou qu’il a besoin de changement culturel pour réussir, vous devriez vous
concentrer sur la communication marketing.
Donner une marque à un projet est une forme des plus sophistiquées de communication marketing. Le
but est d'établir une identité susceptible de créer une image positive et de bonne volonté. C'est
exactement ce qui se passe lorsque les professionnels du marketing créent une marque pour un
produit. Par exemple, la compagnie Coca-Cola espère que vous aurez une bonne opinion de ses
produits et que vous les choisirez dans les rayons d’un magasin parce que vous aimez l'image et
l'émotion qui lui est associée. Peut-être que cela fonctionne de la sorte. Si vous organisez une fête et
que vous fournissez une grande quantité de Coca et de Sprite frais, vous vous sentez probablement
très fier de l’image que vous donnez de vous-même. Par contre, si vous offrez du cola sans marque,
vous vous sentirez peut être un peu embarrassé. Si c’est le cas, le processus de marquage a eu un effet
sur vous.
Donner une marque à un projet a la même connotation. Votre but est d'associer une image positive et
une émotion quand une personne entend parler de votre projet. Cela ne concerne pas la plupart des
projets. Cependant, posez-vous quelques questions concernant les retombées que votre projet aura sur
l’entreprise.
 A-t-il un impact sur un grand nombre de personnes ou peut-être même sur l’entreprise entière?
 Va-t-il nécessiter un changement de culture ou un changement dans la manière dont les gens
exercent leur activité?
 Votre projet rendra-t-il des personnes enthousiastes ? Va-t-il, par exemple, entraîner plus
d’efficacité, de telle sorte que de plus en plus de gens seront requis pour accomplir le même
travail?
Les projets susmentionnés correspondent aux types de projets pour lesquels vous pourriez créer une
marque.
Posez-vous ces questions quand vous envisagez une stratégie formelle d’attribution de marque. Lorsque
les gens entendent parler de votre projet, voulez-vous les faire penser aux avantages que votre projet
apporte ou voulez-vous qu'ils pensent à quel point celui-ci est mauvais? Doivent-ils s’imaginer
l’entreprise faisant face aux défis concurrentiels ou se demander si le projet va leur coûter leur travail ?
Voulez-vous qu’ils aient des pensées positives ou négatives ?
La plupart des grands projets ont une émotion qui leur est associée. Si vous ne faites rien, cette
émotion est généralement négative. De part sa nature humaine, l'homme pense que le changement est
toujours négatif. Une marque positive sur votre projet vous aide à établir de manière proactive l'image
que vous voulez donner plutôt que d’en avoir une qui vous est collée. Naturellement, la construction
d'une marque prend du temps. Aussi avez-vous également besoin d’un projet offrant un horizon
temporel assez long.
Il y a des activités qu’un projet peut embrasser pour aider la campagne de marketing. Si cela est
possible, vous devriez vous réunir avec votre service marketing pour recueillir davantage d'idées et
obtenir de l'aide sur la façon d’établir une marque et de la mettre en application avec efficacité. Voici
quelques exemples de ces activités:
 Choisissez un nom de projet positif. Par exemple, un projet appelé « Ventes Actives »,
donne probablement une image plus positive qu’un autre appelé « Initiative d'amélioration des
296
processus de vente ». Une autre idée sera de trouver un acronyme accrocheur. Vous pouvez
établir une image positive avec un acronyme facile à retenir.
 Établissez une image / un logo. Le projet devrait avoir une image ou un logo qui lui est
associé. L'image doit être positive et elle devra être incluse dans toute la communication
provenant de l'équipe.
 Distribuez des babioles portant la marque. Mettez votre nom ou votre logo de projet sur
des badges, t-shirts, stylos, frisbees, etc. Récompensez les personnes par un objet qui contient
le logo du projet lorsqu’ils réalisent une performance quelconque.
 Tenez des réunions en tête-à-tête. Prenez du temps pour rencontrer autant de personnes
que possible lors de réunions individuelles, ou de réunions en petits groupes, particulièrement
au début du projet. Personne ne veut recueillir toutes les informations sur un projet important
par e-mail. Cela déprécie le projet.
D'autres idées, par exemple des déjeuners d’affaires, une série de termes simples à associer au logo du
projet, recueillir des témoignages d’utilisateurs satisfaits, des communications personnelles continues,
etc. Trouvez des manières de mettre votre projet et votre message positif en évidence.
Naturellement, tout ceci est contingent et doit également comporter un flux régulier de contenu
informationnel. Un flux régulier d'informations, combiné avec un sentiment positif à l’égard de la
marque du projet, est susceptible d’aider celle-ci à réussir et à surmonter les perceptions négatives à
son sujet.
297
6.2 Gérer les communications / Techniques
Principes fondamentaux de gestion de réunions (6.2. P1)
En général, toutes les réunions doivent avoir un ordre du jour. La création de l'ordre du jour nécessite
un peu de travail supplémentaire, mais peut simplement revenir à écrire et envoyer un e-mail aux
participants à la réunion. Il ne faut pas réinventer la roue pour chaque réunion de revue du projet.
L’élaboration de l’ordre du jour n’est nécessaire que la première fois. Une fois que les participants
auront compris le déroulement d’une réunion de revue du projet, structurée autour d’un ordre du jour
standardisé, ce modèle peut être réutilisé à chaque fois.
D’autres considérations sont à prendre en compte lors des réunions:
 Si un groupe important de personnes est présent aux réunions, il devrait y avoir un

modérateur. Ce rôle pourra être tenu par rotation pour des réunions régulières. Il s’agit
habituellement de la personne qui a demandé la réunion à moins que d'autres arrangements
aient été trouvés. Pour les réunions régulières de revue du projet, le modérateur est
habituellement le chef de projet.
 Assurez-vous que les participants savent à l’avance tout ce qu’ils doivent apporter à la réunion
ou si une préparation éventuelle est nécessaire.
 Invitez seulement les personnes qui doivent être présentes. D'autres participants pourraient
diminuer l'efficacité de la réunion.
 La réunion devra commencer à l'heure, avec une certaine souplesse pour ceux qui pourraient
sortir d'une autre réunion.
 La personne qui a demandé la réunion devra en expliquer le but et les résultats attendus.
 Suivez l'ordre du jour et observez l'horaire pour être certain que tous les sujets seront couverts.
 Quelqu'un devra prendre note de tous les éléments de suivi assignés au cours de la réunion. Ce
sera le rôle du modérateur, à moins que d’autres arrangements aient été décidés. Cette
personne est appelée « le rapporteur ».
 Le rapporteur doit récapituler tous les éléments de suivi restants vers la fin de la réunion, en
précisant qui est responsable, ce qui est prévu, et quand l'élément de suivi doit prendre fin.
 Le rapporteur ou le modérateur récapitule toutes les décisions qui ont été prises et les
transpose dans un e-mail (ou tout autre mode de communication de projet approprié).
Veillez à la concentration lors des réunions de revue du projet (6.2. P2)
Il existe toujours une tentation de s’engager dans la résolution de problèmes quand les personnes
concernées sont sur place. Cependant, la résolution en question ne concerne généralement que très
peu de personnes, alors que pour les autres, il s’agit d’une perte de temps. Pendant que vous avez tout
le monde est accessible, utilisez ce moment pour faire le point de la situation, en ce qui concerne les
problèmes majeurs, le contenu du projet et les risques. Il y a beaucoup d’aspects de la santé d’un
projet qui concernent tous les participants. Il peut y avoir des résolutions de problèmes si l’ordre du
jour le permet, mais le modérateur doit s’assurer que les problèmes en question concernent la plupart
des membres de l’équipe.
Un des reproches faits aux réunions de revue du projet, c’est qu’elles durent trop longtemps. Certaines
de ces réunions durent deux heures ou plus. La durée de ces réunions tient du fait qu’on utilise le
temps pour résoudre des problèmes qui ne concernent que quelques-uns des participants. La meilleure
manière de réduire la durée d’une réunion de revue du projet qui prend trop de temps est tout
simplement de réduire le temps qui est alloué à ce genre de problèmes. Par exemple, si vous consacrez
deux heures par semaine aux réunions de revue du projet et que vous constatez que vous n’arrivez pas
298
à traiter tous les points de l’ordre du jour, essayez de réduire la durée des réunions à 90 ou 60 minutes.
Maintenez un temps de réunion court, avec un ordre du jour serré, afin d’être plus efficace. Procédez
aux discussions prolongées en dehors des réunions, ou tenez-les dans le cadre de réunions séparées,
centrées sur ces problèmes particuliers avec les personnes les plus concernées.
Utilisez des rapports standardisés (6.2. P3)
Évitez de créer des rapports particuliers pour chaque personne qui a besoin d'informations. La plupart
des personnes ont seulement besoin d’un ensemble standard d'informations qui peut être communiqué
dans un rapport standard d’avancement. Si un besoin d'informations supplémentaires intervient en
dehors du rapport standard, créez un autre rapport standard pour fournir ces informations. Par
exemple, vous pourriez avoir un rapport d'avancement détaillé à fréquence hebdomadaire et un résumé
mensuel du rapport d'avancement. Cependant, quoique vous élaboriez des rapports multiples, tous
devront être basés sur des modèles standard. L’idée directrice est de réduire autant que possible le
nombre de rapports hors du standard. Ceux-ci demandent beaucoup de temps d’élaboration et leur
valeur supplémentaire est marginale du point de vue global du projet.
Demandez à l’équipe de fournir des rapports d'avancement à une fréquence suffisante (6.2.
P4)
La fréquence des rapports d'avancement est basée sur la longueur du projet et la vitesse à laquelle
vous devez réagir. Par exemple, si votre projet dure deux mois et que le chef de projet reçoit de la part
des membres de l’équipe les rapports d'avancement à une fréquence mensuelle, vous n’aurez pas assez
de temps pour réagir si des problèmes apparaissent. Un bon principe de base pourrait être que :
 Pour de petits projets, vous n’ayez pas besoin de rapports d'avancement.
 Une fréquence hebdomadaire semble raisonnable pour un projet de taille moyenne.
 Pour les grands projets, les membres de l’équipe doivent soumettre des rapports chaque
semaine ou toutes les deux semaines.
Cependant, les rapports d'avancement peuvent être plus ou moins fréquents en fonction de la situation
concrète. Par exemple, durant l'exécution de certaines activités particulièrement importantes du chemin
critique, vous pouvez requérir un rapport d'avancement quotidien. Cela peut être le cas à la fin de la
phase de mise en œuvre où différentes activités convergent pour achever le projet.
N’incluez que des informations utiles dans le rapport d'avancement (6.2. P5)
Regardons les réalités en face. Les rapports d'avancement ne sont généralement pas aussi efficaces
qu'ils devraient l’être. Cela vaut autant pour les membres de l’équipe qui soumettent leurs rapports
d'avancement au chef de projet que pour le chef de projet qui en soumet un aux principales parties
prenantes. L’une des principales raisons est le fait que les personnes qui rédigent ces rapports les
299
considèrent comme une corvée et non pas comme une manière de communiquer les informations
utiles. Vous recevez généralement soit des rapports d'avancement très brefs qui n'indiquent rien, soit
un rapport d'avancement qui contient une multitude de détails qui importent peu.
La personne qui rédige les rapports d'avancement doit le faire de telle manière que le lecteur puisse
utiliser les informations qu’ils contiennent pour la prise de décisions. Ces informations doivent avoir de
la valeur. L’auteur du rapport d’avancement doit toujours se demander si toutes les informations
fournies communiquent quelque chose d’important du point de vue du récepteur ou s’il s’agit d’une
perte de temps pour lui.
Généralement, le rapport d'avancement devra se focaliser sur ce qui suit :
 Les activités de l’échéancier qui ont été accomplies
 Les activités de l’échéancier qui auraient dû être accomplies mais qui ne le sont pas
 Les problèmes majeurs rencontrés, leur impact sur le projet et ce qui a été effectué afin de les
résoudre
 Les demandes de modification du contenu
 Les risques nouvellement identifiés
 D’autres commentaires utiles au lecteur
Si vous vous concentrez sur ce type d'informations dans votre rapport d'avancement, vous constaterez
que les informations sont significatives et qu’elles servent à bien gérer le projet et à garder les parties
prenantes informées. Par contre, si vous rapportez des événements triviaux du point de vue du
récepteur, les gens cesseront de vous prêter attention ou bien vous rappelleront à l’ordre.
Utilisez les annexes pour les détails (6.2. P6)
Vous voulez vous concentrer sur des informations significatives dans votre rapport d'avancement. Vous
constatez cependant que certains de vos lecteurs s’intéressent à la vue d’ensemble, tandis que d'autres
s’intéressent aux détails.
Devez-vous créer deux rapports d'avancement ? Vous ne devriez pas en avoir besoin. Une des manières
de satisfaire les deux exigences est de rédiger le rapport d'avancement à un niveau général et d’inclure
plus de détails en annexes. Par exemple, la plupart des lecteurs veulent savoir ce qui a déjà été
accompli et les activités prévues pour la prochaine période. Cependant, votre manager pourrait exiger
l’intégralité de l'échéancier du projet. Pour satisfaire les deux, incluez juste l'échéancier du projet en
annexe. Si vous envoyez les informations par e-mail, envoyer l'échéancier du projet courant comme
document séparé du rapport d’avancement.
Un exemple semblable serait une situation où vous noterez l’accomplissement d’une activité de
formation. Votre client pourrait vouloir connaître les noms des personnes qui ont suivi cette formation.
A nouveau, n'incluez pas ce niveau de détail dans le corps principal du rapport. Incluez plutôt ces
informations en annexe.
Vous devez donner moins de détails, au fur et à mesure que vos rapports s’adressent plus
haut dans la hiérarchie de l’entreprise (6.2. P7)
Si vous créez un plan de management des communications pour votre projet, les besoins de vos parties
prenantes seront analysés formellement. Mais même sans plan formel de management des
communications, gardez toujours le niveau hiérarchique de votre auditoire à l’esprit. Les membres de
l’équipe ont besoin d'informations fortement détaillées et de spécifications précises concernant le travail
à effectuer. En tant que chef de projet, vous avez besoin d'informations qui couvrent tout le projet mais
à un niveau moins détaillé. Votre supérieur hiérarchique précise les informations récapitulées et les
fournit avec moins de détails. Un cadre supérieur a besoin d'informations encore plus condensées. Bien
que votre projet soit l’élément le plus important que vous ayez à l’esprit, pour la direction, il ne s’agit
que d’un élément important parmi d’autres.
300
Dans certaines organisations, ce filtrage fait partie du système de communication. Par exemple, vous
pouvez donner un rapport d'avancement à votre manager. Celui-ci reçoit de votre part le point sur la
situation, aussi bien que des autres personnes qui dépendent de lui. Il les récapitule ensuite, synthétise
les informations et transmet un rapport plus condensé à son propre supérieur. Ce manager procède
alors, à son tour, de la même manière jusqu'à ce que des informations encore plus synthétiques
parviennent au sommet. En fait, si votre projet est sur la bonne voie, il est même possible qu’il ne soit
même pas mentionné au niveau de la direction.
Dans d'autres entreprises, cependant, le rapport d’avancement n’est pas filtré et le chef de projet est
celui qui doit communiquer avec des niveaux multiples de management. Dans ce cas, souvenez-vous
qu’un seul format de rapport ne conviendra pas pour tout. Vous pouvez avoir besoin de modifier le
contenu des communications selon le niveau hiérarchique des récepteurs. Par exemple, vous pouvez
utiliser un rapport d’avancement d'une page pour votre supérieur direct et vos clients principaux en
faisant le point de la situation du projet et sa situation financière. Celui-ci peut être récapitulé en une
demi page pour le niveau hiérarchique supérieur, et peut-être en un paragraphe pour celui qui suit.
Employez les meilleurs médias de communication (6.2. P8)
Quand vous sélectionnez les mesures les plus appropriées de communication pour votre projet,
déterminez également le meilleur moyen de communication. Par exemple :
 Les rapports d'avancement. Ceux-ci ne doivent pas obligatoirement être sous forme de
papier. Selon la personne qui envoie et reçoit les informations, le point sur la situation peut être
communiqué par l'intermédiaire d’une boite vocale, d’un e-mail, par vidéoconférence ou
d'autres outils collaboratifs. Votre entreprise peut avoir une manière standard de livrer l’état de
l’avancement. Si ce n’est pas le cas, sélectionnez une façon pratique des soumettre au
destinataire, sans pour autant compromettre la valeur des informations.
 L’e-mail/le courriel. Employez l'e-mail pour les messages de routine, le partage

d'informations, et quelques messages marketing. Étalez ces derniers de sorte que vous
n’inondiez pas les mêmes personnes sur une courte période.
 La boite vocale. Employez les boites vocales pour laisser des messages simples, pour des
personnes seules ou pour des services entiers. Pour des messages compliqués ou longs, les
boites vocales ne sont pas appropriées.
Ne tirez pas sur le messager qui apporte de mauvaises nouvelles (6.2. P9)
Vous avez tous entendu cette boutade (ou quelque chose de semblable). Cela signifie que vous ne
devez pas réprimander la personne qui apporte les mauvaises nouvelles. Si vous demandez le point sur
la situation à une personne, acceptez-le, qu’il soit bon ou mauvais. Il vous permettra tout de même de
prendre de meilleures décisions. Si vous voulez que les gens vous informent lorsqu’il y a des problèmes,
vous devez accepter les informations et travailler avec l'équipe sur les causes et les solutions. (Si tout
va bien, le membre de l’équipe proposera des solutions au problème.)
Tous les chefs de projet doivent prendre ce message à cœur. Vous voulez apprendre les mauvaises
nouvelles aussi rapidement que possible de façon à y répondre rapidement. Les problèmes majeurs et
les risques qui sont identifiés tôt vous donnent beaucoup plus de flexibilité pour y répondre. Vous en
aurez beaucoup moins si vous êtes informé à la dernière minute. Cependant, si une personne vous
apporte de mauvaises nouvelles et que vous répondez de façon négative, il sera beaucoup plus difficile
pour les autres messagers de vous faire part dans le futur de mauvaises nouvelles.
Utilisez les indicateurs Vert / Jaune / Rouge pour représenter l’état de santé global du projet
(6.2. P10)
Une bonne technique pour fournir un résumé global d'un projet est d’inclure un système d’indicateurs
multicolore Vert / Jaune / Rouge. Comme vous vous en doutez, un indicateur vert signifie que le projet
est fondamentalement sur la bonne voie. Cependant cela ne veut pas dire qu'il n'y a aucun problème.
Cela signifie que tous les problèmes sont identifiés et que le projet est dans les délais et reste dans les
301
limites du budget.
Un indicateur jaune signifie qu'il y a un certain risque que le projet ne respecte pas son budget ou sa
date limite. L'indicateur jaune permet de gérer les attentes et d’informer les gens que le projet présente
un certain risque.
Si votre projet a un indicateur rouge, vous annoncez que vous avez certainement des ennuis, et que
vous aurez besoin de compromis sur le budget, sur la date limite et / ou sur la qualité.
La valeur réelle de cet indicateur est significative lorsque le point sur la situation du projet est résumé
pour un niveau hiérarchique supérieur. Si les hauts dirigeants ont une page récapitulative de tous les
projets, avec des indicateurs Vert / Jaune / Rouge, ils peuvent facilement s’informer sur le point de la
situation globale de tous les projets. S'ils gèrent en fonction des attentes, ils se concentreront
immédiatement sur les projets qui sont dans le rouge et le jaune.
Communiquer de manière proactive pour gérer les attentes (6.2. P11)
Le management des communications est véritablement une histoire de gestion des attentes. Les
rapports d'avancement, par exemple, sont une manière de communiquer aux parties prenantes la façon
dont le projet progresse par rapport à l’échéancier au budget. Vous incluez les informations sur les
problèmes majeurs, les modifications du contenu, les risques, etc., comme faisant partie des
informations nécessaires à la gestion des attentes. Des informations supplémentaires sur la façon de
gérer les attentes du client sont fournies en détail au paragraphe 6.1.1.1 Gérer les attentes des parties
prenantes.
Inscrire les événements de communication dans l’échéancier (6.2. P12)
Le chef de projet devrait traiter les événements de communication comme n'importe quel produit
livrable du projet. Il faut que vous ajoutiez les activités de communication à l'échéancier du projet et
que vous y affectiez le personnel et des délais, de telle sorte que l'équipe prenne connaissance quand
une mesure de communication est prévue et qui en a la charge.
L’échéancier de votre projet doit inclure les échéances des rapports d'avancement pour les parties
prenantes, ainsi que ceux que vous attendez de la part de votre personnel. L’échéancier doit aussi
comprendre toutes les réunions de revue du projet, les réunions avec le commanditaire, les réunions du
comité de pilotage et d’autres réunions prévues. De même, si vous créez d'autres items tels qu'une
Lettre d'information, ajoutez à l’échéancier les activités requises, quand les données d’entrée devront
être livrées et quand le bulletin sera édité. Si vous n'êtes pas très précis sur vos attentes et les dates de
livraison, vous vous apercevrez que les dates de ces activités de communication commenceront à
glisser. Par exemple, vous découvrirez que votre newsletter trimestrielle est distribuée six semaines
trop tard et devriez alors sauter la suivante, car elle sera trop proche de la précédente.
Utiliser les techniques d’attribution et de développement systématique d’une marque pour le

projet afin de faciliter les processus de changement culturel (6.2. P13)
La plupart des projets n’ont pas à se préoccuper de développer une marque. Leur contenu est limité à
un petit ensemble de personnes et l'impact du projet sur l'entreprise est modeste. Cependant, certains
projets affecteront l’intégralité de l'organisation ou de l’entreprise, et pourront prendre des années pour
être exécutés totalement. C’est pour ce type de projets qu’il est utile d'établir une image positive et de
s’efforcer d’associer de bons sentiments. Ce sont des projets candidats à l’attribution d’une marque.
Voyez le paragraphe 6.1.3.3 Construire une marque pour un projet, pour plus d'informations.
Gérer les documents (6.2. P14)
Pour plus d'information sur la gestion des documents, veuillez voir 6.2.1 Gérer la documentation /
Techniques.
302
6.2.1 Gérer la documentation / Techniques
Utilisez la technologie de gestion des documents comme base de votre processus (6.2.1. P1)
Une grande partie du processus de gestion des documents est influencée par la technologie de gestion
des documents utilisée par le projet. Par exemple, un logiciel de gestion des documents est
habituellement fourni avec une structure logique standard. Vous devez simplement entrer vos noms
spécifiques pour la mettre en activité. Le logiciel peut également imposer un système de contrôle de
version et être doté de fonctionnalités pour gérer les autorisations de mises à jour. L'outil peut
également décrire les méta données requises pour les mots-clés et l’indexation.
Stocker les documents concernant le produit du projet ainsi que le management du projet
dans le dépôt de documents (6.2.1. P2)
Le dépôt de documents inclut tous les livrables du projet, y compris ceux reliés au produit livrable et à
la gestion du projet. Par exemple, le dépôt contiendra la charte du projet et l'échéancier du projet (qui
sont des « livrables de management de projet »), aussi bien que le document de conception et le plan
des tests (qui sont des « livrables du projet »). Quand vous commencez à considérer votre processus
de gestion des documents, tous les documents que votre projet génère doivent être pris en compte.
Transférer les documents là où il faut, après le projet (6.2.1. P3)
Une fois le projet accompli, une partie des documents doivent être archivés, alors que d'autres doivent
être maintenus indéfiniment. Par exemple, des rapports d'avancement du projet peuvent être archivés
(ou évacués) une fois le projet accompli, puisqu'ils correspondent à une période donnée et ont une
valeur limitée, une fois le projet accompli. D'autre part, vous devez sauvegarder un manuel utilisateur,
une fois le projet accompli. Ces documents sauvegardés peuvent continuer à être mis à jour dans le
dépôt de documents si celui-ci est à la disposition de toute l'entreprise. Autrement, ces documents à
long terme devront être déplacés dans le dépôt de documents utilisé par l’équipe de support.
Certaines entreprises maintiennent un dépôt central pour le stockage de livrables majeurs susceptibles
d’être réutilisés. Par exemple, le cahier des charges créé pour votre projet pourra être réutilisé sur un
autre projet touchant le même secteur d'activité. La stratégie des tests pourra, quand à elle, être
réutilisée sur d’autres projets nécessitant des tests semblables. Une fois votre projet terminé, et si
l'entreprise dispose d’un dépôt où les documents peuvent être placés et sauvegardés, le chef de projet
et le responsable du dépôt doivent examiner quelles informations sont susceptibles d’être réutilisées
pour de futurs projets. Cet examen fait partie des activités de clôture du projet.
Donner à chaque membre de l’équipe sa propre zone de travail (6.2.1. P4)
Habituellement, le dépôt de documents ne contient pas les documents qui font l’objet d’un travail en
cours (cela dépend également du logiciel employé pour la gestion des documents). Chaque membre de
l’équipe devra avoir une zone de travail où il pourra stocker des versions des documents qui sont en
cours, mais pas encore en circulation. Il peut s’agir d’un dossier particulier, auquel chaque membre de
l’équipe a un libre accès. Chaque membre de l’équipe peut structurer sa zone de travail de la façon qui
lui semble la plus raisonnable.
Protéger l'intégrité de votre dépôt de documents (6.2.1. P5)
Les grands projets peuvent générer beaucoup de documents. Pour ces types de projets, l'équipe a
besoin de créer un dépôt de documents. Ce dépôt peut être géré à l'aide de logiciels, ou bien vous
pourrez avoir une simple structure de dossier/ classeur sur un répertoire partagé.
Si vous allez créer un dépôt vous devriez établir certains règles et processus pour protéger l'intégrité
des documents stockées. Par exemple, tous les membres de votre équipe ont souvent besoin d'un
accès total à chacun de leurs propres documents qu'ils ont créé. Cependant, vous avez besoin de
303
décider si un membre de l'équipe puisse effectuer la mise à jour des documents créés par d'autres
membres de l'équipe. Dans certains projets ceci pourrait être parfaitement acceptable, alors que dans
d'autres projets ceci pourrait être considéré comme une entorse à la sécurité.
Vous devriez aussi décider si quelqu'un de l'équipe pourrait ajouter des documents dans votre dépôt,
ou si le processus de mise à jour va être détenu par une personne remplissant le rôle d'un
bibliothécaire. Votre première pensée pourrait être que le fait d'avoir un rôle central de bibliothécaire
pour contrôler les mises à jour du dépôt des documents est un exercice dans la bureaucratie.
Cependant, tenez compte du moment où ce rôle pourrait être d'une grande utilité. Si vous avez un
grand volume de documentation, il est important que les documents ajoutés au dépôt reflètent une
qualité consistante et de haut niveau. La qualité du dépôt pourrait dégrader si tout le monde dispose de
la capacité d'ajouter, de supprimer et de modifier les documents dans tous les endroits. Au lieu de ça,
un bibliothécaire peut contrôler le processus d'ajouter des documents.
Le bibliothécaire est aussi responsable de la mise à jour du dépôt de documents. L'élimination des
documents anciens assure la pertinence des informations dans le dépôt. Par exemple, les rapports
d'avancement hebdomadaires pourraient ne plus être nécessaires après trois mois. D'autre part, le
document de la charte du projet est nécessaire durant tout le cycle de vie de ce dernier, même s'il date
de 12 mois. De temps en temps, le bibliothécaire peut retirer du dépôt les documents qui ne sont plus
pertinents et les archiver ailleurs.
304
6.3 Gérer les communications / Références rapides
Livrables (6.3. P1)
ayant une licence.)
 Formulaire de demande de modification du contenu
 Journal des modifications du contenu
 Rapport individuel d’avancement
 Rapport d’avancement du projet
 Rapport d’avancement du projet II
 Rapport d’avancement du projet III
 Rapport d’avancement aux jalons de l’échéancier
 Plan de management des communications
 Journal des débats de réunions
 Tableau des réunions
 Table des matières de la documentation
 Notes de service du projet
 Liste de contrôle de la documentation du projet
 Modèle de maîtrise des versions
Créer les rapports

Hebdomadaire ou toutes les deux semaines. Les
individuels
1 heure membres de l’équipe envoient leur rapport
d'avancement
individuel d’avancement au chef de projet.
(facultatif)
Petits
projets Créer le rapport Toutes les deux semaines ou mensuellement. Le
d'avancement du 1-2 heures chef de projet envoie le rapport d’avancement du
projet projet aux parties prenantes.
Assister aux réunions

de revue du projet 1 heure Hebdomadaire ou toutes les deux semaines.
de l’équipe

Projets
moyens Créer les rapports 1 heure Hebdomadaire ou toutes les deux semaines. Les
individuels membres de l’équipe envoient leur rapport
305
d'avancement individuel d’avancement au chef de projet.
Créer le rapport Toutes les deux semaines ou mensuellement. Le


de revue du projet de 1 heure Hebdomadaire ou toutes les deux semaines.
l'équipe

Hebdomadaire ou toutes les deux semaines. Cette
de revue du projet
1 heure réunion est prévue si les clients n'assistent pas aux
avec le client
réunions de l'équipe du projet.
(facultatif)
Créer les rapports Hebdomadaire ou toutes les deux semaines. Les

individuels 1 heure membres de l’équipe envoient leur rapport
d'avancement individuel d’avancement au chef de projet.
Créer le rapport Toutes les deux semaines ou mensuellement. Le


de revue du projet de 1 heure Hebdomadaire ou toutes les deux semaines.
l’équipe

Hebdomadaire ou toutes les deux semaines. Cette
de revue du projet
1 heure réunion est prévue si les clients n'assistent pas aux
avec le client
Grands réunions de revue du projet de l'équipe.
(facultatif)
projets
Pour chaque événement ou d’autres livrables
prévus dans le plan de communication, ajoutez à
l'échéancier les activités nécessaires à son
Exécuter les activités élaboration. Ceci doit inclure l’affectation de
du plan de ouvert personnes aux tâches en question, l’indication des
communication dates de début et de fin, etc. Cela permet au chef
de projet de s’assurer que les activités prévues
dans le plan de communication seront vraiment
effectuées.
Le responsable du dépôt doit effectuer les activités

requises à un rythme hebdomadaire pour s’assurer
Exécuter les activités
de l’intégrité du dépôt de documents et que les
de gestion de la ouvert
membres de l’équipe suivent les procédures de
documentation
gestion de la documentation dans leur travail pour
le projet.
306
______________________________________________________________________
Processus 7
Gérer les risques
307
7.0 Gérer les risques
Les risques renvoient aux conditions ou

circonstances futures, qui se situent en
dehors du contrôle de l’équipe de projet,
et qui auront un impact défavorable sur
celui-ci si elles se produisent. En d'autres
termes, alors qu'un problème majeur est
un gros problème qui survient et qui doit
être traité, un risque est un futur
problème potentiel qui ne s’est pas encore
produit.
Un chef de projet réactif tente de
résoudre les problèmes au fur et à mesure
qu’ils se produisent. Un chef de projet
proactif tente de résoudre les problèmes
potentiels avant qu'ils ne se produisent.
C'est tout l’art de la gestion des risques.
Tous les problèmes majeurs ne peuvent être détectés à l’avance, et certains problèmes potentiels peu
susceptibles de se produire, peuvent en fait se produire. Cependant, beaucoup de problèmes peuvent
être détectés à l’avance, et devraient être gérés par un processus proactif de gestion des risques.

Tout dans la vie présente un certain degré de risque. Marcher dans la rue peut être risqué. Vos projets
aussi présentent des risques. Le chef de projet devra réaliser une évaluation des risques avec l’équipe
de projet et le client pour identifier les niveaux de risques : élevé, moyen et faible. Si vous avez de la
chance, vous constaterez que vous avez seulement des risques minimes. Cet exercice préparera le
client et l’équipe de projet à l’éventualité de n'importe quel risque ( qu’il soit moyen ou élevé ),
susceptible de poser des problèmes à l’avenir.
Identifier les risques que court votre projet n’est pas nécessairement mauvais, puisque les risques sont
communs à tous les projets. En effet, tous les projets ont un certain degré de risque. D’une manière
générale, les projets ayant un haut niveau de risque exigent plus de rigueur au niveau de la gestion des
risques, et doivent accorder l’intérêt le plus fort à leur gestion générale. Bien qu'on ne puisse pas
éliminer entièrement tous les risques, beaucoup peuvent être prévus et gérés à l’avance.
Le but du management des risques est d'identifier quels risques peuvent survenir au cours d’un projet,
puis d’établir un plan de gestion de ces risques, afin de réduire le tort au projet. Dans la méthodologie
TenStep, la première évaluation des risques se fait lors du processus 1.0 Définir le travail. D’autres
tours complémentaires d’identification de risques devront se poursuivre tout au long du projet, de
manière planifiée (ces évaluations des risques peuvent être mensuelles ou trimestrielles, ou chaque fois
308
qu’un jalon important est atteint).
7.1 Gérer les risques / Processus
7.2 Gérer les risques / Techniques
7.3 Gérer les risques / Références rapides
309
7.1 Gérer les risques / Processus
(7.1. P1)
Les processus utilisés pour gérer les risques sont décrits dans cette partie. Ils peuvent être modifiés si
nécessaire pour s’adapter à votre projet, puis insérés dans le Plan de Management du Projet créé
durant le processus 1.0 Définir le travail. Avant que vous commencez, il serait intéressant d'avoir une
définition plus précise des risques et des comparer aux hypothèses. Voir 7.1.2.2 Hypothèses et Risques
pour cette vue d’ensemble.
Les petits projets (7.1. P2)
Les petits projets ne présentent habituellement pas beaucoup de risques. Rappelez-vous que les risques
impliquent des problèmes qui peuvent se produire dans le futur. Puisque les petits projets n’ont
habituellement pas une longue durée, il y a donc peu d’occasions de voir surgir des problèmes. Si le
chef de projet effectue une analyse des risques dans un petit projet et qu’il en découvre quelques-uns,
il peut les traiter au moyen des procédures de gestion des risques correspondant aux projets de taille
moyenne.
7.1.1 Projets moyens
310
7.1.1 Gérer les risques / Projets de taille moyenne
Au début du projet (7.1.1. P1)
Le processus suivant est utilisé pour le management des risques des projets de taille moyenne.
Rôle Gérer les risques (Projets moyens)
1 Chef de Identifier tous les risques potentiels

projet
Au cours de la définition du projet, effectuez une évaluation complète des
risques. L’évaluation des risques se divise en deux parties. Considérez d’abord
les risques inhérents à votre projet. Ce sont des risques déterminés en fonction
de ses caractéristiques. Par exemple, un projet dont l'effort de travail est
estimé à 10.000 heures est, par nature, plus risqué qu’un autre qui durera
1.000 heures. Un projet avec 20 personnes est plus risqué qu’un projet
impliquant 3 personnes. Un projet qui utilise une nouvelle technologie est par
essence plus risqué qu’un projet qui en utilise une que votre équipe maîtrise
bien. Notez que dans les exemples précédents, vous ne connaissez pas encore
les spécificités du projet. Les risques inhérents sont basés sur les
caractéristiques du projet, quel que soit le produit livrable réalisé. Comme ils
s’appliquent à tous les projets, ces risques inhérents peuvent être compilés
dans une check-list. Voir la partie 7.2.1 Facteurs de risques inhérents, pour plus
d’aide et d’exemples permettant de définir ces risques.
Ensuite, évaluez les risques spécifiques à votre projet. Ces risques ne sont
normalement pas identifiés sur une check-list, dans la mesure où ils
s’appliquent uniquement à votre projet et peuvent ne pas s’appliquer à
d’autres. Par exemple, vous pouvez identifier un risque provenant d’un
fournisseur clé qui peut faire faillite, ou peut-être un problème de météo qui
entraîne des retards de livraison, ou peut-être aurez-vous des problèmes pour
trouver du personnel avec les qualifications spécifiques requises.
Il existe plusieurs manières d’évaluer les risques. Le chef de projet peut créer
une ébauche initiale de la liste des risques du projet basée sur ce qu’il sait, et la
faire circuler pour d’éventuels rajouts, changements ou commentaires. Une
autre technique est de rassembler toutes les parties prenantes principales pour
discuter, une bonne fois, des risques potentiels du projet. Cette alternative est
meilleure que la première dans la mesure où elle engage toutes les parties
prenantes à réfléchir en une seule séance. Vous avez plus de chances d’aboutir
à une liste plus exhaustive de risques réels pour votre projet. Ne soyez pas trop
optimiste, tout de même, lors de cette évaluation. Souvenez-vous que vous
essayez d’identifier des risques potentiels. Il est bon d’avoir des personnes
sceptiques et pessimistes lors de ces sessions, pour s’assurer que tous les
risques potentiels soient identifiés.
2 Chef de Analyser les risques grâce à des techniques qualitatives

projet
Au cours de la première étape de ce processus, vous avez identifié tous les
risques potentiels. Vous allez vous retrouver avec beaucoup plus de risques que
vous ne pouvez en traiter. En fait, cela ne vaut probablement pas la peine de
vous occuper de risques qui n’ont qu’un faible impact sur votre projet.
Cependant, avant de vous préoccuper de mettre des plans de risques en place,
vous devez déterminer sur quels risques vous voulez vraiment concentrer votre
attention. La première étape de l’analyse des risques est l’analyse qualitative.
Voir 7.1.1.1 pour plus d’informations sur l’analyse qualitative des risques.
311
3 Chef de Préparer une réponse pour chaque risque de criticité élevée
projet
Vous devez, en premier lieu, vous préoccuper de trouver des réponses pour
tous les risques de criticité forte, pour vous assurer que les risques seront gérés
avec succès. Votre plan doit comporter des activités destinées à gérer les
risques, l’affectation de ressources pour réaliser ces activités, de même que les
dates d’achèvement de ces dernières et celles des contrôles périodiques des
progrès accomplis. Il y a cinq réponses essentielles à un risque : l’abandonner,
le surveiller, l’éviter, le transmettre à un tiers ou l’atténuer. Pour de plus amples
informations, voir 7.2 Gérer les risques / Techniques.
4 Chef de Évaluer les risques de criticité moyenne

projet
Passez en revue tous les risques de criticité moyenne pour savoir si leur impact
pourrait être suffisamment sévère pour qu’un plan de réponse soit aussi mis en
place pour les contrer.
5 Chef de Évaluer tous les risques de criticité faible

projet
Il reste maintenant à évaluer les éléments représentant un risque de criticité
faible pour voir s’il faut les considérer comme des hypothèses. Dans ce cas,
bien que vous reconnaissiez l’existence d’un problème potentiel provenant de
ces risques, vous inscrivez sur la liste des hypothèses de la définition du projet
l’hypothèse que ces circonstances ne surviendront pas. Voir 7.1.2.2 Hypothèses
et Risques, pour plus d’informations.
6 Chef de Transférer les activités du plan de risques dans l’échéancier du projet

projet
Transférez les activités liées aux plans de gestion des risques dans l’échéancier
du projet. Vous allez aussi ajouter les personnes affectées, les heures d'effort,
les dates de début, etc. Ce transfert vous permet de vous assurer que le travail
sera vraiment réalisé, tout en gardant l’échéancier comme centre d’intérêt de
tout travail de planification et de contrôle.
Surveillance et maîtrise des risques (7.1.1. P2)
7 Chef de Surveiller les plans de risques qui ont été mis en œuvre
projet
Le chef de projet doit surveiller le plan de gestion des risques pour vérifier si les
risques sont gérés avec succès. De nouvelles activités devraient être ajoutées,
s’il semble qu’un risque n’est pas géré efficacement.
8 Chef de Chercher de nouveaux risques

projet
Le chef de projet doit évaluer périodiquement les risques durant tout le projet
et en toutes circonstances. De nouveaux risques peuvent apparaître au cours
du projet et des risques qui n’ont pas été identifiés auparavant deviendront
visibles ultérieurement. Il est également possible que les risques identifiés
précédemment comme faibles (hypothèses) deviennent plus tard moyens ou
grands. Cette évaluation en cours de projet doit être effectuée régulièrement
ou lorsqu’un jalon important est atteint..
312
7.1.1.1 Analyse quantitative des risques
(7.1.1.1. P1)
Cette analyse des risques est dite « qualitative » parce qu’il s’agit d’une approximation rapide réalisée
sans recourir à une analyse numérique profonde. La criticité du risque peut être élevée, moyenne ou
basse, selon la sévérité de l'impact et la probabilité d’occurrence de l'événement.
Il existe plusieurs techniques pour effectuer des analyses qualitatives de risque. Trois exemples sont
présentés dans cette section, mais il y a aussi d’autres techniques.
Table des niveaux : élevé, moyen et faible (7.1.1.1. P2)
Employez la table suivante comme point de départ. Elle permet de distinguer les risques de niveau
élevé, moyen ou faible, en se basant sur la probabilité d’occurrence du risque et son impact global sur
votre projet. Par exemple, une probabilité importante de voir arriver un événement ayant un fort
impact, représente évidemment un gros risque. De même, un risque ayant un impact limité et une
faible possibilité d’occurrence est, de toute évidence, un risque faible. Les autres possibilités trouvent
leur place entre ces deux extrêmes. Cependant, chaque événement doit être évalué individuellement. Si
vous avez, par exemple, un événement qui présente une faible probabilité de se produire, mais dont
l'impact, s'il se produisait, serait dévastateur (quelqu'un pourrait, par exemple, être tué), vous le
considérerez néanmoins comme un gros risque et le placerez en conséquence dans le plan de risques.
Le degré de criticité du risque résulte de la formule Criticité =

impact x probabilité
Criticité
L’impact du risque sur le projet
L’occurrence du risque est
serait
Très négatif Très probable Haute
Très négatif Moyennement probable Haute
Très négatif Peu probable Moyenne / Faible
Moyennement négatif Très probable Moyenne
Moyennement négatif Moyennement probable Moyenne / Faible
Moyennement négatif Peu probable Faible
Faiblement négatif Très probable Faible
Faiblement négatif Moyennement probable Faible
Faiblement négatif Peu probable Faible
Charte multicolore pour les niveaux de criticité du risque (élevé, moyen et faible) combinés
avec un exemple de l’approche pour chaque niveau (7.1.1.1. P3)
Vous pouvez aussi représenter ces neufs niveaux de criticité des risques avec le tableau suivant:
Probabilité
Faible Moyenne Élevée
Impact
313
Faible Ignorer Ignorer Alerte
Moyen Ignorer Alerte Réponse
Grand Alerte Réponse Réponse
Les cases vertes représentent une combinaison de probabilités et d’impact que vous pouvez ignorer
sans risque. Les cases rouges représentent une combinaison qui doit être gérée. Les cases jaunes
représentent des combinaisons qui devraient être évaluées plus en détail et cas par cas.
Tableau des probabilités d’occurrence des risques (7.1.1.1. P4)
Vous pouvez obtenir plus de précision en augmentant le nombre d'options disponibles pour la
probabilité du risque. Par exemple, vous pourriez créer une échelle sur cinq niveaux pour la probabilité
des risques, comme dans le tableau suivant.
Probabilité Impact faible Impact moyen Impact important
Très peu probable (<10%) Risque faible Risque faible Risque faible
Peu probable (<35%) Risque faible Risque faible Risque moyen
Pourrait ou non se produire Risque faible Risque moyen Risque moyen / Grand
(35% - 65%)
Probable (>65%) Risque faible Risque moyen / Grand Gros risque
Fortement probable (>90%) Risque faible Risque moyen / Grand Gros risque
Au lieu de l’échelle élémentaire : impact faible, moyen ou important, vous pourriez en utiliser une plus
affinée. Par exemple, vous pourriez encore développer une échelle à cinq niveaux, comme ci-dessous
(cette échelle s'applique à chaque risque):
1. un impact faible (ou inexistant), en termes de coûts et de délais
2. un impact potentiel de l’ordre de 2% à 4% pour le budget ou les délais
5. un impact potentiel important de l’ordre de 10% pour le budget ou les délais
Après avoir créé une échelle comme celle-ci, vous aurez encore besoin de déterminer de quelle manière
vous allez analyser l’information. Par exemple, vous pouvez décider d’ignorer une échelle de niveau 1
ou 2. En revanche, une échelle de niveau 4 ou 5 devra être gérée. Le niveau 3 représente un risque qui
devra être évalué cas par cas.
314
7.1.2. Gérer les risques / Grands projets
(7.1.2. P1)
Le processus de gestion des risques pour des grands projets est le même que pour les projets moyens
avec, cependant, deux éléments supplémentaires. La première option consiste à utiliser des techniques
quantitatives d'analyse des risques (en plus des techniques qualitatives). En second lieu, il faut créer un
plan de contingence pour documenter les conséquences sur le projet, si jamais le plan de risque échoue
et que le risque se produit réellement.
Au début du projet
Planifier le management des risques (7.1.2. P2)
Rôle Gérer les risques (Grands Projets)
1 Chef de projet Elaborer un plan de gestion des risques

Commencez votre processus de gestion des risques en concevant une approche
globale pour la gestion des risques. Cela inclut la définition de votre processus
de gestion des risques, la désignation des personnes concernées par ce
processus, quels moyens seront utilisés, quelles fonctions seront touchées, le
cas échéant (chef de projet, fonctionnaire chargé des risques, gestionnaire des
risques, etc.), la durée et l’effort liés à la gestion des risques, les techniques qui
seront utilisées, etc. Vous pouvez trouver plus d'informations dans 7.1.2.1 Créer
le plan de gestion des risques.
Identifier les risques (7.1.2. P3)
2 Chef de projet Identifier tous les risques potentiels

Au cours de la définition du projet, effectuez une évaluation complète des
risques. L’évaluation des risques se divise en deux parties. Considérez d’abord
les risques inhérents. Ce sont les risques qui sont classés en fonction de ses
caractéristiques. Par exemple, un projet dont l'effort de travail est estimé à
10.000 heures est, par nature, plus risqué qu’un autre qui durera 1.000
heures. Un projet avec 20 personnes est plus risqué qu’un projet avec 3
personnes. Un projet qui utilise une nouvelle technologie est par essence, plus
risqué qu’un projet qui en utilise une que votre équipe maîtrise bien. Notez que
dans les exemples précédents, vous ne connaissez pas encore les spécificités
du projet. Les risques inhérents sont basés sur les caractéristiques du projet,
quel que soit le produit livrable réalisé. Comme ils s’appliquent à tous les
projets, les risques en question peuvent être compilés dans une check-list. Voir
la partie 7.2.1 Facteurs de risques inhérents, pour plus d’aide et d’exemples
permettant de définir ces risques.
Ensuite, évaluez les risques spécifiques à votre projet. Ces risques ne sont
normalement pas identifiés sur une check-list, dans la mesure où ils
s’appliquent uniquement à votre projet et peuvent ne pas s’appliquer à
d’autres. Par exemple, vous pouvez identifier un risque provenant d’un
fournisseur clé qui peut faire faillite, ou peut-être un problème de météo qui
entraîne des retards de livraison, ou peut-être aurez-vous des problèmes pour
trouver du personnel avec les qualifications spécifiques requises.
315
Il y a plusieurs manières d’évaluer les risques. Le chef de projet peut créer une
ébauche initiale de la liste des risques du projet, basée sur ce qu’il sait, et la
faire circuler pour d’éventuels rajouts, changements ou commentaires. Une
autre technique consiste à de rassembler les principales parties prenantes pour
discuter, une fois pour toutes, des risques potentiels du projet. Cette
alternative est meilleure que la première dans la mesure où elle engage toutes
les parties prenantes à réfléchir au cours d’une seule séance. Vous avez plus
de chances d’aboutir à une liste plus exhaustive de risques réels pour votre
projet. Ne soyez pas trop optimiste, tout de même, lors de cette évaluation.
Souvenez-vous que vous essayez d’identifier des risques potentiels. Il est bon
d’avoir des personnes sceptiques et pessimistes lors de ces sessions, pour
s’assurer que tous les risques potentiels sont identifiés.
Mettre en œuvre l’analyse qualitative des risques (7.1.2. P4)
3 Chef de projet Analyser les risques au moyen des techniques qualitatives

Au cours de la première étape de ce processus, vous avez identifié tous les
risques potentiels. Vous allez vous retrouver avec beaucoup plus de risques
que vous ne pouvez en traiter. En fait, cela ne vaut probablement pas la peine
de vous occuper de risques qui n’ont qu’un faible impact sur votre projet.
Cependant, avant de vous préoccuper de mettre des plans de risques en place,
vous devez déterminer sur quels risques vous voulez vraiment concentrer votre
attention. La première étape de l’analyse des risques est l’analyse qualitative.
Voir 7.1.1.1 pour plus d’informations sur l’analyse qualitative des risques.
Mettre en œuvre l'analyse quantitative des risques (7.1.2. P5)
4 Chef de projet (Facultatif) Utiliser l’analyse quantitative pour tous les risques de
criticité élevée
Ensuite, vous déciderez si vous allez utiliser des techniques quantitatives de
risque plus formelles et rigoureuses pour analyser les risques que vous avez
identifiés comme étant de criticité élevée. Le terme « quantitatif » signifie que
les niveaux de risque sont établis à partir d’une analyse numérique plutôt que
sur des approximations telles que : faible, moyen et élevé. Il y a une multitude
de modèles et d’algorithmes qui se prêtent à l’analyse quantitative des risques.
La plupart des projets, même les grands, n’ont pas besoin de techniques
quantitatives. Cependant, il y a quelques projets qui ont besoin de ces
techniques formelles. Si, par exemple, vous étiez en train de construire un
avion, il ne suffirait pas de classer les risques en utilisant les catégories
générales élevé, moyen et faible, provenant des techniques qualitatives de
nature informelle. Vous devriez certainement recourir aux techniques plus
sophistiquées de la modélisation et de l’analyse statistique des risques qui font
partie de l’analyse quantitative des risques.
Quelques exemples d’analyse quantitative sont décrits dans le paragraphe 7.2.2
Valeur monétaire attendue, et 2.2.1. P6 Utilisez la modélisation de Monte Carlo
pour déterminer les risques de planification.
Planifier les réponses aux risques (7.1.2. P6)
5 Chef de projet Créez un plan de réponse pour chaque risque de criticité élevée
316
Créez des plans réponses pour tous les risques de haute criticité que vous
avez identifiés, pour vous assurer que les risques seront gérés avec succès.
Votre plan doit comporter des activités destinées à gérer les risques,
l’affectation de personnel pour réaliser ces activités, de même que les dates
d’achèvement de ces dernières et les dates périodiques de contrôle des
progrès accomplis. Il y a cinq réponses essentielles à un risque : l’abandonner,
le surveiller, l’éviter, le transmettre à un tiers ou l’atténuer. Pour de plus
amples informations, voir 7.2. Gérer les risques / Techniques.
6 Chef de projet Créez un plan de contingence pour les risques de criticité élevée
Créez un plan de contingence pour documenter les conséquences sur le projet
si jamais le plan de risque échoue et que le risque se produit réellement. En
d'autres termes, identifiez ce qui arriverait au projet si le futur risque devenait
un problème majeur réel. Cette démarche permet au chef de projet de
s'assurer que l'effort de travail lié au plan de gestion des risques est
proportionnel aux conséquences potentielles. Par exemple, si la conséquence
de l’occurrence potentielle d’un risque est l’annulation du projet, on aura une
indication forte que le plan de gestion des risques doit être agressif et complet
pour s'assurer que le risque sera géré avec efficacité.
7 Chef de projet Evaluer les risques de criticité moyenne

Évaluez les risques de criticité moyenne pour déterminer si leur impact est
suffisamment grave pour justifier la création d’un plan pour y faire face.
8 Chef de projet Evaluer tous les risques de faible criticité

Evaluez les éléments représentant un risque de criticité faible pour voir s’il faut
les considérer comme des hypothèses. Dans ce cas, bien que vous
reconnaissiez l’existence d’un problème potentiel provenant de ces risques,
vous inscrivez sur la liste des hypothèses de la définition du projet l’hypothèse
que ces circonstances ne surviendront pas. Voir 7.1.2.2 Hypothèses et risques,
pour plus d’informations.
9 Chef de projet Transférer les activités du plan de risques dans l’échéancier du

projet
Transférez les activités liées aux Plans de gestion des risques dans
l’échéancier du projet. Cela inclue les activités pour gérer les risques, ainsi que
les personnes affectées, les dates de début et celles de l'achèvement etc. Ce
transfert vous permet de vous assurer que le travail sera vraiment achevé,
tout en gardant l’échéancier comme centre d’intérêt de tout travail de
planification et de contrôle.
Surveiller et maîtriser les risques (7.1.2. P7)
10 Chef de projet Surveiller les plans de risques qui ont été mis en œuvre
Le chef de projet doit surveiller le plan de gestion des risques pour vérifier si
les risques sont gérés avec succès. De nouvelles activités doivent être
ajoutées s’il apparaît qu’un risque n’est pas géré efficacement.
11 Chef de projet Chercher de nouveaux risques

Le chef de projet doit aussi évaluer périodiquement les risques durant tout le
317
projet et en toutes circonstances. De nouveaux risques peuvent apparaître au
cours du projet et des risques qui n’ont pas été identifiés auparavant
deviennent visibles ultérieurement. Il est également possible que la criticité de
certains risques, originalement considérée comme faible, devienne plus élevée
quelque temps plus tard. Cette évaluation en cours de projet doit être
effectuée régulièrement ou lorsqu’un jalon important est atteint.
318
7.1.2.1 Créer le plan de gestion des risques
Le Plan de Gestion des Risques décrit comment vous allez définir et gérer les risques du Projet. Ce
document ne décrit pas les risques et les réponses eux mêmes mais les processus et techniques à
suivre pour définir les risques et déterminer les réponses. Le plan de gestion des risques doit
comprendre les informations suivantes:
 Les rôles et les responsabilités. Cette section décrit les rôles de dirigeant et de support
pour les différents processus de gestion des risques. La gestion des risques est une
responsabilité traditionnelle du chef de projet. Cependant, certains grands projets peuvent avoir
recours à un spécialiste dans ce domaine d'activité. La participation de spécialistes extérieurs
peut aider à mettre en place une analyse des risques plus impartiale que celle provenant de
l'équipe interne.
 Budgétisation. Discutez le budget attribué à la gestion des risques du projet. Peut-être qu'au
moment de la création du plan de gestion des risques vous n'avez pas encore suffisamment
d'informations pour concrétiser ce budget. Mais, vous pouvez décrire le processus que vous
pensez utiliser pour déterminer le budget nécessaire.
 Délais. Indiquez quand l'évaluation initiale des risques sera effectuée, et avec quelle fréquence
les processus de gestion des risques seront effectués durant le cycle de vie du projet. Les
résultats de ces analyses doivent être disponibles suffisamment tôt pour influencer les
décisions. N'oubliez pas que les plans détaillés de réponses aux risques doivent être revus
périodiquement durant l'exécution du projet pour s'assurer qu'ils fonctionnent correctement.
 Méthodes d'évaluation (scoring) et d'interprétation. Vous devez définir les méthodes de
notation (scoring) et d'interprétation appropriées aux types d'analyses qualitatives et
quantitatives des risques utilisées. Les méthodes et la notation doivent être déterminés à
l'avance pour assurer leur intégrité.
 Seuils. Les seuils déterminent le niveau de risques qui sera considéré comme suffisamment
important pour s'occuper de ceux qui le dépassent. Le chef de projet, le client et le
commanditaire peuvent avoir des perceptions différentes du seuil de risque. La détermination
du seuil acceptable permet à l'équipe du projet de classer les risques lors des séances
d'analyse. L'équipe développera des réponses différentes suivant qu’un risque détecté se trouve
au dessus ou au dessous du seuil.
 Communications. Décrivez comment les informations concernant la gestion des risques
seront documentées et diffusées. Ceci comprend les risques, les réponses aux risques et la
situation de ceux-ci. Si vous avez déjà traité ces informations dans le plan de gestion des
communications, cette section pourrait ne pas être nécessaire.
 Suivi et audit. Décrivez comment les différents aspects de la gestion des risques seront
documentés et ce, pas seulement en ce qui concerne ce projet mais aussi au bénéfice d'autres
projets à venir car ceux-ci profiteront des leçons apprises lors des projets antérieurs. Vous vous
demanderez également si et comment les processus de gestion des risques seront surveillés.
319
7.1.2.2 Hypothèses et risques
Les hypothèses sont très liées aux risques et, en fait, ne sont simplement que des risques de faible
niveau. Hypothèse et risques prennent leur point de départ dans la même prémisse. Tous deux sont
des conditions et événements futurs qui auront un impact sur votre projet. Dans les deux cas, il y a une
probabilité d’occurrence et un certain impact sur votre projet. Pour différencier un risque d’une
hypothèse, on doit se demander si sa criticité (probabilité x impact) est acceptable ou pas.
Prenons l’exemple d'une affirmation commune qui est incluse dans de nombreuses définitions de projet,
à savoir que « le personnel nécessaire à ce projet sera disponible quand vous en aurez besoin ». De
quel genre d’affirmation s’agit-il ? La plupart des personnes diraient que c'est une hypothèse. Après
tout, quand le projet commence, vous supposez toujours que vous obtiendrez le personnel dont vous
avez besoin.
Cependant, est-ce vraiment une hypothèse ? Ne pouvez-vous pas imaginer le commencement d’un
projet où le personnel et l'équipement ne seraient pas disponibles et où il y aurait une réelle possibilité
qu’ils ne soient pas disponibles quand vous en aurez besoin (peut-être parce que d’autres projets
devront être terminés d'abord) ? Ce n'est pas très difficile à imaginer. Dans ce cas, cette affirmation
sera définitivement un risque, et non une hypothèse.
Le point essentiel est que la même affirmation pourrait être soit une hypothèse soit un risque selon les
circonstances de votre projet même. La différence entre une hypothèse et un risque devient évidente à
partir du moment où vous décidez d’accepter ou de refuser un certain niveau de criticité de l’événement
en question. Si l'événement est négatif et que son niveau de criticité (probabilité x impact) est
inacceptable pour vous, l’événement doit être considéré comme un risque. Par contre si le niveau de
criticité de l’événement est acceptable, il peut être considéré comme une hypothèse.
Une façon de reconnaître les hypothèses importantes c’est d’effectuer une évaluation des risques (7.2.1
Facteurs inhérents de risques) et de passer en revue tous les événements et circonstances de faible
criticité. La plupart de ces éléments ne valent pas la peine d’être mentionnés, mais certains pourront
avoir des implications significatives si les événements ne se déroulent pas comme vous le pensiez. Ces
circonstances sont celles que vous pouvez considérer comme des hypothèses.
Il y a deux caractéristiques principales concernant les risques et les hypothèses. D'abord, il doit y avoir
une certaine dose d’incertitude concernant l'événement. S'il y a 100% de chance qu’un événement se
produise, il s’agit simplement d’un fait. S'il y a une chance de 0% considérez alors qu’il s’agit d’une
fiction. Ni l'un ni l'autre ne sont des risques ni des hypothèses.
En second lieu, les hypothèses et les risques échappent au contrôle de l’équipe de projet. Si
l'événement est à l’intérieur de votre sphère de contrôle, alors il ne s’agit ni d’une hypothèse ni d’un
risque. Il devra simplement être maîtrisé par le chef de projet.
Passez en revue les exemples suivants pour plus de clarté :
Affirmation Hypothèse, risque ou autre?
On ne peut pas dire s'il s’agit d’un risque ou d’une

Nous aurons un fort soutien pour
hypothèse. Suivant le projet, il peut y avoir un haut degré
cette initiative de la part de notre
de risque dans cette affirmation (risque) ou un faible degré
(hypothèse).

La production et les serveurs de tests
seront installés avant que nous soyons
prêts pour les tests d’intégration
(hypothèse).
Le plancher en béton a 12 pouces Cette affirmation est un fait ou une spécification, et non pas
d’épaisseur un risque ou une hypothèse. Elle décrit un produit livrable.
320
Nous complèterons les spécifications Ceci fait partie de l'approche du projet ou de son échéancier
avant de commencer le travail de . Ce n'est pas un risque ou une hypothèse, parce que c’est à
conception. l’intérieur de la sphère de contrôle de l’équipe de projet.

Nos fournisseurs seront prêts à se
connecter à notre application le 1er
octobre
(hypothèse).
Nous devons aller sur Pluton pour

Ce n'est pas un risque ou une hypothèse parce qu'il n'y a
nous approvisionner en fragments de
aucun risque impliqué. C'est de la fiction (0% de chances).
météorites que ce projet exige.
La voiture doit être capable résister à Cette affirmation est une spécification, pas un risque ou une
une collision à 40 km par heure. hypothèse. Elle décrit un produit livrable.
Ce n'est pas un risque ou une hypothèse parce qu'il n'y a

60 minutes sont nécessaires pour aller aucun risque impliqué. C'est un fait (100% de chances). S’il
d’un lieu de travail à l’autre. n’était pas vrai, ce serait une fiction (0 % de vérité), mais
pas une hypothèse ou un constat de risque.
321
7.2 Gérer les risques / Techniques
Utiliser une des cinq stratégies pour la réponse aux risques (7.2. P1)
Une fois le risque identifié, le chef de projet pourra considérer un certain nombre de réponses.
 Acceptation. Dans cette approche, le chef de projet décide de ne rien entreprendre après
avoir passé en revue le risque. Cela peut se produire pour une de ces deux raisons :
1. Le chef de projet peut considérer que ce risque devrait être géré mais que l’impact négatif
du risque ne vaut pas un investissement en coûts et en effort de travail pour sa gestion.
Dans ce cas, vous préférez être confronté aux coûts du risque s’il se produit plutôt qu’aux
coûts de sa gestion.
2. Des activités raisonnables et pratiques pour gérer ce risque peuvent ne pas être
disponibles. Cela diffère de la raison précédente où le coût était supérieur au bénéfice.
Dans ce cas, il n’y a aucun moyen pratique de gérer le risque, même s’il a été identifié
comme un grand risque. Supposons, par exemple, que votre commanditaire risque de se
retirer et que son remplaçant pourrait annuler le projet. Vous pourriez, en effet, savoir que
votre commanditaire attend une promotion et que ce scénario a des chances de se
produire. Cependant, vous ne pouvez pas faire grand-chose tant que votre commanditaire
du moment garde son poste. Il se peut qu’il n’y ait rien que vous puissiez faire pour
l’instant et que vous deviez attendre de voir comment les événements évolueront.
 Réponse conditionnelle. Dans ce cas, le chef de projet ne gère pas le risque de manière
proactive, mais le surveille pour voir s'il est plus ou moins probable qu’il se produise avec le
temps. S'il survient, l'équipe pourra formuler une réponse différente plus tard. Cette approche
peut être utilisée pour les risques sévères avec une faible probabilité d’occurrence. Le chef de
projet crée un plan seulement s'il pense que le risque va se produire. L'avantage est que les
ressources ne seront dépensées que pour les risques qui sont susceptibles de se produire.
L'inconvénient réside dans une possible lenteur de réponse si un risque se produit vraiment et
que la réponse doit encore être développée. Il peut en résulter une gestion moins efficace du
risque.
Cette approche est particulièrement valable si vous avez identifié un risque éloigné dans le temps qui
devrait être géré. Par exemple, si l’événement risque de se produire dans neuf mois, il est inutile de
dépenser des ressources pour ce risque à ce stade du projet. Une meilleure approche consiste à
surveiller le risque à un rythme mensuel. Il est possible que ce risque disparaisse avec le temps en
raison de nouvelles circonstances. Cependant, si le risque subsiste, l’équipe devra y remédier dans les
mois qui suivent.
 Éviter le risque. Éviter le risque signifie que la condition à l’origine du problème est éliminée.
Par exemple, si une partie du projet présente un gros risque, une partie entière du projet est
éliminée. Des risques liés à un fournisseur particulier pourraient être évités si un autre
fournisseur prend sa place. C'est une manière très efficace d'éliminer des risques, mais elle ne
peut évidemment être employée que dans certaines circonstances particulières. Voici un autre
exemple : supposons que le projet doive mettre en œuvre une solution techno informatique sur
différents emplacements et qu’il y ait un risque lié à cette diversité d’emplacements. Le
commanditaire peut répondre à ce risque en modifiant le contenu du projet et décider de se
concentrer sur un seul site. De cette manière, le risque d’une mise en œuvre multiple sera évité
(mais cela a un prix : ne pas accomplir le contenu originellement prévu).
 Transfert du risque. Parfois, la responsabilité de la gestion d'un risque peut être retirée au
projet et assignée à une entité différente ou à une tierce partie. Par exemple, sous-traiter cette
fonction par un tiers extérieur éliminera certains risques pour l’équipe du projet. La tierce partie
devrait avoir une expertise particulière lui permettant d'effectuer le travail sans risque. Même si
le risque est encore présent, il incombe désormais à une autre partie d’y remédier.
322
Vous pouvez également transférer le risque en contractant des assurances. Par exemple, vous pouvez
avoir besoin de faire livrer une pièce très fragile et importante à votre équipe de projet. Ce matériel
pourrait être endommagé. Vous pouvez déplacer le risque lié au transport en vous assurant. Bien sûr, si
le chargement est endommagé, vous perdrez sûrement du temps pour le remplacer. Cependant, vous
ne supporterez pas le risque financier. Par le biais d’une assurance, l’assureur endosse votre risque
financier.
 Atténuation du risque. Dans la plupart des cas, c'est l'approche à adopter. Atténuer le risque
implique que vous preniez des mesures proactives pour vous assurer que le risque ne se
produise pas. Un autre but de l’atténuation du risque est de s'assurer que l'impact du risque
soit réduit au minimum. Pour la méthodologie TenStep de management de projet, les plans de
gestion des risques sont généralement censés remplir cette fonction.
Les cinq stratégies ci-dessus sont utilisées pour les risques classiques, c’est-à-dire les risques négatifs.
Si vous répondez à un risque positif, vous pouvez toujours utiliser la stratégie d'acceptation. Dans le cas
d’un risque positif, vous voudrez probablement trouver les moyens de tirer parti de celui-ci. Les trois
autres réponses (en plus d '«accepter») sont les suivantes:
 Exploiter. Cette stratégie cherche à éliminer l’incertitude associée à un risque positif en

parvenant à concrétiser l’opportunité.
 Partager. Cette approche vous permet de partager le risque positif avec une tierce partie
ayant la capacité de saisir l’opportunité.
 Améliorer. Cette stratégie est utilisée pour accroitre la probabilité et/ou les impacts positifs
d’une opportunité.
La réponse finale au risque positif utilisera normalement l'une des options énumérées ci-dessus. Ne
vous attendez pas à ce qu’une opportunité puisse être saisie par une seule activité de réponse. Il est
plus probable que votre réponse au risque positif entraine un certain nombre d'activités différentes pour
réussir.
Considérez le risque positif comme un moyen de réaliser des bénéfices (7.2. P2)
Un risque est souvent lié à des évènements potentiels qui ont un impact négatif sur le projet. Il existe
cependant un concept de risque d'opportunité, ou risque positif. Avec ces risques, le chef de projet ou
l’équipe de projet peut en faire intervenir un afin de produire beaucoup plus de valeur ultérieurement.
Par exemple, une équipe peut décider d'utiliser une nouvelle technologie pour son projet parce qu'elle
pense que cela aura pour conséquence des économies considérables sur l'effort de travail et sur le coût.
Bien sûr, il y a également une chance que cette nouvelle technologie ne fonctionne pas. Cependant,
l'équipe accepte le risque en fonction du bénéfice envisagé. C'est un exemple de prise de risque
intelligente ou de risque positif. Voir 7.2.3 Risques positifs (opportunités) pour plus de détails.
Note: Dans le cadre de la méthodologie TenStep de management de projet, nous supposons que le
type de risques que vous gérez est du type risques négatifs. Ils doivent être traités de sorte que le
problème potentiel ne se produise pas.
Assurez-vous que vos risques comportent un certain niveau d’incertitude (7.2. P3)
Si un événement est identifié comme un risque, un certain niveau d’incertitude est associé à celui-ci. En
d'autres termes, si un événement a une probabilité nulle de se produire, il est inutile de l'identifier
comme un risque. Il ne constitue pas un risque, pas même faible. D'autre part, si un événement a
100% de chance de se produire, il s’agit d’un fait et non d’un risque (les « risques » avec une
probabilité d’occurrence de 100% sont parfois appelés contraintes). Une contrainte est un événement
ou une limitation qui affecte votre projet et qui doit être considérée lors du processus de planification.
Par exemple, une personne dont vous avez besoin n’est disponible que 30 jours après le début du
projet. C'est une contrainte, pas un risque. (Cette contrainte peut causer un risque de dépassement des
délais, mais elle ne constitue pas un risque en tant que tel.)
Un risque a une certaine probabilité, soit entre 1% et 99% de chance de se produire. Si un événement
a une chance nulle de survenir, il sera ignoré. S'il a une chance de 100% de se produire, c'est un fait
323
(et peut-être une contrainte). Quand vous gérez des risques, soyez sûr de vous concentrer sur les
risques et non sur des faits ou des situations fictives.
Distinguez les risques, les causes et les effets (7.2. P4)
Il y a une cause pour chaque risque et un effet si celui-ci se produit. Lorsque les risques du projet sont
identifiés, assurez-vous que c’est bien le risque lui-même qui est noté, et pas sa cause ou son effet. La
cause est une situation qui existe et qui entraîne un risque potentiel. En général, la cause est un fait
pour le projet. Par contre, l'effet représente les résultats probables qui découleront du risque, si celui-ci
se produit.
Voici un exemple: Une solution doit être mise en œuvre dans tous les locaux d’une compagnie, à
travers le monde, y compris ceux situés dans des pays en voie de développement. Si les lignes de
télécommunications ne sont pas améliorées à temps dans les régions concernées, alors la solution ne
sera pas viable.
Dans l'exemple précédent, quel est le risque ?
 Le risque réside-il dans la mise en œuvre de la solution dans les pays en voie de
développement ? Non, il est plutôt la cause. C'est un fait ou une spécification.
 Le risque fait-il en sorte que la solution ne soit pas disponible dans certains pays ? Non, il est
plutôt l'effet potentiel de ce qui pourrait se produire dans ce scénario.
 Le risque consiste-t-il dans le fait que les mises à jour nécessaires des télécommunications ne
soient pas effectuées à temps ? Oui, c'est là qu’il y a incertitude.
Essayez de définir un budget et un échéancier pour les risques non identifiés (7.2. P5)
Un chef de projet peut demander un budget de réserve pour aléas, basé sur l’analyse qualitative de
risques du début de projet. Cependant, l’identification des risques ne doit pas être effectuée
uniquement au début du projet. Le chef de projet doit la poursuivre durant tout le projet. De ce fait, il
peut être pertinent, dans le cadre de grands projets, d’inclure le temps et le budget pour des risques
non identifiés dans votre processus d’estimation. Cela concerne particulièrement des projets présentant
un certain nombre d'événements à haut risque. Si vous faites un travail efficace de réévaluation
périodique des risques, vous trouverez de nouveaux risques à gérer qui n'ont pas été inclus dans le
budget original. Il est d’usage dans l'industrie qu'une réserve de 5% soit ajoutée au projet pour traiter
les risques qui ne sont connus que lorsque celui-ci commence à être exécuté. (Un laps de temps
nécessaire pour atténuer et gérer les risques connus devra être inclus dans l’estimation originale.)
Impliquez les membres de l’équipe dans l'identification des risques (7.2. P6)
Si les membres de l’équipe connaissent les circonstances qui entourent le projet, ils peuvent participer
activement à l'identification et à l'évaluation des risques. La participation commune de l'équipe peut
aider à identifier les risques du projet et à présenter des propositions efficaces pour les gérer et pour
arriver à un consensus.
Soupesez le coût du plan de gestion du risque par rapport à la criticité de celui-ci (7.2. P7)
Tous les projets présentent des risques, et les plans de gestion des risques ont un coût. Le chef de
projet et les clients devront être sûrs que l'effort de travail et le coût liés au management des risques
du projet ne dépassent pas le coût du problème si le risque se produisait. Pour des risques importants,
cela ne sera normalement pas le cas. Cependant, si vous gérez des risques de criticité moyenne,
assurez-vous que les coûts et les avantages de la réponse au risque conviennent au projet. Si les coûts
liés à la gestion du risque dépassent l’impact du risque, sa gestion s’avèrera superflue. Il est possible
que le coût de la gestion du risque soit plus élevé que celui de son impact. Dans ce cas, vous pouvez
choisir d’accepter le risque.
Connaissez le seuil de tolérance aux risques dans votre institution (7.2. P8)
324
Tous les projets présentent des risques et tous les risques ont un impact négatif potentiel sur le projet.
Vous employez le management des risques du projet pour déterminer les risques suffisamment
importants pour être gérés. Lors du processus d'identification des risques, vous pouvez rencontrer de
nombreux risques susceptibles de se produire et qui auront un impact marginal sur le projet. La
question que vous devez vous poser est de savoir si ce risque est suffisamment critique pour que cela
vaille la peine de s’en inquiéter. (Cette même question se pose pour les approches qualitatives et
quantitatives.) La réponse vous fournit certaines indications au sujet de votre tolérance aux risques.
Supposons, par exemple, que vous identifiiez un risque qui a de très fortes chances de se produire,
mais qui aura un impact de 100 € sur le budget et une demi-journée d’impact sur l’échéancier. Vous
pouvez choisir de ne pas le gérer. Vous ne pouvez pas le considérer comme une hypothèse, puisqu’il a
de bonnes chances de se produire. Cependant, l'impact est assez limité pour que vous soyez disposé à
en assumer le coût s'il se produisait, plutôt que de gérer le coût de la gestion du risque (qui sera
probablement plus élevé). Dans ce cas, vous choisirez une stratégie de gestion qui consiste à accepter
le risque.
Dans l'exemple précédent, les chiffres étaient plutôt insignifiants et il était facile d’ignorer le risque.
Mais supposons que l'impact augmente. Disons maintenant que le risque représente 500 € et une
journée supplémentaire, puis 100.000 € et une durée additionnelle de trois mois. Naturellement, les
réponses sont toujours relatives et dépendent de la taille de votre projet. S’il a un budget de 20.000 €
et que l'impact du risque est de 1.000 €, sa gestion pourra être envisageable. Si le budget de votre
projet est d'un million d’euros, l'impact d’un risque de 1.000 € sera marginal.
Quand vous effectuez l'identification des risques, déterminez votre seuil de tolérance aux risques. Cela
vous aidera à vous concentrer sur les risques importants qui se situent au-dessus de votre niveau de
tolérance, tout en ignorant les risques dont l'impact tombe au-dessous de ce niveau. La tolérance au
risque dépend aussi de la culture de votre entreprise. Certaines entreprises sont prêtes à prendre plus
de risques que d’autres et accepteront un niveau de risque plus élevé pour leurs projets. Elles auront
aussi tendance à avoir un seuil plus élevé avant de décider de gérer un risque.
D’autre part, certaines organisations ne sont pas disposées à prendre des risques. Elles auront
tendance à accepter des projets peu risqués et auront aussi un seuil plus bas pour la gestion des
risques. En d’autres termes, supposons que vous ayez un projet similaire dans ces deux organisations.
Le chef de projet de ce dernier type d’organisation aura tendance à gérer les risques qu’un chef de
projet d’un autre type d’organisation choisira d’accepter.
Utilisez les arbres de décision pour analyser les risques multiples et reliés (7.2. P9)
Une manière de calculer les résultats financiers de risques interdépendants sur un projet est d’utiliser
un arbre de décision. Il s’agit d’une technique pour déterminer le risque total associé à une série de
risques. Les arbres de décision sont une bonne technique lorsque vous disposez des caractéristiques
suivantes :
 Les probabilités d’un risque sont basées sur le résultat d’un risque précédent. Les risques sont
alors liés.
 Un nombre limité de résultats sont probables pour chaque point de décision. Quand le nombre
de résultats probables est élevé, cette technique peut apparaître très complexe.
 Il existe des implications financières dans les calculs de risques.
Considérons l’exemple d’arbre de décision suivant :
325
L’arbre de décision révèle deux risques. Le risque A comporte deux issues. L’issue 1 a 20% de chance
de se produire et l’issue 2 en a 80%. La valeur monétaire du risque A est de 10.000 €. Si le risque A se
produit, un deuxième risque B apparaît avec trois issues possibles, soit 1.1, 1.2 et 1.3. La valeur
monétaire du risque B est de 30.000 €. À l’aide de l’arbre de décision, on aperçoit différentes issues des
risques financiers.
1.1 9.500 € (10.000 x 0,2) + (30.000 x 0,25)

1.2 23.000 € (10.000 x 0,2) + (30.000 x 0,70)
1.3 3.500 € (10.000 x 0,2) + (30.000 x 0,05)
2 8.000 € (10.000 x 0,8)
Votre objectif pourrait toujours être de mitiger le risque A afin d’éviter son occurrence. Cependant, si
vous n’êtes pas en mesure d’éviter effectivement cette occurrence, cet arbre vous indique que si vous
tablez sur l’issue 1.3, vous obtiendrez l’impact le plus faible pour ce risque. Si vous ne pensez pas
pouvoir réaliser l’issue 1.3, essayez l’issue 2. Même si les implications de risque sont nettement plus
grandes que celles de l’issue 1, il y a un second risque associé à l’issue 1, et le risque B a 95% de
chance de faire monter la valeur totale du risque.
Créez une structure de découpage des risques (SDR) pour identifier les (7.2. P10)
Il existe un certain nombre de moyens pour identifier les risques de votre projet. L’un d’eux consiste à
créer une structure de découpage des risques (RBS). Le concept est similaire à une structure de
découpage du projet (SDP), sauf qu’au lieu de découper le travail à accomplir en composantes plus
petites, la structure de découpage des risques est utilisée pour décomposer les risques vers le bas, du
plus général au plus spécifique. Par exemple, vous pouvez définir trois catégories de risques généraux
de votre projet : ceux provenant de la technologie, ceux provenant de la culture et ceux découlant du
fournisseur. Ensuite, vous recherchez des risques plus spécifiques au sein de chaque catégorie. La
structure qui en résulte peut ressembler à la suivante :
Technologie Culture Fournisseurs

- Nouvelle technologie - La technologie est encore - De nouveaux fournisseurs pour
instable de nouvelles technologies.
- Nous ne l’avons jamais - La plupart des employés auront - Le fournisseur est petit et nous
essayée initialement une attitude ne sommes pas certains de sa
négative stabilité.
- La technologie est encore - Le support de la hiérarchie est - Pas certain que le fournisseur
instable; il s’agit d’une version incertain puisse augmenter les prestations si
beta requis.
326
Chaque catégorie de haut niveau se divise en risques plus détaillés. Il est possible que certains de ces
risques puissent être davantage séparés jusqu’à un niveau plus granulaire. À ce stade, vous êtes encore
au cours du processus d’identification des risques. Lorsque vous traitez les risques, vous arriverez à
mieux les préciser.
Traitez les risques très probables comme des contraintes (7.2. P11)
Les risques ont une certaine probabilité d'occurrence. Les contraintes sont des faits qui se produiront
avec certitude. Lorsque vous pouvez essayer de gérer les risques, il y a lieu de piloter le projet en
considérant les contraintes.
Il est une bonne pratique de traiter les risques de très haute probabilité comme s’il s’agissait de
contraintes. Par exemple, si vous pensez que le risque a une probabilité d’occurrence de 99%, il est
probablement judicieux de simplement le considérer comme un fait (100%) et de le gérer comme une
contrainte. Ceci pourrait être plus efficace que de le gérer comme un risque, car il est presque certain
qu’il se produira.
Afin de généraliser ce concept, vous pouvez envisager un risque qui a une probabilité très élevé de
survenance comme une contrainte. Cela pourrait être formalisé numériquement par le traitement en
tant que contraintes de tous les risques ayant une probabilité d’occurrence de 80% ou plus.
327
7.2.1 Facteurs de risques inhérents
Les risques inhérents sont des risques identifiés en fonction des caractéristiques générales du projet. Ce
sont des risques qui peuvent apparaître quelle que soit la nature de votre projet.
Aucun des risques inhérents ne signifie que le projet est en danger. Nombre de ces facteurs seront
classés comme des risques faibles ou moyens. Même si vous identifiez un grand risque, d’autres
facteurs de projet entreront également en compte. Par exemple, la check-list ci-dessous affirme qu’un
grand projet est, par nature, plus risqué qu’un petit projet. Cela est généralement vrai. Cependant, un
chef de projet expérimenté atténuera nombre de risques liés à la grande taille d’un projet. Rappelez-
vous, en outre, que si votre projet entre dans une catégorie à haut risque, cela ne veut pas dire que
vous ne pourrez pas le réussir. Cela signifie seulement que vous devrez mettre en place des plans pour
gérer les risques.
Le tableau ci-dessous identifie les caractéristiques qui peuvent impliquer des risques. Il fournit
également des critères pour savoir s'ils représentent des risques importants ou faibles. Selon les
caractéristiques de votre projet, vous pouvez évaluer si votre risque est important, moyen, ou faible. Ce
type de check-list peut être particulièrement bienvenu si votre organisation documente les
caractéristiques de risque et les critères de risque, pour les communiquer à tous les chefs de projets.
Par exemple, vous pouvez trouver dans votre organisation un projet de moins de 5.000 heures,
considéré comme présentant un faible risque, alors qu'un autre de 20.000 heures aura un plus gros
risque.
Si tous vos projets prévoient une réunion de passage en revue à la fin du projet, les équipes peuvent
revenir en arrière et documenter les problèmes auxquels le projet a du faire face, y compris le plan de
réponse aux risques mis en place et ses résultats. Ces derniers peuvent alors être consolidés et
résumés dans une check-list des facteurs de risques basée sur les connaissances principales et les
meilleures pratiques de votre propre entreprise.
Dans la table ci-dessous, les risques moyens tomberaient quelque part au milieu entre les risques hauts
et faibles. Par exemple, si votre équipe comprend 15 personnes, cela représente un risque moyen. De
la même façon, vous courez un risque moyen si vos contenus / livrables étaient mieux que « mal définis
» et moins que « bien définis ». Ceci pourrait être le cas lorsque certains livrables étaient mal définis
tandis que d’autres étaient bien définis.
Trouvez plus de facteurs inhérents de risque ainsi que des réponses appropriées dans le modèle
« Check-list des Facteurs de Risque » dans la Bibliothèque de modèles pour les usagers qui détiennent
une licence TenStep.
Caractéristique Gros risque Faible risque
Effort de travail total Grand projet > 2.500 heures Petit projet < 250 heures
Durée Supérieure à 12 mois Moins de 3 mois
Taille de l'équipe Plus de 25 membres Moins de 5
Nombre de clients ou Plus de trois Un

d’entreprises clientes
Contenu du projet / Produits Mal défini Bien défini

livrables
Bénéfices commerciaux Pas clairs (le projet ne devrait pas Bien défini
être lancé)
328
Connaissance du métier par Ni l'un ni l'autre n’ont de solides Les deux ont de solides
l’équipe de projet et le client connaissances connaissances
Spécifications Très complexes, difficiles à définir Facile à définir pour le client

pour le client
Dépendance par rapport à Dépendance par rapport à plus de Pas plus d'une dépendance
d'autres projets ou à des équipes trois projets ou équipes extérieurs
extérieures
Commanditaire du projet Inconnu (le projet ne devrait pas Identifié et enthousiaste

être lancé)
Engagement du client Inconnu, passif Passionné
Changements requis pour les Beaucoup de changements Peu de changements

procédures, processus et
politiques existants
Structures de l'organisation Beaucoup de changements Peu ou pas de changements
Expérience du chef de projet Peu d’expérience sur des projets Expérience similaire sur de
semblables multiples projets
Localisation physique de l'équipe L'équipe est dispersée sur L'équipe est concentrée sur le
plusieurs sites même site
Utilisation d’une méthodologie Aucune méthode ou processus Méthodes standard utilisées

formelle formel
Technologie Une nouvelle technologie est Aucune nouvelle technologie

utilisée pour des composants n’est requise
importants
Temps de réponse Les temps de réponse très courts Un temps de réponse normal
sont importants est acceptable
Qualité des données Les données sont de mauvaise Les données sont de bonne
qualité qualité
Relation avec le fournisseur On n’a jamais travaillé avec le Bonne relation avec le
fournisseur auparavant fournisseur
329
7.2.2 Valeur monétaire attendue (VMA) et provisions pour aléas
(7.2.2. P1)
La valeur monétaire attendue (EMV: Expected Monetary Value) est une technique de gestion des
risques qui peut être employée pour aider à mesurer et à comparer les risques sur de nombreux
aspects du projet. La valeur monétaire attendue est une technique quantitative d'analyse des risques
puisqu'elle utilise des chiffres spécifiques et des quantités pour exécuter des calculs, plutôt que des
approximations générales comme haut, moyen et bas.
La valeur monétaire attendue repose sur deux chiffres de base.
Pr = probabilité que le risque se produise
I = impact sur le projet si le risque se produit. Ceci peut être est décomposé davantage en « Ic » pour
l'impact sur le coût, « Id » pour l'impact sur les délais et « Ie » pour l'impact sur l'effort de travail.
Provisions pour aléas (7.2.2. P2)
Si vous employez cette technique pour tous vos risques, vous pouvez demander une provision pour
aléas (que l'on appelle parfois réserves pour imprévus) pour couvrir l'impact sur votre projet si un ou
plusieurs risques se produisent. Par exemple, supposons que vous ayez identifié six risques pour votre
projet, comme ci-dessous :
Risque Probabilité de risque Impact sur le coût Provision pour aléas

A 0,8 10.000 € 8.000 €
B 0,3 30.000 € 9.000 €
C 0,5 8.000 € 4.000€
D 0,10 40.000 € 4.000,00
E 0,3 20.000 € 6.000 €
E 0,3 20.000 € 6.000 €
F 0,25 10.000 € 2.500 €
Total 118.000 € 33.500 €
Sur la base de l'identification de ces six risques, l'impact potentiel sur votre projet est de 118.000 €.
Cependant, vous ne pouvez pas demander un tel budget de réserve pour imprévus. Vous aurez besoin
de tout cet argent uniquement si chaque risque se produit. Rappelez-vous que l'objectif du
management des risques du projet est de s'assurer que les risques n'affectent pas votre projet. Par
conséquent, vous pouvez supposer que vous gérerez avec efficacité la plupart d’entre eux, sinon tous.
Le budget de réserve pour imprévus devra refléter l'impact potentiel du risque, mais aussi la probabilité
qu’il se produise. Elle est reflétée dans la dernière colonne.
Notez que la demande totale de provision pour aléas de 33.500 € est disponible pour protéger votre
budget contre des risques connus. Si les risques C et F se produisaient réellement, vous pourriez utiliser
le budget de réserve pour imprévus pour soulager votre budget. Néanmoins, vous voyez que si le
risque D se produisait réellement, la provision pour aléas pourrait ne pas être suffisante pour vous
protéger de l'impact. Cependant, le risque D a seulement une chance de 10% de se produire, c’est
pourquoi l’équipe du projet devra vraiment se concentrer sur celui-ci pour s'assurer qu’il est géré avec
efficacité. Même s’il ne peut pas être totalement géré, son l'impact sur le projet sera, si tout se déroule
bien, contrôlé par une gestion proactive des risques.
Propagation du risque (7.2.2. P3)
330
La réserve pour imprévus fonctionne convenablement tant qu’il y a un certain nombre de risques pris
en compte. Plus l'équipe identifie de risques, plus la réserve pour imprévus est partagée entre ceux-ci.
Dans le cas précédent, l’accumulation de six risques est suffisante pour obtenir un budget d’appui. Si
vous avez identifié seulement un ou deux risques, vous ne seriez pas capable d’identifier suffisamment
les risques pour être aussi efficace que vous le désirerez. Par exemple, supposons que vous ayez
seulement identifié un risque semblable au risque D dans le tableau précédent. Vous demanderez et
obtiendrez une provision pour aléas de 4.000 €. Vous vous trouverez alors dans une situation de tout
ou rien. Si le risque ne se produit pas, vous n'aurez pas besoin des 4.000 €. Cependant, si le risque se
produit, les 4.000 € économisés ne seront pas suffisants pour couvrir l'impact potentiel. Cela ne signifie
pas que la provision pour aléas doive être ignorée, mais seulement qu’elle couvre mieux les risques si
un certain nombre d’entre eux sont identifiés. La provision pour aléas n’est pas aussi efficiente si un ou
deux risques seulement sont identifiés.
Budgétisez les risques inconnus (7.2.2. P4)
Les calculs de la valeur monétaire attendue ci-dessus cités reflètent seulement les risques identifiés au
début du projet, lors de l’évaluation initiale des risques. Si vous gérez un grand projet, vous devez
continuer à surveillez les risques régulièrement. Par conséquent, vous pouvez également demander un
budget complémentaire de réserve pour imprévus pour couvrir les risques qui apparaîtront
probablement plus tard, et dont vous ne savez rien maintenant. Il est raisonnable de demander 5% de
plus pour votre budget total, pour constituer une provision pour aléas, afin de couvrir les risques
inconnus que vous rencontrerez plus tard, et ce, en complément de la réserve pour les risques connus
déjà identifiés.
331
7.2.3 Risques positifs (opportunités)
Les risques sont des événements futurs ou conditions qui ont une certaine probabilité de se produire et
un certain impact sur notre projet. Habituellement, on pense aux risques comme des événements
négatifs et on met en œuvre un plan pour les régler.
Toutefois, est-il vrai que tous les risques représentent un danger potentiel ? Disons que votre projet est
en train d'utiliser un nouvel outil ou de nouvelles technologies. Est-ce que votre projet est plus risqué
qu'un projet similaire qui utilise la technologie actuelle?
A priori, la réponse semble être "oui", un projet qui utilise une nouvelle technologie a plus de risques
que celui qui se sert d'une technologie connue. Votre équipe comprend probablement mieux la
technologie actuelle, elle est probablement plus stable. Par contre, si la nouvelle technologie n'est pas si
bien comprise, il est plus probable qu'elle rencontre des problèmes inattendus et que votre
infrastructure de maintenance ne soit pas suffisamment solide pour faire face aux problèmes potentiels.
Même sans spécifier de quelle technologie il s'agit dans cet exemple, il est logique de penser que les
projets qui utilisent des nouvelles technologies sont exposés à plus de risques que des projets similaires
qui utilisent des technologies matures.
Cependant, s'il est vrai que tous les projets sont généralement plus à risque lorsque vous utilisez de
nouvelles technologies, pourquoi iriez-vous entreprendre un projet et vous servir d'une technologie de
pointe ? La réponse réside dans l'avantage que vous pensez obtenir pour votre projet. En d'autres
termes, l'impact potentiel sur votre projet est positif. Cela est encore conforme à la définition du risque.
 Il y a un impact sur votre projet. Normalement les évènements à risques ont un impact négatif
sur votre projet; toutefois, dans le cas des risques positifs l'impact potentiel est positif.
 Il y a une probabilité que l'événement survienne. C'est encore le cas avec les risques positifs.
Dans l'exemple précédent, si les avantages du passage aux nouvelles technologies étaient
garantis, vous pourriez prendre la décision d'aller de l'avant avec 100% de confiance. Toutefois,
les avantages ne sont généralement pas garantis. La technologie, ou la mise en œuvre de la
technologie, pourrait s'avérer mauvaise, dans ce cas, cela pourrait être pire qu’au début de
votre entreprise.
Les risques positifs sont aussi appelés «risques d'opportunité." Dans ces cas, le chef de projet ou
l’équipe de projet prennent consciemment un risque afin d'obtenir plus tard un avantage ayant une plus
grande valeur que les problèmes potentiels liés au risque assumé.
De même, vous pourriez avoir entendu que vous devriez savoir prendre des risques. Dans plusieurs
organisations, ils changent cela en disant que vous devriez prendre les risques "intelligents". Ce concept
conduit à la même question. Pourquoi seriez-vous un preneur de risques si ces derniers sont toujours
mauvais? Certainement, la raison est qu'il y a aussi plusieurs risques d'opportunité.
L'un des aspects distinctifs des risques positifs est que vous vous mettez dans la position de prendre le
risque. Les risques négatifs sont des événements négatifs qui peuvent vous arriver. Ce sont ceux que
vous voulez éviter ou éliminer. Les risques positifs sont ceux que vous prenez de bon gré. Ils ne sont
pas à l'extérieur, au contraire, ils sont prêts à ressurgir. Ce sont les risques que vous prenez afin
d'obtenir les bénéfices qui leur sont liés.
La tolérance aux risques est bien différente au sein des organisations. Il faut se demander ce qui
arrivera si vous prenez un risque positif et que ses bénéfices ne se réalisent pas. Si votre organisation
récompense les personnes qui prennent des risques tout en réussissant mais punit ceux qui les
prennent mais n’en tirent pas les bénéfices escomptés c'est qu'elle est réellement opposée aux risques.
Il est facile de récompenser les personnes qui prennent des risques et réussissent. C’est la situation
face à l’échec à la prise de risques qui détermine si votre organisation est tolérante ou non à la prise de
risques positifs.
En général, lorsque vous faites de la gestion des risques vous parlez d'événements potentiellement
négatifs. Toutefois, vous pouvez également prendre des risques d'opportunité dans l'espoir d'obtenir les
bénéfices ayant un lien avec ceux-ci. Ces risques d'opportunité peuvent être gérés de la même manière
332
que les risques négatifs, sauf qu'au lieu d'essayer des éliminer, la réponse à ces risques comprendra
des activités visant à vous donner les meilleures chances de réaliser des bénéfices.
333
7.3 Gérer les risques / Références rapides
Livrables (7.3. P1)
Les livrables suivants sont disponibles dans la bibliothèques de modèles TenStep destinés à soutenir ce
processus. (Certains de ces modèles ne sont accessibles que pour les utilisateurs qui détiennent une
licence).
 Fiche des réponses aux risques
 Liste de contrôle des risques inhérents
 Fiche d’identification des risques
 Plan de gestion des risques
 Revue des risques
 Formulaire de signalement des risques
 Journal de suivi des risques
 Formulaire de surveillance et maîtrise des risques
 Liste de contrôle du management des risques
 Fiche de réponse aux risques
Ces activités sont portées sur l’échéancier pour surveiller et maîtriser les risques. Les activités initiales
d’identification des risques sont supposées avoir été accomplies au cours du processus de définition du
travail.
Petits
Il n’y a pas d’activités supplémentaires à ajouter à l'échéancier pour de petits projets.
projets
Identifiez et analysez tous les

risques dès le départ. Créez un
Il peut s’agir d’un exercice minime ou
plan de management des
ouvert exigeant, suivant la nature de votre
risques pour tous les grands
projet.
risques et certains risques
Projets moyens, si nécessaire
moyens et
grands Après l’étape de définition de projet,
Ajoutez toutes les activités du
ajoutez les activités à l'échéancier du
plan de management des
ouvert projet, avec les dates de début et de fin.
risques à l'échéancier du
Affectez du personnel à toutes les
projet
activités.
Passez en revue la situation du Activité hebdomadaire ou bimensuelle

plan de management des 1-2 heures toujours assignée au chef de projet.
risques Utilisez ce temps pour vous assurer que
des progrès sont accomplis sur tout le
334
plan de gestion des risques et que vous
gérez avec efficacité tous les risques
futurs.
Mensuel. Revenez une étape en arrière

Évaluez les nouveaux risques et évaluez le travail restant sur le projet
1 heure
du projet pour déterminer s’il y a de nouveaux
risques qui devront être gérés.
335
______________________________________________________________________
Processus 8
Gérer les ressources
humaines
336
8.0 Gérer les ressources humaines
Un chef de projet est responsable à 100%

des processus utilisés pour gérer un
projet. Il a aussi des responsabilités de
gestion du personnel dans le cadre de ce
projet, même si ces responsabilités sont
partagées avec les supérieurs
hiérarchiques et les membres de l’équipe.
Certains vont jusqu’à affirmer que la
gestion du personnel, dans un projet,
représente le plus grand défi et la
responsabilité la plus haute parmi toutes
celles du projet.
Les chefs de projets capables de gérer des processus mais qui ne sont pas très compétents dans la
gestion du personnel peuvent éventuellement réussir leurs projets. Ceux qui ne sont pas de bons
gestionnaires de processus mais qui gèrent bien le personnel peuvent aussi connaître le succès, peut-
être à un degré moindre cependant que les premiers. Les meilleurs chefs de projets sont ceux qui font
un bon travail au niveau de la gestion des processus de management de projet mais aussi un bon
travail au niveau du recrutement, du développement et de la gestion de l’équipe de projet.
8.1 Gérer les ressources humaines / Processus
8.2 Gérer les ressources humaines / Techniques
8.3 Gérer les ressources humaines / Références rapides
337
8.1 Gérer les ressources humaines / Processus
Petits projets (8.1. P1)
Même lorsque leur équipe est constituée, les chefs de projets doivent déterminer leurs besoins en
matière de gestion des ressources humaines. Cependant, les petits projets n’ont probablement pas à se
préoccuper énormément des techniques et processus formels de gestion du personnel. Le staff du
projet leur est probablement affecté par un responsable. Il n’y a pas de nombreuses possibilités
d’augmenter le nombre des membres de l’équipe, et le besoin de gestion du personnel est réduit,
puisqu’il se limite à s’assurer que ces membres connaissent le travail dont ils ont la charge et que le
travail est accompli avec succès. De même, un petit projet n’encourt normalement pas de nombreux
problèmes de personnel.
Projets de taille moyenne et grands projets (8.1. P2)
Les projets de cette taille, en particulier les plus grands, ont tendance à avoir beaucoup plus de
membres dans leur équipe, et pendant une plus longue période. Ce sont là les projets où vos aptitudes
à gérer le personnel entrent en jeu. Ce sont aussi les projets où sont requis des processus de gestion
du personnel en matière de recrutement, de formation et de gestion du personnel.
Les processus sectoriels qui suivent peuvent être pris en compte pour la plus grande partie du travail de
gestion du personnel au sein de votre équipe.
 8.1.1 Planification des ressources humaines. Ce processus est utilisé pour définir le travail
associé à l’établissement de directives concernant les ressources humaines, à la définition des
rôles et responsabilités, à la création des descriptions de fonctions, les stratégies de dotation en
personnel, etc. pour votre projet. Certaines des informations nécessaires peuvent être
disponibles dans votre département des ressources humaines. Par exemple, vous n'allez
probablement pas être obligé de créer toutes les descriptions de fonctions faites sur commande
pour votre projet. Cependant, plusieurs aspects de la planification des ressources humaines
vont être spécifiques pour votre projet individuel.
o 8.1.1.1 Créer le plan de management des ressources humaines
 8.1.2 Constituer l’équipe de projet. Ce travail consiste à déterminer les profils des
ressources humaines dont votre projet a besoin, à les trouver et à faire en sorte qu’elles soient
réellement disponibles pour votre équipe.
 8.1.3 Développer l’équipe de projet. Ce travail consiste à s’assurer que l’équipe possèdes
compétences requises et que vous lui apportez le soutien qu’il faut pour qu’elle progresse
techniquement et professionnellement.
 8.1.4 Diriger l’équipe de projet. Ce travail est lié à l’assignation du travail dans le projet et
à s’assurer que ce travail est achevé dans les délais. Il consiste aussi à évaluer le rendement, à
gérer les problèmes en relation avec le personnel et à s’assurer de la cohésion de l’équipe et de
son haut rendement.
338
8.1.1 Élaborer le plan des ressources humaines
Allocation du personnel dans une organisation matricielle (8.1.1. P1)
Dans les grandes organisations ou les grands projets, on peut se payer le luxe de disposer de personnel
à plein temps pour constituer toute une équipe. Cependant, dans de nombreuses (voire dans la plupart
des) situations, le chef de projet doit utiliser du personnel réparti ou affecté à temps partiel pour
réaliser le travail. Certaines personnes peuvent travailler sur plusieurs projets, alors que d’autres
occuperont des rôles (ou des fonctions) de soutien. Le processus consistant à réunir et garder du
personnel dans ce contexte peut être problématique et est lié à la manière dont votre organisation est
structurée.
Dans une organisation matricielle, des personnes sont rattachées à plein temps à une organisation
fonctionnelle, mais peuvent aussi bien être affectées, à temps plein ou à temps partiel, à un projet.
Dans ce cas, le supérieur hiérarchique sera responsable d’une partie de la charge de travail d’un
membre de l’équipe et un chef de projet aura la responsabilité de lui assigner des tâches liées au
projet. Si vous êtes dans une structure où le chef de projet n’est pas la même personne que le chef
hiérarchique, c’est que vous êtes en train de travailler dans un environnement « matriciel ».
L’organisation matricielle est particulièrement efficiente si votre projet ne requiert pas un engagement à
temps plein de personnes appartenant à votre organisation de soutien. Le personnel peut être utilisé à
temps partiel sur un ou plusieurs projets, tout en continuant à rendre des comptes à une autre
structure.
L’organisation matricielle peut être la formule la plus efficace pour utiliser et optimiser le temps et les
aptitudes du personnel. Cependant, cela ne fonctionne que si le chef hiérarchique et le chef de projet
(ou plusieurs chefs de projets) relèvent les défis et travaillent ensemble pour l’intérêt global de la
compagnie.
Vous devez conserver un créneau dans votre planification pour les projets à venir et estimer leurs
besoins en personnel. Si vos exigences en termes de personnel ont tendance à beaucoup fluctuer d’un
mois à l’autre, ou si le projet ne peut être prévu plusieurs mois à l’avance, vous pouvez du moins
planifier l’utilisation d’« une fenêtre » de roulement de trois mois. Ensuite, vous pourrez mettre à jour
et affiner le plan suivant une fréquence mensuelle. Pour le mois le plus proche, les données doivent
être assez fermes. Pour les deux mois qui suivent, elles devront être assez approximatives. Trois mois
et plus est la meilleure hypothèse.
D’autre part, si les projets de votre organisation sont généralement longs et que votre plan du
personnel est bien conçu, vous devrez conserver une fenêtre de planification de trois trimestres (9
mois) et mettre le plan à jour tous les trois mois. Le processus de planification devra impliquer les chefs
de projets appropriés et les chefs hiérarchiques qui ont tendance à partager des groupes de personnel
communs.
Après la planification vient la communication proactive. Gardez à l’esprit le fait que dans une
organisation matricielle, les chefs de projet ont besoin de personnel pour accomplir le travail, mais qu’ils
ne peuvent en disposer à leur guise, à la différence des chefs hiérarchiques. La responsabilité incombe
alors au chef de projet de s’assurer que le personnel sera disponible lorsqu’il en aura besoin, sans être
sujet à de mauvaises surprises. Par exemple, si vous vous mettez d’accord avec le chef hiérarchique
pour qu’un nombre déterminé de personnes soit disponible pour l’un de vos projets, dans un délai de
deux mois, n’allez pas vous présenter deux mois plus tard en vous attendant à ce que tout soit prêt. En
fait, vous devriez vous attendre à ce que ces personnes ne soient pas prêtes, dans la mesure où vous
n’avez pas réitéré votre demande durant cette période de temps. Le chef de projet doit obtenir l’accord
au sujet du personnel deux mois à l’avance. Le personnel devrait être confirmé à la réunion mensuelle
suivante sur le sujet. Le chef de projet devrait s’assurer par deux fois qu’il a bien tout son personnel
deux semaines avant la date de démarrage, puis une nouvelle fois une semaine avant. Vous aurez plus
de chances de disposer de personnel quand vous en aurez besoin si vous passez par ces étapes
proactives.
339
8.1.1.1 Créer le plan de gestion des ressources humaines
Le plan de gestion des ressources humaines indique votre approche propre à acquérir et à gérer les
ressources humaines au sein de votre projet. Parmi les informations à fournir, on peut y inclure les
éléments suivants :
 Approche de dotation en personnel. Définissez toute l'approche que vous allez adopter afin
de doter votre projet de ressources humaines, y compris l'usage d'employés et de sous-
traitants. Par exemple, si une partie du travail est sous-traitée, il convient de le mentionner.
Expliquez les raisons conduisant à utiliser des ressources externes plutôt que des ressources
internes. Si les délais de l'apport des ressources humaines sont cruciaux, vous pouvez aussi le
mentionner dans la présente rubrique.
 Emplacement. Déterminez le choix du lieu de travail que vous avez fixé pour les membres de
l'équipe. Par exemple, si les membres de l'équipe pourraient cohabiter durant le projet, ou si
certains d’entre eux pourraient travailler chez eux. Vous pourriez aussi disposer de membres
d'équipes virtuelles qui résident dans d'autres villes ou dans d'autres pays.
 Acquisition des ressources humaines. Vous pouvez utiliser un tableau qui décrit les types
de ressources humaines dont vous avez besoin, à quel moment ils sont nécessaires ainsi que
leur lieu d'origine. Si vous avez l'intention de faire appel à des ressources externes ou à de
nouveaux employés vous pourriez avoir besoin d’indiquer à quel moment vous allez commencer
à recruter pour ces postes.
 Formation. Dans de nombreux cas, vous pourriez disposer d’un nombre adéquat de membres
de l'équipe propres à faire réussir votre projet. Cependant, certains pourraient être dépourvus
de toutes les compétences nécessaires. Si vous êtes au courant des besoins de formation pour
des personnes spécifiques, vous devez le mentionner dans cette rubrique. Cette dernière
n’aurait pas à s’occuper par contre des capacités générales nécessaires à une amélioration des
compétences au niveau de l'organisation. Elle ne devrait s'occuper que de la formation
nécessaire pour faire évoluer ce projet.
 Réassignation. Une fois que tous les projets auront pris fin, dressez un plan pour la
réaffectation des différents membres de l'équipe une fois que leur rôle dans le projet est
achevé.
 Système de récompenses et de sanctions du projet. Si on a prévu des récompenses

spécifiques pour le personnel du projet, il faudra le mentionner. Ces récompenses pourraient
simplement être des reconnaissances non pécuniaires tel un " merci " formel lors des réunions
de révision du projet. Il peut aussi y avoir des avantages pécuniaires récompensant
l'achèvement réussi du projet. Il va de soi qu'une performance faible ne sera pas récompensée.
340
8.1.2 Constituer l’équipe de projet
Les projets moyens et grands demandent presque toujours des membres pour étoffer leur équipe. Dans
de nombreux cas, ces personnes sont affectées par un manager du personnel ou un manager exécutif,
et aucun autre travail n’est nécessaire pour les obtenir. Au fond, vous avez juste à utiliser des
personnes disponibles et qui correspondent exactement aux besoins de votre projet. Cependant, pour
certains projets, vous avez besoin de savoir comment les trouver.
Une des premières décisions élémentaires que vous devriez prendre est de savoir si vous voulez
recourir à des employés, à des contractuels, ou à une certaine combinaison des deux profils.
appropriées
8.1.2.2 L’entretien avec de nouveaux membres de l’équipe
341
appropriés
Les entreprises disposent, aujourd’hui, de plusieurs options quand elles veulent déterminer comment
pourvoir en personnel une équipe de projet. Vous pouvez utiliser les employés déjà en place, en
embaucher de nouveaux, faire appel à des contractuels, comme vous pouvez tout simplement décider
de sous-traiter tout ou une partie de votre projet. Ces choix sont le résultat des progrès accomplis dans
les domaines de la communication et de la technologie, mais aussi du désir des entreprises d’être plus
souples dans leurs options de recrutement.
Votre entreprise a probablement une stratégie de gestion du personnel qui peut guider votre choix
entre le recours à des employés, à des contractuels ou à la sous-traitance. Si votre entreprise a une
stratégie, vous devriez être en mesure de l’appliquer à la situation de votre projet et de déterminer
l’approche la plus efficiente pour vous pourvoir en personnel.
Peut-être faut-il prendre comme point de départ la disponibilité des agents pendant la période où votre
projet en a besoin. Il n’est pas logique, en général, de recruter des contractuels quand il y a des
employés qui sont disponibles et qui, par ailleurs, n’ont pas grand-chose à faire (à supposer qu’ils aient
les compétences spécifiques recherchées).
Supposons que vous n’ayez pas trouvé ce que vous cherchez, parmi les employés du moment, pour
pourvoir votre projet en personnel. Supposons aussi que vous travaillez dans une entreprise qui accepte
le recours aux contractuels ou au recrutement en fonction des besoins spécifiques de votre projet.
Regardons maintenant quelques critères que vous pouvez utiliser pour prendre la décision de recruter.
(Des critères similaires peuvent être trouvés dans la stratégie de gestion du personnel, si jamais elle
existe).
 L’urgence. Si vous avez l’intention de commencer très rapidement, vous aurez besoin de
recruter des contractuels. Dans la plupart des entreprises, vous pouvez faire appel aux agences
locales d’intérim et, dans les deux jours qui suivent, vous entamez les entretiens avec les
candidats. La plupart des entreprises ne peuvent pas (et ne veulent pas) recruter des employés
aussi rapidement. Vous devez examiner les possibilités de recruter des contractuels, puis
demander, en option, le droit de recruter des employés dans le futur.
 La durée du besoin. Si vous voulez du personnel pour une durée brève et déterminée, alors
les contractuels devraient faire l’affaire. Vous pouvez les engager pour un contrat de courte
durée puis leur donner congé, quand le travail est terminé. Si vous avez besoin d’un plein
temps, pour une longue période, il est plus logique de faire appel à un employé.
 Le travail est stratégique ou pas. Beaucoup de compagnies identifient certains travaux

comme plus stratégiques que d’autres. Par exemple, elles choisissent de nommer des employés
aux postes importants, comme celui de chef de projet, et préfèrent recourir au travail
contractuel pour la planification, les tests et la mise en œuvre.
 Les compétences et savoir-faire requis. Beaucoup d’organismes prennent leurs décisions

concernant le personnel en se basant sur le type de compétences requises. Par exemple, si
vous vous engagez dans une nouvelle technologie, vous aurez envie de recruter des employés
pour constituer un noyau de compétences autour de cette technologie au sein de l’entreprise.
De même, si vous installez de nouveaux logiciels, vous allez probablement chercher à garder
quelques employés sur le projet pour être sûr que le savoir-faire va se maintenir dans
l’entreprise, à la fin du projet.
 La confidentialité. La plupart des compagnies vont choisir d’affecter des employés aux postes
à pourvoir, si l’équipe du projet est amenée à avoir connaissance d’informations confidentielles
ou soumises à un droit de propriété. En effet, il est à craindre que l’information ne soit plus
confidentielle lorsque le contractuel quitte l’entreprise.
 Le coût. En général, le coût horaire d’un contractuel est plus élevé que le coût correspondant
d’un employé à plein temps. Cependant, habituellement, les implications du coût à long terme
342
sont semblables. Avec un contractuel, vous payez, en général, un taux horaire plus élevé, mais
seulement durant la période où vous avez besoin de lui. Les employés coûtent moins cher à
court terme, mais vous prenez envers eux des engagements à long terme.
Si vous examinez les critères ci-dessus, vous pouvez constater que bon nombre de questions
concernant le recours aux employés ou aux contractuels peuvent devenir des risques. Si le projet est de
courte durée, il peut être risqué de recruter un employé car vous n’êtes pas sûr de lui trouver une
occupation à long terme. Si le projet implique un noyau de compétences essentielles pour votre
institution, des informations confidentielles ou s’il est stratégique pour vos affaires, il est tout aussi
risqué de recruter un contractuel.
Les entreprises, de nos jours, ont tendance à garder un personnel réduit à un noyau d’employés. Ce
noyau demeure relativement constant, d’année en année, alors que l’accroissement des charges de
travail est comblé par les contractuels. Vous devez simplement vous assurer que les employés sont
généralement recrutés pour travailler dans des secteurs qui sont déterminants pour le succès à long
terme de votre entreprise. Les besoins additionnels pour pourvoir des postes non stratégiques, à faible
risque ou de type courant, peuvent être satisfaits par le recours aux contractuels ou à la sous-traitance.
343
8.1.2.2 L’entretien avec les nouveaux membres de l’équipe
Une fois votre projet approuvé et prêt à être réalisé, vous devriez former l’équipe de projet. Certaines
personnes travailleront à temps plein, d’autres à temps partiel. Il peut s’agir d’un ensemble constitué de
contractuels et d’employés. Dans de nombreux cas, les employés qui deviennent membres de l’équipe
sont affectés en fonction de leur disponibilité et de leur profil. Cependant, dans de nombreux cas, vous
devez embaucher de nouveaux membres pour certains postes, soit pour une durée déterminée, soit
pour une durée indéterminée.
Le processus d’entretien est important. Il l’est encore plus si la personne sera employée à plein temps.
Voici quelques règles simples à retenir avant que vous ne procédiez à un entretien.
 Comprendre le poste ouvert. Parfois, des personnes se mettent à interviewer un candidat

puis se demandent, à la lumière de cet entretien, à quel poste elles vont l’affecter. Vous
évaluerez mieux le candidat si vous avez une bonne représentation mentale de la tâche qu’il
sera amené à accomplir.
 Comprendre votre rôle. Différentes personnes ont souvent des rôles et des attentes
différentes dans le processus d’entretien. Par exemple, on pourra vous demander si le candidat
a une personnalité qui convient au groupe. On pourra également vous demander de procéder à
un entretien technique. Chaque personne qui effectue un entretien doit savoir quelles attentes
spécifiques sous-tendent l’entretien.
 Soyez prêt. Assurez-vous que vous avez consulté le CV du candidat avant l’entretien. Préparez
quelques questions qui vous permettront d’en savoir plus sur les traits essentiels de la
personnalité du candidat et sur ses aptitudes. Vous aurez sûrement aussi à poser quelques
questions dans le cadre du processus d’examen standard de votre compagnie.
 Libérez votre esprit. N’abordez pas l’entretien en ayant en tête l'échéancier que vous n’aurez
pas à exécuter ou les problèmes de production que vous devriez régler. Lors de l’entretien,
concentrez-vous sur la discussion en cours.
 Interrogez et écoutez. Avez-vous participé à un entretien au cours duquel l’intervieweur

était le seul à parler ? Votre rôle ne consiste pas à parler constamment. Posez plutôt des
questions et tâchez d’écouter les réponses. Posez des questions qui permettent, lorsque cela
est possible, de prolonger le dialogue.
Il peut être intéressant que plusieurs membres de votre équipe soient présents lors de l’entretien. Dans
ce cas, deux méthodes sont possibles. La première est " la porte tournante". Vous placez le candidat
dans une pièce et vous faites entrer les intervieweurs chacun à son tour. De même, le candidat peut se
déplacer d'un bureau à l’autre pour parler seul à seul avec chacun des intervieweurs. Cette méthode
permet à chacun de se faire une opinion, indépendamment des autres, avec des approches et des
questions différentes. Elle est néanmoins relativement longue et éprouvante pour le candidat.
La seconde est " l’inquisition espagnole ". Vous rassemblez l’équipe d’intervieweurs dans une pièce avec
le candidat. Cette approche permet à chacun d’entendre la même histoire en même temps que les
autres ; elle permet aussi l’utilisation efficace du temps du candidat. L’inconvénient, c‘est qu’elle peut
être très intimidante. Vous devez vous efforcer de maintenir une ambiance amicale et détendue.
Nombreux sont ceux qui préfèrent cette méthode, dans la mesure où elle montre comment le candidat
réagit sous une certaine pression.
Votre compagnie compte sur vous pour s’assurer que seuls les bons candidats seront embauchés. Il
s’agit d’un travail important et vous devez le prendre au sérieux. Que les interviews se déroulent
individuellement ou en groupe, posez les bonnes questions et écoutez les réponses attentivement. Puis,
soyez prêt à donner honnêtement vos impressions lors du processus de débriefing. Votre apport au
processus d’entretien gagnera en efficacité et permettra à votre compagnie d‘embaucher des gens
valables sur le long terme.
344
8.1.3 Développer l’équipe de projet
Indépendamment de la manière dont une équipe de projet est composée, le chef de projet doit
s’assurer que les membres de l’équipe ont les aptitudes requises pour assumer leurs tâches. En fait, si
les membres de l’équipe n’ont pas ces aptitudes et que le chef de projet ne peut les aider à les
acquérir, cela peut constituer un risque pour le projet. Cela ne veut pas dire que vous devriez envoyer
ces personnes en formation. De nombreuses autres opportunités d’apprentissage peuvent servir, telles
que :
 Les magazines. Chaque domaine et chaque industrie dispose de magazines spécialisés. Un

grand nombre de ces magazines sont gratuits ou disponibles à faible coût.
 Les livres. Les livres sont semblables aux magazines, excepté le fait que, généralement, ils
exposent avec beaucoup plus de détails les pensées et les idées nouvelles.
 Des séminaires et ‘‘webinaires’’. Les compagnies subventionnent fréquemment des

séminaires. Certains séminaires se sont transformés en webinaires (séminaires sur le web). Un
grand nombre de ces évènements sont gratuits. Il faut seulement prendre le temps d’y
participer. Ils durent généralement un peu plus d’une heure par jour.
 L'encadrement. L'encadrement implique un transfert de conseils de la part d'une personne

dotée d'expérience (le mentor) à une personne qui est en train d'apprendre. Un membre de
l'équipe peut rencontrer d'une façon continue un mentor pour discuter des situations que le
membre rencontre et comment le mentor avait pu traiter des situations similaires dans le
passé. Cela pourrait être le cas pour les situations dans les quelles un membre de l'équipe
pourrait apprendre des connaissances techniques, commerciales, des politiques de bureau ou
n'importe quel domaine là ou les informations peuvent être partagées. La plupart des gens
adorent parler de ce qu’ils font et seront heureux de le faire.
 Des classes d’autoformation et d’e-formation. La plupart des compagnies ont un service

d’e-formation avec des vidéos à la disposition des employés. Ces vidéos peuvent être une
bonne alternative à formation formelle dispensée en classe, étant donné que chacun peut
regarder ces vidéos à sa convenance et à son rythme.
 Divers. Il y a d’autres opportunités pour le développement personnel. Il faut seulement faire

preuve d’imagination. Cela inclut la participation aux activités des associations professionnelles,
la formation par Internet, les cours du soir, aller écouter des communications à l’université
locale, l’enseignement à distance, etc.
Bien sûr, vous ne devez pas oublier la formation en classe. Parfois, elle constitue la meilleure option si
les aptitudes acquises peuvent être appliquées directement à votre projet. Cependant, soyez assidu et
pensez que c’est la seule manière d’arriver aux aptitudes auxquelles vous aspirez. Il y a d’autres voies
efficaces, selon l’aptitude recherchée. La clé d’une formation réussie, quel que soit son domaine, est
que l’on soit capable d’appliquer ce qu’on a appris au projet, immédiatement après l’acquisition des
nouvelles compétences.
345
8.1.4 Diriger l’équipe de projet
C’est sur ce problème que butent la plupart des gens qui s’occupent de gestion du travail. Gérer
l’équipe du projet implique de surveiller le rendement, d’informer les intéressés sur l’évaluation de ce
rendement, de résoudre les problèmes des membres de l’équipe de s’assurer que le rendement collectif
de l’équipe atteint un niveau élevé.
Il n’y a réellement pas de processus consacré à la gestion du personnel. Vous ne pouvez pas trouver
une procédure pour une approche étape par étape pour gérer le personnel. Cependant, la gestion du
personnel utilise un ensemble de techniques et de moyens. Ces différentes techniques sont utilisées de
manière proactive et réactive, selon la situation et les besoins de l’équipe. La raison pour laquelle les
chefs de projets trouvent des difficultés à gérer les membres de l’équipe ne réside pas dans le fait qu’ils
ne disposent pas d’un processus préétabli, mais plutôt dans le fait qu’ils ignorent les techniques de
gestion du personnel ou n’arrivent pas à les appliquer.
Un certain nombre de techniques qui peuvent être appliquées dans différentes situations sont
expliquées dans le paragraphe 8.2 Gérer les ressources humaines / Techniques.
346
8.2 Gérer les ressources humaines / Techniques
Vous trouverez ci-dessous quelques techniques de gestion des ressources humaines.
8.2.1 Les techniques de constitution du staff
347
8.2.1 Les techniques de constitution du staff
Utiliser des techniques spéciales pour les équipes dispersées (8.2.1. P1)
Dans le passé, une équipe de projet était toujours installée sur un même site. Les raisons étaient
évidentes : il n’était pas facile de communiquer et de collaborer avec des gens qui ne se trouvaient pas
au même endroit. Aujourd’hui, il est encore courant qu’une équipe se trouve dispersée sur des sites
proches. Cependant, il devient de plus en plus courant que des membres de l’équipe soient
physiquement disséminés un peu partout, peut-être pour se rapprocher du personnel externe se
trouvant dans les bureaux d’une autre compagnie. Dans certains cas, vous aurez des membres de
l’équipe qui font du télétravail, à partir de chez eux. Dans d’autres cas, vous vous associerez avec une
tierce personne, qui se trouve peut-être à l’étranger.
Tout ceci devient plus courant, aujourd’hui, en raison des avancées technologiques et des nouveaux
logiciels. Vous pouvez accéder au réseau de votre entreprise à distance, avec le même débit que si
vous étiez dans votre bureau. Des logiciels permettent de partager des documents, de faire des mises à
jour en temps réel et des envoyer au reste de l’équipe. Les membres de l’équipe peuvent communiquer
les uns avec les autres, s’ils le désirent, en organisant des téléconférences ou en utilisant les
technologies de la vidéo sur le web.
Tout cela présente des avantages. Cependant, une équipe sur un même site est nettement plus facile à
gérer. Aucune technologie ne peut remplacer le fait de se retrouver face à quelqu’un, de pouvoir lui
parler, de le toucher. Si vous avez une équipe de projet dispersée, vous devez l’identifier comme un
risque, lors de la définition du projet. Cela n’est pas un risque majeur, vu qu’il ne pose pas de problème
pour l’instant. Cependant, il y a un risque que cela puisse poser un problème à l’avenir. Établissez alors
un plan de gestion des risques qui atténuera les risques et évitera que des problèmes surviennent à
l’avenir. Prenez en considération les propositions suivantes :
 Assurez-vous que tout le monde dispose de la même technologie. Assurez-vous que les
membres distants ont le bon équipement, les bons hardwares et logiciels pour accomplir leur
travail. Par exemple, si certains membres travaillent à partir de chez eux, un modem 14.4 ne
suffira probablement pas. Vous avez certainement besoin de connections permettant un accès
rapide.
 Utilisez une technologie collaborative. Il y a de nombreux produits sur le marché qui

permettent d’avoir une collaboration plus facile entre les personnes placées sur des sites
différents. Ces produits sont, pour la plupart, configurés pour l’Internet. Par exemple, vous
pouvez utiliser des logiciels qui permettent à tous de participer à un meeting commun sur la
toile, voire de montrer et d’échanger des documents qui intéressent tout le monde.
 Assurez-vous que tout le monde a une attitude adéquate. Le chef de projet et les
membres de l’équipe doivent être particulièrement attentifs et sensibles aux problèmes de
collaboration et de travail de l’équipe lorsqu’une partie d’entre elle se trouve éloignée. Un
travailleur éloigné peut facilement se retrouver isolé du reste de l’équipe et du travail qui s’y
accomplit. Les personnes qui travaillent à distance doivent communiquer d’une manière
proactive et être particulièrement capables de travailler de manière indépendante, tout en
respectant les délais.
 Établissez de bons processus de communication. Le chef de projet doit développer un

plan proactif de management des communications pour s’assurer que l’équipe dispersée
travaille de concert. Par exemple, il devrait y avoir, si possible, des réunions programmées où
les travailleurs éloignés se rencontrent face à face. Si les membres de l’équipe se trouvent dans
des villes ou des pays différents, cherchez un moment qui arrange tout le monde et où vous
pouvez organiser une télé ou une audioconférence.
 Planifier les relais. Parfois, de nombreuses personnes installées sur des sites différents
travaillent sur le même produit livrable, ou sur un produit livrable relié à celui des autres. Dans
ces cas-là, le chef de projet doit établir des règles pour les passages de relais, surtout en cas
348
de décalage horaire. N’abandonnez pas cela au hasard. Établissez des procédures pour vous
assurer que les travaux sur des livrables partagés transitent sans accrocs d’une personne ou
d’une équipe à l’autre.
l’équipe. Le risque augmente avec la distance, en raison, par exemple, du décalage horaire. Cependant,
un chef de projet proactif peut contourner ces difficultés en considérant de manière globale les
préoccupations liées au personnel, aux logiciels ou à la technologie. Un plan de gestion des risques
peut être établi pour atténuer les aléas et faire en sorte que l’équipe dispersée travaille de concert, pour
le bien commun du projet et de l’équipe.
Recrutez une force de travail diversifiée mais en ne transigeant pas sur la qualité des
candidats (8.2.1. P2)
Tout le problème de la diversité est très sensible aux yeux de beaucoup de gens, pour qui le fait de
d’insister sur la diversité est synonyme de recrutement de mauvaise qualité, et ce, dans l’objectif de se
conformer aux quotas. En fait, l’intérêt accordé à la diversité est un problème beaucoup plus complexe.
Il faut prendre comme point de départ le rôle de la diversité en termes de valeur économique, car la
discussion n’aboutirait à rien si la valeur économique ne constitue pas sa toile de fond. Aucune
entreprise ne va prendre le train de la diversité en marche si elle n’y trouve pas de bénéfice
économique réel. Deux arguments de base jouent en faveur de la diversité. Le premier est le principe
élémentaire d’équité. Le second est la valeur économique à long terme d’une force de travail diversifiée.
Commençons par l’équité élémentaire : L’objectif d’un recrutement pour une entreprise vise toujours à
trouver la bonne personne à placer dans un poste vacant. Cela concerne autant les candidats internes
que les candidats externes, s’ils ont les qualités requises. Bien évidemment, chercher le « meilleur »
candidat peut s’avérer très subjectif. Que signifie être le « meilleur » candidat ?
Livrés à eux-mêmes, des managers différents auront des opinions différentes sur ce qui fait qu’un
candidat est le « meilleur ». Dans certains cas, ils vont choisir la personne qui présente le meilleur
ensemble de compétences pour occuper le poste. Dans d’autres cas, ces managers vont choisir des
personnes qui leur ressemblent. Cette tendance est normale et résulte de deux préjugés, l’un naturel,
l’autre pratiquement inconscient.
1. Un responsable du recrutement a tendance à évaluer les qualifications d’une personne en

utilisant son propre bagage comme étalon. Après tout, si un manager ayant un certain bagage
finit par se trouver dans la position qu’il occupe, n’est-il pas logique de chercher les mêmes
traits chez une autre personne ? Cependant, d’une manière générale, quand un manager prend
ce genre de décision inconsciente, il prend la décision de choisir la personne qui tend à lui
ressembler le plus.
2. L’autre préjugé se glisse sous couvert d’évaluation de l’aptitude d’une personne à s’adapter au
reste de l’équipe. Cela revient souvent au fait qu’il n’y a pas de leader qui s’affirme en tant que
tel en termes de bagage et de compétences. S’il n’y a pas un candidat évident sur la base de la
formation et des compétences, celui qui mène l’entretien commence à chercher des éléments
de différenciation. L’un de ces éléments est d’évaluer dans quelle mesure le candidat s’intégrera
bien avec le reste de l’équipe. Si la majorité des membres de l’équipe sont d’une certaine race
et possèdent un certain background, il y a une tendance naturelle à penser que les gens qui
ont des traits similaires s’entendront mieux, ou, au moins, beaucoup mieux que des personnes
qui ont des caractères différents.
Si les équipes sont livrées à elles-mêmes, ces deux ensembles de préjugés naturels ont tendance à
aboutir à ce qu’un groupe de membres semblables cherchent un candidat qui leur ressemble. Ils vont
recruter une personne ayant une apparence et un background ressemblant aux leurs. Dans certaines
affaires et certaines entreprises, cela débouche sur un préjugé envers les travailleurs du sexe opposé.
Dans d’autres cas, il n’y a pas de préjugé fondé sur le genre, mais plutôt ceux fondés sur la culture et la
race.
Les entreprises, en particulier les plus grandes, ont essayé de formaliser et de standardiser les
opérations de recrutement de telle manière que chaque candidat puisse être jugé sur la base des
349
mêmes critères. L’objectif d’un processus standardisé n’est habituellement pas de recruter des
travailleurs d’horizons divers. Il consiste à secouer le plus possible de préjugés inconscients et de faire
en sorte que c’est le candidat le plus qualifié qui est recruté. Beaucoup de personnes sont
généralement impliquées dans le processus de recrutement. Les candidats sont jugés par plusieurs
personnes utilisant des critères standardisés, dans l’espoir de bannir, autant que possible, toute
subjectivité et de faire en sorte que les recommandations finales soient aussi objectives que possible.
Beaucoup de responsables du recrutement prennent ombrage à cause des restrictions que les services
de ressources humaines imposent au processus de recrutement. En fait, il est évident que certaines
entreprises ont développé un processus de recrutement lourd et qui fonctionne mal. Cependant
beaucoup parmi ces processus sont valables. Ils n’ont pas été conçus pour être la voie de recrutement
la plus facile, mais pour garantir que chaque candidat soit traité équitablement et loyalement, et que
chaque décision de recrutement est basée sur des faits et non sur les préjugés inconscients que portent
beaucoup d’entre nous.
Il n’est donc pas difficile de parvenir à un accord pour que le meilleur candidat soit recruté au moyen
d’un processus loyal de sélection par lequel tous les candidats devront passer. On suppose, au moins,
que les choses devraient se passer ainsi.
En plus de l’argument de l’impartialité élémentaire, la diversité apporte à l’entreprise des bénéfices

économiques réels. Une des hypothèses principales au sujet de la diversité, c’est que personne
n’essaierait de l’imposer si nous étions tous les mêmes. Cependant, c'est un fait que notre société dans
sa globalité est diverse et que les entreprises existent et commercialisent leurs produits dans ce marché
diversifié. Elles ont découvert que la diversité se traduit par la capacité d’exister et de prospérer dans
un marché diversifié. L’entreprise en tire des bénéfices au moins dans trois domaines spécifiques.
 Tirer profit du marché. La logique de base, ici, c’est qu’il est difficile, sinon impossible, de
toucher effectivement un marché diversifié sans un personnel diversifié. Si vous essayez, par
exemple, de toucher des clients d’origine chinoise, il est logique que vous ayez quelques
employés capables de comprendre la mentalité chinoise, qui participent au développement, aux
ventes et marketing du produit. Cela ne veut pas dire que tout le monde doit être d’origine
chinoise, mais que certains le soient. Même chose pour toutes les autres origines ethniques.
Comme le marché est diversifié, vous avez besoin de gens possédant le background et la
mentalité de ces groupes ethniques. Avec eux, vous pouvez effectivement investir un marché
diversifié.
 Prendre de meilleures décisions. Les gens qui ont le même type de background peuvent
avoir tendance à penser de manière semblable et cela peut influer sur les décisions qu’ils sont
amenés à prendre. Les managers ont besoin d’un ensemble d’opinions diverses pour fixer les
meilleurs buts, objectifs et stratégies pour l’entreprise. Bien sûr, certaines personnes sont très
créatives, mais il est difficile d’être créatif dans des secteurs dont on ignore le background et le
contexte. Avoir une structure de management diversifiée permet de mieux orienter les
décisions de l’entreprise, dans un monde divers.
 Mieux recruter. En fin de compte, il y a un bénéfice à tirer de l’aptitude à recruter la

meilleure personne, indépendamment de son background.
350
Essayez de constituer une équipe très performante (8.2.2. P1)
Avez-vous déjà participé à un projet où tout marche bien ? L’accord règne entre les membres de
l’équipe. Tous possèdent les compétences requises. Chacun travaille dur et tous s’efforcent de réaliser
le projet.
Ce sont là quelques-unes des caractéristiques d’une équipe très performante. Les équipes hautement
performantes peuvent quelquefois se former d’elles-mêmes, peut-être même se passer de l’aide d’un
manager. Cependant, il est plus courant qu’un manager aide une équipe à devenir hautement
performante et la soutienne à travers un processus qui amène l’équipe à devenir aussi efficace et aussi
productive que possible.
Pour certains managers, cette voie est très difficile, sinon impossible. Ils peuvent être très organisés,
techniquement très forts et être aussi des maîtres en matière de politiques organisationnelles, mais ils
peuvent aussi être de mauvais gestionnaires de personnel ou s’avérer peu efficaces pour construire une
équipe À certains égards, il est aussi très difficile pour un manager d’amener une équipe à devenir
hautement performante s’il n’a jamais fait partie, lui-même, d’une équipe très performante. Atteindre la
haute performance est presque un rêve et si votre rêve n’est pas basé sur une expérience, il sera très
difficile d’amener un groupe de gens à l’atteindre.
Vous ne pouvez pas commencer avec une nouvelle équipe et espérer qu’elle devienne très performante
en un jour, une semaine ou un mois. Beaucoup d’aspects de la construction d’une équipe très
performante nécessitent une longue période pour donner leurs fruits. Vous vous rendrez compte que
les équipes dont les membres n’ont pas travaillé ensemble auparavant passent habituellement par
quatre stades du développement d’une équipe, comme défini par le modèle de Tuckman. Ces stades
sont les suivants :
 La constitution : Les membres de l’équipe se rencontrent pour la première fois. Ils ne

peuvent pas compter les uns sur les autres car ils ne connaissent ni les compétences ni les
forces ni les faiblesses de chacun d’entre eux.
 La tempête : L’équipe se bat pour comprendre les rôles et les responsabilités dévolus à
chacun des membres. Habituellement, c’est à ce moment-là que commencent à apparaître les
conflits de personnalité. Les membres de l’équipe se sentent plus à même de se plaindre que
pour proposer des solutions. A peine se connaissent-ils qu’ils se mettent à se disputer.
Généralement, l’équipe est dans une situation de fluctuation et les gens ne savent pas ce qu’ils
sont supposés faire. Certaines équipes immatures ne dépassent jamais ce stade.
 La normalisation : Les membres de l’équipe commencent à s’habituer les uns aux autres. Ils
commencent à s’entraider et un esprit de camaraderie commence à prendre place entre eux.
L’équipe commence à se sentir globalement plus forte que lorsqu’elle n’était qu’un groupe de
collaborateurs individuels.
 La performance : C’est le dernier stade par lequel passe une équipe très performante. A ce
niveau, l’équipe est attachée aux mêmes objectifs, qu’ils soient écrits ou pas. Les membres
comptent les uns sur les autres. Quand un problème survient, tous se demandent quelle aide ils
peuvent apporter. Désormais, ils peuvent travailler sans trop avoir à être supervisés de la part
de leur hiérarchie. La productivité globale est très élevée et elle est reconnue comme telle par
des personnes extérieures à l’équipe.
Les membres d’une équipe hautement performante se font confiance les uns aux autres. Ils ne peuvent
atteindre ce niveau de confiance du jour au lendemain, ce qui explique encore plus le temps que ces
équipes mettent à se former. Ce genre d’équipe est rare ; cette rareté est la principale explication du
sentiment que continuent à éprouver, des années plus tard, ceux qui en ont fait partie.
Cependant, et comme il est mentionné plus haut, ces équipes ne se forment pas facilement. Ayant une
idée du résultat final, un manager peut essayer de mettre les pièces du puzzle en place pour permettre
351
à l’équipe de passer par les quatre stades du modèle décrit plus haut. Quelquefois, des équipes
n’arrivent jamais à dépasser l’un ou l’autre de ces différents stades et se trouvent alors incapables de
devenir performantes. Heureusement, il y a des solutions à apporter pour favoriser l’essor d’une équipe.
 Fixer des objectifs communs : Les équipes ont du mal à devenir très performantes jusqu’à
ce que leurs membres soient attachés à un ensemble d’objectifs communs. Même si les
membres de votre équipe exécutent des tâches différentes, un ensemble d’objectifs les
concernant tous peut être fixé par écrit. Si possible, l’équipe doit être récompensée sur la base
de l’accomplissement de cet ensemble d’objectifs. Cela peut aider à faire en sorte que tout le
monde soit poussé vers la même direction.
 Etablir de bons processus internes de travail : C’est un fait que vous ne pouvez pas
fabriquer de manière uniforme un bon produit ou offrir de bonnes prestations de services avec
de mauvais processus. L’équipe très performante dispose d’un ensemble de processus internes
qui peuvent orienter la manière d’agir et de réagir de ses membres dans des circonstances
particulières. Par exemple, si un problème apparaît, ils savent comment recourir à des
techniques de résolution Si un client formule une demande de modification de spécifications, ils
savent recourir aux procédures de modifications de contenu. De cette façon, ils laissent aussi
peu de place que possible à l’incertitude. Une autre qualité inhérente à ce genre d’équipes,
c’est que les membres cherchent constamment à améliorer leurs processus courants. Un
processus qui était parfait il y a un an ne l’est plus aujourd’hui. L’équipe remet constamment en
question l’état actuel des choses et œuvre à l’amélioration de cet état.
 Insuffler une bonne éthique de travail : Cela constitue l’évidence même. Les équipes très
performantes se forment rarement dans un environnement où les gens se plaignent de leur
charge de travail ou bien des habitudes de travail des autres membres. Les équipes très
performantes relèvent les défis et travaillent dur pour achever les tâches qui leur sont
assignées, conformément aux attentes. Parfois, travailler durement est confondu avec le fait
d’effectuer un grand nombre d’heures. Ce n’est pas la même chose. Une équipe hautement
performante travaille efficacement et intelligemment. Ses membres effectuent plus de travail en
une journée ordinaire que leurs homologues (en fait, une équipe qui fait tout le temps des
heures supplémentaires, a probablement des problèmes de concentration qui doivent être
résolus pour la sortir de l’ornière). D’un autre côté, l’équipe très performante comprend quand
ses membres doivent faire un effort pour réaliser les objectifs du projet et quelquefois, cela
peut demander quelques heures supplémentaires.
 Veiller à ce que chacun reste concentré : Une équipe très performante est concentrée sur
les objectifs et les livrables et sait comment les réaliser. Ses membres ne se laissent pas
distraire par les rumeurs ou la politique. Ils ne se laissent pas absorber par les commérages. Ils
ne passent pas plus de temps à se plaindre qu’à travailler. Ils savent ce qu’on attend d’eux et
font du mieux qu’ils peuvent pour répondre à ces attentes
 Maintenir un haut niveau de motivation : Une telle équipe est consciente des défis liés à
la réalisation des objectifs et à l’achèvement des livrables. C’est à la fois de l’auto-motivation de
la part de chaque membre et une motivation renforcé au sein de l’ensemble de l’équipe.
 Rester organisé : Les membres de l’équipe savent quel rôle leur est dévolu au sein de
l’équipe et quel est aussi le rôle de chacun d’eux. Ils connaissent le travail qu’ils doivent
effectuer le jour même et ce qui leur restera à faire par la suite. Ils connaissent les processus
et les procédures nécessaires pour faire avancer l’équipe, y compris la gestion des modifications
du contenu, la gestion des risques, la gestion des problèmes majeurs, la gestion de la qualité et
les rapports d’avancement. Si des évènements inhabituels se produisent, ils savent comment
gérer le processus et comment monter en puissance, s’il le faut.
 S’efforcer d’avoir un ensemble équilibré de compétences essentielles : Une équipe

très performante dispose de toutes les compétences nécessaires pour achever le travail dont
elle a la charge. Les membres de l’équipe ont les compétences nécessaires d’un point de vue
technique aussi bien qu’un ensemble de compétences correspondant à leur rôle ou fonction.
Par exemple, il est difficile d’être une équipe très performante quand chacun veut être le chef
de l’équipe. Si on demande à ces « leaders » de construire plutôt un livrable, ils n’auront ni les
compétences appropriées ni la motivation pour que l’équipe réussisse. S’il lui manque certaines
352
compétences pour une courte durée, ces dernières peuvent être fournies, au besoin, par des
collaborateurs extérieurs. Si l’équipe a besoin de certaines compétences à long terme, les
membres de l’équipe doivent recevoir la formation nécessaire pour effectuer le travail à l’avenir.
Dans une équipe très performante, les gens connaissent leurs forces et leurs faiblesses, mais ils
cherchent aussi à travailler, si c’est nécessaire, hors des domaines où ils se sentent à l’aise.
 Encourager le respect mutuel : Les membres des équipes très performantes passent,
généralement, beaucoup de temps ensemble. Ils éprouvent du respect les uns envers les
autres et sont persuadés qu’ils travaillent avec autant d’abnégation les uns que les autres. Ils
apportent leur aide aux autres membres quand ceux-ci en ont besoin et savent que ces
derniers auront une conduite similaire envers eux, en cas de besoin. En général, les membres
de l’équipe sont d’humeur égale et ne sont pas enclins à l’extase ou à la dépression. Ils
respectent les aptitudes de chacun et apportent leur aide en compensant toute faiblesse
éventuelle, parce qu’ils savent que les autres sont prêts à compenser, s’il le faut leurs propres
faiblesses.
Dans de telles circonstances, un manager peut prendre les rênes pour mener une équipe vers la haute
performance. Cela prend du temps, et dans beaucoup de cas, le résultat s’avère décevant. Si la chose
était facile, chaque équipe deviendrait très performante, au lieu de l’une ou des deux équipes où vous
avez travaillé au cours de toute votre carrière. Lorsque quelqu'un est motivé pour suivre cette voie, on
doit faire les suggestions suivantes :
 Renforcer l’équipe : Les équipes, comme les individus, mûrissent avec le temps, si on leur
permet de prendre de plus en plus de décisions pouvant avoir un impact sur elles. Si l’équipe
est tenue en laisse et doit toujours demander des instructions au chef, elle aura peu de
motivation ou de désir de mûrir et d’atteindre de hautes performances. Il est possible qu’une
équipe très performante n’ait pas besoin d’un responsable officiel. Pour atteindre ce stade,
cependant, le responsable doit permettre à l’équipe de prendre ses propres décisions chaque
fois que c’est faisable. Plus l’équipe mûrira, plus il faudra lui donner de latitude. Dans une
équipe hautement performante, le responsable doit agir comme un coach qui donne des
conseils plutôt que comme un responsable officiel qui dit à chacun ce qu’il doit faire.
 Établir les processus de travail de l’équipe : L’équipe a besoin de disposer de bon

processus à suivre, pour prendre en main les problèmes majeurs, les demandes de
modification, les rapports d’avancement, etc. Les membres de l’équipe doivent comprendre
comment se fait l’approbation, comment diagnostiquer les risques potentiels et à quoi les
livrables doivent ressembler. Nombre de procédures nécessaires peuvent être disponibles, mais
beaucoup restent probablement à définir de façon formelle. Dans le meilleur cas, l’équipe de
projet doit appliquer des procédures déjà mises en place pour la totalité de l’organisme. Mais, si
l’organisme ne dispose pas de procédures de travail standardisées, l’équipe devra les établir
elle-même et les adopter d’un commun accord lorsque le projet démarre.
 Investir dans la formation : Dans un monde parfait, le chef et l’équipe entière devraient
avoir une expérience de la technologie à employer et du contenu de ce qui sera livré. Les
membres de l’équipe doivent connaître l’entreprise et sa politique. En réalité cependant, le chef
et son équipe ont rarement toutes les compétences requises. Ils doivent comprendre ce qu’ils
n’ont pas pu connaître et essayer d’atteindre le niveau d’expertise requis, aussi vite que
possible. Cela implique, habituellement, que vous soyez aussi généreux que possible en matière
de formation, quand vous guidez une équipe sur cette voie. La formation peut être technique,
professionnelle ou concerner le domaine des affaires. Il faut aussi penser à des formations
spécifiques telles que les méthodes de constitution d’une équipe ou d’autres modules conçus
pour montrer à une équipe comment on arrive à travailler efficacement ensemble. Tout cela
permet de réduire le temps nécessaire pour atteindre les plus hauts niveaux de performance de
l’équipe.
 Être souple : Il est difficile de tout savoir et de tout planifier. Un des traits de caractère du
manager qui réussit est de travailler dans de bonnes dispositions dans un environnement qui
change constamment. Si le manager travaille efficacement dans cet environnement, la charge
de travail sera renouvelée continuellement et reflètera exactement ce qui doit être fait pour
353
mener le projet à son terme. Le manager est aussi capable tout le temps de traiter
efficacement les dynamiques de changement au sein de l’équipe.
 Surveiller la dynamique et les progrès de l’équipe : Lorsque l’équipe est en place et

qu’elle a reçu la formation nécessaire, elle doit être surveillée pour s’assurer que ses membres
progressent bien et qu’ils s’orientent vers un niveau de rendement et d’efficacité plus élevé. Le
manager doit constamment soutenir les comportements exemplaires et traiter les problèmes
quand ils surviennent. Lorsque l’équipe devient vraiment très performante, elle a tendance à
traiter elle-même ses problèmes, avant qu’ils ne filtrent en dehors de l’équipe.
354
Il existe des douzaines, voir même des milliers de techniques qui peuvent être appliquées à la gestion
du personnel dans de différentes situations. Plusieurs techniques sont décrites dans cette section qui
vont vous aider à gérer les membres de votre équipe de projet.
8.2.3. P1 Gérer de manière proactive les personnels dans une organisation matricielle
8.2.3. P2 Fournir une rétroaction significative sur les performances
8.2.3. P3 Donner en feedback des appréciations sur les performances, basées sur des faits,
de manière régulière et pas seulement au cours des réunions formelles
8.2.3. P4 Etre vigilent dans la gestion des personnes qui ont une faible performance
8.2.3. P5 Faire preuve de leadership dans les projets complexes
8.2.3. P6 Attaquer les problèmes liés au moral de l’équipe sur tous les fronts
8.2.3. P7 Agir avec diligence pour reprendre en main une équipe de projet inefficace
8.2.3. P8 Gérer les problèmes politiques comme des problèmes majeurs
8.2.3. P9 Aborder ouvertement les problèmes dont vous êtes la cause
8.2.3. P10 Faire preuve de leadership pour mettre en œuvre les demandes critiques de
changement
8.2.3. P11 Accepter l’autonomie des équipes autogérées
8.2.3. P12 Surmonter la résistance de l’équipe au management de projet
8.2.3. P13 Aborder les problèmes de performance au cours d’une première réunion en
amont
8.2.3. P14 Gérer les contractuels efficacement, mais différemment des employés du staff
8.2.3. P15 Comprendre votre staff technique et le gérer en conséquence
8.2.3. P16 Soyez sensible aux différences lorsque vous dirigez un personnel diversifié
8.2.3. P17 Résoudre graduellement un problème de rendement au moyen d’un plan formel
8.2.3. P18 Gérer les équipes virtuelles
Gérer de manière proactive le personnel dans une organisation matricielle (8.2.3. P1)
Un des aspects frustrants du poste de chef de projet est qu’il peut être difficile de gérer un projet
lorsque vous n’avez aucune autorité formelle de gestion sur les membres de votre équipe. D’un point de
vue organisationnel, si les gens ne s’adressent pas à vous comme à un supérieur hiérarchique, vous
opérez alors dans une sorte de structure matricielle. La matrice garantit l’utilisation efficiente du
personnel, mais elle peut constituer un défi pour les chefs de projet.
Comment responsabiliser les membres de l’équipe par rapport aux délais, sans cette autorité ?
Du côté du personnel, bien que les membres de l’équipe ne vous adressent pas leurs rapports
fonctionnels, leur travail sur le projet devra être pris en compte lors du passage en revue de leur
performance. De ce fait, vous pouvez essayer de responsabiliser les membres de l’équipe en leur
signalant que vous émettrez une rétroaction sur leur performance, lors du passage en revue. Cela doit
être approuvé et confirmé par les supérieurs hiérarchiques.
Bien sûr, si des membres de l’équipe dépassent leurs échéances, vous devriez également en chercher
355
les causes. Par exemple, si les capacités leur font défaut, vous devriez y remédier avec des formations
ou en les faisant remplacer. Si c’est parce qu’un membre ne comprend pas parfaitement quelles sont
vos attentes, vous devez également procéder à quelques changements.
Dans une perspective de gestion de projet, il y a des techniques et des processus de gestion de projet
qui devraient être utilisés. D’abord, si la disponibilité ou la performance de l’équipe sont en doute, vous
devriez très rapidement considérer cela comme un risque de projet. Dans le cadre d’une gestion des
risques, vous devriez mettre en place un plan proactif pour vous assurer que ce risque sera écarté.
Lorsque des gens dépassent leurs échéances et que la votre est aussi menacée de dépassement, vous
devriez déclarer un problème majeur et le gérer. Pendant cette gestion, cherchez à nouveau les causes
de ce problème et essayez de le résoudre.
De plus, assurez-vous que chaque membre de l’équipe communique de manière proactive avec vous.
Dans de nombreux cas, la frustration ne vient pas du fait que les gens ne respectent pas les délais. Elle
provient du fait que les personnes concernées ne vous ont pas tenu informé à l’avance. Si les membres
de l’équipe communiquent de manière proactive, vous avez le temps de voir venir le problème. Si un
membre de l’équipe rate uniquement une date et ne vous informe pas, c’est qu’il ne gère pas les
attentes comme il devrait le faire. De même, le chef de projet doit également s’assurer qu’il
communique de manière proactive. Communiquez bien avec votre équipe et assurez-vous qu’elle
connaît les délais impartis ainsi que les attentes. Communiquez de manière proactive avec les
supérieurs hiérarchiques des membres de l’équipe et assurez-vous qu’ils sont au courant quant aux
problèmes liés au partage du personnel ou à ses performances.
La gestion matricielle implique un effort d’équilibre complexe et délicat entre les chefs de projet et les
supérieurs hiérarchiques du personnel. Le chef de projet dispose souvent d’une autorité limitée dans la
gestion des personnes. Il est toutefois possible de mener à terme votre projet avec succès. Il y a de
nombreux processus de gestion de projet qui peuvent vous y aider. Utilisez-les, s’il le faut, pour
remédier à des risques ou des problèmes majeurs. Utilisez-les aussi avec votre commanditaire de
projet. Il peut vous venir en aide en suscitant un sentiment d’urgence et un surplus de concentration
sur le projet. Il peut également avoir une influence sur les supérieurs hiérarchiques vous permettant de
disposer du personnel nécessaire pour mener à bien votre projet.
Fournir une rétroaction significative sur les performances (8.2.3. P2)
Le rôle du chef de projet n’inclut pas un examen formel des performances des membres de l’équipe.
Cela relève de la responsabilité du chef hiérarchique de chaque employé. Cependant, il est clair qu’un
chef de projet doit fournir une rétroaction sur la performance des membres de l’équipe de projet, pour
les informer sur le déroulement de leur travail et leur dire s’ils répondent aux attentes concernant le
rendement. Cela implique de reconnaître éventuellement que les membres de l’équipe tiennent leurs
engagements et de signaler, le cas échéant, par une rétroaction, aux membres de l’équipe qu’ils ne
répondent pas à vos attentes.
Dire aux gens qu’ils font un bon travail est facile. Il est beaucoup plus difficile de dire à un membre de
l’équipe qu’il ne répond pas à vos attentes. Lorsque ce type de dialogue doit avoir lieu, le chef de projet
peut utiliser les techniques suivantes :
 Planifier. Cela aides chefs de projets à développer un cadre pour fournir une rétroaction
efficace. Le chef de projet devrait prévoir à l’avance quelle attitude mettre en relief et comment
il peut aider l’employé à répondre aux attentes.
 Donner des exemples. Les critiques vagues entretiennent l’anxiété. Des exemples tangibles
sont nécessaires dans la rétroaction. Généralement, vous n’avez pas besoin d’une dizaine
d’exemples. Vous devriez pouvoir arriver à convaincre votre employé avec quelques
observations significatives.
 Motiver. Utilisez des techniques de motivation dans la discussion. L’employé sera sûrement
déçu par la rétroaction. Cherchez, néanmoins, un moyen de lui remonter le moral pour qu’il soit
enthousiaste pour s’améliorer.
356
 Choisir la méthode « sandwich ». Le chef de projet devra commencer la session avec des
commentaires positifs, pour aller vers la rétroaction critique, puis terminer avec des
commentaires positifs et motivants.
 Prendre du temps pour la rétroaction. Le processus doit prendre la forme d’un dialogue
entre le membre de l’équipe et le chef de projet. Donc, demandez une rétroaction de la part du
membre de l’équipe, permettez-lui de dire s’il est d’accord ou pas et laissez-le exprimer son
point de vue.
 Fixer un délai pour l’action et le suivi. Le chef de projet doit conserver tous les éléments
de suivi, les diffuser auprès des membres de l’équipe et s’assurer qu’ils sont accomplis. Avant la
fin de la réunion, le chef de projet et le membre de l’équipe doivent aussi s’entendre sur un
délai de suivi pour évaluer l’amélioration.
Donner en feedback des appréciations sur les performances, basées sur des faits, de manière
régulière, et pas seulement au cours des réunions formelles (8.2.3. P3)
Le monde est composé de gens ayant des aptitudes et des talents divers. Souvent, les talents des gens
les amènent à travailler dans certains domaines où ils excellent. Dans d’autres cas, les talents
individuels ne sont pas conformes au type de travail demandé. Beaucoup de gens possèdent les
compétences générales et l’énergie nécessaire pour surmonter un manque d’adéquation.
Si chacun excelle dans le travail qu’il doit accomplir, on aurait beaucoup moins besoin des services des
ressources humaines. Mais cela ne se passe pas toujours ainsi. Certaines personnes ne sont pas
capables de répondre aux attentes et les gestionnaires ne doivent pas se sentir coupables d’avoir
recours à de tels services destinés à vous aider à renverser la tendance.
Les gestionnaires ne doivent pas voir peur d’attirer l’attention de l’employé sur ce problème.
L’appréciation sur la performance doit être donnée immédiatement, lorsque le cas problématique d’un
employé empêche le groupe de répondre à la valeur commerciale recherchée.
La question pour beaucoup de gestionnaires est de savoir quelle est la meilleure façon de procéder
lorsque surgit un problème de performance. Certains vont commencer par engager l’employé dans un
plan de performance, mais ce n’est pas nécessairement la meilleure approche. Il est possible que
l’employé ne se rende même pas compte qu’il y a un problème de performance. Pour cette raison, un
certain travail préliminaire doit être fait pour préparer convenablement le terrain à la discussion.
En tant que gestionnaire, considérez l’approche suivante :
1. La première étape consiste à commencer à collecter des faits. Réunissez des exemples récents
de dépassements de délais, etc. Ces éléments peuvent servir au cours de la discussion avec
l’employé au sujet du problème de performance.
2. Une fois les exemples factuels réunis, la seconde étape consiste à mener une discussion
préliminaire à propos de la performance. Cette réunion doit cibler trois objectifs :
 Faire prendre conscience à l’employé du problème de performance constaté;
 Recueillir la réponse et la réaction de l’employé;
 Déterminer un plan d’action à court terme ; ceci est très important et constituera la clé
permettant de réussir à améliorer la performance.
Dans de nombreux cas, le gestionnaire conclut hâtivement qu’il y a un problème de performance pur et
simple. Cependant, il y a beaucoup de raisons qui peuvent expliquer pourquoi la performance de
l’employé ne répond-elle pas aux attentes. Une fois le responsable comprend les causes, il sera en
mesure d’élaborer le plan d’action approprié.
Cette discussion initiale sur la performance va déterminer les étapes suivantes : Les problèmes de
performance de l’employé peuvent être dus à une cause profonde, pouvant être traitée en même
temps. Il se pourrait même que le simple fait de porter le problème perçu à l’attention de l’employé
357
permette de régler la situation. Tant que cette discussion initiale n’a pas eu lieu, il n’est pas possible de
savoir exactement où réside le problème et quelles seraient les solutions appropriées.
La première réunion sur la performance ne doit pas prendre fin avant d’arriver à un plan à court terme
pour redresser la situation. Un tel plan exigera du travail de la part de l’employé et du gestionnaire en
même temps. Ce plan doit aussi prévoir un moment où tous les deux doivent se rencontrer à nouveau,
peut-être après 3 jours. Il est important de se retrouver à nouveau pour vérifier s’il y a eu une
amélioration de la performance. Si c’est le cas, la situation a peut-être seulement besoin d’être suivie de
près à partir de ce moment-là.
Si la performance n’est pas toujours pas au niveau des attentes, la deuxième rencontre doit à nouveau
explorer les causes et voir si d’autres actions à court terme s’imposent. S’il y en a, il faut aussi les
mettre en œuvre. Cependant, si le responsable ne pense pas que l’employé pourra répondre aux
attentes liées au poste, il doit impliquer le service des ressources humaines et examiner les alternatives
disponibles à ce moment-là.
Etre assidu dans la gestion des personnes qui ont une performance insuffisante (8.2.3. P4)
Gérer des membres de l’équipe qui ne fournissent pas des performances satisfaisantes est un problème
dont beaucoup de chefs de projets aimeraient bien se passer. C’est particulièrement le cas quand ces
membres ne remplissent pas les attentes, sans pour autant atteindre un niveau où ils devraient être
renvoyés. Cependant, vous êtes toujours confronté au défi qui consiste en même temps à essayer de
gérer votre équipe et à mener votre projet à terme. Vous devriez considérer un certain nombre de
causes derrière une mauvaise performance.
 La personne dispose-t-elle de bonnes aptitudes et d’une bonne expérience ? Parfois,

les gens ne s’acquittent pas bien de leurs tâches parce qu’ils ne sont pas suffisamment qualifiés
pour le travail. Par exemple, vous demandez à une personne d’analyser un nouvel ensemble de
rapports mais elle ne sait pas comment poser les bonnes questions ou préparer une discussion
avec les clients. Si quelqu’un rentre dans cette catégorie, vous devez décider s’il pourra
accomplir le travail avec une formation appropriée ou s’il doit être remplacé.
 Comprennent-ils vos attentes ? Si le personnel possèdes qualifications requises, demandez-

lui s’il comprend bien les attentes. Par exemple, parfois, lorsqu’un membre de l’équipe dépasse
un délai, il dira seulement qu’il ne savait pas qu’il fallait remettre le travail à telle date. S’il y a
confusion au niveau des dates, vous pouvez demander à la personne de vous confirmer par
écrit qu’il n’a pas connaissance des attentes concernant les livrables et les dates.
 Y a-t-il des circonstances atténuantes ? Vous pouvez également vous demander s’il y a
des raisons personnelles ou professionnelles qui peuvent expliquer les performances d’une
personne. Par exemple, un membre de votre équipe peut ne pas être très motivé par la tâche si
son conjoint est très malade. Il peut ne pas avoir les moyens susceptibles de l’aider à résoudre
tel type de problèmes, ce qui expliquent le fait que ses performances soient faibles. Si vous
arrivez à découvrir la cause, cela peut vous aider à mieux répondre, ou du moins, à en prendre
conscience.
Si le personnel possèdes qualifications requises et a bien pris connaissance des attentes, les options qui
s’offrent au chef de projet deviennent plus limitées, et il entre de plein pied dans le domaine de la
gestion de la performance. Il est possible que certains membres de l’équipe ne soient pas en mesure de
répondre aux attentes. Peut-être ne veulent-ils pas faire le travail, ou ne sont-ils pas capables de
l’accomplir, indépendamment de la formation et du soutien que vous pouvez leur apporter. Si vous
pensez que c’est le cas, vous devez faire appel au supérieur hiérarchique, de même qu’au service des
ressources humaines. Ils vous indiqueront divers remèdes possibles et acceptables à appliquer au sein
de votre compagnie.
Même lorsque vous avez un problème majeur lié au personnel, vous pouvez utiliser votre expérience
des processus pour atténuer les problèmes que vous rencontrez. Par exemple, si des personnes ratent
des dates de livraisons significatives, vous risquez probablement de voir votre échéancier déraper. Si la
chose se produit parce que les membres de l’équipe passent trop de temps à une autre tâche, vous
avez un problème majeur. Si des personnes livrent tardivement parce qu’elles font plus de travail que
358
ce qui leur est demandé, vous avez peut-être un processus de modification du contenu qui doit être
amélioré. Si des personnes ne livrent pas le travail conformément au niveau de qualité requis, vous
devez utiliser votre processus de gestion de la qualité pour établir des lignes directrices indiquant ce à
quoi les livrables doivent ressembler et quel est le bon niveau de qualité.
Il est difficile et frustrant de travailler avec des personnes peu fiables et de compter sur elles. Après
avoir considéré les problèmes et essayé d’en déterminer les causes, vous devriez agir en tant que chef
de projet, ou, s’il s’agit d’un problème de performance, le porter à la connaissance du chef
hiérarchique.
Faire preuve de leadership dans les projets complexes (8.2.3. P5)
Les chefs de projets doivent être des meneurs. Le leadership peut être aisé lorsque tout fonctionne à
merveille. Tout le monde vous suivra alors. Cependant, lors des phases délicates, le leadership peut
s’avérer difficile, même s’il reste plus vital que jamais. Voici quelques détails que vous devez avoir à
l’esprit, pour sortir votre équipe d’une passe difficile.
 Restez concentré sur le travail global. Lorsque les choses deviennent moins évidentes, on
a tous tendance à se focaliser sur les problèmes. Un leader reste concentré sur la réalisation
des objectifs du projet.
 Restez positif. Lorsque les circonstances ne sont pas en votre faveur, même les membres de
l’équipe les plus loyaux peuvent être tentés de remettre en cause le travail, et,
malheureusement, de se remettre en cause les uns les autres. Ils commencent à se remettre
mutuellement en question puis à trouver des défauts chez chacun. Le leader, lui, reste positif et
agit de manière rationnelle et objective.
 Mettez-vous en première ligne. Lorsqu’il faut partager un moment douloureux, les meneurs
n’ont qu’une chose à faire : mener. Si l’équipe doit faire des heures supplémentaires, le chef de
projet doit le faire aussi. Il en est de même si l’équipe doit travailler un jour de fin de semaine.
 Gardez votre calme. La panique est une émotion humaine contre laquelle personne n’est
immunisé. Un meneur, cependant, doit se concentrer sur problèmes et rester calme. Garder
son calme permet au meneur de prendre les bonnes décisions pour toute l’équipe. La panique
conduit uniquement au désastre, alors que le calme mène vers la victoire.
 Motivez. Dans les moments difficiles, les gens ont souvent le moral bas. Ils ont tendance à
être pessimistes. Ils n’arrivent pas à voir comment cela va finir par s’arranger. Le chef de projet
doit alors motiver son équipe et lui montrer que tout peut s’arranger.
 Remportez des petites victoires. Un des moyens de motiver une équipe consiste à
remporter de petites victoires. Lorsque les choses ne vont pas bien, l’équipe commence à se
demander comment elle va arriver à gagner. Le chef de projet doit alors trouver des moyens de
remporter de petites victoires intermédiaires. Avec chaque victoire, même petite, le meneur
raffermira l’estime que l’équipe porte à elle-même et contribuera à favoriser en son sein une
attitude positive.
 Gardez le sens de l’humour. On peut pratiquement rire de tout. Le chef de projet doit
trouver des moyens d’introduire un peu d’humour ici et là, même en se moquant de lui-même
ou des situations qui se présentent.
Un mauvais chef de projet est souvent incapable de sortir l’équipe d’une mauvaise passe. Lorsqu’il fait
preuve de leadership, l’équipe le suit, peut-être pas tout de suite, mais, au bout du compte, elle le
suivra. Le chef de projet est dans une position où il doit mener ses troupes et remettre le projet sur la
bonne voie.
Attaquer les problèmes liés au moral de l’équipe sur tous les fronts (8.2.3. P6)
Les problèmes liés à un moral bas n’apparaissent pas et ne peuvent pas être résolus du jour au
lendemain. Généralement, les causes et les remèdes ne dépendent pas de vous. Cependant, en tant
que chef de projet, certains éléments sont de votre ressort. Quoi que vous fassiez, si le groupe vous
359
voit agir, il sera tout de suite mis en confiance.
Vous avez besoin de rétroaction de la part du groupe pour déterminer la cause des problèmes qui
affectent le moral de l’équipe. Une fois que vous connaissez la cause, il y a plusieurs moyens d’y
remédier. Voici quelques exemples :
 Être à l’écoute. Vous remarquerez que le simple fait d’être à l’écoute du personnel
contribuera à lui redonner confiance. Être sympathique et faire preuve d’empathie sont les
réponses clefs apportées par un chef de projet. Cela montre qu’au moins vous identifiez les
problèmes et en êtes préoccupé.
 Être reconnaissant. Cela est tout aussi important que d’être à l’écoute. Si les membres de
l’équipe sentent que le chef de projet reconnaît leurs contributions, cela les aidera beaucoup à
se sentir mieux, quelle que soit la situation.
 Assigner du travail plus stimulant. Cela est difficile car, dans la plupart des cas, votre
travail est comme il est et vous ne pouvez en changer la nature de base. Cependant, il y a un
certain nombre d'initiatives que vous pouvez entreprendre pour stimuler votre équipe. Par
exemple, vous pouvez établir des rotations au sein de l’équipe. Si deux membres font le même
travail trop longtemps, permutez-les. Cela permet à chacun d’acquérir de nouvelles aptitudes et
de nouveaux domaines d’expertise, tout en vous procurant un plus grand soutien. Vous pouvez
également donner plus de responsabilités. Cela peut consister à laisser de nouveaux membres
gérer le budget de l’équipe, à en placer d’autres à la tête de sous équipes ou à leur confier la
charge de la gestion du travail des contractuels.
 Donner l’occasion de découvrir de nouvelles technologies. Vous pouvez confronter le

personnel, à tour de rôle, avec de nouvelles technologies, permuter les responsables pour
permettre à chacun d’acquérir de nouvelles aptitudes et accroître les possibilités de formation.
 S’assurer que le personnel sait ce qu’on attend de lui. Assurez-vous que les personnes
sont bien informées sur leurs responsabilités, sur les activités en cours, et sur leur contribution
à la réussite du projet.
 Offrir plus de flexibilité. Permettre au personnel d’avoir davantage de contrôle sur leur
travail et sur leur vie peut relever leur moral. Voici quelques exemples de flexibilité dans le
travail :
o Offrir des possibilités de flexibilité au niveau des horaires pour permettre aux gens de
travailler tôt ou tard. Cela pourra signifier quatre journées de travail de dix heures, ou
bien laisser au gens la liberté de décider d’arriver tôt ou de partir tard, selon leur
convenance.
o Essayer de proposer quelques formules de télétravail. Commencez par une ou deux

journées par semaine, avec des personnes sélectionnées pour un essai.
 Avoir l’équipement approprié. Assurez-vous que les gens disposent du matériel et des
logiciels dont ils ont besoin pour faire leur travail. Travailler sur un équipement lent peut être
frustrant, surtout quand le matériel est aussi bon marché.
 Prendre le temps de se détendre en s’amusant. Cherchez les occasions de rassembler

l’équipe pour des activités sociales, autour d’une pizza, d’un gâteau d’anniversaire, etc.
 Solliciter l’opinion et les idées des employés. Le chef de projet devrait encourager les
membres de l’équipe à s’impliquer davantage et à exprimer leurs points de vue sur le travail. Si
les membres de l’équipe sentent que leurs idées et leurs opinions sont prises en considération,
ils se sentiront mieux.
Plusieurs raisons peuvent expliquer une baisse de moral. En fonction de ces raisons, il y a également
plusieurs moyens de rehausser ce moral. L’essentiel est de comprendre que l’équipe ne travaillera pas
bien si son moral est bas. De ce fait, les chefs de projet doivent être préparés à ces problèmes et
chercher des moyens pour que le moral de l’équipe reste élevé. Quelles que soient les limites de votre
rôle, il est toujours simple d’être à l’écoute et de dire « merci » pour tout ce qui est de votre ressort. Il
360
y a également d’autres manières de réagir qui sont de votre ressort.
Agir avec diligence pour reprendre en main une équipe de projet inefficace (8.2.3. P7)
De nombreuses équipes connaissent des conflits de personnalité entre leurs membres. Dans certaines
équipes, les animosités personnelles sont telles qu’elles affectent le bon fonctionnement du projet. Le
chef de projet, qui fait partie de l’équipe dès le départ, fait aussi partie du problème car il a souvent
une capacité limitée pour identifier et résoudre le problème. Cependant, quand ce problème est
découvert par le commanditaire ou le supérieur hiérarchique, le chef de projet est souvent remplacé.
(Cela est généralement une option plus facile que d’essayer de remplacer toute l’équipe du projet).
Si vous êtes un chef de projet qui hérite d’une équipe de projet qui fonctionne mal, de nombreux
domaines requièrent votre attention.
La première chose à faire est d’estimer l’état actuel du projet en cours. Votre réponse aux problèmes de
l’équipe de projet dépend de votre position par rapport aux délais. Par exemple, s’il vous reste 30 jours
de travail, il vous sera plus difficile d’influer sur la dynamique de l’équipe. Dans ce cas, la meilleure
chose à faire est d’essayer de motiver l’équipe pour l’effort final et le strict respect de l’échéancier. D’un
autre côté, si votre projet est appelé à durer encore plusieurs mois, vous devez évaluer les dommages
qui ont pu toucher l’équipe et tenter d’y remédier. Vous devez également planifier à nouveau
l’échéancier pour pouvoir livrer le projet dans un délai réaliste. Chaque plan inclura les éléments
suivants :
 Bien communiquer. Si le chef de projet communique mal, le projet sera une mauvaise
expérience pour tous. Les équipes au moral bas ont tendance à avoir de mauvais canaux de
communication. Ne laissez pas couver la rumeur ou les incertitudes. Assurez-vous que vous
partagez avec l’équipe le plus d’informations possibles sur la situation du projet et sur tout ce
qui concerne l’équipe.
 Féliciter et complimenter. Lorsque des membres de votre équipe accomplissent un bon

travail, faites-le leur savoir. Ils ne s’attendent pas à recevoir des cadeaux ou de l’argent pour
leur bon travail, juste une tape sur le dos et un « bon travail » de leur chef. Faites cela, aussi
bien formellement qu’informellement.
 Déterminer clairement les attentes. Le personnel doit comprendre ce que l’on attend de lui
afin de savoir à quels défis il est confronté. Assurez-vous de donner des instructions claires
lorsque vous distribuez du travail afin que les gens sachent ce qu’ils ont à faire.
 Ne pas surcharger l’équipe de projet. Tandis que vous essayez de remonter le moral de
votre équipe, faites attention à ne pas trop lui en demander. Déterminez le travail restant
jusqu’à la fin du projet et enlevez tout ce qui est superflu et qui peut être accompli après la
mise en œuvre.
 Gérer le contenu. Assurez-vous que vous gérez le contenu de manière stricte et essayez de
repousser tous les changements après la fin du projet original.
 Remporter des petites batailles. Un moral bas peut faire rater des échéances, ce qui
entraîne plus de pression et affecte encore plus le moral de l’équipe. L’inverse est également
vrai. Si l’équipe de projet commence à respecter les délais intermédiaires (et que vous le lui
faites savoir en la félicitant), alors le moral de l’équipe remontera, et votre prochaine échéance
sera plus facile à atteindre.
Ce sont là quelques idées qui permettent de reprendre le projet en main. D’abord, assurez-vous que
vous connaissez votre situation par rapport aux délais, afin de savoir combien de temps il vous reste
pour effectuer des changements significatifs. En outre, assurez-vous que vous identifiez le plus de
problèmes possibles au sein de votre équipe, de même que leurs causes profondes, si possible. Ensuite,
avec l’équipe, mettez en place un plan d’action basé sur le temps et le travail qui vous restent. S’il n’y a
plus beaucoup de temps, concentrez-vous sur l’échéancier. S’il vous reste beaucoup de temps,
concentrez-vous sur le règlement des problèmes internes de l’équipe, tout en faisant face à
l’échéancier.
361
Gérer les problèmes provenant de manœuvres politiques comme des problèmes majeurs
(8.2.3. P8)
Plus la taille de vos projets est grande, plus vous verrez que la composante politique des problèmes
majeurs que vous rencontrez a tendance à s’accroître. Autrement dit, l’origine d’un bon nombre de
problèmes majeurs se trouve dans la façon dont le projet gère le personnel, les livrables, dans
l’approche choisie et son impact sur les parties prenantes, etc. Pour résoudre ce type de problèmes, il
vous faudra parvenir à un consensus avec des personnes qui ont des opinions et des intérêts différents.
En d’autres termes, la résolution exigera que vous reconnaissiez les enjeux politiques au bureau et que
vous sachiez jouer le jeu.
Pour parler de façon générale, les manœuvres politiques au bureau consistent à interagir avec les gens
et à les influencer afin d’obtenir le résultat souhaité. Cela peut être bon, mauvais ou neutre, suivant les
tactiques employées. Les manœuvres politiques ne sont, à l’origine, ni bonnes ni mauvaises par
définition, elles peuvent le devenir suivant le comportement des personnes concernées. Prenons-en
quelques exemples :
 Vous avez la capacité de faire part de vos idées au sein de votre organisation et de faire en
sorte que le personnel les réalise (bon) … en annihilant des idées adverses, en vous
appropriant les idées des autres et en les présentant comme étant les vôtres (mauvais).
 Vous avez la capacité de parvenir à un consensus sur des sujets épineux avec un certain
nombre de parties prenantes (bon) … en travaillant en coulisses avec les personnes qui
détiennent le pouvoir, en passant des marchés et en éliminant les personnes qui ne sont pas
d’accord avec vous (mauvais).
 Vous recevez des fonds pour des projets importants pour vous et pour l’organisme pour lequel
vous travaillez (bon) … en truquant les coûts et les bénéfices et en contournant les processus
de financement courants (mauvais).
 Vous vous faites la réputation de quelqu’un qui peut réaliser le travail quand il faut (bon) … en
utilisant des tactiques légitimes et illégitimes et en écrasant les personnes qui vous barrent la
route (mauvais).
Ces exemples montrent que s’adonner à des jeux politiques au bureau peut représenter de bonnes et
de mauvaises connotations. Cependant, le terme renvoie souvent à des méthodes peu orthodoxes
employées pour que le travail soit accompli coûte que coûte.
Il n’est pas rare qu’une équipe de projet subisse l’impact des manœuvres politiques. Cela se produit
souvent sous le couvert de différences d’opinions concernant les livrables, les spécifications, les
demandes de modification du contenu, la perception des risques, etc. Le tout est de savoir si ces
divergences d’opinion sont véritablement des manœuvres politiques ou si elles sont de simples
différences d’opinions, légitimes et valides, entre des personnes dont chacune estime représenter le
meilleur intérêt de la compagnie.
Composer avec des manœuvres politiques ne fait pas partie d’un processus standard de management
de projet. Cependant, lorsque ces manœuvres influencent le projet dans le mauvais sens, la situation
devrait être identifiée comme un problème majeur, vu que sa résolution ne dépend pas de l’équipe de
projet. Vous ne pouvez pas utiliser une check-list pour résoudre les problèmes politiques majeurs. Les
problèmes politiques sont liés aux intérêts opposés des personnes concernées et dépendent de
situations particulières. Ce qui peut être appliqué dans un cas, dans une situation donnée et avec une
personne en particulier, ne peut pas l‘être avec une autre car les personnes ont souvent des intérêts
divergents. Classer ce type de situations en tant que « problème majeur » et par conséquent suivre le
processus prévu pour résoudre ce type de problèmes, rendra la situation plus claire et favorisera une
bonne voie de résolution de la part des personnes les plus appropriées.
Généralement, les chefs de projet doivent avoir de bonnes aptitudes pour identifier les situations
potentiellement sensibles aux manœuvres politiques et pour les résoudre. Ils doivent œuvrer suivant
trois niveaux :
362
 Essayer d’identifier des situations et des évènements où la politique pourrait probablement
jouer un rôle. Parmi les points sensibles, on peut citer les questions suivantes: Qui prend les
décisions? Y a-t-il une situation de concurrence pour des moyens financiers limités et des
ressources humaines rares, qui seront consacrés au projet au détriment d’autres projets ?
 D’une manière générale, traiter avec les gens de manière franche et honnête. Lorsque vous
donnez votre opinion ou lorsque vous faites des recommandations, tenez compte du pour et du
contre, afin que vous puissiez donner une opinion équilibrée aux autres parties. Assurez-vous
que vous faites bien la distinction entre les faits constatés et vos opinions, afin que vos
interlocuteurs voient la différence. Vous devez toujours communiquer de manière proactive
avec toutes les parties prenantes.
 Si vous ne vous sentez pas à l’aise avec ce que l’on vous demande de faire, impliquez votre
commanditaire et votre supérieur hiérarchique. Ils ont souvent plus de poids politique et
d’autorité, en raison de leur position, et devraient pouvoir vous conseiller et vous couvrir.
Si vous êtes satisfait de ce que vous entreprenez et de la manière dont vous jouez de votre influence
pour que le travail soit mené à bien, vous gérez probablement la politique de bureau de la bonne
manière. Si vous culpabilisez en raison du traitement que vous infligez au personnel et si vous avez des
doutes quant à vos méthodes, vous pratiquez alors le mauvais côté de la politique de bureau.
Aborder ouvertement les problèmes majeurs dont vous êtes la cause (8.2.3. P9)
Personne ne peut prétendre à la perfection. Généralement, le chef de projet fera tout ce qui est en son
pouvoir pour faire réussir son travail, en utilisant les informations dont il dispose sur le moment.
Cependant, il y a parfois des moments où il est évident qu’un problème majeur n’a pu naître qu’à cause
d’une erreur de la part du chef de projet. Cette erreur peut se situer au niveau des communications, de
l’estimation, de la compréhension des livrables du projet, etc. En fait, pour ’être reconnue comme un
problème majeur formel, l’erreur doit être assez grande, mais la pratique nous enseigne que les erreurs
importantes surviennent tout le temps.
D’habitude, la gestion des problèmes majeurs est un processus qui doit être traité avec un minimum de
logique et sans émotions. Celui-ci implique l’identification du problème et l’application de techniques de
résolution. Cependant, ce type spécifique de problèmes majeurs peut s’avérer particulièrement difficile
à résoudre du fait que le chef de projet pourrait se trouver un peu sur la défensive (et peut-être aussi
se sentir embarrassé) en raison de sa part de responsabilité dans la survenue du problème lui-même.
Parfois, le fait que le problème ait été causé par le chef de projet ne facilite pas la démarche pour
l’aborder d’une façon ouverte et opportune. S’il vous arrive de vous trouver dans une telle position,
suivez les étapes suivantes pour résoudre efficacement le problème :
1. Prenez le problème à votre charge. Vous devez avant tout reconnaître le problème et
admettre le fait que c’est vous qui en êtes la cause. Si c’est vous qui avez été à l’origine du
problème mais que vous essayez d’en faire endosser la responsabilité par une autre personne,
vous découvrirez probablement que la résolution du problème sera encore beaucoup plus
pénible pour vous. Si vous êtes à l’origine du problème ou que vous en êtes partiellement
responsable, soyez assez mûr et honnête pour l’admettre.
2. Communiquez de façon ouverte. Vous serez en fait surpris par la libération que constituent
la reconnaissance et l’aveu du fait que c’est vous qui avez eu un raté cette fois-ci. Le fait de
dire que vous vous êtes trompé empêchera les autres de se sentir obligés de vous jeter la
pierre : cela n’est plus nécessaire puisque vous avez déjà avoué ! Au lieu de perdre son temps
à ce jeu-là, votre équipe se trouve maintenant prête à avancer et mieux décidée à résoudre le
problème.
3. Résolvez le problème avec calme et patience. Maintenant que vous avez déjà dépassé le
stade pénible pour vous, vous êtes en mesure de chercher les alternatives et de résoudre le
problème en utilisant vos techniques habituelles pour gérer les problèmes majeurs. Ne restez
pas prisonnier de votre peine en adoptant une attitude défensive ou en cherchant encore des
moyens de sauver la face. Etant donné que l’erreur a été commise, cherchez la meilleure
solution pour votre projet.
363
4. Tirez la leçon de votre erreur. En général, toute erreur commise peut être transformée en
expérience acquise. Vous pouvez mettre en place de meilleurs processus, si cela vous semble
approprié. Il est également possible que vous tiriez une leçon essentielle pour vous et que vous
adaptiez vos systèmes de gestion (même imperceptiblement) pour éviter que ce type de
problème ne se produise à l’avenir.
Les gestionnaires affirment souvent que le seul point positif qui ressort d’une mauvaise expérience est
le fait d’apprendre à ne plus la refaire. La situation idéale serait d’avoir un endroit plus opportun pour
apprendre nos leçons, au lieu de « l’école des coups durs ». Reconnaissons toutefois, comme nous
l’avons dit plus haut, que nul d’entre nous n’est parfait, non plus. Donc, quand il vous arrive de faire
une erreur grave, assumez-la et parlez-en sans délai. Ensuite, trouvez un moyen de dépasser le
problème et prenez les dispositions personnelles nécessaires pour éviter que ce problème puisse
survenir à nouveau.
Si vous prouvez que vous êtes capable de manier les problèmes de cette façon, vous découvrirez
généralement que non seulement les gens vous accordent le bénéfice du doute, mais qu’en fait, ils
vous admirent pour votre façon de relever ces défis personnels.
Faire preuve de leadership dans la mise en place les demandes critiques de changement
(8.2.3. P10)
Le changement n’est, par nature, ni positif ni négatif. En revanche, l’équipe peut y répondre de manière
positive ou négative, suivant l’état du projet. La réaction courante de la plupart des équipes de projet
est d’aller de l’avant et d’effectuer les changements. Néanmoins, une autre réaction peut s’avérer
problématique : l’équipe peut ne plus vouloir procéder à des changements. Cette situation se produit
habituellement dans des projets qui ont connu des problèmes et peut avoir plusieurs raisons:
 Il s’agit peut-être d’un long projet, qui nécessitera probablement des heures supplémentaires,
et les gens souhaitent seulement qu’il se termine.
 Les changements proposés nécessitent beaucoup de travail, et la date limite est ferme. Encore
une fois, des heures supplémentaires seront exigées.
 Des membres de l’équipe du projet et le client n’ont pas été en très bons termes. Certains
d’entre eux ne veulent plus aider le client davantage.
 Les changements requièrent un gros travail de reprise en amont sur la conception, qui, à son
tour, demandera des changements au niveau de la construction et de nouveaux tests pour
toute la solution.
Toutes ces situations (et bien d’autres encore) entraînent un scénario où l’équipe de projet n’est pas
motivée pour soutenir les modifications de contenu. Cela met le chef de projet dans une situation
délicate où il doit mettre le reste de l’équipe de son côté et la motiver pour un dernier effort.
Il s’agit franchement d’une grande déception. L’équipe est fatiguée et peu motivée. En fait, son moral
doit être au plus bas. C’est le moment, pour le chef de projet, de faire preuve de leadership. Comme
l’origine des problèmes que rencontre l’équipe est probablement complexe, la solution comportera,
probablement aussi, plusieurs facettes. Voici quelques éléments que le chef de projet devrait prendre
en considération :
 Expliquez d’abord les faits. Ne commencez pas directement par un discours triomphaliste.
Rencontrez d’abord l’équipe pour lui expliquer l’arrière-plan et les circonstances. Puis, parlez
des changements nécessaires et de leur importance dans une perspective commerciale.
 Reconnaissez la peine provoquée. Le chef de projet doit reconnaître les problèmes. Faites
savoir à l’équipe que vous comprenez qu’elle n’ait pas trop envie d’effectuer les changements et
que son moral soit en baisse. N’en faites pas votre thème principal, mais prenez cela en
considération.
 Motivez votre équipe. Le moment est venu de motiver votre équipe. Faites appel à son
esprit d’équipe et à sa capacité à faire face à l’adversité. Faites-lui connaître l’importance de
son apport pour la compagnie.
364
 Parlez personnellement à chacun. En plus des réunions de l’équipe, parlez à chaque
membre de l’équipe personnellement pour avoir une idée sur son état psychologique. Écoutez
ses problèmes et obtenez son engagement personnel pour travailler dur et continuer à avancer.
 Impliquez la hiérarchie et le commanditaire. Cette situation est une bonne occasion pour
demander à votre manager et à votre commanditaire de parler à l’équipe, de la remercier pour
le travail accompli jusque-là et pour solliciter à nouveau son aide pour réaliser les
changements.
 Cherchez des remontants. De petits remontants peuvent aider l’équipe à surmonter ses
problèmes de manque de motivation et de baisse de moral. Cela peut consister tout
simplement à apporter des croissants le matin et des pizzas pour ceux qui doivent faire des
heures supplémentaires, tard dans la journée.
 Assurez-vous que vous avez le soutien des clients. Normalement, si l’équipe de projet
fait du travail supplémentaire, les clients doivent supporter une partie du fardeau. Le chef de
projet doit s’assurer que c’est bien le cas.
 Communiquez de manière proactive. Informez chacun de l’état du projet, de la durée et

du travail restants. Si le chef de projet commence à se renfermer sur lui-même et à garder les
informations au secret, cela peut affecter le moral de l’équipe.
 Célébrez les succès. Le chef de projet n’attend pas la fin du projet pour déclarer la réussite
d’un projet. Cherchez des jalons de l'échéancier, ou des mini jalons, et faites-en des
opportunités de célébrer une victoire et de féliciter l’équipe.
Un chef de projet doit avoir des qualités de gestion et de leadership et ne doit pas se contenter de dire
aux gens « faites votre travail ». Cette situation est délicate et nécessite de bonnes aptitudes en
matière de gestion du personnel pour s’en sortir avec succès. Le succès n’est jamais garanti, mais
l’utilisation de certains de ces conseils peut vous sortir d’une situation difficile.
Accepter l’autonomie des équipes autogérées (8.2.3. P11)
Le travail en équipe est utilisé pour effectuer la plupart des tâches d’une organisation. Lorsque les gens
travaillent en équipe, ils deviennent plus motivés et plus enthousiastes, développent de nouvelles idées
pour améliorer leur performance et prennent plus de responsabilités pour mettre ces plans en action.
Les équipes de projet autogérées sont des équipes spécifiques qui maintiennent un haut degré de
collaboration et se gèrent elles-mêmes, dans le but de devenir une équipe hautement performante.
Dans une équipe de projet autogérée, la confiance augmente au sein de l’équipe au fur et à mesure
que le projet avance. Celle-ci devient plus motivée et accepte de plus grands défis. Ces équipes se
concentrent sur la performance autant que sur le travail collectif. Leur succès repose sur un puissant
engagement au niveau personnel et au niveau de la compagnie, sur le développement des aptitudes et
sur le soutien de chaque membre de l’équipe et de la direction.
Toutes les équipes autogérées ont besoin d’une formation qui les prépare à travailler dans ce nouveau
paradigme. Une erreur courante consiste à livrer les gens à eux-mêmes, dans un environnement
autogéré, sans qu’il y ait de préparation adéquate. Cela entraîne un certain chaos, de la frustration et
paralyse le travail. Le meilleur moment d’entreprendre une telle formation est le stade de la constitution
initiale de l’équipe, et, par la suite, de manière continue, lorsque l’équipe rencontre des situations
qu’elle ne peut pas maîtriser.
Bien sur, l’équipe ne peut pas être entraînée à remédier à toutes les contingences possibles. Un des
objectifs d’une équipe autogérée est qu’elle devienne suffisamment flexible pour résoudre des
problèmes imprévus lorsqu’ils se présentent. Aucun entraînement, quel qu’il soit, ne peut donner des
résultats parfaits. Des problèmes imprévus apparaîtront sûrement ; l’équipe doit donc être prête à
investir les ressources et l’énergie nécessaires pour surmonter tous les obstacles.
Surmonter la résistance de l'équipe au management de projet (8.2.3. P12)
Élaborer la charte du projet et l'échéancier du projet est une chose. Gérer efficacement le projet en est
365
une autre. Si vous pouviez accomplir le plan et les tâches assignées et faire en sorte que chacun achève
ses activités à temps, votre vie serait beaucoup plus facile. Mais le processus de gestion de l'équipe et
de l'échéancier du projet se complique en raison des personnes impliquées. Les gens sont imprévisibles.
Pour comprendre comment le projet se déroule et pour s'assurer qu'il demeure sur la bonne voie, des
contrôles sont nécessaires. Vous devez faire le tour de l’équipe et demander à ses membres comment
ils avancent. Ils doivent vous le dire lors des rapports et des réunions de revue du projet. Vous devez
disposer de statistiques au jour le jour sur le travail accompli, le travail en cours et celui qui n’a pas
encore commencé.
Malheureusement, les membres de l’équipe ne répondent pas toujours correctement à ces processus de
gestion et de contrôle, pour de multiples raisons.
 Ils peuvent penser que les processus sont encombrants et ne pas les utiliser quand ils réalisent
leurs livrables.
 Ils peuvent penser qu'ils seront sanctionnés s’ils apportent de mauvaises nouvelles ou font les
choses de manière incorrecte.
 Ils peuvent ne pas être convaincus que les processus de management de projet sont efficaces.
 Ils peuvent nourrir une méfiance compréhensible comme celle que l’on peut éprouver envers
des processus qui ressemblent à des contrôles.
 Les membres de l’équipe peuvent avoir essayé de suivre les processus, mais ont trouvé que ces
derniers sont incomplets ou qu’ils ne sont pas respectés par d’autres.
 Ils peuvent estimer que si le chef de projet ne suit pas les procédures, ils n’ont eux aussi
aucune raison des suivre.
 Ils peuvent avoir remarqué des personnes dont le comportement penche vers la non
observance des processus sans que cela prête à conséquence.
Connaître et reconnaître ces tendances humaines normales vous aidera à contrecarrer la résistance que
vous pouvez rencontrer dans votre projet. Le chef de projet doit également communiquer sur ces
processus de manière efficace, et expliquer leur utilité pour le projet. Après en avoir discuté avec
l'équipe, il est important d'appliquer constamment ces processus de gestion de projet pour qu’ils soient
appliqués avec succès dans le projet.
Aborder les problèmes de performance au cours d’une première réunion en amont (8.2.3.
P13)
Quand on a affaire à un employé difficile, il faut d’abord regarder du côté du rendement. Si l’employé
fait partie du projet, la première question qui se pose est de savoir quel est l’impact de son
comportement sur le projet, en termes de livrables et de délais.
La question suivante, dans la perspective du projet, est de savoir si ce comportement peut causer des
problèmes à l’avenir. Si oui, ce comportement peut être considéré comme un risque pour le projet. En
fait, à ce stade, les risques sont la plus grande préoccupation. Ils sont nombreux et incluent :
 Le risque que le comportement entraîne, en fait, des dépassements des délais dans le futur
 Le risque que ce comportement affecte le reste de l’équipe et que le moral et la cohésion de

cette dernière en souffrent
 Le risque que le partage des connaissances fasse défaut et qu’il ait un impact sérieux sur le
projet, si l’employé vient à partir.
Si le manager s’aperçoit que l’employé peut constituer un risque significatif, il doit traiter la situation de
manière proactive. Le point de départ dans la gestion des problèmes de personnel est habituellement
de prendre le chemin le plus court : le dialogue direct. Au cours de cette discussion, le manager expose
sa manière de juger le comportement de l’employé tout en expliquant pourquoi cela risque de poser
des problèmes pour le projet. Le manager qui connaît les risques encourus par le projet, doit en
366
informer l’employé.
L’un des avantages de la première réunion c’est que le manager peut faire partager ses préoccupations
et que l’employé aura l’occasion d’exposer son point de vue.
Vous ne savez jamais sur quoi ces discussions préliminaires vont déboucher. Parfois, elles sont difficiles
et ne permettent pas de réaliser ce que vous espériez ; d’autres fois, la personne à qui vous parlez va
se mettre d’accord avec vous et vous expliquer les raisons de son comportement. En tant que manager,
si vous arrivez à connaitre les causes, vous devriez être en mesure d’arranger les choses.
L’employé peut avoir un problème dans sa vie personnelle. Il peut y avoir des conflits de personnalité
entre lui et les autres membres de l’équipe. Parfois, les gens se taisent et évitent d’en parler, par peur
de perdre leur travail.
Quoi qu’il en soit, si vous trouvez la cause du problème, vous avez des chances de trouver le remède.
En fait, il doit y avoir un certain nombre de remèdes sur lesquels le chef et l’employé peuvent travailler
ensemble. Ils peuvent par exemple, tenter de renforcer les aptitudes de l’employé à communiquer et
celles des autres à réagir, ou apporter un soutien moral (coaching) continuel ou encore modifier le
travail de l’employé de sorte qu’il puisse y exceller. La solution précise dépendra de ce qui sortira des
échanges qui ont lieu au cours de la réunion.
La réunion doit se terminer sur des engagements concrets pour résoudre le problème. Le manager doit
se sentir satisfait de voir l’employé s’engager à nouveau aux côtés du reste de l’équipe. Le manager
doit aussi obtenir un engagement réel de formation croisée, si bien que l’employé pourra transmettre
ses compétences et ses techniques aux autres membres de l’équipe. S’ils ne se mettent pas d’accord
sur ces points, c’est que la réunion a échoué et qu’un effort plus soutenu est nécessaire. Si l’employé
accepte un plan d’action à court terme, puis ne le suit pas, une nouvelle tentative doit être inscrite à
l’ordre du jour.
Gérer les contractuels efficacement, mais différemment des employés du staff (8.2.3. P14)
Le recours aux contractuels fait partie de la vie des entreprises. Beaucoup d’entreprises aujourd’hui ont
pris la décision délibérée de recruter seulement un noyau d’employés pour leur staff. Quand il y a plus
de travail que ce noyau ne peut en effectuer, l’entreprise engage du personnel contractuel pour
pourvoir les postes vacants. Quand le travail additionnel est achevé, on mettra fin à leurs services.
Il n’y a toujours pas de distinction claire entre les termes « contractuel » et « consultant ». Pour cette
leçon, un consultant est une personne à qui on fait appel pour un ensemble de compétences
spécifiques et dans la plupart des cas, il est chargé d’exécuter un ou plusieurs livrables spécifiques. Un
contractuel, de son côté, est utilisé comme un agent supplémentaire pour affronter une surcharge de
travail, et il s’en va quand le travail est achevé. Cependant, même lorsque vous avez assez d’employés
pour répondre à votre charge de travail, vous devez aussi faire appel à des consultants pour travailler
dans des domaines où vous ne disposez pas du niveau de compétences approprié. Par exemple, vous
devez faire appel à une société de marketing pour vous aider à lancer une compagne de publicité sur le
web, ou, si votre entreprise se procure un contrat spécifique de sécurité pour les ordinateurs, vous
aurez besoin d’un consultant pour installer les logiciels.
D’un autre côté, un contractuel est recruté généralement sur la base d’une durée et d’une
rémunération, pour effectuer tout travail qui a besoin d’être exécuté dans des délais impartis. Il y a des
domaines spécifiques où vous pouvez avoir besoin de contractuels et, par conséquent, vous allez les
embaucher sur la base de compétences spécifiques. Une fois engagé, le contractuel fera tout ce que
vous lui demanderez, durant toute la période où vous en aurez besoin. En d’autres termes (soit dit sans
aucun mépris) nous embauchons généralement les consultants pour « le pouvoir cérébral » et les
contractuels pour leur « force de cheval ». Encore une fois, c’est ainsi que nous utiliserons ces deux
termes au cours de cet exposé. D’autres entreprises voient ces deux fonctions différemment.
Voyons les contractuels de plus près. Les managers se trouvent quelques fois dans des situations
embarrassantes lorsque le rendement d’un contractuel engagé pour travailler sur un projet, commence
à baisser. Normalement, un manager traite le faible rendement des employés à travers un processus
consistant à essayer de déterminer la cause de ce problème de performance, puis à contrôler le travail
367
plus précisément en ce qui concerne les livrables et les délais, à enregistrer les problèmes de
performance, etc.
Cependant, un contractuel n’est pas, techniquement parlant, un employé de la société. Aussi, ce niveau
de contrôle des performances n’est pas approprié. En fait, il peut même être dangereux.
Habituellement, il y a une barrière informelle qui sépare les employés et les contractuels, mais dans de
nombreuses circonstances, les managers traitent les contractuels de la même manière que les
employés. Les contractuels sont invités aux réunions des employés, participent aux sessions de
formation des employés, assistent aux fêtes des employés et participent à leurs repas. Ils sont donc
généralement traités comme des employés. Le personnel sait très bien que ce sont des contractuels,
mais dans de nombreux cas, ils sont traités exactement comme n’importe quel employé.
De nos jours, les entreprises doivent maintenir avec vigilance le mur de séparation entre les employés
et les contractuels. Le problème s’est posé lorsque des contractuels ont commencé à poursuivre en
justice leurs anciens employeurs pour demander à bénéficier des mêmes avantages que les employés,
en arguant, avec succès, qu’ils étaient vraiment, dans les faits, des employés de l’entreprise quand ils y
travaillaient sous contrat. Pour preuve, ils ont montré qu’ils effectuaient le même nombre d’heures que
les employés, qu’ils travaillaient avec eux dans le même espace, qu’ils assistaient aux mêmes réunions
que les employés et que, dans tous les aspects de leur travail, ils étaient traités comme des employés.
C’est là que la position des managers devient délicate. Il y a dix ans, j’aurais dit qu’il faut simplement
prendre le chemin le plus direct, s’asseoir avec le contractuel pour voir ce qui se passe. Cependant,
comme vous pouvez le voir à travers ce qui vient d’être dit, cette approche pourrait poser des
problèmes aujourd’hui. Traiter les problèmes de performance est l’un des aspects de la relation du
manager avec ses subordonnés. Si l’on ne fait pas attention, ce type de discussion peut être utilisé
contre l’entreprise pour montrer que le contractuel devrait en réalité être classé comme un employé.
D’un autre côté, vous ne ne pouvez pas non plus ériger un mur infranchissable entre un manager et un
contractuel. Ce dernier doit communiquer avec tous les membres de l’équipe et cette communication en
soi ne peut pas être considérée comme faisant partie de la relation d’un manager avec ses
subordonnés. De même, un manager doit assigner des tâches, recevoir des informations sur l’état des
travaux et tenir les gens pour responsables des dates limites. Ces aspects ne constituent pas la totalité
de la relation du manager avec ses subordonnés.
Par conséquent, où faut-il tracer la ligne de démarcation ? D’une manière générale, la plupart des
entreprises suivent une politique qui garantit que les employés traitent les contractuels loyalement et
avec respect, et qui évite de s’enliser dans des situations qui seraient logiquement considérées comme
faisant partie de la relation fonctionnelle entre le manager et ses subordonnés.
Par exemple, l’une des prérogatives d’un chef de projet est de distribuer les tâches et de recueillir des
informations en retour (feedback) sur la situation du projet. Il s’agit là d’une relation entre le chef de
projet et le membre de l’équipe, mais elle n’est pas le signe d’une relation fonctionnelle entre eux. D’un
autre côté, si vous effectuez un examen de la performance d’un contractuel, cela peut sembler être une
situation concernant un responsable fonctionnel et un employé qui lui est subordonné.
Supposons, maintenant, que vous ayez engagé un contractuel et qu’il ne réponde pas aux attentes.
Dans une telle situation, vous devez être clair sur le fait que vous assignez une tâche et recueillez un
feedback sur la situation du travail. Si ce dernier n’est pas achevé à temps, vous avez tout à fait le droit
d’interroger le contractuel sur les causes du retard. Il peut y avoir une myriade de raisons. Le travail a
peut-être tout simplement été surestimé. Peut-être le contractuel a-t-il été poussé à faire un autre
travail. Dès lors, s’asseoir avec le contractuel d’abord pour déterminer s’il y a une cause simple ne
devrait pas poser de problèmes.
Ce qui arrive après cette rencontre permet de décider s’il faut impliquer la compagnie d’intérim. Si le
rendement du contractuel redevient acceptable, le problème est résolu de lui-même. D’un autre côté, si
la situation n’est pas réglée, vous avez un problème de rendement à résoudre. Mais parce que le
problème concerne un contractuel, vous ne pouvez pas résoudre ce problème par vos propres moyens.
Le mode d’action le plus indiqué serait d’appeler la société d’intérim et de l’impliquer. Vous pouvez
expliquer à la personne idoine dans cette société que le contractuel commence à avoir des problèmes
de performance. Décrivez la situation et présentez vos observations. Vous pouvez ensuite demander
368
que la société d’intérim s’implique. Le responsable du contractuel au sein de la société d’intérim peut
alors parler à ce dernier, dans le cadre plus formel d’une relation de chef à subordonné, et revenir vers
vous avec les résultats de la réunion.
Ce processus peut sembler lourd ou embarrassant, mais il est conforme à la nature de la relation avec
un contractuel. En faire davantage peut entraîner un examen plus serré de la question de savoir si
l’agent concerné est un contractuel ou un employé.
En résumé, un manager doit se sentir libre de communiquer et d’interagir avec le contractuel (et avec
n’importe quel contractuel parmi son personnel) de la manière la plus appropriée pour gérer la charge
de travail. Cependant, le manager dispose de beaucoup moins de flexibilité quand il s’agit de n’importe
quelle situation qui requiert une relation formelle de chef à subordonné. Dans ce genre de situations, il
y a lieu d’impliquer la société contractante afin qu’elle fasse valoir la relation hiérarchique qui convient.
Comprendre votre staff technique et le gérer en conséquence (8.2.3. P15)
D’abord, il ne faut jamais oublier qu’il est impossible de classer chacun selon sa profession. Vous
pouvez avancer quelques hypothèses générales au sujet des gens qui travaillent dans le domaine
techno informatique, mais cela ne veut pas dire qu’elles s’appliquent à chacun. Comme manager, vous
devez, en fin de compte, disposer de plusieurs techniques qui s’appliquent à différentes personnes dans
des circonstances différentes. Une seule technique peut ne pas s’appliquer tout le temps à tout le
monde.
Cela dit, examinons quelques généralités au sujet du personnel technique.
 Il a tendance à être introverti : D’une manière générale, un introverti est quelqu’un qui se
sent à l’aise quand il est replié sur lui-même, alors qu’un extraverti est généralement plus à
l’aise quand il est tourné vers l’extérieur. Par exemple, quand des introvertis reçoivent un
ensemble d’informations nouvelles, ils vont réfléchir un moment avant de parler ou de tirer des
conclusions. Les extravertis, eux, sont plus à l’aise lorsqu’il s’agit d’exprimer leurs idées face
aux autres. S’ils tirent une mauvaise conclusion d’une manière hâtive, ils n’ont pas de peine à
changer d’avis. Au fond, les extravertis ne sont nullement gênés lorsqu’ils réfléchissent tout
haut. Les introvertis vont plutôt réfléchir sous la forme « d’esquisses grossières » dans leur
tête, puis ils parleront quand ils penseront avoir une position cohérente et logique.
 Il a tendance à penser plus froidement qu’émotionnellement : Cette tendance est

évidente. Le personnel technique n’est pas attiré par beaucoup de discours enthousiastes. En
fait, il a tendance à être indifférent envers ce genre d’effusions. De manière générale, il va
écouter poliment (peut-être en grognant doucement, en lui-même) mais les effets sont de
courte durée. En revanche, il peut adhérer et être sensible à un argument logique. Si un
argument logique peut être combiné avec quelques techniques motivantes, vous avez une
chance de le voir réellement s’exciter.
 Il a tendance à vouloir résoudre les problèmes : Il s’agit là d’une grande force du

personnel technique, mais aussi de l’une de ses faiblesses. Beaucoup de techniciens ne désirent
rien autant que d’être confrontés à un problème. Ils s’excitent et commencent immédiatement
à mettre en contribution leurs aptitudes à résoudre les problèmes. La faiblesse vient de ce qu’ils
se ruent sur le problème à résoudre avant de bien le comprendre au préalable. Cela peut
souvent amener à utiliser ce personnel d’une façon qui est loin d’être optimale. Dans de
nombreux cas, les techniciens vont s’attaquer hâtivement au problème, et ensuite se ressaisir
quand ils se rendent compte qu’ils ne l’ont pas très bien compris au départ.
 Il a tendance à être techniquement créatif : Cela peut ressembler à une contradiction. De

prime abord, vous allez probablement penser que le personnel qui s’occupe de ventes et de
marketing est le plus créatif. En fait, il l’est, dans le domaine des ventes et du marketing. Il va
être le premier à vous le dire, parce qu’il est extraverti. Cependant, les disciplines techniques
aussi exigent un niveau appréciable de créativité. Cela est surtout vrai dans le monde de la
techno informatique. Dans de nombreux cas, il n’y a pas une seule bonne solution à un
problème commercial. Dans le domaine de la programmation, par exemple, les analystes ont
besoin de créativité quand ils définissent une solution avec des clients commerciaux. Les
369
programmeurs doivent être créatifs pour pouvoir appliquer les meilleures techniques de la
meilleure façon. Les programmeurs doivent aussi être créatifs quand ils essaient d’appliquer les
meilleures techniques pour bâtir la solution la plus élégante.
Comprendre ces caractéristiques générales constitue le point de départ pour celui qui gère un personnel
technique. Lorsque vous commencez à comprendre comment les gens travaillent et comment ils
peuvent être motivés, vous pouvez commencer à réfléchir à la meilleure manière des diriger. Ces idées
ne sont pas toutes applicables à votre staff, et même si elles l’étaient, vous ne pouvez pas agir sur tous
les fronts en même temps.
D’abord, le manager doit s’assurer qu’il a créé un environnement favorable à un bon rendement. Pour
un personnel du domaine techno informatique, cela veut dire s’assurer que ces techniciens ont les
moyens et les outils pour faire leur travail, mais aussi lever tous les obstacles relatifs à l’organisation.
Par exemple, ce personnel doit disposer d’un bon équipement. Il n’est pas nécessaire que cet
équipement soit « l’état de l’art » mais il faut qu’il soit de qualité acceptable. Etant placés sur le terrain
techno-informatique, ces techniciens vont se sentir frustrés s’ils ne disposent pas du hardware
approprié pour faire efficacement leur travail. Créer le bon environnement veut dire aussi lever les
obstacles organisationnels et protéger les techniciens contre la politique de l’entreprise. Les techniciens
du domaine techno-informatique deviennent passablement indifférents s’ils sentent que le politique
commence à s’immiscer dans leur travail et dans les décisions qui les concernent.
Les managers doivent aussi s’assurer que leurs agents possèdent les compétences requises pour faire
leur travail et que des opportunités de progresser dans des nouveaux domaines techniques leur sont
offertes. Les techno- informaticiens veulent apprendre du nouveau. Beaucoup de gens veulent
apprendre de nouvelles technologies uniquement pour le plaisir d’apprendre. D’autres sentent qu’ils ont
le devoir de s’initier aux nouvelles technologies. Les managers doivent trouver des moyens qui
permettent au personnel de continuer à apprendre, pas forcément à travers des formations assurées en
classe. Cela peut se faire à travers le e-Learning, les séminaires, les « webinaires » (sessions de
formation sur le web), les livres, les magazines, etc.
Dans de nombreuses circonstances, les gens n’ont pas la possibilité de faire l’apprentissage des
nouvelles technologies, tout simplement parce que leur entreprise n’en dispose pas ou parce qu’on ne
peut se passer de ces gens qui ne doivent pas quitter leurs postes. Une des options possibles pour
beaucoup d’équipes est de pratiquer la rotation des tâches. Les gens qui travaillent dans le domaine du
soutien et de la maintenance doivent avoir l’opportunité d’échanger leurs responsabilités, ce qui leur
permet d’apprendre du nouveau. Les membres de l’équipe d’un projet doivent être en mesure
d’échanger leurs formations dans différents domaines pour leur permettre d’acquérir de nouvelles
connaissances.
Les managers doivent s’efforcer d’être des communicateurs proactifs. Rappelez-vous : beaucoup de
spécialistes en techno-informatique sont des introvertis qui veulent traiter l’information intérieurement.
Ils peuvent donc venir ou ne pas venir vers vous pour vous poser des questions sur ce qui se passe.
Cependant, ces techniciens consacrent un certain temps à réfléchir intérieurement. Aussi faut-il
s’assurer qu’ils ont assez d’informations pour garder leurs modèles mentaux en état d’éveil. Les
managers doivent s’assurer qu’ils communiquent autant qu’ils peuvent sur ce qui se passe dans
l’entreprise, dans leur service ou leur groupe. Ils doivent au moins s’assurer que les gens comprennent
ce qu’ils font et pourquoi ils le font. Le personnel a besoin de savoir comment le travail qu’il effectue
produit de la valeur pour l’entreprise. Lorsqu’un groupe de personnes travaille sur des projets, il faut
s’assurer que les chefs de projet cherchent à s’informer sur la situation, sur ce qu’ils font et comment ils
le font, et sur la manière dont chaque personne contribue à la solution finale.
Les responsables doivent aussi s’assurer que l’équipe continue à réfléchir en tant que groupe
homogène. Puisque les techno-informaticiens ont tendance à être introvertis, cela peut vous amener à
penser qu’ils préfèrent travailler seuls. Dans certains cas, cela est vrai, mais ce n’est pas souvent le cas.
Ces techniciens préfèrent travailler de manière indépendante, mais ils veulent aussi rester membres du
groupe. Les managers doivent aussi nourrir ce besoin. Par exemple, ils doivent tenir des réunions
régulières avec l’équipe. Si l’équipe n’est pas habituée à ces réunions, ils doivent d’abord rencontrer les
membres suffisamment longtemps. Très vite, l’équipe va leur faire le plaisir de se remettre ensemble.
Les managers doivent s’assurer aussi d’avoir des occasions de prendre du plaisir en tant que groupe,
même s’il ne s’agit que de déjeuner ensemble, de temps en temps.
370
Vous aurez remarqué que plusieurs de ces techniques de gestion ne concernent pas uniquement le
personnel technique en général et le personnel techno-informatique en particulier. Beaucoup de ces
techniques peuvent être utilisées dans d’autres domaines. Cependant, elles conviennent
particulièrement aux techno-informaticiens. Maintenant que vous avez examiné plusieurs idées, voici un
résumé des idées générales dont vous devriez tenir compte lorsque vous gérer votre personnel.
 Essayez de créer un environnement où les gens sentent qu’ils disposent de ce dont ils ont
besoin pour faire leur travail, y compris le hardware approprié, les logiciels, les assurances, les
procédures, etc.
 Les techniciens veulent comprendre les processus au sein du groupe et veulent donc être
créatifs quand ils travaillent avec cette structure. Aussi faut-il établir les règles générales mais
ne pas se mêler de gérer les détails.
 Donnez aux gens autant d’informations que nécessaire pour qu’ils fassent leur travail. Le
personnel technique a tendance à réfléchir sur ces informations. Demandez-lui d’exprimer ses
avis et ses opinions, mais donnez-lui du temps et beaucoup d’occasions. N’attendez surtout pas
qu’il réagisse immédiatement.
 Protégez l’équipe contre les politiques bureaucratiques et contre toutes sortes de distractions
qui abondent dans une grande entreprise. Dites aux gens ce qu’ils ont besoin de savoir (voir le
point précédent) mais ne les laissez pas patauger dans la boue de l’entreprise.
 Offrez aux gens des opportunités continuelles d’apprendre. Encouragez-les à investir leur temps
dans l’apprentissage mais aidez-les en leur offrant quelques occasions. Il y a beaucoup de voies
très créatives pour apprendre. Une fois qu'une personne a maîtrisé une compétence particulière
ou un aspect de son travail et qu’il commence à se lasser, cherchez les moyens de l’amener à
partager ses connaissances et à découvrir de nouveaux domaines auprès des autres membres
du groupe.
 Soyez là quand il le faut et répondez aux questions et aux préoccupations. Tous les problèmes
ne peuvent pas être résolus, mais souvent le seul fait d’être à l’écoute et d’essayer suffit. Les
gens vous seront reconnaissants d’avoir essayé, même si la solution dernière du problème n’a
pas été trouvée.
Soyez sensible aux différences lorsque vous dirigez un personnel diversifié (8.2.3. P16)
Vous avez tous certainement entendu le dicton: "On a besoin de tout genre de personne" En fait, pour
qu’une équipe, un département ou même un pays puisse être constitué, il faut qu’il y ait des personnes
diversifiées. Imaginez qu'on était tous identiques! La vie aurait été ennuyeuse. Certaines personnes ne
sont pas si si enthousiastes d'elles-mêmes. Imaginez si tout le monde est dans cette même vision.
Les meilleures équipes sont souvent formées de groupes de personnes avec des profils variés et qui
sont là pour assurer le bon fonctionnement du travail. Des personnes différentes ont des points forts et
des points faibles différents, et le tableau est achevé quand les points forts des uns coïncident avec les
faiblesses des autres.
Cependant, quand nous parlons de diversité, nous parlons souvent de concepts plus larges que de la
diversité des compétences, mais plutôt de groupes d’hommes et de femmes ayant différentes cultures,
appartenances et contextes ethniques. Ces groupes diversifiés ont besoin de s’unir afin de réaliser par
leur travail un ensemble d’objectifs communs.
Plusieurs raisons font que la diversité est importante pour les entreprises. D’abord, une force de travail
diversifiée implique généralement (mais pas toujours) que l’entreprise ne pratique pas, consciemment
ou inconsciemment, de discrimination raciale. L’idée, ici, c’est qu’une entreprise ou un organisme
composé en majorité d’hommes, pratique peut-être une discrimination à l’égard des femmes. De
même, une entreprise qui ne compte que de personnes appartenant à une ethnie donnée pratique
peut-être une discrimination à l’encontre de personnes appartenant à d’autres ethnies. Cette
discrimination peut ne pas être évidente et provenir de la tendance de certains managers à recruter les
gens qui leur ressemblent, mais le résultat c’est qu’un certain nombre de bons candidats seront
disqualifiés en raison de leur différence culturelle.
371
La diversité peut également favoriser l’existence d’une large gamme d’idées et de points de vue. Par
exemple, les hommes et les femmes peuvent avoir des opinions différentes au sujet d’un même
problème. Lorsque des problèmes complexes apparaissent ne vaut-il pas mieux avoir quatre opinions à
examiner émanant d’un groupe d’hommes et de femmes plutôt que deux seules solutions proposées
par un groupe d’hommes qui pensent de la même manière ? Dans certains organismes, la diversité est
vitale pour atteindre le succès.
Par exemple, le service de marketing peut mieux attirer un large spectre de clients si l’équipe de
marketing est constituée d’un large spectre de gens. En d’autres termes, un groupe composé de cinq
personnes de sexe masculin et appartenant au même groupe culturel aura du mal à faire efficacement
du marketing auprès des femmes appartenant à un groupe culturel différent. Renforcer le groupe au
moyen de cinq femmes du même groupe culturel peut être utile, mais ne résout pas le problème de
base. Il semble évident qu’une équipe de marketing diversifiée, composée d’hommes et de femmes
appartenant à différents milieux culturels présente de plus grandes chances de succès.
La question est donc maintenant de savoir comment gérer au mieux une force de travail diversifiée.
Comme manager, la première chose dont on doit se rappeler c’est que tout le monde est différent. Il
est important de reconnaître les différences et de mélanger les individus pour former un groupe
cohérent. Les managers devraient considérer la diversité sous plusieurs angles.
 Ne pas tolérer les préjugés ou le harcèlement : Il s’agit là d’un point de départ vital et si
un responsable ne peut pas prendre en charge cette exigence, il doit être remplacé. Avant
d’aller plus loin dans les détails de la gestion d’une main d'oeuvre diversifiée, un responsable
doit être absolument sûr que l’environnement est sain et que le champ d’action n’est pas semé
d’embûches. Le harcèlement et les actes hostiles ne peuvent être tolérés.
 Etre attentif aux différences : L’idée ici c’est que chaque personne est différente du fait de
ce qu’elle est, mais aussi du fait de la culture au sein de laquelle elle a grandi. Par exemple,
une femme peut être discrète parce qu’elle a une personnalité introvertie ou parce qu’elle
appartient à une culture où la discrétion est considérée comme une vertu. Le manager du
groupe doit être attentif à cette particularité et chercher le moyen de faciliter sa participation
dans les échanges de vues de l’équipe de projet.
 Soutenir la différence quand cela est possible : Il s’agit là de l’un des aspects essentiels
de la gestion d’une force de travail diversifiée. Le manager est tenu de le faire comprendre à
tous pour que tout se déroule convenablement. Si le manager ne cherche pas à découvrir les
raisons qui font que cela ne marche pas, la diversité de l’équipe sera considérée comme une
entrave, pas comme un facteur de réussite.
 Aider chacun à progresser : Il faut chercher des raisons pour offrir à chacun des
responsabilités et des opportunités. Encore une fois, ne cherchez pas des raisons susceptibles
d’entraver les gens. Intéressez-vous plutôt à leurs points forts.
Bien que la diversité puisse nettement contribuer au bénéfice de tous, il est vrai que dans un nombre
limité de cas, une difficulté culturelle peut réellement avoir un important impact négatif sur l’aptitude
d’un individu à effectuer un certain travail. Cependant, si vous dirigez tout en étant acquis au principe
de la diversité, vous finirez par trouver que ces situations sont peu nombreuses et qu’elles se
présentent rarement. Si un manager fait un effort, il finira par trouver comment tirer parti de la
diversité dans beaucoup de circonstances. Ces situations vont contribuer au bénéfice de l’individu et à
celui de l’équipe.
Résoudre graduellement un problème de rendement au moyen d’un plan formel (8.2.3. P17)
Une des tâches les plus pénibles pour un manager est de s’engager avec un employé sur une voie qui
mène, au bout du compte, au licenciement. Il est déjà assez difficile pour la plupart des responsables
de fournir des réactions en retour (feedback) pour commencer, même quand le rendement de
l’employé est bon. Lorsque le rendement de l’employé n’atteint pas le niveau requis, c’est encore plus
difficile.
La première chose à faire lorsque vous vous apercevez d’un problème de rendement, c’est de vous
asseoir avec l’employé, de présenter vos observations sur le sujet, d’essayer de trouver la cause et
372
d’établir un plan à court terme, de telle sorte que l’employé puisse avoir une chance de renverser la
situation.
Malheureusement, les premières réactions au sujet de la performance et le plan à court terme, dans
certains cas, ne produisent pas l’effet attendu. Lorsque cela arrive, le manager doit prendre des
mesures supplémentaires. Dans certaines entreprises, et dans certaines situations, l’étape suivante
serait la rétrogradation ou le licenciement. Cela peut être le cas dans les petites compagnies où l’équipe
de direction doit prendre vite les décisions concernant le personnel et où la compagnie n’est pas
soumise à beaucoup d’obligations du point de vue des ressources humaines.
Dans des entreprises de plus grande envergure, par contre, les managers n’exercent normalement pas
l’autorité de congédier le personnel de leur propre chef. Le service des ressources humaines dispose de
processus mis en place pour s’assurer que les gens sont traités équitablement et dans le cadre de la
légalité. Si un manager a essayé de résoudre un problème par ses propres moyens mais n’a pas réussi
à le faire, c’est au tour du processus formel des ressources humaines d’entrer en jeu.
Un manager qui met en lumière un problème de rendement et essaie de le traiter est digne de
confiance. Beaucoup de managers fuient la confrontation directe avec ce genre de situations, au
détriment de l’entreprise toute entière.
Cependant, pour le bien de l’individu et celui de l’entreprise, un problème de rendement ne devrait pas
traîner en longueur.
Les responsables hésitent quelques fois à prendre des mesures concernant le personnel parce qu’ils
s’inquiètent de la manière dont le reste de l’équipe va réagir. Si l’employé est populaire, on est tenté de
croire que la réaction sera négative. En fait, cela devrait être le cas si le manager agit arbitrairement. Si
le manager donne à l’employé une chance d’améliorer son rendement mais que le problème persiste, le
licenciement devient nécessaire. Dans ce cas, le manager doit être capable d’expliquer au reste de
l’équipe tout ce qui a été fait en faveur de l’employé. Le reste de l’équipe comprendra du premier coup
que le rendement de l’employé était faible. Ils comprendront aussi que le remplacement de cet employé
est dans le meilleur intérêt de l’équipe, de l’entreprise et peut-être aussi de l’employé lui-même.
Une équipe connaît ses maillons faibles. Dans nombre de situations, le reste de l’équipe finit par
travailler plus dur pour compenser le faible rendement d’une personne. Dans le meilleur des cas,
l’équipe agit ainsi de son plein gré (et peut être inconsciemment), mais cette façon de faire signifie que
cela n’est peut-être pas la bonne solution. Dans le pire des cas, la camaraderie commence à se
retourner contre la personne au faible rendement et provoque du ressentiment, de l’animosité et des
frictions entre les membres de l’équipe.
En général, les personnes performantes se sentent aussi mal à l’aise. Quelques fois, la découverte d’un
problème de performance les heurte de plein fouet. Cependant, dans la plupart des cas, ils connaissent
déjà la situation. Les travailleurs à faible rendement se rendent compte qu’ils sont en train de dépasser
les délais fixés et que la réalisation du travail exige beaucoup de travail de reprise. Lorsqu’ils se
trouvent engagés dans un plan d’amélioration à court terme, ils deviennent profondément attentifs au
fait que leur performance répond ou ne répond pas aux attentes. S’ils continuent à ne pas pouvoir
répondre aux attentes, cela deviendra de plus en plus évident pour eux. La situation leur occasionnera
plus d’anxiété, ce qui peut affaiblir encore le rendement. La situation doit être réglée aussi bien pour
l’intérêt de l’employé que pour celui de l’entreprise.
N’oubliez pas que mettre en place un plan formel de performance ne veut pas dire la même chose que
licencier. Le plan formel est réellement un moyen de sauver la personne d’un possible licenciement. Un
bon plan de performance met tout noir sur blanc, et doit surtout préciser les attentes. Il faut en
particulier inscrire les éléments suivants dans le plan de performance :
 Les éléments de base : Nom de l’employé, nom du chef, date, entreprise, etc.
 Durée du plan de performance : Il faut indiquer en particulier la date de fin. Ne dites pas
seulement trois mois, mais plutôt : Le 30 juin 200x.
 Les attentes : Préciser les attentes spécifiques du manager, en indiquant les dates
intermédiaires correspondantes, s’il y a lieu. Par exemple, si l’employé a des livrables à terminer
373
dans les deux mois à venir, il faut les inclure dans le plan de performance, en précisant les
dates correspondantes.
 Exiger de l’employé des rapports réguliers : Demandez à l’employé de faire des rapports
intermédiaires de performance, par écrit, chaque semaine ou toutes les deux semaines. Ces
rapports doivent être soumis au responsable dans les délais.
 Rapport du responsable : Le plan de performance explicite aussi les engagements du

manager. Ce que ce dernier doit faire surtout, c’est fournir, par écrit et continuellement, ses
appréciations à l’employé sur la manière dont il progresse par rapport au plan de performance.
 Les approbations : Signatures de l’employé, de son chef et du responsable des ressources

humaines. Cela confirme que le plan a été lu et approuvé.
Une fois que le plan de performance signé, il est mis en route. L’employé doit s’efforcer de répondre
aux attentes fixées par ce plan. Le chef de projet doit donner continuellement ses appréciations sur les
performances de l’employé et dire s’il répond aux attentes. Si ce n’est pas le cas, le chef doit continuer
à le rappeler dans ses appréciations écrites. Cela garantit qu’il n’y aura pas de surprises.
Le plan de performance peut être achevé de plusieurs manières :
1. L’employé réalise le plan avec succès : Cela montre que ses performances sont maintenant
conformes aux attentes. Cela ne veut pas dire qu’il excelle, mais simplement qu’il a répondu
aux exigences du plan de performance. S’il peut continuer à assurer ce niveau de rendement, il
sera probablement en règle. Si son rendement dérape à nouveau, des mesures plus drastiques
seront nécessaires, y compris la décision de licenciement, sans qu’il lui soit possible de
bénéficier d’un autre plan de performance.
2. L’employé s’en va : Dans de nombreux cas, lorsqu’un employé se trouve impliqué dans un
plan de performance, il va laisser entendre qu’il se met à chercher un autre travail. Comme
manager vous devez vous préparer à une telle éventualité. En fait, cela peut être la meilleure
solution pour tout le monde. L’employé finit par trouver une opportunité où il pourrait avoir plus
de chances de succès. L’entreprise se met immédiatement à la recherche d’un autre employé,
plutôt que de continuer un plan de performance qui peut se terminer avec succès comme il
peut se terminer par un échec.
3. L’employé échoue dans le plan : Un plan de performance est une tentative sérieuse de
renverser une performance inacceptable. C’est aussi la dernière tentative. Lorsque vous mettez
en place un plan de performance formel, des délais précis doivent être fixés et ce qui peut
arriver si le plan se termine par un échec doit être indiqué clairement : le renvoi. Cependant,
l’entreprise doit se sentir à l’aise au sujet de la manière dont la situation est prise en charge.
L’employé a bénéficié d’un plan informel à court terme. Il a ensuite bénéficié de la chance de
réaliser un plan formel de performance. Comme partie prenante dans le plan, le chef a donné
continuellement ses appréciations, si bien qu’il n’y a pas eu de surprise lorsque l’employé n’a
toujours pas répondu aux attentes. Par conséquent, le renvoi est un résultat évident et prévu.
En fait, on peut affirmer que l’employé s’est renvoyé lui-même puisqu’il était entièrement
responsable du processus qui a mené à son licenciement.
Le moment où vous mettez en place le plan de performance est significatif. Ce plan doit comporter
clairement les critères d’échec et de succès. Une fois que ce plan a été mis en place, le manager ne fait
qu’exécuter un processus et ce dernier doit exactement être suivi conformément au plan de
performance. Toute déviation de la part de l’employé peut entraîner son échec dans la réalisation du
plan à ce stade. Toute déviation de la part du responsable doit entraîner la revalidation du plan.
Gérer les équipes virtuelles (8.2.3. P18)
La majorité des gens travaillent en équipe. Il a toujours été prouvé que les équipes les plus efficaces
sont celles où il existe une certaine cohésion entre ses membres. En fait, plusieurs gérants décident de
placer leurs équipes ensemble après une réorganisation afin d'éviter la perte de productivité liée à une
équipe dispersée.
374
Par contre, l'Internet, en tant qu'outil de communication et de collaboration rapide et fiable, permet aux
gens de conformer des équipes distantes. En fait, le phénomène de la mondialisation permet de mettre
à travailler ensemble des personnes qui habitent dans des lieux disséminés un peu partout dans le
monde.
Ces groupes sont parfois appelés "équipes virtuelles". Ce sont de vraies équipes et elles correspondent
à la définition classique des équipes dans le sens d'interagir pour réaliser un ensemble d'objectifs
communs. Cependant, elles sont surtout appelées "virtuelles" parce qu'elles ne communiquent pas
directement et n'interagissent pas d’une manière traditionnelle.
Les techniques suivantes peuvent être utilisées pour gérer ces équipes virtuelles:
 Établir les objectifs de l'équipe. Les membres de l'équipe devraient savoir et comprendre le fait
qu'ils vont travailler ensemble. Si chaque personne ne comprend que son propre rôle et son
propre travail, l'équipe ne se conformera pas et les personnes sont condamnées à n’être que
des collaborateurs individuels.
 Rappeler à chacun qu'il fait partie d’une équipe. Si les membres de l'équipe pensent qu'ils
travaillent d'une manière indépendante, ils vont agir individuellement. Si, par contre, ils savent
qu'ils constituent une équipe, qu'ils partagent des objectifs communs et qu’ils créent ensemble
les livrables du projet, ils se sentiront mieux et seront plus à même de coopérer avec les autres
co-équipiers.
 Établir les règles de base. Même si les membres de l'équipe peuvent être remplacés, ils ont
encore besoin de faire preuve d'un ensemble de comportements acceptables. En fait, ceci est
probablement plus important pour les équipes virtuelles. Parmi ces règles de base se trouvent
des éléments tels que les horaires de travail, les réunions obligatoires (téléréunions par
l'intermédiaire de l'Internet, téléconférences téléphoniques et les réunions sur place), les
attentes par rapport au tems de réponse dans le cadre de la communication asynchrone, etc.
 Obtenir la bonne technologie. Probablement, il y a toujours eu des équipes virtuelles. Mais cette
tendance a considérablement augmenté depuis ces dernières années en raison du
développement technologique. La technologie est là pour soutenir les équipes virtuelles - il n'y
a aucune raison de s'en passer. Ceci comprend l'accès à l'Internet, les audioconférences, les
vidéos-conférences, les logiciels de collaboration, les répertoires partagés, etc.
 Rechercher des opportunités pour “socialiser.” À la différence des membres d'équipes placés
ensemble qui ont des opportunités pour socialiser tout au long de la journée, les équipes
virtuelles ont du mal à le faire. Ainsi, le chef de projet doit chercher des opportunités pour
améliorer l'esprit d'équipe. Y compris l'organisation de réunions sur place, par exemple à
l'occasion de la réunion de lancement du projet.
 Être conscient des différences culturelles. Il est possible que votre équipe virtuelle pense et agit
de la même manière. Cependant, de plus en plus d'équipes virtuelles sont formées de gens
provenant de plusieurs pays et appartenant à plusieurs cultures. Si vous fonctionnez en tant
que chef de projet dans un tel contexte, assurez-vous que vous avez une idée sur les
différences relatives à la manière d'agir et de travailler des gens.
 Communiquer, communiquer, communiquer. Le chef de projet doit être extrêmement proactif

dans sa communication pour s'assurer que tout le monde comprend ce que l'on attend de lui.
Les gens peuvent commencer à se sentir isolées s’ils ne bénéficient pas d'une communication
régulière. Il est déjà assez difficile de garder tout le monde informé dans le cadre d'un projet
"ordinaire". Les canaux de communication dans le cadre d'une équipe virtuelle doivent être
encore plus ouverts. Et le chef de projet a un rôle central au sein du groupe pour diffuser des
informations.
 Prendre en considération les décalages horaires. Le chef de projet doit comprendre que ce qui
lui convient peut ne pas convenir à certains membres de l'équipe. Par exemple, si vous êtes un
chef de projet dans une société internationale, ce ne serait pas pratique de commencer toutes
les réunions de projet à 9:00 du matin. En effet, cela peut convenir au chef de projet mais ne
375
pas convenir aux personnes se trouvant dans d'autres endroits là ou ils doivent rester tard dans
les bureaux pour assister à ces réunions.
 Être très diligent par rapport à la gestion du flux des travaux. Le chef de projet doit être très
précis dans l'affectation du travail aux membres de l'équipe virtuelle et il doit s’assurer que le
travail est achevé dans les délais.
 Donner aux gens des missions courtes. Le contexte d'une équipe virtuelle ne permet pas de
donner aux gens de longues missions en espérant que ces dernières soient achevées dans les
délais. Au lieu d'attribuer une activité de six semaines comme mission, par exemple, le chef de
projet doit assigner le travail en trois activités de deux semaines chacune. Sinon, il devra
attendre six semaines pour obtenir un résultat. Le découpage de l'activité en trois activités plus
petites lui permet d'obtenir des résultats toutes les deux semaines et d'appliquer davantage de
mesures correctives.
376
8.3 Gérer les ressources humaines / Références rapides
Livrables (8.3. P1)
Les livrables suivants sont disponibles dans la bibliothèques de modèles TenStep destinés à soutenir ce
processus. (Certains de ces modèles ne sont accessibles que pour les utilisateurs qui détiennent une
licence).
 360 formulaires de revue de détail et de résumés
 Fiche de l’expérience professionnelle du candidat
 Formulaire d’action de coaching
 Plaintes des employés
 Auto évaluation des employés
 Journal de formation des employés
 Avertissement formel au sujet de la performance
 Autorisation de recruter
 Description du métier
 Poste de travail
 Journal des nouveaux recrutements
 Plan de rendement et de développement
 Revue des performances
 Plan de gestion du recrutement
 Formulaire de demande de congé
 Objectifs de rendement annuel
Petits
Pas d’activités requises
projets
C’est le travail lié à la détermination du type de

Former l’équipe personnel dont vous avez besoin pour votre projet, à la
ouvert
Projets de Projet façon des découvrir et de faire en sorte qu’ils soient
moyens et réellement disponibles pour votre équipe.
grands
Développer les Ce travail vous permet de vous assurer que votre
compétences de équipe possèdes compétences requises et que vous lui
ouvert apportez le coaching nécessaire pour aider ses
l’équipe
de projet membres à progresser techniquement et
professionnellement. Beaucoup d’activités spécifiques
377
peuvent être associées à ce travail, mais elles varient
d’un projet à l’autre.
C’est le travail qui consiste à assigner les tâches dans le

cadre du projet et à s’assurer que le travail est terminé
à temps. Ce thème est traité dans la méthodologie
TenStep, 3.0 Gérer l’échéancier et le budget. Ce travail
Gérer l’équipe de consiste aussi à donner des appréciations sur les
ouvert
projet performances, à gérer les problèmes liés au personnel
et à s’assurer que le groupe est cohérent et très
performant. Nombre d’activités spécifiques peuvent
être associées à ce travail, mais celles-ci varient d’un
projet à l’autre.
378
______________________________________________________________________
Processus 9
Gérer la qualité et les
métriques
379
9.0 Gérer la qualité et les métriques
La qualité est, en fin de compte, définie

par le client et représente la façon dont le
projet et les livrables répondent à ses
exigences et à ses attentes.
Le vieil adage à propos de la qualité, qui
serait dans les yeux du spectateur, se
vérifie : la qualité est bien, en fin de
compte, mesurée par votre client. Ce n'est
pas au au gré de l'équipe du projet de
déterminer le niveau de qualité exigée
pour le projet. L'équipe du projet doit
assimiler les exigences et les attentes du
client – et par la suite atteindre ces
attentes.

Il s’agit d’un concept critique au sujet de la qualité. On a parfois tendance à penser que « qualité »
signifie le meilleur matériel, le meilleur équipement et absolument aucun défaut. Cependant, dans la
plupart des cas, le client n’attend pas une solution parfaite, et n’en a probablement pas les moyens.
Même s’il y a quelques défauts dans le projet, le client peut toujours dire que la solution a été fournie
avec un niveau élevé de qualité. D'autre part, une solution conçue de façon parfaite et sans défauts, si
elle ne répond pas aux besoins du client, ne sera pas considérée comme étant de haute qualité. Le but
de la gestion de la qualité est de comprendre d’emblée les attentes du client en termes de qualité, puis
de mettre en place un plan et un processus proactifs pour répondre à ces attentes.
Comme la qualité est définie par le client, il peut sembler qu’elle soit complètement subjective.
Cependant, beaucoup d’éléments au sujet de la qualité peuvent devenir objectifs. Cela exige d'abord
une décomposition du terme générique « qualité » en un certain nombre de caractéristiques spécifiques
que le client considère comme importantes. Vous examinez ensuite chacune de ces caractéristiques et
déterminez une ou plusieurs métriques qui peuvent être collectés pour la refléter. Une des
fonctionnalités d'une solution de qualité peut être, par exemple, le fait qu'elle possède une quantité
minimale d'erreurs. Cette caractéristique est mesurée en comptant les erreurs et les défauts une fois
que la solution a été trouvée.
La gestion des métriques et la gestion de la qualité sont liées. Il est très difficile d'améliorer la qualité
de vos livrables ou l’efficacité de vos processus si vous ne rassemblez pas des métriques. Les métriques
sont utilisées pour donner une indication de l’état de la qualité au départ (qualité des livrables et qualité
380
des processus du projet) et déterminer si la qualité croît ou décroît. En plus de déterminer le niveau de
qualité d’un projet, les métriques peuvent aussi être utilisées pour fournir des critères objectifs afin de
déterminer si votre projet a été réussi. Ceci représente l’objectif du tableau de bord du projet.
En plus de la définition de la qualité donnée par le client, il est également important de comprendre les
intérêts des autres parties prenantes. Suivant leurs rôles, il se peut qu’elles aient d’autres spécifications
sur la qualité qui devront être satisfaites. Par exemple :
 Pour la compagnie - la solution répond aux objectifs stratégiques.
 Pour les acheteurs - la solution répond aux spécifications.
 Pour l’utilisateur final - la solution lui permet d’exécuter son travail avec plus de rapidité, avec
plus de facilité et avec plus de compétence.
 Pour les organismes de soutien TI - la solution est stable, connaît peu de bogues, est
compréhensible et peut être modifiée facilement.
Cliquez ici pour mieux comprendre la nature du management de la qualité - 9.0.1 Comprendre la nature
de la gestion de la qualité.
9.1 Gérer la qualité / Processus
9.1.3.1 Gérer les métriques / Processus
9.2 Gérer la qualité / Technique
9.2.1 Gérer les métriques / Techniques
9.3 Gérer la qualité / Produits livrables
9.3.1 Gérer les métriques / Références rapides
381
9.0.1 Comprendre la nature de la gestion de la qualité
Trouver les erreurs le plus tôt possible (9.0.1. P1)
Un dirigeant de Hewlett Packard a fait la remarque suivante : “ si vous découvrez un défaut sur une
résistance à deux centimes avant de l’utiliser et que vous vous en débarrassez, vous perdez deux cents.
Si vous ne trouvez pas le défaut avant que la résistance soit soudée dans un composant informatique,
vous devrez dépenser 10 $ pour la réparer. Si vous ne le trouvez pas avant qu’elle soit dans
l’ordinateur… la dépense dépassera le coût de production… ”
L’un des objectifs de la gestion de la qualité est de trouver les erreurs et les défauts le plus tôt possible
dans le projet. Par conséquent, c’est en amont qu’un bon processus de management de la qualité
demandera plus d’heures d’effort et coûtera davantage. Mais le bénéfice sera plus grand au fur et à
mesure que le projet progresse. Par exemple, il est beaucoup plus facile de repérer les problèmes
relatifs aux exigences commerciales durant la phase d’analyse du projet que d’être obligé de faire du
travail de reprise pour résoudre les problèmes durant les tests. Il revient aussi moins cher de découvrir
un problème de microplaquette d’un ordinateur au moment où cette dernière n’est fabriquée qu’au
moment où le client ramène l’ordinateur au service après vente. En d’autres termes, l’équipe de projet
doit veiller à maintenir une haute qualité et un faible niveau de défauts durant le processus entier de
création du livrable, plutôt que d’espérer découvrir les problèmes et les résoudre durant la phase de
tests, à la fin du projet (ou, pire, de voir le client découvrir le problème quand le projet est terminé).
Sur de nombreux projets, le repérage des erreurs a lieu lors des phases plus tardives de tests et de
maintenance du produit.
La meilleure approche est d’effectuer le contrôle qualité et l’assurance qualité tout au long du projet.
Votre but devrait être d’abord de prévenir autant d’erreurs que possible. Cependant, il est aussi
important de découvrir aussi vite que possible les erreurs qui surviennent, afin de minimiser l’impact
des mesures correctives qu’elles impliquent.
Contrôle qualité et assurance qualité (9.0.1. P2)
Avant que le processus global de qualité ne puisse être défini, une brève explication est donnée ici pour
fournir une définition commune du contrôle qualité et de l’assurance qualité.
 Le contrôle qualité se rapporte aux activités associées à la validation de la qualité des

livrables. Le contrôle de la qualité est aussi appelé « inspection » puisqu’il signifie que la qualité
est validée au sein d’un livrable (ou brouillon de livrable) qui existe déjà. On emploie le CQ pour
vérifier que les livrables sont d’une qualité acceptable et qu’ils répondent aux critères
d’acceptation établis dans le processus de planification de la qualité. Le contrôle qualité est
mené de façon continue tout au long du projet, et est placé sous la responsabilité des membres
382
de l’équipe et du chef de projet. Voir la section 9.2.3. Questions de contrôle qualité pour des
exemples et pour plus de détails.
 L’assurance qualité (AQ) ne se réfère pas directement à des livrables spécifiques. Elle se
rapporte aux processus qui aboutissent à la création des livrables. L’assurance qualité est aussi
désignée par le terme « prévention ». Les activités d'assurance qualité se concentrent sur les
processus employés pour gérer et livrer la solution. Elles peuvent être exécutées par un
manager, par un client ou par un vérificateur extérieur. Par exemple, un vérificateur
indépendant sera incapable d’affirmer si le contenu d'un livrable spécifique est acceptable.
Cependant, il sera en mesure de dire si ce livrable semble acceptable en se basant sur le
processus employé pour le créer. Il peut déterminer, par exemple, si des révisions ont été
exécutées, s’il a été testé convenablement, si le client a approuvé le travail, etc. Voir la section
9.2.4 Questions d’assurance qualité pour plus de détails et pour des exemples.
L’assurance qualité est effectuée à un niveau plus général que le contrôle qualité. Par exemple, vous
devez inspecter 100% des produits que vous fabriquez. Cette inspection physique est un exemple de
contrôle qualité. Durant votre inspection, vous découvrez que 3% de vos produits présentent des
défauts et doivent être détruits. Vous considérez cela comme une dépense acceptable et continuez
ainsi, en étant satisfait de saisir les 3% du produit pour les jeter au loin.
Si vous utilisez les techniques de l’assurance qualité, cependant, vous voudriez déterminer ce qui a
causé ce taux de 3% de défauts. Une fois que vous avez découvert la cause de ces erreurs, vous
modifierez votre processus de production pour essayer d’éliminer ces erreurs. Ce travail sur votre
processus, c’est l’assurance qualité. Les modifications apportées à votre processus (assurance qualité)
entraînent la baisse du nombre de défauts trouvés au cours du processus d’inspection (contrôle
qualité).
383
9.1 Gérer la qualité / Processus
Les processus utilisés pour gérer la qualité sont décrits dans cette partie. Ces processus peuvent être
modifiés selon les besoins spécifiques de votre projet, et ensuite être insérés dans le document des
processus de management de projet créé à l’étape 1.0 Définir le travail.
Petits projets (9.1. P1)
Les petits projets ne sont pas assez longs pour que les processus internes de travail soient révisés et
améliorés pour être ramenés à un niveau de qualité plus élevé (assurance qualité). Ils doivent par
conséquent se préoccuper uniquement des étapes de contrôle qualité. Chaque livrable réalisé doit être
passé en revue et approuvé. La révision finale (peut-être la seule) se déroule avec le client. Celle-ci se
focalise sur la qualité globale du livrable. De plus, si le livrable peut être testé, la revue inclura une
discussion sur le processus de test utilisé et un examen des résultats de ces tests.
Cela ne veut pas dire que vous devriez être négligeant ou que vous allez produire des solutions de
mauvaise qualité dans les petits projets. Cependant, le travail nécessaire pour établir un processus
officiel de management de qualité, y compris le contrôle qualité, l’assurance qualité et la réunion des
métriques pour soutenir le programme, ne sera pas bénéfique quand aux coûts dans les petits projets.
9.1.2 Projets de taille moyenne
384
9.1.2 Gérer la qualité / Projets de taille moyenne
Au début du projet
Planification de la qualité (9.1.2. P1)
Rôle Gérer la Qualité (Projets moyens)
1 Chef de projet Déterminer les exigences du client en matière de qualité

Développez un plan de management de la qualité pour identifier les livrables
principaux, les critères d’acceptation, les activités de contrôle qualité, et celles
d’assurance qualité.
Voir 9.1.2.1 Créer le plan de management de la qualité pour plus de détails.
2 Chef de projet Créer un plan de management de la qualité

Travaillez avec votre client afin de déterminer ses exigences en matière de
qualité. Ce sont les caractéristiques détaillées qui importent aux yeux du client.
Les exigences de qualité détaillées devraient être mises en évidence pendant la
collecte des exigences commerciales pour votre solution.
Au cours des processus
Exécuter le contrôle qualité et l’assurance qualité (9.1.2. P2)
3 Chef de projet Exécuter les activités de contrôle qualité

Assurez-vous que les activités de contrôle qualité pour chaque produit livrable
sont exécutées pendant le déroulement du projet. (Une technique courante de
contrôle qualité est la révision des livrables, décrite plus en détail au
paragraphe 9.1.3.2 La révision des livrables.)
4 Chef de projet Exécuter les activités d’assurance qualité

Pendant le projet, menez toutes les activités d’assurance qualité telles qu’elles
sont indiquées dans l'échéancier du projet.
5 Chef de projet Mettre à jour et contrôler le plan de management de la qualité

Évaluez le plan de management de la qualité à un rythme mensuel ou lors de
l'accomplissement des principaux jalons. La révision devra se focaliser sur le
plan de management de la qualité pour savoir s’il est toujours adéquat et
s’assurer que les livrables du projet sont réalisés conformément aux attentes
du client. Si ce n’est pas le cas, apportez des modifications au plan de
management de la qualité pour le mettre à jour, et mettez à jour l'échéancier
du projet en y ajoutant les activités nouvelles ou modifiées requises.
6 Chef de projet (Facultatif) Examiner les principaux enseignements à la fin du projet

A la fin de votre projet, donnez à l'entreprise une rétroaction sur les résultats
de votre processus de qualité, et faites un rapport sur les métriques recueillies.
Celles-ci pourront être généralisées dans un programme plus large de gestion
des métriques, à l’échelle de l’entreprise, et être intégrées aux meilleures
pratiques susceptibles d’être réutilisées dans d’autres projets. Cette étape n’a
pas lieu d’être si votre entreprise ne collecte pas des métriques de projet.
385
9.1.2.1 Créer le plan de management de la qualité
Le plan de management de la qualité décrit la manière avec laquelle vous allez vous assurer que les
exigences de qualité du client sont atteintes. C'est aussi l'endroit dans lequel vous décrivez les
processus et activités qui vont être mis en place dans le but assurer la production de livrables de
qualité. Le plan de management de la qualité vous permet de savoir si les livrables sont complets et de
démontrer qu'ils sont corrects.
Les exigences de la qualité réelles ne sont pas connues au moment de la création du plan de
management de la qualité, cependant, vous devez décrire le processus et les techniques que vous allez
utiliser pour tenir compte des exigences relatives à la qualité et vérifier que ces exigences soient
respectées. Les informations dans le plan de management de la qualité comprennent les éléments
suivants:
 Les rôles et responsabilités. Décrivez les différents rôles par rapport à la qualité dans le
projet. Le chef de projet assume toute la responsabilité, mais vous pourriez avoir d'autres rôles
de support. Ceux-là pourraient inclure des auditeurs, des experts externes en matière de test,
des inspecteurs, etc.
 Critères d’achèvement et d'acceptation. L'objectif des critères d’achèvement et

d'acceptation est de travailler à l'avance avec le client pour définir comment un livrable sera
considéré comme achevé et correct. Après, quand vous y arrivez, vous pouvez certainement
vous attendre à ce que le client soit satisfait. Si vous définissez les critères et les attentes à
l'avance, vous serez beaucoup plus à même de satisfaire les attentes du client. En d'autres
termes, il ne doit pas y avoir de surprises.
 Processus des exigences qualité. Décrit le processus que vous allez utiliser pour tenir
compte et valider les attentes du client quant à la qualité. Généralement, cela fera partie du
processus de reunion des exigences.
 Les activités d'assurance qualité. Les activités d'assurance qualité se concentrent sur les
processus utilisés pour élaborer le produit du projet et gérer ces travaux, et elles peuvent être
mises en œuvre par un cadre dirigeant, le commanditaire, ou peuvent être sous-traités.
Décrivez les activités importantes et les techniques d'assurance qualité à utiliser dans le projet.
 Les activités de contrôle qualité. Les activités de contrôle qualité sont effectuées d'une
manière continue tout le long du projet pour vérifier que la gestion du projet et ses livrables
sont de bonne qualité. Décrivez les activités importantes et les techniques de contrôle qualité à
utiliser dans le projet.
 Les normes qualité. Identifiez les normes qualité que la société ou l'organisation a défini
comme pertinentes pour ce projet.
 Les outils de gestion de la qualité. Identifiez les outils à utiliser pour la gestion de la
qualité.
386
9.1.3 Gérer la qualité / Grands projets
Au début du projet (9.1.3. P1)
Les grands projets ont besoin d’un processus officiel de management de qualité qui combine entre le
contrôle qualité, l’assurance qualité et le management des métriques.
Planifier la qualité (9.1.3. P2)
Rôle Gérer la qualité (Grands projets)
1 Chef de projet Créer un plan de management de la qualité

Développez un plan de la qualité pour identifier les livrables principaux, les
critères d’acceptation, les activités de contrôle qualité, et celles d’assurance
qualité. Le plan de qualité vous permet de savoir la date où ces livrables sont
achevés, et de montrer s’ils sont corrects. Le plan de qualité décrit
également la façon dont vous envisagez de prouver que les exigences de
qualité du client ont été réalisées. C'est également l'endroit où vous décrivez
les processus et les activités qui seront mis en œuvre pour s'assurer que des
livrables sont des produits de qualité.
Le plan de qualité fournit une description des plans d’assurance qualité et de
contrôle qualité utilisés pour le projet. Les activités réelles nécessaires pour
la mise en place de ces processus ont besoin d'être identifiées et incluses
dans l’échéancier du projet, afin de s’assurer qu’elles seront bien effectuées.
2 Chef de projet Déterminer les exigences du client en matière de qualité

Travaillez avec votre client afin de déterminer ses exigences en matière de
qualité. Il s’agit des caractéristiques détaillées qui importent aux yeux du
client. Les exigences détaillées de la qualité doivent être prises en compte
lors de votre collecte des exigences commerciales.
3 Chef de projet Définir un ensemble d’indicateurs pour valider que les exigences de
qualité ont été satisfaites
Identifiez un ensemble de métriques qui fourniront un aperçu des progrès du
projet et des processus de création des livrables. Le chef de projet devrait
déjà collecter des indicateurs financiers et de durée, au niveau global. Les
métriques liées à la qualité devront être plus sophistiquées. Il y a deux
secteurs où vous pourrez essayer de gérer la qualité : vos processus de
travail du projet et les livrables réels que vous construisez. Vous devriez
essayer de collecter des métriques mesurant ces deux secteurs. Voici des
exemples de métriques des processus :
 La satisfaction du client par rapport à la communication de l’équipe
de projet
 La quantité de l'effort de reprise du travail en raison d’une analyse
défectueuse en amont
 La quantité de temps consacrée à la résolution des problèmes
majeurs
Exemples de métriques des livrables :
 Le nombre d’erreurs majeures découvertes durant les tests
 Le temps de réponse d’une application informatique que vous
construisez
387
 Le temps moyen pour se rendre compte de l’échec d’un produit
(Des informations complémentaires sur les métriques sont disponibles au
processus 9.1.3.1 Gérer les métriques / Processus.
Durant le cycle de vie du projet
Mettre en œuvre l’assurance qualité (9.1.3. P3)
4 Chef de projet Exécuter les activités d’assurance qualité

Au cours du projet, menez toutes les activités d’assurance qualité telles
qu’elles sont indiquées dans l'échéancier du projet.
Mettre en œuvre le contrôle qualité (9.1.3. P4)
5 Chef de projet Exécuter les activités de contrôle qualité

Assurez-vous que les activités de contrôle qualité pour chaque livrable sont
exécutées pendant le déroulement du projet. Vous devriez avoir au minimum
une revue visible du livrable et un processus d’évaluation. Vous devez au
minimum avoir en vue un processus de révision des livrables, décrit plus en
détail au paragraphe 9.1.3.2 La révision des livrables.
Mise à jour et contrôle (9.1.3. P5)
6 Chef de projet Mise à jour et contrôle du plan de management de la qualité

Évaluez le plan de management de la qualité à un rythme mensuel ou lors de
l'accomplissement des principaux jalons. La révision devra se focaliser sur le
plan de management de la qualité pour savoir s’il est toujours adéquat et
s’assurer que les livrables du projet sont réalisés conformément aux attentes
du client. Si ce n’est pas le cas, apportez des modifications au plan de
management de la qualité pour le mettre à jour, et mettez à jour l'échéancier
du projet en y ajoutant les activités nouvelles ou modifiées requises.
7 Chef de projet Recueillir des indicateurs pour confirmer que vous avez satisfait les
exigences de qualité
Pendant le projet, collectez les métriques qualitatives et prévues pour
mesurer la qualité. La plupart doivent être collectées mensuellement.
Certaines, comme les enquêtes de satisfaction du client, peuvent être
collectées chaque trimestre. Si vous construisez ou bâtissez quelque chose de
concret, vous collecterez chaque jour des métriques relatives au produit.
8 Chef de projet Analyser les indicateurs pour améliorer le processus

Analysez les métriques pour déterminer comment les processus de travail de
votre projet peuvent être améliorés. Par exemple, le processus de révision
des livrables pourra être modifié pour inclure une première révision lorsque le
produit livrable sera réalisé à 50%, au lieu d’une seule révision lorsqu’il est
achevé. Le temps requis pour cette ébauche de révision sera plus que
compensé par une nette réduction du nombre d’erreurs trouvées une fois le
produit livrable achevé. Autre exemple : pour un processus de fabrication,
vous aurez besoin d’améliorer l'équipement, d’envoyer des opérateurs suivre
des formations supplémentaires ou d’investir dans de meilleures matières
388
premières.
9 Chef de projet Analyser et résoudre les problèmes liés à la qualité

Quand des problèmes de qualité sont décelés, mettez en application un
processus visant à déterminer leur cause et à apporter des améliorations à ce
processus. (voyez le paragraphe 9.1.3.3 Résoudre les problèmes de la qualité
pour de plus amples détails.)
10 Chef de projet Mettez en œuvre les améliorations identifiées

Il peut y avoir de nombreuses idées que vous pouvez sans risque mettre en
application dans un cycle de revue. Si vous pensez que c’est le cas, donnez la
priorité aux suggestions et mettez en application celles qui vous semblent
avoir le plus de valeur, tout en exigeant un moindre effort de travail. Vous
serez en mesure de mettre en œuvre d'autres idées lors du prochain cycle de
revue et d'analyse.
11 Chef de projet Continuez à mesurer

Continuez à mesurer. Vous devrez identifier de nouveaux indicateurs, ou des
métriques révisées, pour suivre des procédés de travail nouveaux ou révisés.
389
9.1.3.1 Gérer les métriques / Processus
Petits projets (9.1.3.1. P1)
La plupart des chefs de petits projets devraient se préoccuper uniquement de recueillir les métriques
qui sont requises pour tous les projets au sein de toute l’entreprise (s’il y en a). Ces indicateurs se
composent habituellement d’informations de base, telles que la façon dont le projet progresse en
termes de coût, d'effort de travail et de durée. A la fin du projet, ces chiffres peuvent être comparés
aux estimations originales pour déterminer les performances du projet par rapport aux attentes. Des
indicateurs de satisfaction du client peuvent également être recueillis, une fois les travaux terminés.
Tous les autres métriques exigées pour tous les projets (s’il y en a) devraient également être collectées
et faire l’objet d’un rapport.
Il n’y a généralement pas besoin de collecter des métriques plus élaborées sur les livrables du projet
puisque ces derniers sont souvent, mais aussi carrément petits. Vous n’êtes pas obligés de collecter des
métriques pour améliorer le processus puisqu'il n'y a pas assez de temps pour effectuer des
améliorations ou mener des actions sur la base des résultats des métriques.
Projets moyens (9.1.3.1. P2)
Les chefs de projets moyens devraient rassembler toutes les informations exigées au sein de
l’entreprise, et qui sont les mêmes que pour de petits projets. Selon l'entreprise, des informations plus
nombreuses peuvent être exigées pour des projets de cette taille. Le chef de projet devrait également
examiner le processus de définition des métriques concernant les grands projets. Plus un projet moyen
se rapproche de la taille d'un grand projet, plus il y a intérêt à collecter de façon formelle des
métriques. Il se peut qu’elles ne deviennent pas aussi élaborées que celles d’un plus grand projet, mais
des métriques complémentaires peuvent apporter des informations de grande valeur.
Grands projets
Créer le tableau de bord du projet (9.1.3.1. P3)
Les grands projets doivent absolument collecter les métriques qui fourniront des informations sur la
qualité des livrables et des processus de création des livrables. Le processus suivant peut être employé
pour fournir des métriques appropriées au projet. Ce processus aura comme conséquence la création
d’un tableau de bord du projet.
Rôle Gérer les indicateurs (Grands projets)

Créer le tableau de bord du projet
1 Chef de projet Identifiez les critères de réussite de votre projet

Passez en revue les objectifs et les livrables figurant dans la charte du
projet, ainsi que toute autre information existante relative au projet. En
390
vous basant sur cette documentation disponible, définissez les informations
nécessaires pour prouver que le projet est achevé avec succès. Cela peut
être accompli suivant deux perspectives différentes:
 Interne. Ces caractéristiques indiquent que le projet a été géré et
exécuté de manière efficace. Ces types de métriques impliquent
que les livrables soient approuvés en deux passages en revue au
maximum, que les dates des principaux jalons de l'échéancier
soient respectées, et qu’un nombre minimum d’erreurs soit
découvert lors des tests d'acceptation par les utilisateurs, etc.
 Externe. Ces caractéristiques indiquent que les objectifs et les
livrables de votre projet ont été réalisés avec succès. Parmi les
exemples de métriques destinées à un usage externe, il y a le fait
que le projet soit achevé dans les limites du budget et du délai
approuvés, l’assurance que les livrables respectent les critères de
qualité, et la confirmation du fait qu’ils répondent bien aux attentes
du client.
Si votre entreprise essaie de se conformer au modèle CMMI, vous devez
sans doute ajouter la valeur commerciale générée par le projet comme l’un
des principaux aspects du succès du projet.
2 Chef de projet Identifiez les métriques potentielles

Identifiez les métriques potentielles pour chacun des critères de réussite
qui vous signalent si vous êtes sur la voie du succès. Ceux-ci peuvent être
des métriques directes et quantifiables, ou des métriques indirectes qui
donnent un sens aux critères de réussite. Pour chacun de ces indicateurs,
déterminez brièvement comment vous rassemblerez les informations, quel
effort de travail et quel coût la collecte de ces indicateurs implique, ainsi
que la valeur qui sera obtenue à partir de ces métriques.
3 Chef de projet Recherchez un équilibre

La liste potentielle des métriques devrait être divisée en catégories, pour
s'assurer qu'ils fournissent une vision équilibrée du projet. Par exemple, il
ne suffit pas d’avoir seulement un ensemble de métriques financières, bien
qu’ils soient plus faciles à obtenir. En général, recherchez les métriques qui
fournissent des informations sur les secteurs suivants:
 Le coût
 L'effort de travail
 La durée
 La productivité
 La qualité des livrables
 La satisfaction du client par rapport aux livrables produits
 Les performances de l’équipe de projet
 La valeur marchande fournie
Un tableau regroupant des exemples de métriques est disponible au
paragraphe 9.1.3.1.1 Exemples de métriques.
4 Chef de projet Donnez la priorité à la liste équilibrée des métriques

Suivant le nombre métriques que vous avez identifiées, donnez la priorité
dans cette liste uniquement aux indicateurs dont la collecte demande un
moindre coût mais qui donnent le plus de valeur au projet. Tous les
indicateurs collectés seront significatifs pour le projet, mais, au bout du
compte, il n’y en aura pas plus d'un ou deux par catégorie. En général,
essayez de fournir le plus d'informations possibles avec le moindre effort
de travail. Après avoir classé les métriques par ordre de priorité, vérifiez
391
une nouvelle fois pour vous assurer qu’elles sont bien équilibrées.
Réajustez ces différents indicateurs, au besoin, pour vous assurer que vous
avez toujours une liste finale équilibrée de métriques à collecter et à
analyser.
5 Chef de projet Etablissez des objectifs

Les métriques per se peuvent être d'un certain intérêt, mais la mesure de
votre réussite tient surtout à la comparaison de votre situation réelle par
rapport à un objectif prédéfini. L’objectif donne le contexte qui permet de
savoir si la situation actuelle est bonne ou mauvaise ou si elle va dans la
bonne direction. L’objectif peut être une valeur unique que vous essayez
de réaliser, comme il peut être une gamme de valeurs. Par exemple, il est
possible que vous soyez dans l’obligation d’accomplir votre projet à une
date fixe, mais que votre coût réel devra être de +/- 10% par rapport au
budget approuvé.
6 Chef de projet Ajoutez des détails à l'échéancier

Pour chaque métrique qui reste, déterminez les activités spécifiques
nécessaires pour rassembler et analyser les informations. Ces activités sont
alors ajoutées à l'échéancier du projet. Ces informations doivent inclure les
éléments suivants:
 Quelles données spécifiques sont nécessaires pour les métriques?
 Qui est responsable de la collecte des métriques ?
 Quand les métriques seront-elles collectées et feront-elles l’objet
d’un rapport?
 Comment les métriques seront-elles rapportées (rapports sur la
situation du projet, réunions trimestrielles, rapport de métriques)?
Processus continu (9.1.3.1. P4)
7 Chef de projet Collectez et améliorez vos processus

Les métriques seront collectées continuellement durant tout le projet. Elles
doivent être analysées et comparées aux chiffres visés. Des modifications
de processus peuvent devoir être effectuées en fonction des résultats des
métriques. En plus des valeurs absolues de chacun de ces indicateurs, il est
également important de considérer les tendances. Par exemple, vous
pouvez être en dépassement de budget par rapport à votre objectif.
Cependant, la tendance montrera peut-être qu’au bout de quelques mois,
vous reviendrez dans les limites de votre budget, au terme du projet. Dans
ce cas, aucune action corrective n’est nécessaire.
De même, vous pouvez avoir un objectif de satisfaction de client de niveau
4 sur une échelle de cinq points. Votre estimation courante peut être de
4,1. Cependant, si les taux précédents étaient de 4,5, 4,3 et 4,2 c’est que
la tendance est dans la mauvaise direction, et que vous devriez effectuer
des modifications, bien que vous soyez, aujourd'hui, au-dessus de l’objectif.
8 Chef de projet Analysez le tableau de bord durant tout le projet

Évaluez l’ensemble des métriques que vous collectez mensuellement pour
vous assurer qu’ils reflètent toujours exactement le point sur la situation
globale du projet, et que ce dernier se comporte comme vous le souhaitez.
Si ce n’est pas le cas, effectuez les changements appropriés.
La fin du projet (9.1.3.1. P5)
392
9 Chef de projet Faites un rapport sur vos résultats finaux ainsi que des
recommandations pour le succès global du projet
Quand le projet est achevé, l’équipe devrait établir un tableau de bord qui
reflète l’ensemble des résultats du projet. L’équipe du projet peut analyser
les derniers indicateurs et faire des recommandations sur le succès global
du projet et l’adresser au commanditaire. Celui-ci peut examiner les
résultats et décider d’accepter les recommandations de l’équipe ou de
rendre publique une évaluation finale différente au sujet du succès du
projet.
10 Chef de projet Envoyez le résultat final au Bureau de projets– PMO - (ou à tout
autre service qui centralise les rapports et les améliorations de
processus)
L’équipe du projet doit transmettre ses indicateurs finaux au Bureau de
projets (PMO) qui se charge de faire connaître la réussite du projet à
travers l’entreprise. Le Bureau de projets devra utiliser cette information
comme une donnée au sein d’un tableau de bord organisationnel qui
effectue le suivi du succès de tous les projets en continu. (Si votre
entreprise ne dispose pas d’un Bureau de projets (PMO), vous devriez
envoyer l’information à n’importe quel service responsable de l’amélioration
continue des processus.
Améliorer les processus internes du projet
Début du projet (9.1.3.1. P6)
Le processus suivant est utilise pour améliorer les processus internes du travail dans le projet.
Rôle Gérer les métriques (Grands projets)

Améliorer les processus internes du travail
1 Chef du projet Identifier les processus les plus importants du travail

Vous devez d’abord identifier les processus les plus importants du travail.
Cela inclue les processus de revue et d’approbation, ceux de la création des
livrables, les processus d’évaluation, etc. Cela n'a pas de sens d’identifier les
processus qui sont exécutés une seule fois seulement, puisque vous ne
seriez pas capable d’améliorer le processus s’il n’est jamais exécuté une
deuxième fois. Vous n’avez pas à vous soucier des processus de moindre
importance sauf s’ils se répètent encore une fois. Encore une fois vous êtes
entrain d’essayer de déterminer les processus qui vous permettront de
recevoir une certaine amélioration signifiante des coûts, de l’échéancier et
des heures d’effort.
2 Chef du projet Assigner des métriques potentielles

Identifiez les métriques potentielles pour chaque processus interne qui
fournit une indication sur l’efficacité du processus. Ces indicateurs
pourraient être directs, quantifiables ou indirects, démontrant dans quelle
mesure le processus sous-jacent est entrain de progresser. Vous devez
également déterminer comment vous allez collecter les informations, l’effort
nécessaire à la collecte et son coût ainsi que la valeur qui résulterait de la
métrique.
3 Chef du projet Classer par priorité la liste équilibrée des métriques

En vous basant sur le nombre des métriques que vous avez identifiées,
393
classer par priorité la liste pour n’y inclure que les métriques ayant le
moindre coût de collecte et fournissent la valeur la plus élevée au projet.
4 Chef du projet Etablissez des cibles

Les métriques per se pourraient s’avérer intéressantes, cependant, la
mesure du succès provient de la comparaison entre vos chiffres réels et les
chiffres ciblés prédéfinis. La cible permet reconnaitre si la valeur a été bien
mesurée ou non, ou si cela est entrain d’être réalisé. La cible pourrait être
une valeur simple que vous essayez d’atteindre comme elle pourrait être
une série de chiffres. Il est très fort probable que vous n’ayez pas de cibles
prédéfinies pour plusieurs de ces métriques. Dans ce cas, vous pourriez
avoir besoin de collecter les données dès le début du projet afin des utiliser
comme un fondement. Du moment où vous avez collecté le premier lot de
métriques, votre objectif serait d’améliorer ces métriques jusqu’à un certain
pourcentage.
5 Chef du projet Ajoutez les détails à l’échéancier

Déterminez les activités spécifiques nécessaires à la collecte et à l’analyse
des informations pour chaque indicateur de performance restant. Ces
activités sont ensuite ajoutées à l’échéancier du projet. Ces informations
devraient inclure les éléments suivants:
 Quelles sont les données spécifiques nécessaires pour les
métriques?
 Qui est responsable de la collecte des métriques?
 Quand est ce que la métrique va-t-elle être collectée et rapportée?
 Comment les métriques seraient elles rapportées (rapports
d’avancement, les réunions trimestrielles, les rapports de
métriques)?
Processus continu (9.1.3.1. P7)
6 Chef du projet Collectez et améliorez vos processus

Les métriques seront collectées continuellement pendant le projet. Ces
indicateurs doivent être analysés et comparés aux chiffres cible. La
modification d’un processus pourrait s’effectuer en se basant sur les
résultats des métriques. En plus des valeurs absolues de chaque métrique,
il est également important d’analyser les tendances. Par exemple, vous
pourriez dépasser le budget et ce à l’encontre de votre objectif.
Cependant, pendant des mois, la tendance pourrait montrer que vous allez
atteindre votre budget à la fin du projet. Dans ce cas la, aucune action
corrective ne sera nécessaire.
7 Chef du projet Analyser les métriques pendant le projet

Évaluer les métriques que vous collectez mensuellement pour vous assurer
qu’ils continuent à refléter précisément les processus du projet et qu’ils
sont entrain d’influer le type de comportement voulu. Si ce n’est pas le
cas, effectuez les modifications.
Fin des processus du projet (9.1.3.1. P8)
8 Chef du projet Établissez des rapports des résultats finaux et des

recommandations pour le succès de tout le projet
Quand le projet est achevé, l’équipe devrait établir un rapport sur les
394
métriques du processus final pour s’assurer que les buts de l’amélioration
ont été achevés. Il est probable que les résultats provenant des métriques
de l’amélioration du processus va être un aspect du tableau de bord.
9 Chef du projet Envoyez les résultats au bureau du management de projet (ou à

une autre organisation centralisée de reporting ou d’amélioration
de processus)
Les demandes commerciales sont de plus en plus difficiles. Les
Organisations doivent être capables de réaliser plus avec moins de
ressources. Le niveau de performance qui était suffisamment bien cette
année ne sera plus à la hauteur des attentes de plus haut niveau de l’année
suivante. Le Bureau de projets ainsi que toute l’équipe du management doit
toujours être à la recherche de méthodes pour améliorer leur processus de
livraison de projet et de tout le niveau du service.
L’équipe du projet devrait rendre compte des indicateurs finaux de
performance au Bureau de projets afin que ce dernier puisse effectuer le
suivi des métriques similaires à travers l’organisation. Le bureau de projets
devrait utiliser ces informations tout en tenant compte qu’il s'agit de donnée
de valeur au sein d’une initiative d’amélioration de processus dans toute
l’organisation. (Si votre organisation ne dispose pas d’un Bureau de projets,
vous devriez envoyer les informations à n’importe quelle autre organisation
responsable de l’amélioration du processus en cours.)
Votre organisation devrait mettre en place un programme pour encourager
les idées relatives à l’amélioration de processus. Le programme devrait
inclure la communication de l’importance de l’amélioration de processus,
quelques mécanismes pour réunir les idées, et des processus de suivi pour
assurer que chaque idée soit bien discutée. La personne qui fournit la
proposition devrait recevoir un feedback, sans se soucier du fait que la
proposition ait été implémentée ou non. Si la proposition n’a pas été
implémentée, la personne à qui on a envoyé le feedback doit aussi fournir
un feedback dans lequel elle explique les raisons pour lesquelles la
proposition n’a pas été implémentée.
395
9.1.3.1.1 Exemples de métriques
La liste suivante donne une idée sur les types de métriques qui peuvent faire l’objet d’un rapport. Cette
liste n'est en aucune façon exhaustive, mais peut apporter des idées supplémentaires pour votre projet.
Catégorie Métriques
Coût  Coût effectif par rapport au budget (variance) pour le projet, pour
une phase, pour une activité, etc.
 Coût total du support pour x mois après l’accomplissement de la
solution
 Coûts de travail et coûts de non travail totaux (par rapport au
budget)
 Coût total des employés, par rapport au contrat, coût des consultants
(par rapport au budget)
 Le coût associé à la construction de composants pour la réutilisation
 Coût total par transaction
 Idées pour des réductions des coûts: mises en application et
économies réalisées
Effort de travail  Effort de travail réel par rapport au budget (variation)

 Temps de travail du chef de projet par rapport à l'effort de travail
global
Durée  Durée réelle par rapport au budget (variation)
Productivité  Effort de travail par unité de travail / poste de travail

(Difficile à mesurer  Lots de travaux / par poste, produits par heure de travail
exactement, à moins
que des postes de  Réduction de l’effort de travail grâce à l’utilisation des processus de
travail soient comptés) projet standard
 Effort de travail économisé grâce à la réutilisation des livrables,
modèles, composants précédents, etc.
 Le nombre d'idées d'amélioration de processus mises en application
 Nombre d’heures / Euros économisées grâce à l’amélioration de
processus
Qualité des  Pourcentage des livrables soumis à des examens de qualité

livrables  Pourcentage des revues de livrables ayant pour résultat l'acceptation
dès la première fois
 Nombre de défauts découverts après l’acceptation initiale
 Pourcentage des livrables qui sont conformes à 100% aux normes de
l’entreprise
 Pourcentage des livrables qui sont conformes aux normes
d’architecture de l’entreprise
 Nombre de demandes de changement émanant du client pour
modifier le contenu (plusieurs demandes de modification peuvent
impliquer l’utilisation d’un mauvais processus de collecte des
exigences)
 Nombre d'heures de travail de reprise sur des livrables préalablement
réalisés
396
 Nombre de meilleures pratiques identifiées et appliquées au projet
 Nombre de risques qui ont été atténués avec succès
Satisfaction du Satisfaction globale du client par rapport aux livrables en termes de:
client par rapport (sondage):
aux livrables  Fiabilité
 Défauts
 Exploitation
 Temps de réponse
 Facilité d'utilisation
 Disponibilité
 Flexibilité
 Intuitivité
 Sécurité
 Réponse aux attentes du client
 Messages faciles à comprendre
 Documentation utilisateur
 Temps de réponse de l'application (calculé par le système)
 Nombre de spécifications approuvées satisfaites par le projet
Satisfaction du Satisfaction globale du client par rapport à l’équipe de projet en termes de:
client par rapport à (sondage)
l’équipe de projet  Réactivité
 Compétence
 Facilité de contact
 Courtoisie
 Communication
 Crédibilité
 Connaissance des affaires
 Fiabilité / Suivi
 Professionnalisme
 Formation
 Satisfaction globale du client
 Délais requis pour répondre aux questions et aux problèmes du client
 Temps moyen requis pour résoudre des problèmes majeurs
397
9.1.3.2 La révision des livrables
La révision des livrables, ou leur examen pas à pas, peut être appliquée à de nombreux livrables
produits par le projet. Par exemple, l'échéancier du projet peut faire l’objet d’une révision d’un produit
livrable. Les exigences commerciales du projet peuvent être passées en revue. Vous pouvez examiner
pas à pas un code de programme, des campagnes de marketing et des exposés de recherche. Les
livrables qui exigent des connaissances et une créativité humaines peuvent être passés en revue.
Cependant, vous ne pouvez pas examiner pas à pas des livrables concrets tels qu'un nouvel ordinateur,
un composant d’avion, une automobile ou un vêtement. Il y a d'autres techniques, comme les
inspections, pour valider ces types de livrables. Le processus suivant peut être employé pour planifier et
conduire une révision formelle des livrables.
Rôle Revue formelle des Livrables
1 Le chef de Déterminer les participants appropriés à la révision

projet Essayez d’inclure seulement les personnes qui peuvent contribuer de manière
significative à la révision. Plus il y a de personnes concernées, plus il est
probable que la revue dure longtemps. Les révisions de livrables sont des
activités de contrôle qualité, puisqu’elles s’intéressent au livrable lui-même.
Par conséquent, les participants à la réunion doivent disposer d’une expertise
dans le domaine du livrable qui fait l’objet de la revue. Les participants sont
généralement des pairs de la personne qui a réalisé le livrable.
Plusieurs revues pourraient être nécessaires pour s’assurer que les livrables
de grande envergure ont été réalisés correctement.
2 Équipe de (Facultatif) Définir les critères d’achèvement et de justesse

revue L’équipe de révision peut définir des critères intermédiaires d’acceptation
pour examiner le livrable. Ces critères intermédiaires peuvent être utiles à
l’équipe de révision pour savoir à l’avance que les critères d’acceptation ne
seront pas satisfaits. L’équipe sera ainsi préparée pour de nombreuses
révisions avant que le livrable ne soit achevé.
3 Participants à Envoyer le matériel de révision avant la réunion

la revue Il y a des situations où ce n'est pas faisable. Cependant, lorsque cela est
possible, la révision formelle sera effectuée plus rapidement si l'équipe a eu,
à l’avance, la possibilité de passer en revue le produit livrable.
4 Participants, Diriger la réunion

équipe de La ou les personne(s) qui ont créé les livrables progressent dans le travail
revue suivant un ordre logique et répondent aux questions au fur et à mesure
qu’elles sont posées par les participants. Il faudrait garder les principes
suivants à l'esprit:
 Faites en sorte que la revue dure une heure ou même moins. Si le
produit est trop important pour qu’il soit passé en revue en une
heure, envisagez la possibilité de le décomposer en de plus petits lots
qui peuvent être revus en une heure.
 Pendant la revue, les participants devront soulever des questions,
exprimer des préoccupations et suggérer des solutions. Si certains
points deviennent trop compliqués, ils ne devront pas être résolus au
cours de l’examen au fur et à mesure. Ils devront être différés. De
même, aucun consensus n’a besoin d’être atteint. Un consensus ou
une confirmation pourrait se faire si nécessaire en dehors de la
réunion.
 Dans de nombreux cas, l'équipe de revue trouvera des erreurs dans
398
les livrables. Dans d'autres, elle donnera des avis ou fera des
suggestions qui peuvent être ou non observées. S’il y a rétroaction,
c’est qu’il y a un membre de l’équipe qui dévoile une erreur qui devra
être corrigée ou qui fait une suggestion qui pourrait être observée.
 Il ne faudrait pas inclure de commentaires en rapport avec le
personnel. La revue concerne le produit, pas la personne qui a
développé le produit. Par exemple, au lieu de dire que l’auteur a
commis une erreur, la personne qui effectue le passage en revue
peut souligner cette erreur dans le produit livrable. Au lieu de dire
que l’auteur manque de rigueur, le participant au passage en revue
peut simplement indiquer les secteurs du livrable qui lui semblent
manquer de soin.
 S'il y a des problèmes majeurs avec l’auteur ou le processus de
réalisation du livrable, ils devront faire l’objet d'une réunion séparée.
 Gardez une liste des éléments d'action examinés pendant la revue.
5 Équipe de Vérifiez aussi les processus

revue L’examen des livrables doit se concentrer sur l’acceptation du livrable.
Cependant, les examinateurs doivent aussi valider le fait que les processus
standard ont été utilisés pour réaliser le livrable. Il peut s’agir de confirmer
que les modèles appropriés ont été utilisés, que les approbations adéquates
ont été obtenues ou de s’assurer que le livrable a été réalisé conformément à
la politique de l’entreprise. Ce type de questions est lié à l’assurance qualité
mais ce sont des questions pertinentes, à poser durant l’examen d’un
livrable. La réunion devra ensuite confirmer que le livrable est acceptable et
que le processus utilisé pour fabriquer le livrable l’est aussi.
6 Équipe de Concluez la revue.

revue Déterminez où en est le produit en employant une des évaluations suivantes:
 Accepté. Le produit répond à tous les critères d'accomplissement
déterminés pendant la revue et n'a pas besoin de davantage de
révision. Quelques petites modifications peuvent être demandées,
mais le produit livrable ne devra pas être passé en revue une
nouvelle fois.
 Travail supplémentaire nécessaire. Le produit nécessite un
travail de reprise pour satisfaire les critères d'accomplissement requis
par la revue. Les éléments d’actions issus de la revue doivent être
documentés et conservés pour la prochaine réunion de suivi. Quand
un produit échoue à une révision, il devra généralement être passé
en revue une nouvelle fois avec les mêmes critères
d'accomplissement, une fois que les modifications nécessaires auront
été apportées.
7 Participants Communiquez les résultats de la revue

Vérifiez que toutes les parties prenantes ont reçu les résultats de la revue.
399
9.1.3.3 Résoudre les problèmes de la qualité
Les problèmes de qualité n’atteignent pas le niveau d’un problème majeur. Ce sont néanmoins des
problèmes, et ils peuvent être résolus en utilisant certaines des mêmes techniques de résolution des
problèmes décrites à l’étape 4.0 Gérer les problèmes majeurs. Faire des hypothèses sur la cause du
problème donne rarement des résultats. Une approche structurée fonctionne bien mieux. Vous voulez
non seulement résoudre ce problème particulier, mais également le comprendre suffisamment pour
pouvoir identifier sa cause profonde et empêcher qu’il se pose à nouveau.
Employez le processus général suivant pour identifier et résoudre les problèmes de qualité.
Rôle Traiter les problèmes de qualité
1 Chef de projet Identifier le problème ou le symptôme.

Vous ne devriez pas supposer que chacun connaît déjà le problème. Prenez le
temps de documenter le problème avec des termes clairs que chacun peut
comprendre. Assurez-vous également que vous expliquez bien l'impact du
problème de qualité sur le projet.
2 Chef de projet Identifier la cause profonde.

C'est l’étape la plus importante dans la mesure où vous ne voulez pas perdre
votre temps à résoudre un symptôme de qualité. Au lieu de cela, vous devriez
être très clair au sujet de la cause profonde, et expliquer comment elle a
débouché sur ce problème. Si vous ne pouvez pas trouver la cause profonde du
problème perçu, c’est que vous n’avez pas poussé suffisamment loin votre
investigation. Il y a un certain nombre de techniques identifiées à l’étape 4.0
Gérer les problèmes majeurs, qui décrivent comment concentrer l’attention sur
la cause profonde.
3 Chef de projet Déterminer les alternatives et leurs impacts.

Le chef de projet peut charger une ou plusieurs personnes de trouver des
alternatives. Pour chaque alternative, ces personnes doivent également prévoir
son impact sur le projet.
4 Chef de projet, Choisir la meilleure alternative.

membres de L’équipe du projet, le commanditaire et le client peuvent s’impliquer ensemble
l’équipe afin de déterminer la meilleure alternative. Cependant, l’équipe de projet devrait
être en mesure de résoudre le problème par elle-même puisqu'il ne s’agit pas
d’un problème formel majeur. En fait, il peut s’agir d’un problème au niveau de
produits de travail intérimaires, qui tombent tout-à-fait dans la sphère de
contrôle de l’équipe de projet.
5 Chef de projet Résoudre le problème

Un mini plan est mis en place pour résoudre le problème de qualité et mettre en
application l'alternative choisie. Ces activités doivent être intégrées dans
l'échéancier du projet de manière à s’assurer qu'elles seront bien effectuées.
6 Chef de projet Valider que le problème a été résolu

Le processus doit être revalidé afin de s’assurer que la qualité s'est améliorée
comme prévu. Si la qualité s’est améliorée ou qu’elle est en voie de l’être, vous
aurez simplement à la surveiller pour le reste du projet. Si au contraire la
qualité ne s'améliore pas comme prévu, des actions correctives supplémentaires
pourraient être requises.
400
9.2 Gérer la qualité / Techniques
Comprendre les caractéristiques de la qualité pour votre projet (9.2. P1)
Il est difficile de définir la qualité d’un produit ou d’un service dans le cadre d’une approche générale,
parce que le terme « qualité »est vague et que sa signification peut varier d’une personne à une autre.
Vous devez prendre le temps de définir le niveau le plus bas des caractéristiques de qualité pour
chaque service ou livrable spécifique. Si vous voulez vous assurer qu'un service ou un produit respecte
les attentes du client en termes de qualité, vous devez comprendre les caractéristiques de la qualité
sous-jacentes.
Le tableau suivant montre des exemples de caractéristiques spécifiques de qualité.
Qualité du produit Qualité de service

Le produit est: Les personnes sont:
Fiable Responsables
Facile à utiliser Compétentes
Facile à entretenir, une fois réalisé Accessibles
Disponible, en cas de besoin Courtoises
Flexible pour des besoins futurs Sont de bons communicateurs
Présentant un rapport qualité/prix satisfaisant Crédibles
Intuitif / Facile à comprendre À l’écoute du client
Sécurisé Fiables
Bien documenté
Présente un minimum de défauts (il n’a pas besoin d’être parfait)
Réactif (son temps de réponse est bon)
Adapté aux besoins du client
Utiliser les activités de contrôle qualité pour valider la qualité de vos livrables (9.2. P2)
Les activités de contrôle qualité se concentrent sur la qualité globale du produit livrable qui a été
réalisé. Selon votre type de projet, voici quelques exemples d’activités de contrôle qualité:
 Passage en revue du produit livrable / Revues par des pairs/ Revues techniques / Revues des
codes. Voir 9.1.3.2 La révision des livrables, pour plus de plus amples informations.
 Listes de contrôle pour s’assurer que les livrables sont cohérents et contiennent toutes les
informations nécessaires. Pour trouver un exemple, voir 9.2.3 Questions de contrôle qualité.
 Réutilisation de logiciels éprouvés.
 Standards pour s’assurer de la cohérence.
 Inspection par des tiers de la fourniture et des livrables
 Mesurer le produit et le comparer aux cibles
 Méthodes structurées pour s’assurer que des processus standard éprouvés sont utilisés.
 Test approfondi (unité, système, intégration, acceptation). La phase de test est probablement
l’aspect du contrôle qualité le plus utilisé aujourd’hui. Même s’il y a plusieurs techniques pour
intégrer la qualité très en avance, la confiance que vous avez dans la qualité globale provient
probablement de vos tests. Les tests sont votre dernière chance de garantir que la solution que
401
vous livrez répond aux attentes du client. De manière générale, les tests sont le moyen de
s’assurer que la solution satisfait aux exigences et est exempte de défauts. Cependant, à un
niveau moins général, les tests permettent également de :
o Prouver une fiabilité globale.
o S’assurer que la solution fonctionnera dans le même environnement que celui qu’elle
rencontrera en phase de production.
o S’assurer que la solution sera pérenne.
o S’assurer que les résultats produits sont cohérents et fiables.
o S’assurer que les résultats ne se dégraderont pas sous l’effet du temps.
Utiliser les activités d’assurance qualité pour valider les processus qui ont permis de
construire les livrables (9.2. P3)
L’assurance qualité est concentrée sur les processus que vous utilisez pour gérer le projet et créer les
livrables. Un certain nombre d’activités relatives à l’AQ devraient être prise en compte.
 Audit de la qualité. Comme l’assurance qualité est liée aux processus utilisés pour créer les
livrables, la technique la plus efficace est une revue formelle d’assurance qualité, ou audit. Lors
d’une revue de la qualité une tierce partie pose des questions sur les processus utilisés pour
créer les livrables, pour s’assurer qu’ils sont adéquats. Le livrable lui-même ne doit pas du tout
être examiné lors de la revue d’assurance qualité
L’audit de la qualité doit également valider que les processus relatifs à la qualité du projet sont
réellement bien suivis. Par exemple, si l’équipe a un processus formel pour gérer les problèmes majeurs
et les modifications du contenu, un audit devra passer en revue les problèmes majeurs du projet et les
modifications du contenu, pour voir si les processus ont, en effet, bien été suivis. Cela inclura une revue
du journal des problèmes majeurs, du journal des modifications du contenu, des activités de
l'échéancier, des rapports d'avancement, etc. Tous ces examens devraient donner une indication sur la
mise en application efficace de la part de l’équipe des processus de gestion des problèmes majeurs et
des modifications du contenu.
 Planification de la qualité. Le fait de créer un plan de la qualité permet d’établir de bons

processus de qualité pour votre projet.
 Formation relative à la qualité. La formation est une manière pour éviter les erreurs.
 Des listes de contrôle d’AQ. Parmi les activités d’assurance qualité, il y a une liste de
contrôle qui assure qu’un processus standard de produit livrable a été suivi. Par exemple,
cette check-list peut inclure des dates d’achèvement du produit livrable, les dates de passage
en revue, de confirmation que chaque élément a été réalisé, les dates d’approbation des
clients, etc. Comme ce type de check-list se concentre sur un processus et pas sur le produit
livrable, il s’agit bien d’un exemple d’assurance qualité. Rendez-vous à la section 9.2.4
Questions d’assurance qualité pour y trouver plus d’informations et un exemple de check-list
d’assurance qualité.
Avoir confiance dans les coûts et avantages de la qualité (9.2. P4)
Un des principes de base du management de la qualité est que les avantages globaux d'une solution de
qualité compenseront largement l’accroissement des coûts. Pour une explication sur les coûts et les
avantages de la qualité et les coûts d’une qualité inférieure, voyez le paragraphe 9.2.2 Le coût et les
avantages de la qualité.
Ne pas « plonger un produit dans un bain d’or » (Ne pas fournir plus de fonctionnalités que
le client n’en a demandée) (9.2. P5)
402
Vous devez toujours essayer de définir soigneusement les attentes du client puis répondre à ces
attentes. Cependant, si vous n'êtes pas sûr d’être à la hauteur, vous avez certainement entendu dire
qu’il est préférable de promettre moins, mais de livrer plus. Cela peut réellement être une bonne
stratégie si cela se rapporte à votre capacité de livrer votre travail plus tôt que promis, ou pour un coût
moindre que prévu dans votre estimation. Cependant, ce n'est pas la meilleure méthode à suivre que
de livrer plus d’exigences ou un niveau de qualité plus élevé que ce que le client a demandé.
L’expression « dorer » se rapporte au fait de fournir plus de qualité que ce que le client n’en a
demandé. Même si cela semble être un paradoxe, ce n’est réellement pas la meilleure idée et cela pour
deux raisons : D'abord, la préoccupation première du projet consiste à s'assurer que vous livrez ce que
désire le client, et que vous livrez à temps et dans les limites du budget. En ajoutant du travail
supplémentaire, vous augmentez le risque que le projet ne respecte pas les délais fixés ou le budget. Si
vous finissez par dépasser les délais imposés, vous ne rencontrerez pas d’approbation au cas où vous
justifiez le dépassement de la date convenue par le travail supplémentaire occasionné.
En second lieu, si vous « plongez un produit dans un bain d’or » vous prenez la responsabilité de
prendre une décision économique sur ce qui compte le plus pour le client. Il peut y avoir de bonnes
raisons pour lesquelles le niveau de qualité a été défini par le client. Il sera plus intéressant de trouver
des solutions entraînant des coûts moindres. L’important, c’est qu’il s’agit d’une décision qu’un chef de
projet ne devrait pas prendre à la place du client.
Promettre moins et livrer plus devrait seulement s’appliquer au fait de livrer plus tôt ou pour moins cher
que ce qui a été convenu. Cela ne devrait pas inclure la livraison d’exigences supplémentaires par
rapport à celles qui étaient demandées. Le client pourra, en fait, demander d’inclure plus d’exigences
dans la solution. Si le client en demande plus, ces nouvelles exigences devraient être traitées à l’aide de
la gestion des modifications du contenu. Cependant, le client peut avoir d’autres projets plus importants
pour les économies réalisées. Si vous pouvez achever le projet plus tôt ou pour moins cher que prévu
dans le budget, laissez le client prendre la décision concernant la marche à suivre par rapport à cette
circonstance favorable.
Assurez-vous que le management de la qualité s’intéresse au processus, pas aux personnes

(9.2. P6)
Le but du processus de management de la qualité est d’établir de bons processus, de telle sorte que
l'équipe entière puisse produire des livrables qui répondent aux attentes du client. Par conséquent, si
un produit livrable particulier pose un problème de qualité, le chef de projet et son équipe de projet
devront se concentrer sur l’amélioration des procédés de travail du projet, et non pas essayer de
chercher la personne à blâmer.
La plupart des problèmes de qualité sont le résultat d’un processus de travail faible ou inadéquat, et
non pas d'actes malveillants d'une personne particulière. En fait, on considère qu’au moins 80% des
problèmes de qualité peuvent être résolus en modifiant et en renforçant les processus commerciaux.
Moins de 20% des problèmes sont provoqués par les travailleurs. De plus, les processus que votre
organisation utilise sont largement déterminés par le management. De ce fait, lorsque des travailleurs
ou des membres de l’équipe rencontrent des problèmes de qualité, il est important que les managers
identifient les processus faibles ou inachevés afin des rectifier. Cette responsabilité revient au
management, pas au personnel. Cela ne signifie pas que tout le monde ne peut pas être impliqué. (Voir
la technique ci-dessous). Cependant, la mise en œuvre et l’application de processus commerciaux est
surtout une responsabilité qui incombe à la direction.
Pour que cette idée soit réalisable, le chef de projet est responsable des processus utilisés pour gérer et
exécuter le projet. Si vous découvrez que vous avez des problèmes relatifs à la qualité dans votre
projet, vous devriez chercher des méthodes pour renforcer les processus de travail de manière à ce que
les problèmes de la qualité soient évités (AQ) ou au moins de manière à ce qu’ils soient découverts le
plutôt possible (CQ).
Insistez sur le fait que la qualité est la responsabilité de chacun (9.2. P7)
Le chef de projet a la responsabilité globale du processus de gestion de la qualité. Quelques projets
403
peuvent également comporter des rôles spécifiques pour une personne responsable de l’assurance
qualité, ou pour des experts dans le domaine des tests. Cependant, même si des personnes spécifiques
exercent des responsabilités au niveau de la qualité, cette dernière n'est pas le fait d’une ou deux
personnes. C’est celle de chacun. Toute l'équipe, y compris le client, a comme souci le fait que les
livrables produits soient de haute qualité. Il incombe aussi à chacun de proposer des idées susceptibles
d’améliorer des processus de création des livrables.
Soulignez le fait que la qualité est une façon de penser, pas un événement (9.2. P8)
Dans certains projets, la qualité est considérée comme une étape particulière dans le processus, ou
peut-être une série d'activités à la fin du processus. Cependant, pour être efficace, l'équipe doit
entretenir une mentalité continuellement axée sur la qualité. Les membres de l’équipe doivent
s’approprier les livrables qu'ils produisent, et s'assurer qu’ils sont réalisés selon des critères de qualité
dès l’instant où ils ont été crées. En outre, ils ne doivent pas se mettre sur la défensive quand d'autres
personnes passent leur travail en revue. Les membres de l’équipe doivent se rendre compte qu'un
processus de la qualité permet à l’équipe entière du projet de produire des livrables de qualité, avec
une quantité minimale d'erreurs et de travail de reprise.
La qualité d’un projet commence avec la planification, mais la réalisation de la qualité doit être menée
tout au long du projet. Une approche à multiples facettes de la qualité inclura les éléments suivants :
 La réalisation d’un plan de management de la qualité au début du projet.
 La mise en place de la qualité au sein de l’équipe (formation, communication,…).
 La mise en place de la qualité au sein des processus de travail (analyse, conception...).
 L’intégration de la qualité dans les livrables de management du projet.
 L’intégration de la qualité dans les livrables du projet.
Cette approche continue et à facettes multiples est la meilleure manière pour créer des livrables de
qualité sur des bases solides.
Identifier et réduire le travail de reprise au minimum (9.2. P9)
À vrai dire, si vous disposez d’un processus rigoureux de la qualité, il n’y aura aucune raison d’avoir des
discussions au sujet d’un travail de reprise. En fait, un tel travail résulte de l’absence d’un processus de
la qualité suffisamment rigoureux dès le départ. Mais, soyons plus concrets. Aucun projet n’a le moyen
d’employer suffisamment de temps et de fournir suffisamment d’effort pour garantir que chaque produit
livrable soit parfait dès le début. Même une entreprise opérant au niveau " Sigma Six " a toujours une
petite probabilité d'erreur.
Ainsi, supposons que vous ayez mis en place un plan de management de la qualité sans défauts. Vous
aurez tout de même affaire à du travail de reprise. Avec certaines méthodologies de projet qui se
concentrent sur la création de livrables indépendamment de la qualité initiale, un travail de reprise peut
faire partie de la nature du projet. Il y a certains éléments à garder à l'esprit au sujet du travail de
reprise :
 Ce travail n'est pas de la même nature que votre processus normal de collecte de rétroaction
sur les livrables. Si vous créez un document, par exemple, et que vous le faites circuler pour
recueillir une rétroaction, les changements qui en découlent ne sont pas considérés comme un
travail de reprise. Ces changements apportés au document constituent le meilleur moyen de
vous assurer que vous avez un bon document au départ. Cependant, si vous publiez votre
document complété et que vous trouvez ensuite des erreurs dans le contenu, les mises à jour
consécutives seront considérées comme du travail de reprise.
 Même lorsque vous acceptez le travail de reprise comme partie intégrante de la nature du
projet, cela ne signifie pas que le chef et l’équipe de projet ne doivent pas tout faire pour
l'éliminer. Votre but doit toujours consister à d'éliminer les défauts et le travail de reprise, en
améliorant continuellement vos processus.
404
 S'il est nécessaire d’effectuer un travail de reprise, faites en sorte de le découvrir aussi tôt que
possible dans le cycle de vie du projet. Rappelez-vous que les erreurs au stade de l'analyse se
propagent dans la conception puis dans la construction. Si vous ne trouvez pas les erreurs
avant la phase des tests, il y aura un travail de reprise requis durant tout le cycle de vie
(phases d’analyse, de conception et de construction). D'autre part, il y a moins de chances de
propagation en aval des erreurs au sujet des exigences si vous prenez le temps de rechercher
les erreurs lors de la phase d’analyse, ainsi que lors de chaque phase suivante du projet.
 Vous pouvez repérer le travail de reprise pour calculer le temps que vous passez à travailler
deux fois sur les mêmes problèmes. Par exemple, dans le processus de tests, vous pouvez
constater le nombre d'erreurs qui sont corrigées. Une fois ces erreurs corrigées, vous
constaterez que les changements n’ont pas eu pour effet de résoudre le problème de manière
adéquate, ce qui entraînera un travail de reprise. Vous pouvez également constater que la
réparation d’une erreur va en révéler une autre. Cette deuxième erreur, fortuite, provoquera
également un travail de reprise. Vous pouvez compter le nombre d'erreurs corrigées, aussi bien
que le nombre total d'erreurs qui exigent un travail de reprise. Généralement, si l'équipe se
fatigue et travaille de longues heures, le besoin de travail de reprise se fera encore plus sentir.
Vous tenterez donc, dans la mesure du possible, de réduire à zéro les erreurs qui entraînent du
travail de reprise.
 Le travail de reprise est différent d’une modification du contenu. Il est dû à des problèmes
inhérents au processus de gestion de la qualité. Ce travail est nécessaire car il s’agit de
ramener un produit livrable au niveau de qualité qu’il aurait dû avoir dès le départ. Une
modification du contenu se rapporte à un changement d’une partie de la solution en raison
d'une nouvelle exigence. L'effort de travail et le coût lié au travail de reprise doivent être
supportés par le projet. Ce même travail et ce même coût sont liés aux modifications du
contenu .Ils devront être acceptés et payés parle client.
Utilisez des techniques solides de résolution des problèmes de qualité (9.2. P10)
Si vous collectez des métriques relatives à vos processus et vos livrables, il est possible que vous
constatiez que vous n'allez pas respecter vos engagements de qualité. Il y a un certain nombre de
techniques qui peuvent être appliquées pour déterminer les causes des problèmes de qualité et,
lesquelles parmi ces causes doivent être traitées en priorité. Ces techniques sont les mêmes que celles
qui peuvent être appliquées dans le cadre de n'importe quel exercice de résolution de problèmes. Trois
techniques courantes sont décrites en tant qu'éléments de l'étape : Gérer les problèmes majeurs/
Techniques du processus TenStep. Il s’agit de l’analyse des causes et des effets, de l’analyse des
causes profondes et de l’analyse de Pareto. Vous trouverez plus de détails sur la résolution des
problèmes de qualité dans 9.1.3.3 Résoudre les problèmes de qualité.
Utilisez des techniques statistiques de contrôle de processus pour vous assurer que le
processus reste sous contrôle (9.2. P11)
Lorsque vous considérez les causes des défauts du produit (erreurs), vous remarquez qu’elles se
divisent en deux catégories générales. Dr. Edward Deming a donné à ces erreurs le nom de « cause
spéciale » et de « cause commune ».
Les erreurs ayant une cause spéciale sont celles que les utilisateurs locaux peuvent trouver et réparer.
Elles incluent les mauvais fonctionnements, le manque de formation, la mauvaise utilisation de
l’équipement, le vandalisme, etc.
Les « causes communes » peuvent entraîner de grandes variations de qualité et incluent des problèmes
systématiques dont les utilisateurs locaux n’ont peut-être pas conscience. Par exemple, les erreurs
ayant des causes ordinaires peuvent être des imperfections mineures de l’équipement, une mauvaise
conception du produit, des processus qui ne fonctionnent pas de manière optimale, etc. Ce sont des
problèmes « ordinaires » mais très difficiles à détecter pour les utilisateurs locaux.
Des techniques de contrôle statistique du processus (CSP) peuvent être utilisées pour surveiller, gérer,
analyser et améliorer la performance d’un processus, en éliminant les causes spéciales de variation (les
405
problèmes de qualité les plus facilement détectables). Pour plus d’informations sur les techniques de
contrôle statistique du processus (CSP) et l’utilisation des grilles de contrôle, rendez–vous à la section
9.2.5 Contrôle statistique de processus par des opérations statistiques.
406
9.2.1 Gérer les métriques / Techniques
Assurez-vous que vos mesures apportent une valeur ajoutée (9.2.1. P1)
Identifier, recueillir et consolider l’équilibre des métriques sont des voies qui permettent d’apporter de
la valeur ajoutée à un projet. La valeur peut être mesurée dans un certain nombre de domaines tels
que :
 L’amélioration des performances du projet au niveau des réalisations globales et du processus

de livraison
 L’amélioration des estimations pour de futurs projets
 La validation des objectifs de durée, de coût, d'effort de travail et de qualité pour le projet
 L’identification et la diffusion des meilleures pratiques
 L’amélioration de la satisfaction du client
En général, les métriques fournissent une base plus factuelle et plus quantitative pour comprendre ce
que vous êtes en train de faire et quelles améliorations peuvent être apportées. Sans un minimum
d’informations de base fournies par des métriques, toutes les discussions sur le rendement et
l'amélioration sont basées sur des évidences anecdotiques, des illusions et des conjectures. Si vous
voulez que les réussites ou les échecs de votre projet soient basés sur des informations concrètes, vous
devez déterminer au préalable les critères de réussite et la manière de les mesurer. Rassemblez ensuite
les métriques même si elles sont imparfaites et imprécises. Elles fournissent toujours une base plus
solide que des souvenirs, des illusions et des conjectures.
Employez les métriques que vous collectez (9.2.1. P2)
Ne pas collecter des métriques uniquement pour le plaisir de les collecter. Cela n'est pas logique dans
une perspective de management de projet et n’aboutirait qu’à une perte de temps. Si certains
métriques sont exigées par votre entreprise, alors collectez-les. En outre, vous devriez rassembler
n'importe quels autres métriques pertinentes dans le cadre spécifique de votre projet. Cependant, si
vous n'avez aucun but précis derrière la collecte des métriques, ou si votre projet n'est pas assez
important pour justifier l’utilisation de l’information, la collecte de ces indicateurs spécifiques, faits sur
mesure, ne présente aucun intérêt pour votre projet.
Comparez le coût de la collecte d’une métrique par rapport à ses avantages (9.2.1. P3)
De même qu’un certain coût est lié à la plupart des activités de management de projet, il y a un coût lié
à la collecte et à la gestion des métriques. Dans le cas de la gestion du contenu ou du management de
problèmes majeurs, c’est un coût dans lequel les chefs de projets doivent investir s’ils veulent connaître
la réussite, car il s’agit de processus clés de management de projets. La gestion des métriques,
cependant, est plutôt laissée à la discrétion du chef de projet et relève de la culture globale de
l'entreprise. Dans de nombreux cas, le coût pour rassembler et utiliser certains types de métriques est
prohibitif. Ces indicateurs ne devraient pas être recherchés. D’autres indicateurs sont intéressants mais
ne fournissent pas le type d'information susceptible de permettre une plus grande amélioration. Le coût
de la collecte de chaque métrique doit être comparé aux avantages potentiels qui en seront tirés.
Commencez par collecter les métriques qui sont exigées par l'entreprise. Ajoutez ensuite celles
présentant le coût le plus bas et dont la collecte exige un effort de travail minime pouvant ainsi fournir
le plus grand avantage potentiel.
Liez les performances de l’équipe et les performances individuelles (9.2.1. P4)
Le vieil adage qui dit que « ce qui est mesuré est accompli » se vérifie sur les projets. Si vous utilisez
des informations métriques en vous basant sur des métriques pour prendre des décisions sur les revues
407
de performance ou sur la compensation, les gens sont généralement prêts à tout faire pour atteindre
les cibles. Par exemple, si la communication est importante pour votre projet, établissez quelques
métriques autour de la communication. Consultez les clients et les parties prenantes à un rythme
trimestriel pour savoir ce qu’ils pensent de votre communication dans le cadre du projet.
Vous n’obtiendrez toujours pas les comportements souhaités si les résultats des métriques n'ont pas un
impact personnel correspondant aux membres de l’équipe. La solution consiste à rassembler les
métriques qui donnent une indication quantifiable sur la performance globale de l'équipe et permettent
de s'assurer qu'il y a une connexion entre la performance de l’équipe et la performance individuelle.
Un exemple où celles-ci ne sont pas liées se retrouve dans le cas classique du projet qui est considéré
comme un échec alors que tous les membres de l’équipe ont tous été bien évalués lors de l’examen de
leurs performances. Cela ne semble pas avoir un sens. Assurez-vous que le succès de l’équipe est
reflété convenablement par les évaluations des performances individuelles. Si l'équipe a réussi, les
membres de l’équipe devraient être récompensés. Si ce n’est pas le cas, les évaluations des membres
de l’équipe devraient être infléchies en conséquence. Rappelez-vous que l'équipe de projet n'a pas
besoin d'un 100% dans la revue du processus. Il y aura d’autres facteurs qui doivent être pris en
compte pour l’ensemble de la performance. Cependant, ce n’est pas vrai non plus que la performance
de l’équipe du projet soit de zéro pour cent. Il faut qu’il y ait une certaine liaison entre le succès d’un
projet et celui des personnes travaillant sur ce dernier.
Prenez garde aux conséquences involontaires quand vous définissez vos métriques (9.2.1.
P5)
La collecte des métriques attire certains comportements, si les résultats des indicateurs sont utilisés
comme données d’entrée pour la performance d’une personne. En fait, c’est exactement ce que vous
voudriez qu’il se passe, sinon vous n'auriez pas réuni les métriques pour commencer avec. Par
conséquent, il est très important que ces indicateurs induisent de bons comportements et non pas des
conduites indésirables.
Penchons-nous sur l’exemple suivant : Le degré de réussite d’une équipe était mesuré en fonction du
temps nécessaire pour répondre à des demandes clients. L’objectif était de répondre à toutes les
demandes des clients en cours dans un délai de deux jours ouvrables. Les membres de l’équipe ont
constaté qu’on attendait d’eux surtout une résolution rapide des problèmes, sous peine de se voir
imputer un échec. L’équipe du projet a également réalisé que si elle ne peut pas clôturer les tickets
aussi rapidement que possible, elle doit deviner la cause du problème et clôturer le ticket. Si la
résolution s'avérait erronée, le problème se présentait à nouveau et le ticket est alors clôturé aussi
rapidement que le précédent. Le résultat est un battage répétitif de tickets provoquant une plus grande
perte de temps qu’il n’était nécessaire. En d’autres termes, la cible a été atteinte en attirant un mauvais
comportement.
Dans cet exemple, l’un des problèmes était justement l’indicateur de performance. Cette équipe
semblait performante sur papier puisqu'elle a répondu aux tickets rapidement. Mais en réalité, elle avait
de faibles performances, occasionnant ainsi du travail supplémentaire et, par conséquent,
l’insatisfaction du client. L’idée était bonne, mais peut-être eut-il mieux valu avoir un meilleur indicateur
de performance qui n’aurait considéré le ticket comme clôturé qu’après l’approbation de la résolution
par le client.
Quand vous envisagez un indicateur de performance pour votre projet, pensez au fait qu’il pourrait
induire des conséquences fortuites. Assurez-vous que vous êtes en train de mettre la métrique en place
d'une manière qui conduit clairement aux comportements désirés.
Recueillez des métriques de base, si aucun objectif n'est fixé (9.2.1. P6)
La collecte des informations fournies par des métriques, en soi, ne donne qu’une valeur limitée au
projet. Une valeur ajoutée plus grande provient de la comparaison des métriques avec certains types de
normes ou d’objectifs. Pour beaucoup de métriques, il y a un objectif implicite, même si vous ne le
déclarez pas toujours ouvertement. Par exemple, la collecte des informations concernant l'effort de
travail, la durée et le coût réels est utilisée dans le but de comparer ces données à l’effort estimé, aux
408
délais et au budget afin de voir comment le projet se comporte.
Pour beaucoup de métriques, cependant, il n'y a pas nécessairement d’objectif implicite à atteindre. Par
exemple, si vous assurez un suivi de la satisfaction de votre client par rapport au projet, le client
pourrait évaluer votre équipe à partir d’une moyenne de 3,8 sur 5. Cependant, ce chiffre est-il bon ou
mauvais? Puisque vous n’avez rien avec quoi le comparer, c’est difficile à dire. Pour tirer plus de profit
des métriques, il faut utiliser la première mesure comme ligne de base, c'est-à-dire comme un reflet du
point où vous êtes aujourd'hui. Dans l'exemple des enquêtes, vous considérerez vos premiers résultats
comme une ligne de base, puis tâcherez d’améliorer vos chiffres de base. Par exemple, après la collecte
d'une ligne de base de 3,8 sur 5, vous pouvez choisir de réaliser 4,2 sur 5 avant la fin du projet. Une
autre option est de rechercher une amélioration de 10% par rapport à la ligne de base, une fois les
métriques collectées.
Gardez à l’esprit qu'il n’est pas facile de définir la ligne de base des métriques. Dans certains cas, vous
pourriez chercher à accumuler un certain nombre de métriques initiaux avant de fixer votre ligne de
base. Par exemple, vous pouvez suivre des défauts sur un système pendant trois mois, puis prendre le
chiffre moyen par mois comme ligne de base globale. C’est alors ce chiffre que vous allez essayer
d’améliorer à l’avenir.
Soyez créatif dans la recherche des moyens de mesurer la valeur marchande (9.2.1. P7)
Un des saints Graal des métriques est de pouvoir mesurer précisément la valeur marchande produite
par un projet. Par exemple, les ventes ont pu augmenter. Les niveaux de stocks peuvent avoir baissé
ou moins de gens sont nécessaires pour un processus. Cependant, dans de nombreux projets, la valeur
commerciale reste difficile ou impossible à mesurer exactement. Parmi les problèmes courants, on peut
constater que:
 Le projet produit des bénéfices non quantifiables, tels que l’amélioration du niveau de
satisfaction du client ou de la qualité du produit.
 Le projet concerne l'infrastructure qui est utilisée par de grands groupes de personnes. Par
exemple, quel sera l’accroissement de la productivité des gens si vous doublez la mémoire des
ordinateurs de bureau? Quelle est la valeur quantifiable provenant de l’installation d’un nouveau
système de téléphone interne? L’imprécision de ces questions rend difficile la mesure d’un
bénéfice commercial.
 Le projet a comme conséquence une augmentation de la quantité d'informations dont les gens
disposent. Il est difficile de savoir exactement si les informations favorisent une meilleure prise
de décisions.
 Les choses s'améliorent en raison des projets multiples sur une certaine période, mais il est
difficile de savoir exactement quelle valeur chaque projet a produite.
 Les résultats sont de faibles améliorations difficiles à quantifier de manière significative. Par
exemple, éliminer des étapes dans un processus. Ce processus prend moins de temps, mais le
temps gagné est consacré à une autre tâche.
La meilleure approche pour déterminer la valeur commerciale d’un projet est habituellement de
considérer une proposition de prix ou une étude de cas, qui ont été réalisées avant le début du projet.
Voyez comment les bénéfices ont été quantifiés dans ce document, pour savoir si vous pouvez
réellement mesurer des résultats similaires, une fois le projet terminé. Si vous identifiez certains
bénéfices tangibles, les métriques doivent montrer quelle valeur a été produite. Si vous trouvez des
bénéfices non quantifiables, il faudra probablement vous satisfaire d’une enquête anecdotique qui ne
fournit pas des indications évidentes sur la valeur produite.
Si le projet a pour commanditaire une entreprise cliente, celle-ci va prendre l’initiative de la collecte et
du suivi des métriques. Cependant, un suivi devra être assuré pour vérifier que les métriques sont
collectées. Les indicateurs spécifiques à rechercher se basent sur ceux qui ont justifié le démarrage du
projet. Heureusement, ce coût peut être comparé au coût commercial estimé. Cependant, comme les
bénéfices du projet ne commencent généralement à rentrer que lorsque ce dernier est achevé, ces
bénéfices ne peuvent être connus qu’après les faits. Dans de nombreuses circonstances, l’équipe du
409
projet se sera alors dispersée, si bien que l’aide à apporter à l’organisation cliente dans le suivi des
bénéfices ne peut généralement être assurée que par le service de soutien de l’entreprise.
Collectez des métriques subjectives avec des enquêtes sur la satisfaction du client (9.2.1. P8)
La collecte des métriques est importante parce qu'elle vous permet de voir quelles sont vos
performances par rapport aux attentes de vos clients. Dans un monde parfait, tous les métriques que
vous rassemblez seraient effectives, pertinentes et précises. Cependant, dans de nombreux cas, ce
n’est pas pratique et c’est prohibitif au niveau du coût, d’essayer de recueillir des chiffres exacts et
quantitatifs. On peut compléter n'importe quels métriques quantifiables en utilisant des enquêtes de
satisfaction du client. Pour plus d'informations sur les enquêtes, voyez le paragraphe 9.2.1.1 Collecter
des métriques au moyen des enquêtes.
Rassembler des métriques du projet et des données démographiques peut être utile pour des
projets futurs (9.2.1. P9)
Recueillir et rapporter un ensemble cohérent de métriques à la fin d'un projet peut aider votre
entreprise à évaluer les tendances dans le domaine des produits des projets sur une certaine période
de temps. Les métriques doivent montrer à quel point les équipes de projet respectent leurs
engagements en termes de qualité, de coût et de durée. Comme de plus en plus de projets rassemblent
des métriques, une ligne de base devra être établie pour permettre à votre entreprise de voir si elle
s'améliore ou dérape, au fil du temps.
Si vous rassemblez les métriques au niveau de l’entreprise, vous devez rassembler des données
démographiques sur le projet, en plus des métriques réelles. Les données démographiques du projet
sont des caractéristiques prédéfinies qui fournissent une description de chaque projet particulier. Si
vous stockez les données démographiques et les métriques dans un dossier ou une base de données,
ils peuvent être analysés pour montrer les tendances globales de manière plus détaillée et plus fine.
Si vous ne rassemblez pas les indicateurs démographiques, vous pouvez toujours comparer le coût
effectif de production au coût estimé. L'avantage que présente la collecte des indicateurs
démographiques d’un projet c’est que vous pouvez comparer des projets similaires. Par exemple, vous
pouvez comparer le coût et l'effort de travail liés à des projets de développement d’unités centrales à
ceux de projets de développement Web. Vous pourriez aussi comparer à quel point les projets d’un
service de ventes respectent leurs dates limites et leur budget par rapport à des projets dans le
domaine financier.
L'autre avantage que présente la collecte de données démographiques de projet est que vous pouvez
employer les informations comme des données en entrée pour des estimations de projets futurs. Par
exemple, supposons que vous menez des compagnes de marketing concernant différents produits.
Supposons aussi que vous avez collecté les estimations relatives au projet et les résultats réels des
coûts et de la durée. Si vous avez réussi à disposer de ces informations, vous pourriez estimer le coût
et la durée de la compagne de marketing actuelle du produit et ce en comparant votre projet à d’autres
projets similaires qui ont été achevés dans le passé. Ces informations pourront vous être utiles pour
estimer votre projet. Les données démographiques que vous collectez concernant des projets réalisés
peuvent être employées pour effectuer des recherches ultérieures dans le cadre de nouveaux projets.
(Un modèle de feuille de travail pour collecter les données démographiques et les métriques de projet
est disponible dans la Bibliothèque des modèles).
Assurez-vous que vos métriques racontent une histoire complète (9.2.1. P10)
Dans plusieurs exemples, l’équipe du projet publie les résultats d’une métrique d’une manière qui ne
permet pas au lecteur de bien comprendre si les résultats sont bons ou s’ils ne le sont pas. Ceci
s’explique par le fait que le lecteur voit l’indicateur de performance mais ne comprend pas l’objectif ni
ce que la métrique essai d’achever. Le chef de projet et l’équipe de projet sauront ce qu'une métrique
donnée leur apprend, mais d'autres personnes, à la lecture de ces informations, ne sauront pas de quoi
il s’agit. Une façon d’aider à la compréhension est de toujours accompagner les métriques de leur
objectif. Par exemple, si vous rapportez vos dépenses courantes du moment, incluez également vos
dépenses prévues à ce point du projet. Si vous rapportez que votre projet a coûté 100.000 € jusque-là
410
et que votre budget total est de 150.000 €, le lecteur n'a pas toujours les moyens de savoir si c'est une
bonne ou une mauvaise situation. Il est certain que vous n’avez pas dépassé le budget, mais le travail
n'est pas terminé non plus. La manière meilleure de rapporter ces informations est de déclarer que
vous avez dépensé 100.000 € jusque-là. Si cette tendance persiste, le coût final du projet sera de
135.000 € par rapport à un budget de 150.000 €. Si vous rapportez les métriques dans ce contexte, vos
lecteurs pourront comprendre ce que les chiffres signifient.
Communiquez avec l'équipe et formez-la à propos des métriques (9.2.1. P11)
Si vous parlez aux membres de votre équipe de l'importance d’élaborer un produit de qualité,
généralement, ils comprendront ce que vous leur dites. La qualité est un terme qui a une connotation
familière pour tout le monde. La définition générale des métriques n'est toutefois pas aussi évidente. Le
chef de projet peut essayer de créer un programme métriques pour un grand projet, alors que l’équipe
de projet ne voit pas le rapport entre cette opération et la valeur commerciale qu’on peut en tirer. Les
clients peuvent eux aussi ne pas faire la liaison. Le client peut ne pas comprendre intuitivement que
vous devez effectuer des mesures pour savoir si les livrables et les processus répondent réellement aux
attentes. Il peut également ne pas s’apercevoir du lien entre le fait de recueillir des métriques et la
capacité d'améliorer les processus.
Le chef de projet doit prendre le temps d’expliquer pourquoi les métriques sont nécessaires et comment
les informations rassemblées conduiront à des améliorations. De même, l’équipe devra apprendre
comment rechercher les métriques qui renseignent sur l'état d'un processus ou d'un produit livrable.
Instruire l'équipe et le client aidera le chef de projet à obtenir de meilleurs métriques avec moins de
suivi et moins de rejets. Si votre entreprise est focalisée sur la qualité globale, cette éducation devrait
toucher l'ensemble du personnel.
Utiliser les Facteurs Critiques de Succès (FCS) et les Indicateurs Clés de Performance (ICP)
pour communiquer les indicateurs à vos clients (9.2.1. P12)
Les expressions " Facteurs Critiques de Succès " - FCS - (Critical Success Factors - CSF -) et «
Indicateurs Clés de Performance » - ICP - (Key Performance Indicators - KPI -) sont utilisées pour faire
connaître les objectifs de succès. Ces termes indiquent normalement quelque chose d’important à
mesurer qui concerne votre activité commerciale. De nombreuses organisations utilisent les deux
termes de manière interchangeable; il y a cependant une légère nuance entre les deux.
 Indicateur clés de performance (KPI). Généralement, les indicateurs clés de performance se

concentrent sur les processus. Par exemple, un de vos ICP peut être la réduction du temps
d’expédition d’une commande à un client. Il s’agit d’une mesure liée au succès de votre
processus parce que c’est un indicateur d’assurance qualité.
 Facteur Critique de Succès (CSF). Un facteur critique de succès se rapporte, quant à lui, aux
caractéristiques d’un livrable. Par exemple, vous pouvez avoir un FCS associé à la réduction du
nombre de défauts de l’un de vos produits. Il s’agit alors d’un indicateur de contrôle qualité.
Les métriques sont désignées pas KPI et par CSF s’il s’avère qu’ils sont indispensables pour succès de
votre société ou de votre organisation. L’idée générale est que votre organisation n'atteindra pas ses
objectifs avec succès à moins que ces KPI et CSF soient respectés.
Identifiez les produits de votre travail (livrables) comme des réussites (9.2.1. P13)
Lors du processus de définition du travail, vous avez établi un ensemble d’objectifs pour votre projet. Si
celui-ci réalise ces objectifs, vous pouvez considérer votre projet comme un succès. De même, vous
avez identifié un ensemble de livrables que vous devez réaliser pour atteindre ces objectifs. Cela établit
un lien entre vos livrables et le succès de votre projet.
Quand vous créez le tableau de bord du projet, la première chose à savoir ce sont les critères de succès
de votre projet. Parmi ces critères de succès se trouve naturellement la réalisation des livrables de
votre projet. Si vous les avez réalisé avec succès et avec le niveau requis de qualité, vous aurez au
moins l’un des éléments des critères de succès global sur votre tableau de bord.
411
9.2.1.1 Collecter des métriques au moyen des enquêtes
(9.2.1.1. P1)
En complément aux métriques quantifiables, on peut réaliser des enquêtes de satisfaction du client. Par
exemple, au lieu d’essayer de mesurer le temps de réponse exact d’une application par rapport à un
niveau de service standard, vous pourrez simplement demander à vos utilisateurs principaux s’ils sont
satisfaits du temps de réponse de l'application. Que vous faites vraiment du bon travail dans votre
domaine aurait un sens si vous réussissez à avoir 4.5 sur 5.0 (5 étant la meilleure note). Cependant, si
les résultats provenant de votre enquête sont de 1.8 sur 5.0 (5 étant la meilleure note) alors il serait
évident que vous avez manqué votre note. Vous n’avez pas eu besoin d’un système compliqué, une
métrique pour vous en informer. Un simple sondage de satisfaction client vous donnerait rapidement le
même résultat. De la même manière, vous voulez recueillir des métriques qui signalent le temps
nécessaire pour résoudre les problèmes d’un client. Cela implique le fait de revenir à la date de la
demande initiale, de savoir quand vous avez répondu au client la première fois et quand la demande a
été satisfaite. D’un autre côté, vous pourriez simplement demander à vos clients s’ils étaient satisfaits
du temps mis pour résoudre le problème.
Les enquêtes sont qualitatives par nature, c'est-à-dire qu’elles reflètent l’opinion de la personne
interrogée. Par conséquent, vous ne voudriez pas nécessairement que tous les critères de réussite de
votre projet se basent sur des indicateurs fournis par des enquêtes. Quelques résultats peuvent être
plus facilement obtenus quantitativement. Par exemple, il n’y a généralement aucune raison d’envoyer
une enquête au service financier pour savoir si vos dépenses respectent le budget. Vous devriez avoir
les données disponibles. Cependant, pour beaucoup d'autres types de métriques, une enquête
qualitative peut être menée pour remplacer des métriques quantitatives.
Une enquête comporte des questions et des espaces pour les réponses. Nombre d’enquêtes demandent
une combinaison d’évaluations rétroactives et de rétroactions écrites. Les réponses chiffrées sont
employées pour guider les métriques, alors que les rétroactions écrites fournissent une perspective
complémentaire qui peut être employée pour leur analyse. Une enquête bien formulée procure un
certain nombre d'avantages.
 Lorsque vous essayez de déterminer comment des personnes interagissent entre elles, ou
comment un processus interagit sur les personnes, peut-être la meilleure manière de recueillir
la rétroaction est-elle d’interroger directement les personnes concernées. Obtenir une
rétroaction verbale peut être utile ; néanmoins, cela ne vous permet pas de quantifier les
informations. Des enquêtes sur les métriques vous offrent cette latitude, à savoir la mise à
contribution des personnes concernées sous forme de données chiffrées.
 Elles sont une manière relativement peu coûteuse d’obtenir une rétroaction de la part de
nombreuses parties prenantes. Par exemple, un commerçant peut essayer de rassembler des
rétroactions de centaines ou de milliers de clients. Une enquête serait une manière efficace de
permettre à cette masse des personnes de contribuer par leurs idées à la réussite du projet.
 La rétroaction chiffrée peut être interprétée mathématiquement dans un but de précision et de

facilité d’utilisation. Les enquêtes offrent un avantage considérable dans la mesure où vous
pouvez recueillir la rétroaction d'un grand nombre de personnes, tout en synthétisant les
résultats par des calculs mathématiques simples.
 Vous obtiendrez des nuances de gris avec les rétroactions chiffrées. Une enquête vous permet
de recevoir des réponses basées sur une continuité ou sur une gamme de résultats possibles.
Naturellement, une approche basée sur des enquêtes présente aussi un certain nombre de faiblesses :
 À moins d’insister vraiment, vous n’aurez généralement pas un pourcentage élevé d’enquêtes
qui vous sont renvoyées. Estimez-vous heureux si vous en recevez 50% ; un taux de 25% est
assez ordinaire. Si vous obtenez trop peu de retours d’enquêtes, vous ne pourrez pas être sûr
que les résultats dont vous disposez sont représentatifs du groupe entier.
412
 Beaucoup d’enquêtes, peut-être bien la plupart, contiennent plusieurs questions qui ne sont pas
bien rédigées, et les informations retournées sont sujettes à caution. Des problèmes peuvent
apparaître:
o Une difficulté à compléter les réponses, peut-être parce qu’il n’y a pas assez d’espace
o L'échelle d'évaluation a été conçue de manière confuse ou contradictoire
o Des questions à choix multiples sont posées alors que tous les choix ne sont pas
représentés dans la réponse
o Des questions biaisées, orientant les réponses vers une direction donnée
o Une seule réponse est demandée alors que deux questions implicites, voire plus, sont
énoncées (par exemple : êtes- vous satisfait de la fréquence et du format du
rapport?)
Quand vous élaborez une enquête, une question se pose couramment : celle de savoir si les
participants doivent décliner ou non leur identité. Si on le demande aux sondés, cela permet de leur
poser ultérieurement des questions si on cherche une plus grande clarté émanant des réponses
initiales. Cela peut néanmoins inhiber la rétroaction et dissuader complètement certains de répondre à
l’enquête.
Soyez prudent en posant des questions « oui / non » (9.2.1.1. P2)
Beaucoup de concepteurs d’enquêtes inexpérimentés supposent qu’ils ne poseront que des questions
auxquelles on répondra seulement par « oui » ou par « non ». De cette façon, les réponses sont nettes,
sèches et faciles à interpréter. Si vous posez à dix personnes une question appelant une réponse par «
oui » ou par « non », vous pouvez facilement classifier les résultats et déterminer les préférences
globales.
Le problème avec la réponse simple de type « oui ou non » c’est que c’est « noir ou blanc » (tout ou
rien) et que cela ne permet pas d’obtenir des nuances de gris. Il arrive souvent que la personne qui
répond ait un point de vue plus complexe. Par exemple, elle peut être satisfaite une fois à propos d’un
élément, puis mécontente les fois suivantes. La personne répondant à l’enquête peut ne pas vouloir
être acculée à répondre uniquement par oui ou par non.
La meilleure méthode est de toujours poser des questions qui suscitent des réponses nuancées. Par
exemple, vous pouvez demander au commanditaire : « Etes-vous satisfait de la réussite globale du
projet? » et lui permettre d’exprimer sa réponse sur une échelle de un à cinq (ou de un à dix). S’il est
totalement satisfait, il mettra cinq sur cinq. S’il était satisfait de la plupart des tâches, mais pas de
toutes, il pourra évaluer l'équipe avec un quatre sur cinq, ou peut-être un sept sur dix. Une fois de plus,
ces scores sont classifiés et ramenés à une moyenne pour déterminer le niveau de réussite globale.
Envoyer les questionnaires assez tôt et souvent pour trouver le temps des améliorer (9.2.1.1.
P3)
Une enquête client peut être envoyée à la fin de chaque projet - petit, moyen ou grand. Cette enquête
fournira la rétroaction finale du client pour savoir jusqu’à à quel point les livrables ont satisfait ses
besoins et comment le projet a été exécuté. Cependant, l'équipe n'aura aucune chance de s'améliorer si
une seule enquête est recueillie à la fin du projet. Pour les plus grands projets, l'équipe devra effectuer
des enquêtes périodiques. Une enquête pourra être menée à la moitié du projet, par exemple, aussi
bien qu’à la fin. Si votre projet est suffisamment grand, vous devriez faire des enquêtes lors de
l'accomplissement des phases ou des jalons importants du projet. Si vous faites trop d’enquêtes, celles-
ci risquent d’être ignorées dans la mesure où peu de choses auront changé depuis l’enquête
précédente. Cependant, si vous ne faites pas assez d’enquêtes, il vous sera difficile de connaître votre
niveau de performance actuel (du point de vue du client) et d’apporter des améliorations basées sur sa
rétroaction.
413
9.2.2 Le coût et les avantages de la qualité
Le coût de la qualité (9.2.2. P1)
Inscrire des étapes de la qualité dans l'échéancier du projet ajoute une certaine quantité d’effort de
travail et un certain coût au projet. Cependant, cet accroissement des coûts sera compensé par des
avantages accrus et la réduction des coûts tout au long du cycle de vie de la solution. Voici des
exemples qui peuvent être inclus dans le coût de la qualité:
 Révision des livrables. Il y a un coût associé au temps nécessaire pour assister aux revues.
Ceci inclut la préparation, le temps réel de révision pour tous les participants, et le travail à
venir résultant de la revue.
 Création du plan de management de la qualité. Le temps requis pour planifier la qualité
dans le projet et la solution, y compris l’identification des critères d’acceptation.
 Approbation du client. Le temps et l'effort de travail dont le client a besoin pour passer en
revue les livrables intermédiaires et définitifs et pour les approuver formellement comme
corrects et complets.
 Tests. Les tests font partie du cycle de vie du projet, mais ils sont également effectués pour
s’assurer que la solution répond aux spécifications et aux standards de la qualité.
 Standards de contrôle qualité. Le temps et les coûts associés à la définition des normes
appropriées utilisées dans tout le projet et / ou dans l'entreprise.
 Audits. Les audits constituent des opportunités propres à faire passer en revue par une partie
extérieure les processus utilisés pour la création de vos livrables. Cette tierce partie apporte
une perspective nouvelle et une opinion impartiale pour savoir si de bons processus de travail
ont été définis et sont suivis. Cependant, il n’est pas question que l’audit demande du temps et
du travail supplémentaires au chef de projet ou à la personne qui effectue l’audit.
 Listes de contrôle. Elles sont habituellement dressées afin de garantir que toutes les étapes
d'un processus ont été accomplies ou que tous les composants d'un produit livrable sont en
place.
 Groupes de contrôle qualité et d’assurance qualité. Si votre entreprise a des groupes
distincts qui se spécialisent dans le contrôle qualité ou l’assurance qualité, leurs coûts font
partie des coûts globaux de la qualité pour l'entreprise.
 Collecte des métriques. Les métriques sont normalement recueillies pour faire le point de la
situation d'un processus et pour corriger ou améliorer ce dernier en cas de besoin. La collecte
des métriques prend du temps et un coût lui est associé.
Les avantages de la qualité (9.2.2. P2)
Les coûts de la qualité doivent être pondérés par les avantages qu’il y a à fournir une solution de
qualité. Alors que les coûts associés à la qualité apparaissent au cours du projet, les avantages de la
qualité se révèlent au cours du cycle de vie entier de la solution. Les avantages de la qualité incluent:
 Une satisfaction accrue du client. Un nombre limité de défauts signifie que le client sera
plus satisfait. Une qualité plus élevée de service sera, pour le client, une expérience encore plus
appréciable. Si vous êtes dans un organisme à but lucratif, cela pourrait amener de la clientèle
et se traduire par des ventes supplémentaires ou des marges bénéficiaires plus élevées sur de
futurs produits.
 Une productivité plus élevée. La correction des erreurs et les travaux de reprise sur des
livrables supposés terminés affaiblissent la productivité. En fait, ils contribuent à amener une
productivité négative. Si les livrables sont réalisés avec une meilleure qualité et une proportion
de travail de reprise limitée, la productivité globale du projet augmentera.
 Des coûts réduits / Une durée plus courte. Bien que le coût initial de la prise en charge
d’un processus de qualité soit élevé, ce coût est plus que compensé par la faible quantité de
414
travail de reprise à effectuer jusqu’à la fin du projet. Cela permet d’économiser du temps et des
coûts sur le projet.
 Un moral plus élevé pour l’équipe de projet. Le moral de l'équipe est entamé lorsque
beaucoup d'erreurs sont découvertes dans le projet. Les gens se sentent mal à l’aise chaque
fois que des erreurs sont découvertes et il peut être frustrant d’avoir sans cesse à corriger des
erreurs. Le moral de l’équipe pourra remonter (ou du moins restera stable) si les livrables sont
réalisés avec le moins d’erreurs, dès le début.
 Moins d'erreurs / défauts. Une meilleure qualité se manifeste, au cours de la vie de la
solution, avec une faible proportion de défauts et d'erreurs. Si vous réalisez un produit pour le
mettre en vente sur le marché, une meilleure qualité sera synonyme de moins de retours,
moins de travail de garantie, moins de réparations, etc. Si vous créez une solution à long
terme, vous aurez à faire face à moins de problèmes de support et de maintenance au cours de
son cycle de vie.
Le coût de la mauvaise qualité (9.2.2. P3)
Réaliser une solution de qualité coûte du temps et de l’argent. Vous pensez peut-être qu’il est plus
économique d'omettre les étapes de la qualité mais ce n'est généralement pas le cas. Il est important
de reconnaître qu'il y a également un coût associé à la mauvaise qualité. Ces coûts peuvent ne pas être
évidents au cours de l’évolution du projet, mais devront certainement être pris en considération comme
faisant partie du coût total du cycle de vie de la solution livrée. Voici quelques exemples de coûts de la
mauvaise qualité :
 Travail de garantie. Il inclut le travail qui est effectué gratuitement sur un produit ou une
application sous garantie.
 Réparations / Maintenance. le travail effectué pour résoudre des problèmes une fois qu’une
solution est trouvée.
 Mécontentement du client. Si une solution s’avère être de mauvaise qualité, le client sera
mécontent et pourrait ne plus rien vous acheter par la suite. Si le projet est interne, le client
pourra ne plus vouloir employer le chef de projet et les membres de l’équipe sur les projets
suivants.
 Bureau d’assistance. Une grande partie (mais pas la totalité) de l'effort de travail et des
coûts associés au maintien d’une ligne ou d’un bureau d’assistance au client peuvent être
nécessaires parce que ce dernier rencontre des problèmes avec la solution proposée ou qu’il a
des questions à poser à propos des moyens d’utiliser la solution.
 Personnel de soutien. Une grande partie de l'effort de travail et du coût associé au maintien
d’un employé de soutien est requis pour entretenir et soutenir une solution en raison de
problèmes, d’erreurs, de questions, etc.
 Travail de reprise. Ce travail est nécessaire pour corriger les livrables que vous croyez déjà
achevés et corrigés.
 Mauvaises décisions. S’il s’avère qu’il y a des erreurs inhérentes à vos systèmes eux-mêmes,
vous allez finir par prendre des décisions en vous basant sur de mauvaises informations.
 Investigations sur les causes de l’échec. Localiser un problème et déterminer les causes
des erreurs et des défauts au cours d’ un projet peut prendre beaucoup de temps.
 Un moral bas. Personne n’aime travailler pour une entreprise ou un projet qui comporte de
mauvais processus ou qui produit des solutions de mauvaise qualité. Le coût d’un moral bas
inclut l’accroissement de l'absentéisme, une plus grande instabilité du personnel et la
diminution de sa productivité.
Investir tôt dans la qualité pour réduire les coûts durant le cycle de vie du produit (9.2.2. P4)
Voila quatre aspects des coûts de la qualité:
 Coûts de prévention (AQ)
415
 Coûts d’inspection (CQ)
 Coûts relatifs à la mauvaise qualité durant le projet (coûts d’échec internes)
 Coûts relatifs à la mauvaise qualité après la fin du projet (coûts d’échec externes)
Tous ces aspects relatifs à la qualité ont un coût. L’un des points les plus importants du management
officiel de la qualité est le suivant: si vous passez plus de temps et si vous dépensez davantage sur l’AQ
et le CQ, vous serez capable d’effectuer une épargne substantielle quant aux coûts d’échec internes et
externes. En fait, l'épargne pour faire face à d’éventuels coûts d’échec externes peut s’avérer
substantielle. Dans certains cas, vous pouvez délivrer un produit que votre organisation utilisera durant
plusieurs années. Si vous créez un produit de mauvaise qualité, les coûts de soutien (coûts d’échec
externes) pourraient s’avérer substantiels. D’autre part, si vous consacrez plus de temps à vous
concentrer sur la création d’un produit de meilleure qualité pendant le projet, le coût de soutien du
produit sera terriblement réduit à long terme.
416
9.2.3 Questions de contrôle qualité
Les activités de contrôle qualité sont celles qui se concentrent sur la qualité globale du livrable réalisé.
Le contrôle qualité relève habituellement de la responsabilité du chef de projet et de la personne
responsable d'un livrable.
La liste suivante présente le genre de questions de contrôle qualité qui peuvent être posées au sujet
des des livrables majeurs de votre projet et du management des livrables d’un projet de développement
de logiciel. Plusieurs types de projets peuvent créer une liste similaire de questions de CQ et ce pour
refléter les livrables spécifiques de ce projet.
Questions de contrôle qualité d’un projet de développement de logiciel

Livrable
(Echantillons de livrables. Une liste non exhaustive.)
 Un modèle standard a-t- il été utilisé pour la charte du projet?

 Les objectifs du projet sont-ils spécifiques, réalistes et dans la sphère de
contrôle de l’équipe de projet?
 Les livrables du projet sont-ils clairement définis?
 Le contenu énonce-t-il clairement ce qui est dans le contenu et ce qui est
en dehors du contenu?
 L'approche globale du projet est-elle logique?
La charte du  Le coût, l'effort de travail et la durée globale sont-ils clairs?
projet  L'organigramme du projet est-il clair?
 Est-ce qu’un commanditaire de projet a été identifié?
 Les hypothèses et les risques majeurs ont-ils tous été identifiés?
 Des plans de gestion des risques sont-ils en place pour tous les risques de
niveau moyen et élevé?
 Les personnes appropriées pour approuver le projet ont-elles été
identifiées?
 La charte du projet a-t-elle été approuvée par les personnes appropriées?
L'échéancier du  L'échéancier prend-il en compte l'approche globale de la charte du projet?

projet  Les plans de management des risques, des communications, de contrôle
et d'assurance qualité sont-ils inclus dans l'échéancier global?
 Le chemin critique a-t-il été repéré et identifié?
Les exigences  Un modèle standard a-t-il été utilisé pour les exigences commerciales?
commerciales  Les exigences commerciales ont-elles été établies à partir d’une
perspective utilisateur?
 Les modélisations appropriées au niveau du processus et au niveau
commercial ont-elles été réalisées?
 Le livrable répond-il aux critères définis d’acceptation?
 Les exigences commerciales ont-elles été approuvées par les personnes
appropriées?
La conception  Un modèle standard a-t-il été utilisé pour la conception du système?

du système  Les interfaces ont-elles été identifiées et définies?
 Est-ce que des écrans et des formes ont été identifiés à un niveau
global ?
 Les processus globaux en ligne et les processus différés fonctionnent-ils
417
correctement du début à la fin?
 Les bases de données ont-elles été identifiées et définies?
 Le livrable répond-il aux critères d’acceptation définis ?
 La conception du système a-t-elle été approuvée par les personnes
pertinentes?
La conception  Un modèle standard a-t-il été utilisé pour la conception technique du

technique du système?
système  L’architecture technique est-elle conforme à toutes les normes courantes,
ou a-t-elle bénéficié d’exceptions?
 La conception suit-elle toutes les normes et directives de développement
appropriées?
 Les écrans, les rapports, les composants, les bases de données, etc., ont-
ils été définis avec suffisamment de détails pour que le processus de
construction puisse commencer?
 Le produit livrable répond-il aux critères d’acceptation définis ?
 La conception technique du système a-t-elle été approuvée par les
personnes pertinentes?
La construction  Des révisions de code ont-elles été menées pour tous les nouveaux
modules?
 Le code a-t-il été bien documenté, pour être compréhensible à l’avenir?
 Tous les composants du logiciel ont-ils passé avec succès des tests
d’ensemble?
 Les livrables répondent-ils aux critères d’acceptation définis ?
Le plan de tests  Un modèle standard a-t-il été utilisé pour le plan de tests?
 Les tests ont-ils été effectués pour s’assurer que le logiciel remplit les
fonctions pour lesquelles il a été conçu?
 Les tests ont-ils été effectués avec une variété de données non valides et
inattendues pour s’assurer que le logiciel répond comme prévu?
 La solution est-elle passée par les tests d'intégration, les tests système, et
les tests d'acceptation par l’utilisateur
 Les livrables répondent-ils aux critères d’acceptation définis ?
 Les clients commerciaux ont-ils formellement approuvé les résultats du
processus de tests, signifiant ainsi que la solution est prête pour passer à
une situation de production?
418
9.2.4 Questions d’assurance qualité
(9.2.4. P1)
L’assurance qualité vise la validation des processus employés pour créer les livrables. C’est un
processus particulièrement utile pour les managers et les commanditaires. Même s’ils ne disposeront
pas toujours du temps ou de l’expertise nécessaires pour valider l’état des livrables en termes
d’exécution, d’exactitude et de bonne qualité, cela ne devrait pas les empêcher de discuter des
processus utilisés pour les créer, et donc de déterminer si les processus eux-mêmes semblent sains et
raisonnables.
A quoi devrait ressembler une bonne question d’assurance qualité ? Donnez votre avis sur les exemples
suivants:
 Comment ça va ? (Non)
 Est-ce que vous pensez pouvoir terminer à temps ? (Non)
 Rien de spécial à rapporter ? (Non)
 Est-ce que tout est sur la bonne voie ? (Non)
 On dirait que tout va bien, alors ? (Non)
 Dites-moi si vous avez un problème quelconque. (Non)
 Pas de nouvelles, bonnes nouvelles ! (Non)
 Je dois vous faire confiance, je ne peux pas dire si vous êtes sur la bonne voie ou non. (Non)
Ce ne sont pas là de bonnes questions d’assurance qualité. Elles ne sont pas précises et les réponses
que vous obtiendriez ne vous aideront pas beaucoup à déterminer la situation globale du projet. Au
contraire, ce sont des exemples de ce que l’on appelle : « A poser une question stupide, tu n’obtiendras
qu’une réponse stupide ». Les questions d’assurance qualité doivent être bien plus spécifiques et bien
plus ciblées pour déterminer l’état courant du projet. De bonnes questions en matière d’assurance
qualité doivent permettre de découvrir l’état des processus utilisés pour gérer le projet. Vous trouverez
de meilleures questions d’assurance qualité, plus loin dans cette section.
En plus de l’examen des processus en cours, l’un des principes de base d’une révision d’assurance
qualité est de rechercher ce qui pourrait mal tourner. Par exemple : vous pouvez demander comment
un document a été rédigé et approuvé, et vous pouvez recevoir une réponse valide. Cependant, celui
qui effectue la revue a aussi besoin d’être en mesure de déterminer si le processus est aussi approfondi
qu’il doit l’être. Les questions doivent explorer les secteurs susceptibles de mal tourner, et discuter
l'impact sur le projet de ce qui pourrait être le cas dans le processus.
Une revue de la qualité doit dévoiler les défaillances du processus. Cependant, c’est à ce stade que la
perspective individuelle entre en jeu. Le responsable de revues doit comprendre que les processus
utilisés pour un projet ne sont pas parfaits, mais qu’ils doivent être suffisamment bons. Aucun chef de
projet (ni aucune entreprise) ne voudrait perdre du temps et des efforts pour essayer de rendre vos
processus parfaits. Il y a des chances que quelque chose tourne mal avec n’importe quel processus.
Cependant, l’impact d’un problème n’est normalement pas suffisant pour exiger des processus
additionnels et redondants. Si les conséquences sont désastreuses, vous voudriez naturellement avoir
un processus plus solide même s’il est redondant. Si les conséquences ne sont pas significatives, alors
un processus qui tourne à 80% devrait suffire.
L’assurance qualité doit faire en sorte que les « bons » processus soient établis et que ces « bon »
processus soient respectés. Il n’est pas nécessaire que ces processus soient parfaits.
Audit d’assurance qualité (9.2.4. P2)
Dans de nombreux cas, il est logique de faire appel à une partie extérieure pour venir évaluer les
processus de management de projet qui sont entrain d’être utilisés et effectuer une deuxième
419
vérification pour garantir que le projet progresse comme prévu. Le chef de projet ou son supérieur peut
demander un audit de projet dans le cadre d’un programme global de management de la qualité. Dans
certains cas, comme dans les projets gouvernementaux, des audits périodiques peuvent faire partie du
contrat global. Cette « partie extérieure » peut être n’importe quelle personne qualifiée, en dehors du
chef de projet. Dans certains cas, votre entreprise dispose d’un spécialiste interne de l’audit des projets.
Il est possible que cet audit soit assuré par le directeur de projet ou le commanditaire. La partie
extérieure peut être (mais ceci n’est pas obligatoire) un contractuel ou un consultant.
L’audit, lui-même, cherche à déterminer si des processus de gestion efficaces sont utilisés et si le projet
est sur la bonne voie. Un audit de projet se concentre sur l’assurance qualité en posant des questions
sur les processus utilisés pour l’élaboration des livrables. Il peut suivre ce processus :
Rôle Audit de l’assurance qualité
1 Auditeur Informer les parties prenantes.

L’auditeur informe le chef de projet de l’audit à venir, et programme un lieu
et un moment appropriés. D’autres parties prenantes peuvent également
être informées.
2 Auditeur Préparer l’audit.

L’auditeur peut d’emblée demander certaines informations. Il peut
également demander au chef de projet d’être prêt à discuter de certains
aspects du projet. Cela garantit que la durée réelle de la réunion sera aussi
productive que possible.
3 Auditeur, équipe Mener l’entretien initial.

de projet Lors de la réunion d’audit, l’auditeur pose les bonnes questions pour
s’assurer que le projet est sur la bonne voie. Si certains secteurs ne le sont
pas, l’auditeur doit en prendre note.
4 Auditeur, équipe Mener autant d’autres entretiens que nécessaire (facultatif).

de projet Il y a de nombreux projets où l’audit peut se limiter à une réunion initiale. Si
le projet est grand et complexe, l’auditeur pourra éprouver le besoin de
procéder à des analyses supplémentaires. Cela inclut des rencontres avec
d’autres membres de l’équipe et avec des clients, et d’examiner davantage
de documents.
5 Auditeur Consigner les conclusions.

L’auditeur prend note de la situation et des processus utilisés dans le projet,
en comparaison avec les meilleures pratiques. Si l’organisation a des
standards et des politiques définies pour le management de projet,
l’auditeur détermine s’ils sont suivis ou pas dans le cadre du projet audité. Il
doit aussi faire des recommandations au sujet des mesures qui peuvent être
prises pour avoir une gestion du projet plus efficace et plus proactive.
6 Auditeur, chef Passer en revue l’ébauche du rapport d’audit.

de projet L’auditeur et le chef de projet doivent se rencontrer une nouvelle fois pour
discuter des conclusions initiales. L’auditeur décrit toutes les déficiences
dans la gestion et fait ses recommandations pour des changements. Ce
passage en revue permet aussi au chef de projet d’exposer ses arguments
et de se défendre, s’il l’estime nécessaire. Dans de nombreux cas, les
remarques de l’auditeur seront modifiées sur la base d’une rétroaction
spécifique et ciblée de la part du chef de projet.
7 Auditeur Rédiger un rapport final.

L’auditeur livre son rapport final avec ses conclusions et ses
recommandations. Le chef de projet peut aussi rédiger une réponse formelle
420
à l’audit. Dans cette réponse, le chef de projet peut accepter les conclusions
et examiner des plans pour les mettre en œuvre. Il peut également
exprimer son désaccord avec certains points de l’audit et expliquer les
raisons de son désaccord. Dans ce cas, le commanditaire et le directeur du
projet (le supérieur du chef de projet) doivent décider si le chef de projet
doit ou non se plier aux recommandations.
Questions d’assurance qualité (9.2.4. P3)
Les questions suivantes peuvent être utilisées pour guider la discussion d’assurance qualité concernant
un projet de développement de logiciel. Plusieurs types de projets peuvent créer une liste similaire de
question d’AQ. Les questions de management de la qualité devraient être similaires indépendamment
du projet. Cependant, les questions relatives au cycle de vie du projet seront différentes en fonction de
la nature du projet et en fonction de la phase spécifique dans laquelle se trouve le dernier.
Discussion d’assurance qualité pour un projet de développement

Quand de logiciel
(Echantillon de livrables. Liste non exhaustive.)
Définition préalable  Le bon commanditaire a-t-il été identifié, et a-t-il formellement

du projet approuvé le projet?
 Une charte du projet a-t-elle été rédigée et approuvée par les
gestionnaires concernés et par le commanditaire?
 Les parties prenantes principales ont-elles participé à la
planification?
 Les requêtes en matière de personnel sont-elles adéquates.
 Un échéancier valide a-t-il été élaboré pour le projet?
 Les jalons majeurs pour la gestion, le contrôle et l’établissement
de rapports de qualité ont-ils été définis?
 Des estimations précises en termes d'effort, de coûts et de durée
ont-elles été réalisées?
 Quel Plan de management de projet sera-t-il employé pour
contrôler le projet?
 Y a-t-il des critères d’acceptation pour chaque livrable majeur?
Questions de  Le chef de projet utilise-t-il l’échéancier du projet pour gérer le

management de travail effectué par l'équipe?
projet, à poser à la fin  L’échéancier du projet reflète-t-il exactement le travail qui reste à
de chaque phase faire?
principale
 L’échéancier du projet indique-t-il les activités détaillées requises
pour les trois mois à venir (ou jusqu’au prochain jalon majeur)?
 Le chef de projet peut-t-il expliquer clairement où en est le
projet, par rapport au moment où il devrait être?
 Tous les livrables inscrits dans la charte du projet seront-ils
accomplis?
 Des processus solides sont-ils employés pour gérer les problèmes
majeurs, le contenu et les risques?
 La charte du projet sera-t-elle mise à jour pour refléter tous les
changements majeurs apportés au projet?
 Le chef de projet communique-t-il efficacement au moyen des
réunions de revue du projet et des rapports d'avancement?
421
 Le projet est-il sur la bonne voie en termes de coûts, de durée et
de qualité?
 Les clients commerciaux sont-ils satisfaits du progrès du projet
jusque-là?
 Les attentes des clients sont-elles correctement gérées?
À la fin de la collecte  Les exigences commerciales ont-elles été consignées et

des exigences approuvées par les entités pertinentes du client?
commerciales  Quels autres livrables le projet a-t-il produit pendant cette phase
? Les clients commerciaux appropriés les ont-ils approuvés?
Exemples :
o Le système de conception
o La stratégie des tests
o La stratégie de conversion des données
o La stratégie de formation
 Le projet suit-il les normes, les directives et la politique
appropriées de l’entreprise?
À la fin de la  Quels livrables le projet a-t-il réalisé pendant chaque phase ? Les
conception et des entités pertinentes du client les ont-ils approuvés ? Exemples de
phases de livrables:
construction et de o La conception technique
tests
o Le plan des tests
o Le plan de formation
o Le plan de conversion des données
o La solution testée
 Si les livrables précédents n’ont pas été créés, discutez de la
façon dont les tests ont été accomplis, comment la formation sera
effectuée et comment les données seront converties.
 Le projet suit-il les normes, les directives et la politique
appropriées de l’entreprise?
 Le projet suit-il l'architecture technologique standard de
l’entreprise?
Après la mise en  La solution a-t-elle été formellement approuvée et acceptée par

œuvre de la solution le commanditaire avant le passage à une situation de
production?
 L’équipe de projet soutient-elle la solution de production?
 Les problèmes initiaux sont-ils sur la voie d’une résolution
opportune?
 La solution est-elle sur la voie d’une bonne transmission à
l'équipe de soutien?
422
9.2.5 Contrôle statistique de processus
(9.2.5. P1)
Les techniques de contrôle statistique de processus (CSP) fournissent un moyen objectif et reposant sur
des données, de déterminer si votre projet réalise des produits d’un niveau acceptable de qualité. Ces
techniques se basent sur des tests ou des inspections de la qualité, effectués sur les produits réalisés
par l’équipe du projet. Si votre projet crée un faible nombre de livrables très spécifiques, les techniques
de CSP ne sont pas faites pour vous. Cependant, si votre projet a pour résultat la création de plusieurs
produits similaires, les techniques de CSP sont un bon moyen de déterminer si votre processus suffit
pour réaliser des produits de bonne qualité.
Le CSP vous aide aussi à déterminer si vos processus sont « sous contrôle », c’est à dire si vos
processus sont adaptés à la réalisation de produits d’un niveau de qualité acceptable et de manière
continue. Lorsque les processus commencent à faiblir et réalisent des produits non conformes aux
standards de la qualité, les processus sont alors appelés« hors de contrôle ». Les techniques de CSP
vous indiquent aussi tôt que possible si vos processus sont « hors de contrôle ».
La philosophie qui se trouve derrière le CSP est que le rendement du processus peut être contrôlé de
manière statistique par un procédé d’ingénierie et des actions de gestion. Cette approche permet aux
compagnies et aux équipes de projet :
 D'identifier rapidement les secteurs du projet où se posent des problèmes critiques.
 De réduire la variabilité du produit.
 De déterminer la capacité d’un processus.
 D'optimiser un processus.
 De déterminer la fiabilité d’un produit.
Bien que le CSP apparaisse comme une technique directe et accessible, sa mise en œuvre peut s’avérer
complexe. Cette technique requiert une manière générale et cohérente de tester les produits réalisés,
de même qu’une manière de mesurer les résultats des tests et d’interpréter les résultats pour mieux
comprendre ce qui est en train de se passer.
Grilles de contrôle (9.2.5. P2)
L’utilisation de grilles de contrôle est un aspect critique du CSP. Ce n’est cependant pas la seule
manière de le mettre en place. Une grille de contrôle est un graphique avec un axe horizontal qui
représente des nombres servant d’échantillons ou des points dans le temps, et un axe vertical qui
représente les mesures effectuées à partir de ces échantillons. La grille comporte une ligne centrale qui
représente la cible du processus et deux limites de contrôle (une inférieure et une supérieure) qui
représentent les limites acceptables autour de la ligne de cible du processus.
Une grille de contrôle repose sur les données collectées lors du processus d’échantillonnage. Vous
devez collecter suffisamment de données et les intégrer au graphique. Lorsque tous les points du
graphique sont dans les limites de contrôle, le processus est qualifié de « sous contrôle ». S’il y a des
points en dehors des limites supérieure et inférieure, le processus est considéré comme incontrôlé ou
« hors de contrôle ».
423
Sur la grille de contrôle, l’axe horizontal représente les échantillons ou des points dans le temps. L’axe
vertical comporte des mesures de ces échantillons. La ligne de contrôle (LC) montre la cible du
processus. Les niveaux de contrôle acceptables sont représentés par les lignes (LCS) et (LCI).
Un processus sous contrôle est celui où toutes les mesures tombent toujours entre la limite supérieure
de contrôle et la limite inférieure de contrôle.
Un processus est considéré comme étant « hors de contrôle » quand un ou plusieurs des évènements
suivants se produisent :
 Un point ou plusieurs points sont en dehors des limites de contrôle
 Une série de huit points d’un même côté de la ligne centrale (ce qui représente plus qu’une
coïncidence)
 Une séquence peu courante mais non fortuite dans les données
 Une série de sept points dans une ligne montante ou descendante
424
 Une séquence au dessus ou en dessous de la ligne de contrôle, mais à l’intérieur des limites
 Plusieurs points près d'une limite de contrôle (mais sans être en dehors des limites)
Si l'une de ces situations se produit, l’équipe de projet doit rechercher la cause du problème et
déterminer les changements nécessaires pour que le processus retourne « sous contrôle ».
On considère souvent que les techniques CSP sont objectives, mais que leur utilisation pour la prise de
décisions est plus subjective. Les managers et les membres de l’équipe doivent interpréter les résultats
et mener des actions nombreuses. Le simple fait de mettre en place une grille de contrôle n’améliore
pas la qualité et ne prévient pas les problèmes du processus. Les avantages du CSP dépendent de
l’interprétation et de l’utilisation que l’on fait des résultats.
Quoi que vous fassiez pour obtenir un processus parfait, vous n’y parviendrez jamais. Le facteur
humain, des imperfections au niveau des machines et des outils, la fragilité des équipements et les
exceptions par rapport au processus entraîneront toujours une certaine variabilité. Vous pouvez
ramener les LCS et LCI à une échelle de plus en plus réduite si vous continuez d’améliorer vos
processus (et vos outils). Toutefois, vous n’obtiendrez jamais une variabilité égale à zéro.
425
9.3 Gérer la qualité / Références rapides
Livrables (9.3. P1)
ayant une licence.)
 Plan de management de la qualité
 Révision de livrable
 Liste de contrôle d'assurance qualité pour les projets sous-traités
 Critères d’acceptation
 Estimation du projet 1
 Estimation du projet 2
 Résumé de l’estimation du projet
 Liste de contrôle d'assurance qualité
 Liste de contrôle (check-list) de contrôle qualité
Activités de l'échéancier (9.3. P2)
Les petits projets ne sont pas suffisamment de longue durée pour pouvoir réviser et
améliorer les processus internes dans le but de leur assurer une meilleure qualité
(assurance qualité). En conséquence, les petits projets devraient seulement focaliser
Petits sur les processus de contrôle qualité. Chaque livrable produit devrait être revu et
projets approuvé. La revue finale (peut être bien la seule) est celle qui s’effectue en compagnie
du client. La revue va focaliser sur l’ensemble de la qualité du livrable. Si le livrable
peut être évalué, la revue inclura aussi une discussion du processus d'évaluation et une
revue des résultats réels des évaluations.
Définir le plan de Se fait pendant le processus de définition du

management de la Ouvert projet, comme faisant partie du plan de
Projets qualité management du projet.
moyens
Activités de Déplacez toutes les activités de contrôle qualité,
Ouvert
contrôle qualité pour chaque livrable, dans l’échéancier du projet.
Activités Déplacez les activités d'assurance qualité dans

Ouvert
d’assurance qualité l’échéancier du projet.
Grands
projets
426
Commencez par les mêmes activités que pour un projet moyen et ajoutez des activités
plus élaborées pour rassembler et analyser les métriques relatives à la qualité.
Rassemblez les métriques à un rythme mensuel,

Collecte des
Ouvert pour montrer la qualité des livrables principaux et
métriques
des procédés internes de travail.
Consacrez un peu de temps, chaque mois, pour

Analyse des analyser les métriques rassemblées et voir si des
métriques en vue processus peuvent être améliorés. Quand des
1-2 heures
d’une amélioration processus sont modifiés, continuez à rassembler
des processus ces indicateurs pour voir si les améliorations
peuvent être prouvées quantitativement.
427
9.3.1 Gérer les métriques / Références rapides
Livrables (9.3.1. P1)
Les livrables suivants sont disponibles dans la bibliothèque TenStep de modèles conçus pour soutenir
ce processus. (Certains de ces modèles ne sont accessibles que pour les usagers qui détiennent une
licence).
 Tableau de bord du projet
 Collecte des indicateurs de fin de projet
 Enquête de satisfaction client
Activités de l'échéancier (9.3.1. P2)
Puisque les petits projets tendent à avoir une

Petit
Collectez les métriques courte durée, vous devez collecter et
projet 1 heure /
et consignez-les dans enregistrer les informations de façon
semaine
un rapport hebdomadaire. Les métriques feront l’objet
d’un rapport seulement à la fin du projet.
Ce travail peut être fait dans le cadre de la

Projet charte du projet ou en tant qu’une des
moyen : 2 - premières activités à réaliser après le début du
Créez le tableau de 4 heures. projet. Suivez le processus décrit à l’étape
bord du projet Grand 9.1.3.1. L’essentiel de ce travail peut être
projet : 3 - accompli lors d'une réunion des membres
8 heures. principaux de l’équipe et des parties
prenantes.
Mensuel. Collectez les métriques et établissez

Projets Collectez et rapportez
ouvert un rapport comme celui qui figure dans le
moyens les métriques
tableau de bord de votre projet.
et
grands
Mensuel. Ajoutez à votre échéancier le temps
nécessaire à l’analyse des métriques. Ajoutez,
Engagez les tout au long du projet, des activités destinées
ouvert
activités d'amélioration à mettre en application des améliorations de
processus, basées sur une analyse des
métriques recueillies jusque-là.
Mensuel. Évaluez les métriques que vous

rassemblez mensuellement, pour vous assurer
Évaluez le tableau de
ouvert qu’elles reflètent toujours exactement la
bord du projet
situation globale du projet et qu'ils conduisent
aux comportements désirés.
428
______________________________________________________________________
Processus 10
Gérer les
approvisionnements
429
10.0 Gérer les approvisionnements
Les fournitures se rapportent aux aspects

du management de projet liés à l’obtention
de marchandises et de services auprès
d’entreprises extérieures. Cela renvoie
spécifiquement à des commerçants et des
fournisseurs, et non pas à d’autres
organismes internes au sein de votre propre
entreprise. (Pour les besoins de cet exposé,
les achats et les fournitures sont des termes
équivalents). Nous abordons un domaine
que les chefs de projet doivent vraiment
bien comprendre, un domaine où le chef de
projet peut apporter une contribution.
Cependant, dans beaucoup voire dans la
plupart des entreprises, les fournitures sont
un secteur que le chef de projet ne contrôle
pas. Le chef de projet n’a normalement pas
le pouvoir de passer des contrats au nom de
la société et, normalement, il n’est pas
chargé d’administrer les contrats une fois
qu’ils sont établis.
Si vous êtes sur le point d'acheter des marchandises ou des services pour votre projet, vous devriez
déterminer vos plans et stratégies de l'approvisionnement. Dans certains cas, vous allez simplement
poursuivre des contrats et des plans d'approvisionnement déjà établis par votre société ou votre
organisation. Par exemple, vous pourriez utiliser un modèle de contrat mis à disposition par votre
compagnie afin d'acheter du matériel dont votre projet a besoin. Vous pourriez sélectionner des
fournisseurs à partir de la liste des fournisseurs préférés de votre compagnie et utiliser les accords
préétablis avec eux. C'est á dire, très souvent vous devriez travailler ensemble avec le Service des
achats de votre compagnie pour établir le plan de management des approvisionnements de votre
projet.
La plupart des équipes de projet considèrent que les processus d'identification et de sélection des
fournisseurs font partie des travaux à effectuer durant l'exécution du projet, plus précisément lors de la
phase d'analyse (qui démarre après la définition et l'approbation du projet). Cependant, dans certains
projets vous devrez effectuer ces activités avant de commencer les travaux d'exécution, c'est à dire,
durant le processus de définition du projet.
10.1 Gérer les approvisionnements / Processus
10.2 Gérer les approvisionnements / Techniques
10.3 Gérer les approvisionnements / Références rapides
430
10.1 Gérer les approvisionnements / Processus
(10.1. P1)
Parfois, il est plus sensé de fabriquer un produit en interne et d’autres fois, il est plus judicieux
d’acheter le produit. Toutefois, à plusieurs occasions on peut avoir le choix d'acheter ou de fabriquer un
produit. Dans ces cas, une analyse plus approfondie est nécessaire afin de déterminer s'il est préférable
de fabriquer ou d'acheter. Pour plus d’informations, lire le point 10.1.2 Évaluer les options fabriquer vs.
acheter.
Le processus suivant peut être utilisé pour sélectionner un fournisseur de services ou pour acheter un
produit. Le processus n'est pas ajusté selon la taille du projet. Le même processus de base fonctionne
pour tous les projets. La diligence et l'effort consacrés à chaque activité sont en fonction de la taille et
de l'implication de la sélection des fournisseurs. Si les conséquences de la sélection sont mineures, vous
pouvez réduire la diligence que vous appliquez à chaque activité. Si l'impact sur le projet est important,
vous devrez consacrer plus de rigueur et de diligence dans les activités.
Planifier les approvisionnements (10.1. P2)
Pour toutes les organisations, il y a des moments où elles doivent chercher des fournisseurs afin de
pourvoir à certains besoins. Le processus est simple, mais le traitement de certaines fournitures peut
prendre beaucoup de temps. Les techniques décrites ci-dessous peuvent être utilisées dans presque
tous les processus de sélection, qu’il s’agisse de choisir un logiciel, un fournisseur, des équipements
informatiques, etc. Le processus est décrit ici à un niveau très général et a besoin d’être élaboré avec
plus de détails pour s’appliquer avec la précision nécessaire à votre projet.
Rôle Processus de sélection des vendeurs
1 Chef de projet Recueillir et classer les besoins commerciaux

Il est très difficile de sélectionner un fournisseur si vous ne savez pas
exactement quels sont vos besoins ; aussi la première partie d’un projet
consiste-t-elle à rassembler les exigences commerciales. Cela ressemble au
processus de collecte des exigences commerciales d’un projet ordinaire. Il
faut se poser des questions telles que :
 A quoi ce fournisseur nous sera-t-il utile?
 Quel problème sera-t-il résolu en travaillant avec lui ?
 Quelles capacités doit-il avoir ?
Assez souvent, vous ne pourrez pas identifier toutes les exigences en
interrogeant les clients. Il se peut que les clients ne soient pas assez informés
pour connaître les exigences de façon complète et correcte à 100%. Dans un
projet normal, il vous suffira d’ajouter le reste des exigences en utilisant le
processus de modification du contenu. Mais quand il s’agit d’un projet de
sélection de fournisseur(s), il faut tout faire pour arriver à recueillir les
exigences correctes le concernant autant que possible dès la première fois. La
découverte d’exigences manquantes, après avoir effectué la sélection du
fournisseur, aura toutes les chances d’arriver trop tard.
Chaque exigence devrait être évaluée à l’aide d’une échelle numérique, ou en
utilisant les qualificatifs grande/moyenne/faible, ce qui permet de refléter son
importance relative par rapport aux autres (vous pourriez aussi utiliser
d’autres échelles, bien sûr). Votre commanditaire et vos parties prenantes
devront aussi examiner et approuver cette liste exhaustive d'exigences
relatives aux fournisseurs et la méthode de pondération utilisée.
En plus des exigences commerciales, d'autres caractéristiques pourraient vous
431
intéresser chez le fournisseur.
 L'ensemble des coûts ou le coût du cycle de vie
 Capacité technique
 Management et approche du management de projet
 Approche technique
 Capacité financière
 Capacité de production et intérêt
 Taille et type de l'entreprise
 Références
 Droits de propriété intellectuelle
 Droits de propriété
 Plus
Procéder aux approvisionnements (10.1. P3)
2 Chef de projet Établir la liste longue des fournisseurs

Après avoir rassemblé les exigences, il est temps de chercher tous les
fournisseurs qui seraient à même de répondre à vos besoins. Cela peut se
faire à travers des recherches sur le web, en parcourant des magazines
commerciaux, en consultant d’autres entreprises, etc. Le but de cette étape
est d’établir une liste complète (sans devoir être exhaustive) des fournisseurs,
que vous voudriez étudier davantage. Cette étape vous aide à vous assurer
qu’il n’y aucun candidat potentiel qui échappe à votre attention.
3 Chef de projet Créer la liste courte des fournisseurs

Effectuez une évaluation initiale globale de la liste longue, en essayant de
trouver quelques raisons évidentes pour éliminer quelques uns des candidats.
Par exemple, il se pourrait que certains des fournisseurs soient introduits sur
le marché depuis peu ou bien de toute évidence, trop chers. Le but de cette
étape est de créer une liste courte de fournisseurs potentiels qui semblent
avoir une chance raisonnable de pouvoir répondre à vos besoins. Votre appel
d’offres devra être envoyé aux fournisseurs potentiels qui se trouvent sur
cette liste. (Si la liste longue n’est pas trop longue, vous pourriez envoyer
l’appel d’offres à tous les fournisseurs. Cependant, il est toujours important de
réduire la liste jusqu’à ce qu’elle soit assez courte pour que vous puissiez
effectivement les comparer et les confronter, au cours de votre sélection
finale).
4 Chef de projet Évaluer la liste courte des fournisseurs

C’est parfois la partie la plus dure de la sélection des fournisseurs. Vous devez
établir l’état des capacités des fournisseurs et les confronter avec vos
exigences et aux facteurs de pondération, afin de déterminer quel fournisseur
a la meilleure chance de répondre à vos besoins. Vous pourriez aussi conduire
des interviews avec les fournisseurs, visiter leur site, etc. Normalement, on
emploie une sorte de calcul numérique pour déterminer un score pour chaque
fournisseur, basé sur le degré de réponse à chacune de vos exigences,
multiplié par le facteur de pondération choisi. Le fournisseur qui a le score le
plus élevé pour l’ensemble des exigences, devrait être celui qui aurait la
meilleure chance de répondre à vos besoins. Lorsque vous avez complété
432
cette étape, vous devriez avoir une liste, établie par ordre de priorité, de
fournisseurs qui répondent le mieux à vos besoins.
5 Chef de projet Faire la sélection finale et négocier le contrat

Dans de nombreuses organisations, l’équipe de projet fait les
recommandations finales, puis elle renvoie le processus à la division officielle
des achats ou des approvisionnements. En fait, à ce stade, vous devriez avoir
toutes les informations requises pour faire le choix. S’il s’agit seulement de
sélectionner le meilleur fournisseur, vous devriez avoir les résultats de votre
calcul numérique et être en mesure de faire votre recommandation. Si vous
devez sélectionner un certain nombre de fournisseurs potentiels, vous pouvez
choisir les fournisseurs que vous estimez nécessaires pour répondre à vos
besoins.
Lorsque la sélection finale a été effectuée, il faudra encore négocier un
contrat ou une licence. Si ce processus ne se déroule pas de manière
satisfaisante, vous devriez être préparé à descendre plus bas dans votre liste,
pour essayer votre second, puis votre troisième choix, et ainsi de suite,
jusqu‘à ce que vous rencontriez les fournisseurs qui répondent à vos
exigences minimales.
La donnée de sortie finale d'une négociation de contrat est un contrat. Vous
pouvez trouver plus d'informations sur les types de contrats dans la section
Choisissez les types de contrats adéquats à votre projet (1.2. P10).
Administration des contrats (10.1. P4)
6 Chef de projet Examiner la situation de vos contrats avec les fournisseurs

L'administration du contrat est un processus qui assure que le fournisseur
respecte ses obligations contractuelles. Le chef de projet et l’administrateur
du contrat doivent travailler ensemble pour assurer que le fournisseur
respectent ses obligations. Si le fournisseur ne remplit pas ses obligations
contractuelles, des recours légaux pourraient alors être poursuivis à la fin.
Vous devez confirmer que tout est sur les rails en ce qui concerne les biens et
services (équipements informatiques, logiciels, autres équipements et
fournitures) fournis par des tiers. C'est tout juste une façon de vous assurer
que vos fournisseurs sont toujours en mesure de vous livrer les biens et les
services requis conformément à l’échéancier convenu avec eux. Il est possible
que le chef de projet et le comptable du fournisseur travaillent ensemble au
jour le jour, mais ils doivent se rendre compte qu’il est toujours nécessaire de
travailler selon les règles de la relation contractuelle. Cela signifie que lorsqu’il
y a besoin d’une modification quelconque dans la relation contractuelle, ce
sont probablement le service juridique et le service des achats qui sont
responsables d’effectuer cette modification du contrat. Si vous avez sous-
traité un composant de votre projet à un fournisseur, vous devez toujours
continuer à gérer le travail concédé au sous-traitant afin d’éviter les surprises.
Voir 10.1.3 Gérer les projets impartis.
433
10.1.1 Créer le plan de management des approvisionnements
Le plan de management des approvisionnements décrit comment vont être approvisionnés les articles
nécessaires au projet durant son cycle de vie et l'approche à utiliser pour gérer les fournisseurs du
projet. Les éléments suivants font partie des domaines à inclure dans ce plan:
 Processus d'approvisionnement. Cette section fournit un bref aperçu d'un processus de

gestion des approvisionnements. Le processus devrait inclure les éléments suivants:
o Démarrer une demande de fourniture
o Élaboration des exigences (techniques, de délais, de qualité, contraintes)
o Approbation de la demande
o Entité chargée d'effectuer l'achat
o Les offres / traitement des offres
o Responsabilités pour la gestion de contrats
o Exigences pour la clôture administrative d'un contrat
o Diagramme de flux du processus de gestion des approvisionnements
 Rôles et responsabilités. Cette section décrit les différents rôles dans le projet qui ont une
certaine liaison avec l'approvisionnement. Cette section devrait décrire celui qui peut demander
des ressources extérieures, qui peut approuver les demandes, l'intervention de certains
approbateurs supplémentaires si besoin, etc.
 Les besoins identifiés de l'approvisionnement. Cette section détaille les produits ou

services identifiés pour l'approvisionnement extérieur. Si un article peut être acheté ou produit
à l'intérieur de la compagnie, mais qu'on demande de l'acheter à l'extérieur, cet article devrait
inclure un énoncé expliquant la raison pour laquelle l'approvisionnement de l'extérieur est
demandé (justificatif pour la décision sur les options "acheter" contre "produire").
 Délais. Cette section informe sur les délais pour l'approvisionnement des marchandises
nécessaires. Ces informations aideront à démarrer à temps le processus d'achat pour chaque
article.
 Coûts. L'analyse fabriquer - ou - acheter doit prendre en considération les coûts directs et les
coûts indirects des approvisionnements éventuels. Dans ce cadre, les coûts indirects d'un achat
externe peuvent aussi inclure les le coût du contrôle et de la supervision de la procédure
d'achat
 Les processus à suivre par le fournisseur. Cette section décrit les processus que les
fournisseurs devraient suivre lors de leurs approvisionnements pour le projet, par exemple les
fiches de contrôle du temps de travail, de traitement de factures, de renégociation de contrat,
du rapport d'avancement des travaux, du traitement des demandes de modification du
contenu, etc.
434
10.1.2 Évaluer les options fabriquer vs. acheter
Décider de fabriquer ou d'acheter un produit est une décision clé qui

doit être prise au préalable et qui va influencer tout le dossier
commercial du projet, ainsi que l'approche sous-jacente de
l'exécution du projet. Dans certains cas, il est plus rentable d'acheter
alors que dans d'autres cas il serait plus logique de créer une solution
interne.
Voici deux situations dans lesquelles les décisions du genre Fabriquer
vs. Acheter sont normalement prises.
Décider de fabriquer ou d'acheter un produit est une décision clé qui doit être prise au préalable et qui
va influencer tout le dossier commercial du projet, ainsi que l'approche sous-jacente de l'exécution du
projet. Dans certains cas, il est plus rentable d'acheter alors que dans d'autres cas il serait plus logique
de créer une solution interne.
Voici deux situations dans lesquelles les décisions du genre Fabriquer vs. Acheter sont normalement
prises.
 Au préalable dans les processus de planification. Dans plusieurs projets (peut être la
plupart) vous pouvez décider au préalable quels sont les articles que vous avez et lesquels vous
allez acheter. L'analyse fabriquer - ou - acheter devrait être effectuée dans la définition initiale
du contenu afin de déterminer si le projet entier devrait être achevé par des moyens internes
ou s'il doit être procuré. Pendant la progression du projet des décisions supplémentaires de
type fabriquer- ou- acheter sont nécessaires.
 Après que les exigences commerciales soient au point. Dans plusieurs cas, vous pouvez
ne pas être sûr des détails ou de ce que vous devez créer jusqu'à ce que les exigences
commerciales soient achevées. A ce moment la vous pouvez estimer le coût de la création de la
solution et vous pouvez envoyer un Appel à proposition aux fournisseurs pour qu'ils puissent
estimer le temps qui leur faudra pour la créer. Vous pouvez par la suite prendre une décision
sur ce qui devrait être créé et sur ce qui devrait être acheté.
D'autres facteurs entrent en jeu en plus du coût de construction et d'achat. La stratégie à long
terme de l'organisation du client est aussi un composant de l'analyse fabriquer- ou- acheter.
Faire le point sur l'analyse fabriquer- ou- acheter peut aussi comprendre les éléments suivants :
Les raisons pour fabriquer Les raisons pour acheter

Moins coûteuses Moins coûteuses
Les compétences internes ne sont pas disponibles ou
Utiliser des compétences internes
n'existent pas
Maîtrise du travail Un petit volume de travail
Maîtrise de la propriété intellectuelle Plus efficace
Apprendre de nouvelles compétences Déplacer les risques
Personnel disponible Fournisseur disponible
Permettre à l'équipe du projet de focaliser sur d'autres
Focaliser sur le cœur du travail du projet
éléments du travail
La décision fabriquer- ou- acheter ne doit pas être une décision du genre tout ou rien. Il existe
plusieurs options pour créer des choses à l'intérieur et acheter d'autres.
 Se procurer tout ou pratiquement tous les produits et services d'un ou de plusieurs fournisseurs
435
 Se procurer une portion significative de produits et de services d'un ou de plusieurs
fournisseurs
 Se Procurer une portion relativement petite de produits et de services de sources extérieures

(un/plusieurs fournisseurs)
 Fabriquer tout à l'intérieur; ne rien se procurer de l'extérieur
Dans certains cas, vous pourriez également devoir choisir entre acheter ou louer un produit. Ce n'est
probablement pas une décision à prendre concernant les produits finaux ou les services, cependant cela
peut être applicable pour l'équipement, les installations, les approvisionnements et d'autres produits et
services dont votre projet a besoin. Par exemple, vous pourriez avoir besoin d’un équipement
personnalisé pour votre projet. Vous pourriez soit acheter l'équipement soit le louer. Vous pouvez
décider comment mieux obtenir l'équipement. Louer coûte habituellement moins cher mais
naturellement vous n’allez pas en devenir propriétaire. Dans certains cas cela pourrait être une bonne
chose et dans d'autres cas cela pourrait être un inconvénient.
Vous pourriez prendre cette décision d'une manière similaire à celle lorsque vous avez à prendre une
décision du genre fabriquer-ou-acheter. En partie la réponse se résume au coût d'achat et le coût de
location au cours du projet. Il y aura d'autres facteurs, y compris si vous serez en mesure de profiter du
produit à long terme, si le soutien pour le produit va être une distraction: l'impôt et amortissements,
etc.
436
10.1.3 Gérer les projets impartis
(10.1.3. P1)
La sous-traitance du travail d'un projet est plus populaire que jamais. Cependant, la sous-traitance du
travail ne signifie pas que vous pouvez complètement sous-traiter la responsabilité de vous assurer que
le projet avance sans à-coups. Si tout va bien chez le sous-traitant, vous n’aurez pas trop de soucis à
vous faire. Malheureusement, il y a aussi bon nombre de cas où les performances du fournisseur, à qui
vous avez confié un lot de travail, ne répondent pas aux attentes. Si cela se produit, vous aimeriez être
mis au courant aussitôt que possible. Supposons donc, pour illustrer le propos de cette discussion, que
votre entreprise ait sous-traité un projet ou une partie d’un projet et qu’elle vous ait aussi demandé de
gérer la relation pour vous assurer que les performances du fournisseur sont conformes aux attentes.
Beaucoup de gens hésitent sur la démarche à suivre lorsqu'il leur est demandé de gérer une relation de
sous-traitance. Cette incertitude s’explique en partie, par le fait que certains rôles joués par le projet se
trouvent inversés au moment où un lot de travail est confié à une tierce partie. Dans un projet interne
normal, c’est le chef de projet qui doit assigner le travail, gérer les problèmes, le contenu, les risques,
la qualité, etc. C’est lui aussi qui s’assure que le travail est effectué à temps, et qu’il progresse d’une
manière convenable. C’est encore lui qui est tenu pour responsable de la réussite du projet. D’autres
personnes s'occupent d’assurance-qualité et garantissent que le projet avance comme il se doit. Cette
fonction peut être assumée par un groupe formel d’assurance-qualité, mais dans la plupart des cas, ce
sont le commanditaire et le supérieur du chef de projet qui remplissent cette fonction. Leur intérêt ne
porte pas tellement sur les détails de ce qui est en train de se produire, mais sur leur besoin de poser
les questions qui leur permettent de se sentir à l'aise, parce qu'ils savent que tout progresse
convenablement.
Dans un projet imparti, les fonctions sont toujours là, mais elles sont remplies par d’autres personnes.
S’il s’agit d’une véritable sous-traitance de travail, c'est le chef de projet du fournisseur qui s’occupe des
détails. C'est lui qui planifiera et assignera le travail, qui gèrera les problèmes, le contenu, les risques,
etc. Dans cette situation, si vous êtes invité officiellement à « gérer » le projet sous-traité, ce qui vous
est demandé, en fait, c’est de jouer le rôle d’assurance-qualité. Ce que vous devez faire, c’est poser les
bonnes questions, pour vous assurer que le chef de projet du fournisseur fait son travail correctement.
Vous n'avez pas nécessairement besoin de connaître tous les détails sur sa façon de gérer et d'exécuter
le projet, mais vous devez vous sentir rassuré sur le fait que le projet est en train d’avancer comme
convenu.
Ce qu'il faut chercher au début (10.1.3. P2)
En premier lieu, il faut chercher les livrables, que vous espérez disponibles, de tous les projets
antérieurs. Par exemple, y a-t-il un document de charte de projet ? Assurez-vous que le projet soit
défini de façon correcte et satisfaisante pour vous. Si c’est le cas, approuvez ce document. Le vendeur
doit aussi avoir un échéancier de projet. Alors que le projet avance, vous devez être attentif aux dates
des principaux jalons du projet, et il doit y avoir un contrôle formel pour vous assurer que les livrables
qui ont été produits jusque-là sont complets, corrects et ont été fournis dans les délais. Vous et votre
commanditaire devez alors approuver formellement les jalons importants. Si le fait d’atteinte un jalon
implique un paiement partiel, vous devez vous assurer que les critères pour effectuer ce paiement sont
bien définis et qu’ils sont, en fait, réunis. Selon la nature du projet, vous pouvez avoir besoin de
réunions régulières pour évaluer la situation et de rapports d’avancement formels. Voici une liste de
questions que vous pouvez poser au début d’un projet :
 Une charte de projet (ou bien un document similaire) a-t-elle été approuvée par les managers
de votre compagnie et les parties prenantes appropriées?
 Y a-t-il un accord contractuel qui énonce en détail les attentes et les exigences des deux parties
en termes de livrables à produire, d’échéances, de programme de paiement, de critères
d'acceptation, etc.?
437
 Un échéancier du projet, détaillé et clair, a-t-il été établi?
 Quel plan de management de projet le vendeur utilisera-t-il pour contrôler le projet ?
 Le vendeur a-t-il clairement indiqué quelles personnes provenant de votre entreprise seront
nécessaires et quand le seront-elles?
 Y a-t-il un accord sur un nombre de jalons de projet établis pour examiner l'état d’avancement
et valider que le projet est sur les rails pour être achevé?
Questions permanentes (10.1.3. P3)
Au fur et à mesure que le projet progresse, vous devez continuer à vous poser les questions qui vous
permettront de déterminer l’état courant du travail. En dehors des réunions d’avancement que vous
pouvez tenir chaque semaine, il devrait y avoir un examen d’assurance qualité à la fin de chaque jalon
convenu. Nous vous présentons ici quelques exemples de questions que vous pouvez poser, entre
autres, à l’occasion de chaque jalon :
 Les livrables spécifiés dans la charte du projet ont-ils été réalisés à ce stade?
 Les livrables appropriés ont-ils reçu l’accord et l’approbation officielle de votre entreprise?
 Si le vendeur a réussi à répondre aux attentes jusque-là, des paiements intermédiaires ont-ils
été effectués?
 Le vendeur est-il capable d’expliquer clairement où le projet se trouve par rapport à où il

devrait être à ce moment-là ?
 Tous les futurs livrables spécifiés dans la charte du projet seront-ils achevés?
 Les problèmes majeurs, le contenu et les risques du projet sont-ils gérés conformément au plan
de management du projet?
 Est-il nécessaire de mettre à jour le contrat ou la charte du projet afin de pouvoir apporter des
modifications importantes à ce dernier ?
Lorsque vous avez une bonne compréhension de votre rôle dans le projet, il devient beaucoup plus
facile de poser les bonnes questions pour vous assurer que tout se déroule comme il se doit. Pour une
liste de questions plus complète, référez-vous au modèle « Check-list d’assurance qualité pour les
projets impartis » dans La Bibliothèque de Modèles.
438
10.2 Gérer les approvisionnements / Techniques
Choisissez les types de contrats adéquats pour votre projet (10.2. P1)
Il existe plusieurs types de contrats standards pour guider la relation entre les acheteurs et les
vendeurs. Il existe aussi plusieurs variantes de ces types de contrat de base. Ces types de contrats sont
classés en fonction de la quantité de risque que chaque partie s'engage à assumer. L'objectif de
l'acheteur est de placer un maximum de risque d'exécution du côté du vendeur, tout en maintenant des
incitations d'ordre économique et une exécution efficace. L'objectif du vendeur est de minimiser les
risques et maximiser le bénéfice potentiel. Les trois grandes catégories de contrats sont les Contrats à
coûts remboursables, les contrats à prix fixes et les contrats pièces et main d'œuvre.
Contrats à coûts remboursables (10.2. P2)
Selon ce type de contrat, le vendeur est payé pour le produit. Lors du payement, le vendeur jouit d'une
marge de bénéfice représentée par la différence entre les coûts réels du produit et le montant des
ventes. Les coûts actuels du produit se divisent en deux catégories:
 Coûts directs – Ces coûts sont ceux encourus par le projet pour assurer l'existence de ce
dernier. Exemples: la fourniture nécessaire pour achever le travail du projet, les salaires de
l'équipe du projet, ainsi que d'autres frais liés directement à l'existence du projet.
 Coûts indirects – Ces coûts sont ceux qui résultent de l'activité commerciale. Exemples: les
services, les espaces de bureaux, et d'autres frais généraux.
L'exemple suivant montre le modèle général des contrats à coûts remboursables.
Exemple de contrat en régie à intéressement (CPIF)
Coût réel + Rémunération cible + ((Coût cible - Coût réel) * Proportion de partage)
Coût cible 100.000 €
Rémunération cible 10.000 €
Proportion de partage 80/20
Coût réel 80.000 €
Le vendeur reçoit 94.000 € calculés comme suit:
80.000 € + 10.000 € + ((100.000 € - 80.000 €) * 20%)
Il existe plusieurs variétés de ce contrat type y compris:
 Contrat en régie avec honoraires fixes (CPFF = Cost Plus Fixed Fee). Un contrat CPFF
autorise le remboursement des coûts autorisés, plus des frais fixes proportionnellement payés
selon la progression du contrat. Bien qu'il y ait un plafond pour le bénéfice du vendeur, rien ne
motive le contrôle des coûts, de manière à ce que la majeure partie du risque reste avec
l'acheteur. Ce type de contrat est surtout utilisé pour la recherche et pour les projets de
développement là ou l'effort exigé reste incertain jusqu'à ce que le projet soit sur le bon
chemin.
 Contrat en régie au pourcentage des coûts (CPPC = Cost Plus Percentage of Cost)). Un
contrat CPPC permet le remboursement des coûts autorisés du service exécuté, en plus d'un
pourcentage convenu des coûts en tant que bénéfice. Le vendeur est obligé de fournir tous ses
efforts pour exécuter les clauses du contrat dans le cadre du montant estimé; l'acheteur
finance tous les dépassements du coût estimé. Ce type de contrat est interdit aux États Unis
quant aux contrats fédéraux; cependant, il est rarement utilisé dans le secteur commercial.
439
 Contrat en régie à intéressement (CPIF = Cost Plus Incentive Fee). Un contrat CPIF permet
le remboursement des coûts autorisés plus des frais prédéterminés en tant que bonus pour une
performance supplémentaire. Si le coût réel est inférieur au coût attendu, l'acheteur et le
vendeur partagent l'épargne en se basant sur une formule prédéterminée. Ce type est surtout
utilisé pour les contrats qui nécessitent de longues périodes d'exécution et un développement
d'équipement substantiel et pour les exigences de l'évaluation.
Les contrats à prix fixe (PF) (10.2. P3)
Il s'agit de la forme de contrat la plus commune. Elle est appropriée lorsque l'acheteur est capable de
décrire le contenu du travail. Ces contrats peuvent aussi inclure des incitations de réunion ou de
dépassement des objectifs du projet. Lorsque les incitations sont présentes, elles comprennent aussi un
prix plafond. Ce type de contrat représente le moindre risque pour l'acheteur.
 Prix forfaitaire (FFP = Firm Fixed Price). Un contrat FFP est un contrat forfaitaire selon lequel
le vendeur fournit la marchandise ou les services à un prix fixe. Le vendeur supporte tous les
risques, mais en contre partie des meilleurs bénéfices. Il s'agit du contrat type le plus commun.
Il convient principalement aux situations ou les cahiers des charges sont bien déterminés ainsi
que certain coûts.
 Contrat à prix fixe avec intéressement (FPIF = Fixed Price Incentive Fee). Un contrat FPIF
fournit au vendeur un prix fixe plus des frais prédéterminés en tant que bonus pour une
performance supplémentaire. L'acheteur ainsi que le vendeur partagent les risques. Ce type de
contrat est essentiellement utilisé pour les projets d'une grande valeur, ceux qui nécessitent de
longues périodes d'exécution, comme par exemple pour les projets de construction de bateaux
et pour les projets de développement de systèmes importants.
L'exemple suivant montre le modèle général pour les contrats à coûts remboursables.
Coût réel + Rémunération cible + ((Coût cible - Coût réel) * Proportion de partage))
Coût cible 125.000 €
Prix cible 150.000 €
Rémunération cible 25.000 €
Plafond de Prix 175.000 €
Proportion de partage 80/20
Coût réel 100.000 €
Le vendeur reçoit 130.000 € calculés comme suit
100.000 € + 25.000 € + ((125.000 € - 100.000 €) * 20%)
Maintenant, nous allons reprendre le même exemple avec un coût réel de 175.000 € :
175.000 € + 25.000 € + ((125.000 € - 175.000 €) * 20%)
200.000 € + (-50.000 € * 20%) = 190.000 € ?
Le Plafond de Prix est maintenant un facteur à cause des dépassements de coût dans le Coût réel.
L'acheteur est seulement obligé de payer le prix plafond convenu qui s'élève à 175.000 €.
Temps et équipement (T&M) (10.2. P4)
Il s'agit d'une combinaison entre les contrats à coûts remboursables et les contrats à prix fixes. Cela
concerne souvent le travail du projet qui n'a pas de date de fin précise (variable) mais le prix est
unitaire (heure ou unité). Le coût total est inconnu et il varie selon la durée et/ ou le matériel.
440
Les risques du contrat (10.2. P5)
Le diagramme suivant décrit le niveau de risque pour les acheteurs et pour le vendeur et ce pour
chaque type de contrat.
Énoncé contractuel des travaux (10.2. P6)
Dans plusieurs cas, vous pouvez ne pas avoir d'idée sur le travail jusqu'à ce que l'exécution du travail
soit imminente. Dans ces cas, il est courant d'établir un contrat principal entre le client et le vendeur, et
ensuite créer un énoncé du travail pour décrire tout le travail actuel et les livrables qu'il faut achever. Il
doit également décrire comment le produit du projet ou le service serait soutenu. L'énoncé du travail
devient alors une partie du contrat entre l'acheteur et le vendeur.
Seuil d’absorption totale (10.2. P7)
Le prix déterminé par un Contrat à prix fixe avec intéressement (FPIF) dans lequel le vendeur supporte
tous les préjudices d'un dépassement de coût. Du moment où les coûts atteignent le Point of Total
Assumption, le Plafond de Prix convenu est le montant maximal que l'acheteur va payer. Ceci est la
partie prix dans le contrat cité au dessus selon lequel le vendeur assume la responsabilité de tous les
coûts supplémentaires.
Incitations contractuelles (10.2. P8)
Les incitations contractuelles fournissent " une carotte " pour le contractant afin d'essayer d'ajuster les
objectifs et les intérêts du contractant à ceux de l'acheteur. L'expérience a démontré que ces incitations
contractuelles sont souvent nécessaires pour assurer l'efficacité des coûts. Les incitations peuvent être
structurées de plusieurs manières. Elles sont flexibles et peuvent être utilisées avec tout type de
contrat.
Éléments d'un contrat légalement mis en vigueur (10.2. P9)
Chacun des deux parties doit fournir son consentement et une contrepartie (condition de la validité du
contrat), les parties contractantes doivent jouir de la capacité légale de conclure des contrats, le contrat
doit avoir un objet légal, et le contrat ne doit pas porter atteinte à l'ordre public.
441
Pour qu'un contrat soit valide, il doit:
 Contenir une offre

 Avoir été accepté
 Stipuler une contrepartie (payement)
 Avoir un but légal
 Être exécuté par par une personne ayant une capacité et une autorité
Clauses typiques dans un contrat (10.2. P10)
Les termes et les conditions du contrat doivent définir les aspects de l'engagement tels que:
 L'échéancier de la livraison
 L'échéancier du payement
 Une méthode pour déterminer le prix
 La manipulation des modifications
 Les garanties
 L'assurance
 Inspections
 Les retards
 La résiliation
 Les sous-contrats
 Garanties de bonne fin
 Les résultats de l'administration du contrat
 Les demandes de paiements et les échéanciers
 La correspondance
 Les modifications demandées
 Les évaluations de la Performance
 Les clauses standards. L'utilisation des clauses standards est encouragée chaque fois que cela
est possible parce qu'elles sont légalement valides pour la plupart des situations contractuelles
et parce qu'elles reviennent moins chères (un contrat fait sur commande prend beaucoup de
temps et parfois son élaboration peut s'avérer coûteuse).
o Les modifications apportées au contrat
 Maîtrise des modifications
 Qui lance une demande de modification
 Comment les modifications sont financées
 Autorité finale d'approbation
 Maîtrise de la configuration
o Les garanties
 Établir un niveau de qualité
 Garantie explicite- le contrat stipule explicitement le niveau de la qualité requis
 Garantie tacite - le contrat décrit “la valeur marchande” ou “justesse de
l'utilisation”
o La clause dérogatoire. La renonciation par une partie à ses droits contractuels à cause
de la non application de ces droits
o Retards. Décrire ce qui va arriver en se basant sur
 Qui l'a causé
442
 La nature de l'interruption
 L'impact
 Cautions de bonne exécution - assure à l'acheteur l'exécution et
l'accomplissement du contrat
 Garantie de payement - garantit le payement aux sous contractants et aux
ouvriers grâce à la prime ou la caution
o Rupture du contrat
 La non exécution d'une obligation contractuelle
 La mesure du dommage s'estime par la valeur des dégâts que la partie lésée a
subis
 Rupture matérielle - plus grave que la rupture d'un contrat. La partie non
fautive est déchargée de toute obligation ultérieure —par exemple, lorsqu'un
contrat stipule que le temps est une condition existentielle, la non exécution
dans les limites du temps assigné représente une rupture matérielle du contrat
et le chef de projet ne sera pas obligé d'accepter une exécution tardive
Les contrats exclusifs (10.2. P11)
Assurer un climat de concurrence parmi les contractants potentiels chaque fois que cela est possible est
généralement une bonne chose. Il existe un nombre considérable de documents qui démontrent les
avantages de la concurrence. Cependant, il est logique de permettre la sélection de contractants non
concurrents et ce sous certaines conditions y compris les suivantes:
 Lorsqu'un contractant dispose d'une qualification unique qui ne peut pas être trouvée ou
atteinte ailleurs
 Lorsque d'autres mécanismes existent pour assurer que le prix que vous avez payé est
raisonnable. Par exemple, vous pouvez effectuer une expertise interne pour évaluer l'offre du
contractant d'une manière appropriée et ce concernant son degré de précision et de conformité
aux critères raisonnables
 Lorsque votre projet est sous une extrême pression de délais, une sélection d'une source de
sélection prend plus de temps, parce que devez consacrer du temps pour préparer votre
document de sollicitation, pour envoyer et recevoir la sollicitation, pour les contractants
potentiels afin qu'ils puissent préparer et soumettre une proposition, et du temps pour vous
pour les évaluer tous et faire un choix
Le processus de négociation du contrat est une activité qui vise à créer un juste prix en contre partie du
travail que doit accomplir le vendeur. L'organisation de l'exécution crée une offre et l'envoie au
vendeur. Ce dernier considère alors cette offre. L'organisation de l'exécution et le vendeur doivent se
mettre d'accord sur les attentes, les exigences, les pouvoirs, les termes, les approches techniques et
commerciales du management, le prix et tous les autres facteurs pertinents relatifs au contrat et ce
avant de signer le contrat. Le contrat final peut être une offre révisée par le vendeur ou une contre
offre par l'acheteur.
Connexité contractuelle (10.2. P12)
Selon la Connexité des contrats, la relation contractuelle existe entre l'acheteur et son contractant
principal. Aucun contrat n'existe entre l'acheteur et les sous contractants, et il est considéré comme
illégal le fait que l'acheteur dépasse le contractant et traite directement avec un ou plusieurs sous
contractant (s).
A part le côté juridique, il existe d'autres raisons face aux quelles un acheteur devrait être vigilent en
traitant avec les sous contractants. L'acheteur pourrait, par mégarde, décharger le contractant principal
de certaines responsabilités. Par exemple, si un acheteur informe un sous contractant que les choses
pourraient être mieux si le sous contractant "essaierait l'approche suivante..." et si le sous contractant
443
rencontre des problèmes, le contractant principal aurait le droit d'accuser l'acheteur d'avoir causé ces
problèmes par son interférence.
444
10.3 Gérer les approvisionnements / Références rapides
Livrables (10.3. P1)
ayant une licence.)
 Plan de gestion des approvisionnements
 Demande d‘information
 Appel d'offres, appel à propositions
 Contrats
 Énoncé des travaux
Activités de l'échéancier (10.3. P2)
Les activités de sélection des fournisseurs ne sont ni répétitives ni continuelles au cours d'un projet. Ces
activités ne sont exécutées que lorsque la sélection des fournisseurs est nécessaire. Les heures peuvent
varier considérablement en fonction du coût, de l'implication et de l'impact de la sélection des
fournisseurs.
Rassembler et classer les

besoins d’affaire.
Ces activités sont effectuées au début du
Établir les critères de ouvert
processus.
sélection des
fournisseurs.
Petits Établir la liste longue des Ceci vous assure d'avoir identifié plusieurs
ouvert
projets, fournisseurs fournisseurs potentiels qualifiés.
projets
moyens et Il s'agit d'éliminer les fournisseurs potentiels les
Créer la liste courte des
grands ouvert moins qualifiés. Distribuer l'appel d'offres
fournisseurs
auprès d'un group restreint de candidats.
Évaluer les propositions des fournisseurs

Évaluer la liste courte
ouvert potentiels face aux besoins d'affaire et les
des fournisseurs
critères de sélection établis.
Faire la sélection finale et Sélectionner le fournisseur le plus approprié et

ouvert
négocier le contrat négocier le contrat.
445
_____________________________________________________________________
Clore le projet
446
90.0 Clore le projet
(90.0 P1)
De même que le démarrage officiel du projet est important, il importe de clore le projet avec succès.
L’importance d’une fin de projet planifiée réside dans le fait qu’elle met en valeur toute l’information et
l’expérience recueillies au cours du projet. Si l’équipe se disperse dès que la solution est mise en
œuvre, vous n’avez pas l’opportunité de boucler les derniers détails, d’évaluer le staff, de documenter
les principales leçons apprises, ni de vous assurer que les livrables ont été transmis à l’organisation
chargée du support de la solution fournie par le projet. Bien sûr, un projet peut aussi prendre fin sans
parvenir à un succès. Même dans ce cas, il y a d'importantes leçons à retenir, une équipe à évaluer, des
activités à effectuer pour exposer l’essentiel de ce qui a été accompli au cours du projet.
Quand l’échéancier du projet est élaboré, pensez aux activités qui doivent être mises en œuvre afin de
mener à terme le projet avec éclat et de façon appropriée. Ces activités incluront:
 La tenue d’une réunion de clôture du projet. Une réunion devra être tenue avec l’équipe
du projet, le commanditaire et les parties prenantes appropriées pour clôturer formellement le
projet. Cette réunion devra inclure un récapitulatif du projet et documenter les aspects qui se
sont biens déroulés et à ceux qui ont mal tourné ainsi que les forces et les faiblesses du projet
et de ses processus de management, de même que les étapes à accomplir pour mener le projet
à terme. Les techniques ou processus qui ont particulièrement bien ou mal fonctionné, seront
identifiés comme apprentissages clés du projet. Si votre entreprise peut publier ou mettre en
valeur ces apprentissages clés, elle doit les envoyer au groupe approprié. (Les principales
leçons apprises qui semblent pouvoir fonctionner uniformément sur beaucoup de projets, dans
de nombreuses circonstances, peuvent être élevés au rang de meilleures pratiques et être
utilisés sur tous les projets semblables).
L’ordre du jour de la réunion de conclusion se concentrera sur ce que le projet était sensé
accomplir, et ce qu’il a réellement accompli. La discussion devrait déboucher sur un ensemble
de leçons clés décrivant ce qui a bien marché et ce qui n’a pas fonctionné. L'ordre du jour
devrait être le suivant :
o Discuter l'objet de la réunion
o Développer des règles de base (facultatif)
o Arrêter la liste ce que le projet aurait du réaliser
o Décrire ce que le projet a effectivement réalisé
o Discuter le « pourquoi » de toutes les anomalies entre les « aurait du faire » et les « a
réellement effectué »
o Convenir d’un ensemble de leçons à retenir pour de futurs projets
o Établir la liste de tout travail qui reste à accomplir pour clôturer le projet. Ceci inclut
des activités comme celles décrites ci-dessous :
 Déclarer la réussite ou l'échec du projet. Il est parfois évident qu'un projet est un succès
total; dans d'autres cas, le projet est un échec total. Cependant, dans de nombreux cas, il y a
des résultats mitigés. Par exemple, les livrables principaux peuvent avoir été accomplis, mais
avec un dépassement de budget. Ou encore, l’équipe de projet a livré à temps et dans les
limites du budget, mais la solution ne répond qu'à 80% des exigences commerciales. La clef
pour déclarer la réussite d’un projet est la définition préalable des critères de réussite. Si un
accord est conclu avec le commanditaire et le manager approprié sur les critères de réussite,
l’équipe de projet pourra être évaluée selon ces critères. L’équipe de projet devra tout d’abord
s’évaluer elle-même par rapport à ces critères, puis faire valider la recommandation par le
commanditaire.
447
 Effectuer la transition de la solution vers le support (le cas échéant). Si la solution doit
exister en dehors du projet, elle doit être transférée à l’organisation de support appropriée. La
transition inclut le transfert de connaissances vers l'équipe de support, de même que
l’élaboration et la transmission de toute la documentation et la transmission de la liste du travail
restant, etc.
 Transmission des dossiers du projet (le cas échéant). Une discussion devrait avoir lieu
avec l'équipe de support pour déterminer quels matériels du projet et de gestion du projet,
accumulés au cours de sa réalisation, devraient être transmis à l'équipe de support. Suivant cet
accord, une partie du matériel du projet sera supprimée, détruite, sauvegardée ou archivée,
etc. Les dossiers et documents nécessaires à l'équipe de support devront lui être transmis afin
d’être entreposés dans la bibliothèque ou le dossier à long terme appropriés.
 Effectuer des évaluations de performance. Si le projet est substantiel, il est indiqué de

procéder à des évaluations de performance à la fin du projet. Le supérieur hiérarchique du chef
de projet et le commanditaire du projet évaluent alors le chef de projet. Le chef de projet, à
son tour, passe en revue l’intégralité de l'équipe, du moins les membres avec lesquels il est en
rapport direct (ceux-là passent ensuite en revue leurs subordonnés, jusqu'à ce que chacun soit
évalué). Parfois, l'équipe est évaluée en totalité, puis les membres de l'équipe se servent de
l'évaluation de cette dernière comme d’une indication pour l’évaluation des performances
individuelles. D'autres fois, les membres de l’équipe sont passés en revue individuellement sur
la base de leur propre contribution. Il doit y avoir certains liens, cependant, entre les
performances de l’équipe et les performances individuelles.
 Réaffecter l’équipe de projet restante. Chaque membre de l'équipe restante devra être
convoqué une nouvelle fois quand toutes les activités de fin de projet seront bouclées. Pour
certains d’entre eux, cela signifiera des projets complètement nouveaux. Pour le personnel sous
contrat, cela signifiera la fin de ce dernier. Pour des salariés à temps partiel, cela signifiera un
retour à leur activité antérieure à temps plein. Quelques membres de l'équipe peuvent être
transférés à l’équipe de support pour continuer à travailler sur la même solution.
Le chef de projet a la responsabilité d'inscrire les activités de clôture du projet dans l’échéancier du
projet. Ces activités devront être traitées comme des parties essentielles du projet, pas comme une
idée qui arrive sur le tard, quand l’équipe commence à se disperser. De même que le projet en question
ne sera pas considéré comme terminé avant la fin des activités de clôture, tant que les activités de mise
en œuvre de la solution ne sont pas terminées.
Clôturer les contrats (90.0 P2)
1 Chef de projet Clore tous les contrats

Votre projet a fait appel à l’assistance de commerçants, de fournisseurs de
matériel informatique, de logiciels, de fournitures, etc. D’une façon générale,
ces contrats spécifiques au projet doivent être clôturés, car cela fait partie de
l’achèvement du projet. Bien sûr, certains contrats dépassent le cadre de
votre projet, et ceux-là resteront ouverts. Vous pouvez avoir, par exemple,
un contrat ouvert avec un cabinet de conseil et vous pouvez avoir ouvert un
relevé de travail pour les services spécifiques rendus à votre projet. Dans ce
cas, le contrat général restera ouvert, mais le relevé de travail spécifique
devra être clôturé. Il est même probable que toutes les factures n’ont pas
été payées (ni même présentées) quand le projet s’achève officiellement.
Cependant, le chef de projet ou l’administrateur de contrats concerné sera
responsable de la clôture de ces contrats spécifiques au projet, quand les
factures en instance auront été payées.
La clôture d’un contrat implique la vérification du produit, en d’autres termes
vérifier si le travail a été effectué, et la liquidation administrative, à savoir
l'actualisation des enregistrements du contrat. Ces derniers sont vraiment
très importants et comprennent le contrat en lui-même et d’autres
documents utiles tels que les rapports d'avancement, les dossiers financiers,
448
les factures, et les enregistrements des paiements. Ces derniers sont gardés
dans un dossier du contrat, qui doit faire partie de l’ensemble du dossier du
projet. La documentation relative au contrat est importante aussi dans le cas
d’un audit d’approvisionnement. Un tel audit représente une revue structurée
du processus d’approvisionnement à partir de la planification de
l’approvisionnement jusqu’à l’administration du contrat. L’objectif de l’audit
est d’identifier le succès ainsi que l’échec justifiant le recours à d’autres
articles d’approvisionnement dans le projet actuel ou dans de futurs projets.
449
______________________________________________________________________
Redressement de projets en
danger
450
40.0 Redresser des projets qui ont des problèmes
Vous souvenez-vous d’avoir travaillé sur un projet qui a été planifié et exécuté parfaitement et où vous
avez répondu aux attentes en termes de budget, de date limite et de qualité du produit ? D’un projet
où vous vous êtes entendu de manière cordiale et professionnelle avec vos clients et où il n’y a eu
aucun problème ?
Si vous aviez eu de la chance, vous pourriez penser à un projet de ce genre, peut-être même à deux. Il
est facile d'oublier que beaucoup de projets sont menés à leur terme avec succès. Bien qu'aucun projet
ne soit absolument parfait, beaucoup de projets sont réalisés avec un minimum de problèmes et de
stress.
Beaucoup de projets sont menés à terme d’une manière satisfaisante. Cependant, la plupart des chefs
de projet ont, au moins une fois, travaillé sur des projets moins réussis. Il arrive parfois que le projet
soit, à 100%, un désastre pur. Habituellement, les résultats sont plus nuancés. Il est commun de
réaliser un projet en dépassant la date limite ou le budget. D'autres fois, il arrive que le client
n’obtienne pas tous les dispositifs et toutes les fonctionnalités qu’il avait prévus au départ. Sur certains
projets il y a tellement de frictions entre l’équipe de projet et le client que le projet laisse un mauvais
goût à chacun, même lorsque les livrables sont finalement produits.
Premièrement : le projet a-t-il vraiment des problèmes?
Quand vous examinez un projet qui semble avoir des problèmes, il faut d’abord s’assurer que c’est bien
le cas. Dans de nombreux cas, on voit des problèmes là où il n’y en a pas vraiment. Dans d'autres cas,
un projet peut avoir des problèmes, mais le chef de projet aura déjà commencé un processus de
contrôle et de correction des dommages. Parfois, le projet est en difficulté, mais les problèmes ne sont
pas suffisamment significatifs pour qu’il soit considéré en danger. Par exemple, si un projet prévu pour
une durée de neuf mois, se termine avec une semaine de retard, s’agit-il vraiment d’une difficulté ?
Aussi faut-il d’abord confirmer que vous avez réellement un problème, en déterminant si le projet est
en dessous des tolérances acceptables. Pour plus d'informations à ce sujet, voir le paragraphe 40.1
Tolérances du projet .
Il est important de s’en tenir aux tolérances fixées, lorsque le projet commence à tendre vers un
dépassement du budget ou des délais. Toutefois, ce dépassement peut être contenu dans des
marges acceptables et le projet peut alors être considéré comme n’étant pas en difficulté.
Peut-on changer rapidement le cours du projet?
Si le projet est en difficulté, mais n’a pas encore atteint le stade du désastre, voyez si vous pouvez
déterminer la cause du problème et mettre en place un plan de réponse rapide. Le chef de projet peut
déjà avoir un plan de rétablissement en réserve, ou avoir besoin d’assistance. Si les dommages sont
mineurs, le projet peut être remis sur la bonne voie, avec un peu plus d'attention et un plan proactif.
On appelle parfois ces mesures un « redressement » doux. Dans de nombreux cas, ce redressement
doux peut remettre le projet sur la bonne voie sans accroître le budget ni avoir un impact sur
l'échéancier. Les activités qui y sont associées peuvent se limiter à la mise en application d’un meilleur
processus de management de projet ou à la permutation de ressources ayant des qualifications
semblables. Si ce type de changements relativement mineurs se multiplie, une intervention plus radicale
sera requise.
Quelques problèmes courants affectant des projets et leurs solutions potentielles sont décrits dans les
paragraphes ci-dessous.
40.2 Problème #1 - Définition et planification inadéquates du projet
40.3 Problème #2 - Mauvais management du contenu
40.4 Problème #3 - Absence de gestion de l'échéancier du projet
40.5 Problème #4 - Mauvaise Communication
40.6 Problème #5 - Mauvais management de la qualité
Définir un projet en difficulté
A ce stade, vous reconnaissez que le projet est probablement en difficulté. Vous avez vérifié que le
451
projet a outrepassé toutes les tolérances définies par votre entreprise. Vous avez également fait un
contrôle rapide pour déterminer qu'il n'y a pas une cause simple aux difficultés constatées et qu’il
n’existe pas un remède susceptible d’être rapidement mis en place. Quelques critères permettent
d’identifier les projets en difficulté. En voici quelques exemples:
 Le projet tend à dépasser de plus de 30% son budget estimé
 Le projet tend à dépasser de plus de 30% sa durée estimée (bien que cela puisse ne pas être
aussi grave, si le budget n’est pas, lui aussi, dépassé de 30% ou plus).
 Le projet semble respecter les tolérances, mais seulement en raison du report de
l’accomplissement d'un ou plusieurs livrables principaux.
 Le projet semble respecter les tolérances, mais seulement en compromettant la qualité, la
valeur et l'intégrité du produit livrable.
 Le client est extrêmement déçu par la performance de l’équipe de projet. Si le client devait
refaire un projet, il n'emploierait pas la même équipe de projet.
 La relation client - équipe de projet ne fonctionne pas. Ceci peut inclure des situations où le
client et le commanditaire ont perdu tout intérêt pour la réussite ou l’échec du projet, une
animosité entre l’équipe de projet et le client, le sabotage délibéré fomenté par une partie pour
en discréditer une autre, etc.
Tous les projets devraient être financés sur la base d’une certaine valeur ajoutée à produire.
Cependant, au fur et à mesure que le projet progresse, la justification commerciale s’affaiblit. Lorsque
cela arrive, le projet doit être décommandé. Il ne s’agit cependant pas, dans ce cas, d'un projet en
difficulté : il n'y a pas nécessairement de problèmes avec le projet lui-même, et rien n’est, à
proprement parler, à préserver. Le projet peut alors être décommandé, suite à une évaluation
commerciale courante, pas en raison de difficultés.
De même, l’étude de faisabilité du projet peut avoir été défectueuse dès le départ. Le projet pourra se
terminer sur un constat de réussite, mais la valeur ajoutée ne répond pas aux attentes. Encore une fois,
un projet dans cette situation ne sera pas classé comme étant en difficulté.
Processus de rétablissement de projet
Rétablir un projet en difficulté n'est jamais facile. Néanmoins, vous pourrez appliquer des approches qui
vous donneront de bonnes chances de réussite. (Souvenez-vous que la réussite ne signifie pas
atteindre les objectifs et les engagements initiaux. Il est vraisemblablement trop tard pour cela).
Désormais, le présupposé est qu’une partie essentielle du projet est en difficulté. Vous avez outrepassé
les tolérances acceptables et un remède ne peut être mis en route facilement et simplement. Pour ces
projets en difficulté, le remède est plus qu’une simple résolution. Le modèle suivant de rétablissement
de projet peut être employé:
41.0 Définissez et planifiez le redressement du projet
42.0 Évaluez le projet en difficulté
43.0 Développez un plan de redressement
44.0 Activez le plan de redressement
45.0 Évaluez et surveillez le plan de redressement
452
40.1 Tolérances du projet
Vous avez tous lu des histoires au sujet du grand nombre de projets qui échouent. Selon les rapports
que l’on lit, on apprend que plus de la moitié - voire 80% - d’entre eux échouent! Selon ces mêmes
rapports, plus le projet est grand, plus il y a de chances qu'il échoue. Cependant, si vous considérez les
projets dans votre entreprise, diriez-vous vraiment que 80% d'entre eux sont défectueux? 50% d’entre
eux seraient-ils même considérés comme des échecs? Il n'y a aucun doute que quelques uns sont des
échecs absolus. Ils subissent des accidents, sont annulés, prennent fin nettement au-delà du budget,
de la date limite, ou en dessous des attentes. Cependant, y a-t-il vraiment 50% à 80% des projets qui
correspondent à cette définition?
Tolérances
Pour répondre à la question de savoir combien de projets ont échoué, vous devez d'abord comprendre
la définition d'un projet raté. Le concept qui joue un rôle clé, dans ce contexte, est alors celui de
tolérance. Si vous estimez qu'un projet coûtera 230.000 €, est-ce que votre projet est un échec si le
coût effectif est de 230.500 € ? Vous avez dépassé votre budget, n’est-ce pas? Oui, mais ceci entre
dans la zone de tolérance. Si vous livrez avec moins de 500 € de dépassement sur un budget de
230.000 €, l’équipe devrait vous porter sur ses épaules et vous faire faire le tour des bureaux de votre
entreprise, tellement cela relève de l’exploit.
Votre entreprise doit établir le niveau de tolérance qu’elle considère raisonnable pour ses projets. Dans
certaines entreprises, par exemple, le niveau de tolérance varie de -10% à +5.
Si vous fournissez le projet avec un dépassement de budget de 5%, il sera toujours considéré comme
une réussite. Pour notre projet de 230.000 €, cela signifie que nous pourrions avoir un dépassement de
budget allant jusqu’à 11.500 € et continuer à le considérer comme réussi.
D’autre part, si le coût final est en dessous de plus de 10% par rapport au budget, cela posera
également problème. Ici, le problème est que l’entreprise doit normalement livrer des projets qui
répondent aux attentes : si le commanditaire avait su que le projet coûterait réellement beaucoup
moins qu'estimé, il aurait pu prendre d'autres décisions concernant le budget inutilisé. L'estimation des
coûts doit être aussi précise que possible et devrait également inclure tout changement du contenu
formellement approuvé. Si votre budget original était de 200.000 € et que le client a approuvé 30.000 €
complémentaires dans le cadre des modifications du contenu, le montant final dont vous aurez la
responsabilité est de 230.000€, plus les tolérances.
Normalement, il y a également des tolérances concernant les dates limites. Si vous estimez la durée
d’un projet à six mois, et qu’il est achevé en six mois et une semaine, cela est normalement acceptable.
Votre date limite originale doit également être reportée si des modifications du contenu ont été
approuvées. Naturellement, tous les projets n’ont pas cette flexibilité. Les projets de logiciels de
passage à l’an 2000, par exemple, devaient être fins prêts pour le 31 décembre 1999. Une semaine de
retard n’aurait pas été concevable.
Déclaration de réussite dans une perspective de projet
Une fois que vous avez compris ce que sont vos tolérances (s’il y en a), vous pouvez commencer à
évaluer la réussite du projet. Généralement, les membres de l’équipe du projet peuvent déclarer la
réussite si:
1. Le projet est livré dans les limites du coût estimatif, y compris la tolérance, en plus ou en
moins.
2. Le projet a été livré avant l’expiration de sa date limite, y compris la tolérance, en plus ou en
moins.
3. Tous les livrables principaux ont été accomplis (quelques produits mineurs ou des
fonctionnalités mineures peuvent ne pas être livrés).
4. La qualité globale est acceptable. (Elle n’a pas à être parfaite.)
Quelques entreprises regardent également si le travail avec l’équipe de projet s’est bien déroulé, c'est-
à-dire si le client et l’équipe de projet ont bien travaillé ensemble, s’il y a eu une bonne communication,
par exemple. Si le client avait un autre projet (et le choix entre plusieurs entreprises), ferait-il appel à
nouveau à la même entreprise?
453
Déclaration de réussite dans une perspective d’entreprise
Du point de vue du projet, la déclaration de réussite relève normalement de la responsabilité de
l’équipe de projet. Du point de vue de l’entreprise, votre réussite est également liée à la réalisation de
la valeur ajoutée promise par les calculs initiaux de ROI. Si le projet est un échec du point de vue du
projet, c'est normalement un échec pour l’entreprise également (bien que ce ne soit pas toujours le
cas : certains projets dépassent leur budget et leur date limite, pourtant la solution est toujours
considérée globalement comme une réussite commerciale). Il y a également beaucoup d’exemples de
projets qui ont été livrés avec efficacité, et ce, sans avoir produit la valeur ajoutée attendue. Si l’équipe
de projet a bien livré les résultats dans les temps qui lui étaient impartis, il n’y a habituellement rien de
plus qu’elle puisse faire. Cependant, il est possible que les calculs de rentabilité des investissements
aient été biaisés, ou que le marché ait été mal jugé par le client et le commanditaire. Il est également
possible que ce projet ait fait partie d'une plus grande initiative. Bien que votre projet soit réussi,
l'initiative globale, plus grande, peut être un échec.
Chaque entreprise devrait suivre quelques règles générales pour déclarer la réussite ou l’échec d’un
projet dans son ensemble. Votre projet n'est pas un échec si vous dépassez le budget d’un Euro et que
vous le livrez avec un jour de retard. Normalement, un projet sera encore considéré comme réussi s'il
est mené à terme dans les tolérances de coût et de durée, et qu’il fournit les principaux livrables avec
une qualité acceptable. Dans une perspective commerciale globale, d’autres questions devraient être
posées afin de savoir si la valeur marchande réalisée correspond aux attentes.
454
40.2 Problème de projet #1: Définition et planification
inadéquate du projet
Avez-vous jamais assisté à une réunion de conclusion d’un projet qui a eu des problèmes majeurs? Si
c’est le cas, il y a de fortes chances pour qu’un des thèmes principaux ait été : « Nous aurions dû
passer plus de temps sur la planification ». Beaucoup de chefs de projet pensent qu'ils doivent plonger
directement dans le projet, en recueillant les spécifications commerciales. Ils pensent que s’ils font un
bon travail de collecte des spécifications commerciales, ils seront parés pour lancer le projet. Cela n'est
pas vrai. Une définition et un procédé de planification doivent être mis au point avant que vous ne
commenciez la collecte des spécifications d'affaires.
Avant que le projet ne soit entamé, le chef de projet doit s'assurer que le travail est correctement
compris et approuvé par le commanditaire du projet et les principales parties prenantes. Il
doit s'assurer que tout le monde comprend bien ce que le projet est censé apporter, quand il sera
accompli, ce qu’il coûtera, qui effectuera le travail, comment ce dernier sera fait et quels en seront les
avantages. Plus le projet est grand, plus il est important que les informations soient enregistrées,
formellement et explicitement. Tous les projets devraient commencer par ce type de planification en
amont, pour prévenir des problèmes éventuels, provoqués par des points de vue différents sur les
termes de base du projet.
Problèmes communs de planification
Une définition et une planification faibles entraînent des problèmes dans beaucoup de secteurs du
projet, qui surgissent souvent à un stade avancé, dont :
 Des bases commerciales faibles. Sans définition préalable des caractéristiques majeures
d'un projet, il est très courant d’avoir des attentes différentes chez les principales parties
prenantes. Cela se vérifie même si la direction initiale a été dictée par le commanditaire. Même
ce dernier peut ne pas avoir une idée claire des éléments nécessaires à la réussite du projet, au
fur et à mesure que celui-ci prend de l’envergure. Le commanditaire peut avoir une idée, mais
d'autres idées peuvent être meilleures ou plus viables. Ces idées concurrentes peuvent
apparaître plus tard dans le projet, semer la confusion et occasionner un travail de reprise.
 Les estimations faibles. Habituellement, un projet doit avoir un budget et une date limite
avant que les spécifications commerciales ne soient établies. Dans de nombreux cas, si la
définition et la planification ne sont pas effectuées en amont, l’équipe de projet commence avec
des ressources et un timing inadéquats. Malheureusement, vous ne vous apercevrez de cela
qu’une fois le projet en route. Beaucoup de projets qui pourraient être réussis sont considérés
comme des échecs parce qu'ils ont dépassé leur budget et leur date limite. Cette situation est
souvent provoquée par le chef de projet qui a avancé des chiffres trop bas ; elle résulte d'un
manque de planification en amont.
 Le faible contrôle du contenu. La définition du contenu de l’ensemble d’un projet est une
action primordiale. Si vous ne définissez pas le contenu et n’obtenez pas un accord à son sujet,
vous aurez du mal à gérer efficacement le contenu, tout le long du projet.
Comment éviter les erreurs ?
Consacrer du temps à une bonne définition et à une bonne planification finit par coûter beaucoup moins
de temps et d'effort que de devoir corriger les problèmes lorsque le projet est en cours. Il n’est donc
pas surprenant que la meilleure manière d'éviter les problèmes soit de bien définir et de bien planifier le
projet, à l'avance.
 Définir. Avant que le travail effectif du projet ne commence, assurez-vous d’avoir passé
suffisamment de temps à définir les objectifs du projet, le contenu, les hypothèses, les risques,
le budget, la chronologie, l’organisation et l’approche globale. Le chef de projet peut penser
qu'il connaît déjà tout cela. Cependant, le but de ce travail est de s'assurer qu'il y a un
consensus entre le chef de projet, le commanditaire et toutes les autres parties prenantes.
Même si le chef de projet et le commanditaire sont d'accord, d'autres parties prenantes
principales peuvent avoir des idées différentes. Ces divergences de vues doivent être résolues
avant que le projet ne commence, pas une fois que vous êtes en plein dedans.
455
 Planifier. Le chef de projet doit élaborer un échéancier du projet avant que ce dernier ne
commence. Cela lui permet d’estimer la quantité totale de travail et la durée du projet. Il doit
également s'assurer que le travail détaillé a été planifié pour les mois à venir, afin de s’assurer
que les ressources seront assignées aux tâches appropriées, une fois que le projet aura
réellement commencé.
En outre, il est très utile d'avoir un ensemble convenu de procédures de management de projet. Celles-
ci indiqueront comment le chef de projet doit gérer le contenu, les problèmes majeurs, les risques, la
communication, l'échéancier du projet, etc. Définissez tout ceci à l’avance, afin de mieux gérer les
attentes. Par exemple, si vous définissez la procédure d’approbation des demandes de modification du
contenu et que vous obtenez un accord à son sujet, vous aurez une gestion du temps beaucoup plus
facile, une fois le projet lancé.
Que se passe-t-il si le projet est déjà en cours de réalisation?
Naturellement, la meilleure manière de résoudre un problème est de le prévenir. Cependant, que faire
si vous n’avez pas cette latitude? Admettons que le projet soit en cours et que vous commenciez à voir
des domaines cités ci-dessus devenir problématiques. Par exemple, des parties prenantes arrivent avec
des idées nouvelles sur ce que le projet devrait accomplir, alors que vous êtes déjà en train de mettre
en application une vision précédente.
Si vous avez des ennuis avec un ou deux aspects du processus de définition, vous devriez pouvoir vous
en sortir avec un processus de mini définition. Si vous constatez, par exemple, que vous ne pouvez pas
contrôler le contenu des deux aspects en question parce que vous ne les avez pas définis au départ,
consacrez du temps à la définition formelle qui s’impose et à l’obtention d’un accord la concernant. Cela
implique le fait de revenir vers le commanditaire et les parties prenantes principales pour obtenir le
consensus et l'approbation que vous n'avez pas obtenus plus tôt.
Si vous commencez à buter sur des visions différentes de ce que le projet devrait réaliser, vous devriez
compléter l’intégralité du processus de définition alors que le projet est déjà en cours. C'est très
difficile, voire douloureux, mais cela peut être fait. Vous devriez revenir une étape en arrière et définir
les objectifs, le contenu, les rôles, les risques, etc. Vous serez amené à suspendre le travail sur le projet
jusqu'à ce que ce processus de définition soit accompli, bien que, dans de nombreux cas, ce ne soit pas
pratique.
Bien qu’il soit douloureux de définir le projet alors qu’il est déjà en cours, cela vaut nettement mieux
que d’ignorer le problème. La première option donnera sûrement lieu à un travail de reprise, qui, à son
tour, entraînera un coût complémentaire et un retard de la date de livraison. Cependant, ignorer le
problème peut finir par rendre la solution entière non pertinente ou désuète dès qu'elle sera livrée.
456
40.3 Problème #2 : Faible gestion du contenu
Définir le contenu est peut-être la partie la plus importante du processus de définition en amont d’un
projet. En fait, si vous n’êtes pas sûr de ce que vous livrez et des frontières du projet, vous n'avez
aucune chance de réussir. La gestion du contenu est un des aspects essentiels de la gestion d’un
projet. Cependant, si vous n’avez pas fait un bon travail de définition du contenu, sa gestion sera
presque impossible.
Le but de la définition du contenu est de tracer clairement les frontières logiques de votre projet et
d’obtenir un accord à leur propos. Les rapports sur le contenu sont employés pour définir ce qui est
dans les limites du projet et ce qui est en dehors de ses frontières. Plus vous identifierez d'aspects
appartenant au contenu, meilleur sera votre projet. Les informations suivantes peuvent être utiles :
 Les types de livrables qui sont dans le contenu et hors du contenu (Spécifications, estimations
de l'état actuel…)
 Les principaux processus du cycle de vie qui sont dans le contenu et hors du contenu (analyse,
conception, tests…)
 Les types de données qui sont dans le contenu et hors du contenu (Données financières,
ventes, employés…)
 Les sources de données (ou bases de données) qui sont dans le contenu et hors du contenu
(facturation, grand livre, fiches de paie…)
 Les organisations qui sont dans le contenu et hors du contenu (Ressources humaines,
fabrication, fournisseurs…)
 Les fonctionnalités principales qui sont dans le contenu et hors du contenu (soutien de décision,
saisie des données, rapport de gestion…)
Ayez un processus en place pour gérer efficacement les modifications de contenu
Le chef de projet et l’équipe de projet doivent se rendre compte qu'il n'y a aucun mal à procéder à des
modifications de contenu. Ces dernières ne sont pas forcément de mauvaises propositions, même
lorsqu'un projet est en cours. En fait, dans de nombreux cas, il s’agit d’une bonne chose. D'abord, le
client ne peut généralement pas identifier chaque spécification et chaque dispositif qui seront exigés
pour la solution finale. Même s’il le peut, les affaires varient avec le temps, et les spécifications du
projet peuvent changer.
Si vous ne vous adaptez pas au changement, la solution finale sera moins valable que ce qu'elle devrait
être ; il se peut qu’elle soit, en fait, inutilisable. C’est pourquoi vous voulez que le client ait la capacité
d’apporter des modifications pendant le projet, quand cela s’avère indispensable. Le problème survient
quand le chef de projet ne contrôle pas de manière proactive les modifications proposées. Chaque
projet devrait mettre en place un processus pour gérer efficacement les modifications de contenu. Ce
processus devrait inclure l’identification des modifications, la détermination de la valeur ajoutée pour
chaque modification, l'impact sur le projet, de même que la transmission au commanditaire des
informations qui en découlent, pour qu’il les évalue. Le commanditaire peut décider si la modification
doit être effectuée. Si c’est le cas, il devra également comprendre l'impact sur le projet et alors assigner
le budget complémentaire et le temps nécessaire à l’exécution de la modification.
Problèmes courants de management du contenu du projet
Il y a un certain nombre des problèmes communs que les équipes de projets rencontrent dans le cadre
du management du contenu d’un projet.
 Les modifications incontrôlées du contenu. Nombre de chefs de projet identifient les
grandes modifications du contenu mais ne sont pas attentifs aux plus petites. Une tendance
consiste à avancer et à accumuler le travail complémentaire sans trop réfléchir. Les
modifications incontrôlées du contenu se rapportent à ce qui se produit lorsqu’un projet est
sujet à un grand nombre de petites modifications. Quand toutes ces petites modifications sont
combinées, l'équipe se rend compte qu’elle a accepté trop de travail supplémentaire, et qu’elle
ne peut plus respecter ses engagements au sujet du budget et de la date limite.
 Les problèmes d’approbation. Souvent, un chef de projet recevra des demandes de
modifications des utilisateurs, des parties prenantes ou des managers du client. Puisque toutes
457
ces personnes font partie de l’entreprise cliente, on pense souvent que leurs requêtes devraient
être acceptées. Une fois de plus, c'est une erreur. Même si les utilisateurs constatent
habituellement des besoins de modifications du contenu, ils ne peuvent les approuver. Même
un manager du client ne peut approuver des demandes de modifications du contenu. La seule
personne habilitée à le faire est le commanditaire (à moins qu’il ait délégué cette autorité à
d'autres). De nombreux projets rencontrent des problèmes parce que l'équipe pense pouvoir
obtenir l'approbation pour effectuer des modifications de contenu, mais découvre, plus tard,
que la personne qui compte vraiment, à savoir le commanditaire, n'est pas d’accord.
 La responsabilité de l'équipe de projet. Puisque les membres de l’équipe de projet peuvent
avoir beaucoup d'interactions avec le client, ce sont ceux à qui sont adressées, le plus souvent,
les demandes de modification du contenu. Par conséquent, l’équipe de projet toute entière doit
comprendre l'importance de la gestion des modifications du contenu. Tous les membres doivent
veiller à les détecter quand elles se produisent et les rapporter au chef de projet. S'ils
s’accordent du travail supplémentaire de leur propre chef, il y a une forte probabilité que leurs
activités soient accomplies avec du retard et compromettent l’intégralité du projet.
Il n’est jamais trop tard pour commencer
Si vous trouvez que votre projet commence à tendre vers un dépassement de budget et de délais,
essayez d’en trouver la cause. Dans de nombreux cas, vous constaterez que vous travaillez plus qu’il n’a
été convenu au départ. Pour définir un processus de gestion des modifications de contenu, le moment
le plus opportun se situe avant que le projet ne commence (dans le cadre des procédures de
management de projet). Cependant, si vous n'avez pas de bon processus en place, il n'est jamais trop
tard pour commencer. Le chef de projet doit demander un arrêt rapide et travailler avec le client sur un
processus pour détecter et approuver les demandes de modification du contenu. Puis chacun doit être
informé sur ce nouveau processus. L’avantage de cette opération, c’est que l'équipe et le client
évaluent directement l'impact du fait de ne pas contrôler le contenu, parce que le projet a déjà des
problèmes. Ils devraient alors mieux comprendre le but de la gestion des modifications de contenu et
être plus disposés à suivre ce processus de façon plus rigoureuse à l’avenir.
458
40.4 Problème #3 : Absence de gestion de l'échéancier du projet
Au début, le chef de projet doit passer le temps qu’il faut à définir le projet et à le planifier et aboutir à
une charte de projet et à un échéancier du projet. Ce dernier est un outil essentiel pour s’assurer que le
chef et l’équipe savent ce qu'ils doivent faire pour réaliser le projet. Différentes approches devraient
être adoptées au cours de cette étape, selon la taille du projet. L'échéancier du projet pour de petits
projets peut être construit sans trop de formalités. De plus grands projets exigent habituellement un
échéancier élaboré d’après l'échéancier d'un projet précédent similaire. Une autre possibilité consiste à
réaliser un échéancier du projet en partant de zéro et en employant la technique de la structure de
découpage du projet (SDP) qui consiste à considérer le projet à un niveau général, puis à le découper
en de petits lots de travaux jusqu'à obtenir une image complète de la totalité du travail qui doit être
effectué.
Les signes de danger
Beaucoup de chefs de projet pensent que la création de l'échéancier de projet original est la finalité de
l'effort de travail. Il y a un certain nombre de signes qui indiquent que l'échéancier du projet n'est pas
mis à jour :
 Le chef de projet ne peut pas vous dire exactement quel travail doit encore être accompli sur le
projet.
 Le chef de projet n’est pas sûr que le projet soit terminé à temps et dans les limites du budget.
 Le chef de projet n’a aucune idée du chemin critique des activités.
 Les membres de l’équipe ne sont pas sûrs des tâches qu’ils devront accomplir par la suite (ou
même de ce sur quoi ils devraient travailler sur le moment).
Un projet a visiblement et indéniablement des ennuis, lorsque le chef de projet tient un échéancier du
projet sans vraiment voir les progrès déjà accomplis et combien de travail il reste à effectuer. Lorsque
cela se produit, l’équipe de projet n'est probablement pas utilisée efficacement sur la plupart des
activités importantes. Au bout du compte, l’équipe en question arrive à la fin du projet et s’aperçoit
alors qu'il lui reste beaucoup plus de travail que prévu, puisque des travaux programmés pour une
période antérieure n'ont toujours pas été accomplis. L'équipe peut également découvrir qu'il lui reste du
travail de reprise à faire, en raison d’étapes antérieures qui n’ont pas été accomplies.
Autres erreurs courantes dans la gestion de l'échéancier du projet
La plus grande erreur que les chefs de projet commettent est de ne pas mettre à jour l'échéancier du
projet, une fois le projet accompli. Mais il y a un certain nombre d'autres problèmes communs qui
peuvent survenir.
 Mises à jour peu fréquentes. Parfois le chef de projet met à jour l'échéancier du projet, mais
par intervalles : par exemple, tous les deux mois pour un projet de six mois. Le problème, dans
ce cas, c’est qu'avant que vous ne fassiez une mise à jour formelle, vous aurez déjà manqué
un certain nombre d’activités. En outre, si vous êtes en retard ou en dépassement de budget, la
notification prendra trop de temps, et il pourrait être trop tard pour réparer les erreurs.
 La gestion par pourcentages d’accomplissement. Toutes les activités devraient avoir une
date de livraison. Si l'activité est accomplie à l'heure, tout va bien. Dans le cas contraire,
considérez le pourcentage accompli. Ce pourcentage est très subjectif. La meilleure question à
poser est la suivante : « quand le travail sera-t-il terminé? » C’est incontestablement
l’information la plus importante que vous devez recevoir pour déterminer si votre projet se
trouve ou non en péril.
 Assigner des activités qui sont trop grandes. Si vous donnez une activité qui doit être
achevée pour la fin de la semaine à un membre de l’équipe, vous savez exactement si le travail
est sur bonne la voie quand la semaine est terminée. Cependant, si vous assignez à quelqu'un
une activité qui doit être terminée dans quatre semaines, il se passera beaucoup du temps
avant que vous sachiez si le travail est vraiment dans les délais. Bien sûr, la personne affectée
à cette tâche peut vous dire qu’elle l’a accomplie à 25% ou 50%, mais c'est une réponse
fortement approximative. Le seul moment où vous savez avec certitude si vous êtes dans les
délais, c’est lorsque le travail est réellement accompli au bout de quatre semaines. Vous pouvez
trouver cette période d’incertitude trop longue. En général, si vous avez un grand projet,
459
essayez de limiter les activités de travail à une durée de deux semaines ou moins. Si le projet
est plus petit, ce seuil pourrait être fixé, de préférence, à une semaine. De cette façon, vous
pouvez découvrir rapidement s’il y a un retard.
Comment revenir sur la bonne voie?
Si tout va bien, vous ne serez jamais dans une situation où l'échéancier du projet n’est pas à jour et où
vous ne savez pas exactement où vous en êtes dans le projet. Si jamais c’est le cas, la première chose
à faire est de revenir une étape en arrière, et de remettre à jour l'échéancier du projet. Il faut alors:
 Comptabiliser tout le travail effectué jusque là.
 Déterminer le travail en cours et savoir quand chaque activité sera accomplie.
 Travailler avec l'équipe pour identifier à nouveau tout le travail restant sur le projet, ainsi que
l'effort de travail estimé. Vous pouvez employer l'échéancier du projet comme point de départ,
mais il faut revalider tout le travail restant, et que vous avez identifié, pour accomplir le projet.
 Reprogrammer le projet pour déterminer si vous pouvez encore respecter vos engagements
concernant le budget et la date limite. Si vous ne pouvez le faire, vous devez examiner avec
votre client les moyens permettant d’accomplir le travail conformément aux attentes. Si cela ne
peut pas être fait, vous devriez remettre à plat les attentes, en vous basant sur l'échéancier du
projet nouvellement révisé.
Il n'y a pas de bonne manière de rattraper le retard d’un échéancier du projet une fois que le projet est
lancé. Généralement, votre projet a déjà des problèmes au moment où vous réalisez que vous devez
mettre à jour l'échéancier du projet. La mise à jour opérée à ce stade ne fait que révéler quels sont vos
ennuis. Une bien meilleure approche est de mettre à jour l'échéancier du projet de façon régulière. Les
mises à jour hebdomadaires sont les meilleures, mais pour un grand projet, elles peuvent peut-être
avoir lieu toutes les deux semaines.
460
40.5 Problème #4 : Mauvaise communication de projet
Il y a des années, un bon chef de projet pouvait être un mauvais communicateur et s’en sortir.
Généralement, les clients n’apprécient guère ce défaut de communication, mais aussi longtemps que le
chef de projet livrait les marchandises, le client était enclin à le laisser faire à sa manière. Aujourd’hui,
les projets doivent être entrepris en partenariat avec les milieux d’affaires, et cette association exige
absolument une communication solide. Plusieurs problèmes qui apparaissent au cours d’un projet sont
souvent le résultat d’un manque de communication. Une mauvaise communication peut être la source
d'ennuis dont voici quelques exemples :
 Des attentes différentes. Le chef de projet doit tâcher de s'assurer que toutes les personnes
liées au projet ont des attentes communes concernant ce qui sera fourni, le délai et le coût.
L’endroit où ces attentes doivent être initialement identifiées est la charte du projet. Mais
beaucoup de chefs de projet n’avisent pas les principales parties prenantes des changements
au niveau des attentes. Par exemple, quelques parties prenantes peuvent penser que le projet
va être achevé le 31 décembre, alors qu’il a été prolongé jusqu'au 31 mars. Les personnes
prennent généralement des décisions sur la base des meilleures informations dont elles
disposent à un moment donné. Si le chef de projet ne tient pas tout le monde au courant, il
peut très rapidement y avoir désynchronisation.
 Les gens sont étonnés. Si les gens ne sont pas au courant de ce qui se passe, ils seront
étonnés lorsque des changements se produiront. Par exemple, si vous vous rendez compte que
vous n'allez pas être en mesure de respecter votre date limite, vous voudriez vous assurer que
les gens ne le découvriront pas soudainement en lisant un rapport d'avancement. La
communication proactive signifie que vous prévenez de la possibilité de dépasser la date limite
dès que cela devient un risque. Ensuite, vous continuez à maintenir les personnes informées de
l’évolution de la situation. De ce fait, si vous devez déclarer que vous ne pourrez pas respecter
vos dates, elles seront préparées à cette éventualité. Les gens sont souvent médusés et
contrariés lorsqu’ils apprennent de mauvaises nouvelles à la dernière minute.
 Personne ne sait quel est l'état du projet. Au cours de certains projets, les gens ne sont
pas vraiment sûrs de l’état d’avancement. La communication sur ces projets est succincte et
n’informe pas exactement le lecteur de ce qui se passe vraiment. Encore une fois, les gens ne
peuvent pas prendre les meilleures décisions s’ils ne disposent pas de bonnes informations. S'ils
ne sont pas sûrs de ce qui se passe, ils doivent passer du temps supplémentaire à chercher à
s’informer davantage. Si vous envoyez des mises à jour aux parties prenantes et qu’elles
continuent à vous demander plus d'informations, votre communication n’est peut être pas
correctement ciblée.
 Les gens subissent l’impact du projet à la dernière minute. C'est la cause principale de
beaucoup de problèmes. Dans cette situation, le chef de projet ne communique pas de manière
proactive avec les autres parties concernées au sujet des éléments qui auront un impact sur
eux. Quand la communication intervient, c’est seulement à la dernière minute, et tout est
précipité. Cela se produit, par exemple, quand le chef de projet attend le dernier moment pour
dire aux managers des ressources humaines que des membres de l’équipe ne sont plus utiles
pour le projet et sont donc disponibles pour exercer d’autres activités. Il peut également s’agir
du chef de projet qui sait depuis trois mois qu'un spécialiste sera nécessaire mais qui le
demande seulement une semaine avant d’en avoir besoin. Dans chaque cas, l'autre partie est
étonnée par la demande et n’a pas le temps de s’y préparer convenablement.
 Les membres de l’équipe ne savent pas ce qu’on attend d’eux. Dans les situations
évoquées ci-dessus, les problèmes de communication se posaient entre l'équipe et les parties
extérieures. Une mauvaise communication est également possible au sein même d’une équipe
de projet. Certains chefs de projet font un mauvais travail de communication avec leur propre
équipe lorsqu’ils doivent lui expliquer ce qu'il y a à faire. Parfois, le chef de projet n'est pas clair
au sujet des dates auxquelles les travaux doivent être achevés. Dans d’autres cas, le chef de
projet peut avoir une idée sur ce à quoi les livrables doivent ressembler, mais ne communique
avec la personne chargée du travail que lorsque la première épreuve ne convient pas. Quelques
fois, le chef de projet ne communique pas clairement, et les membres de l’équipe perdent alors
du temps à effectuer un travail superflu. Une fois encore, cela entraîne du travail inutile et une
frustration supplémentaire chez les deux parties.
461
Quelle est la solution?
Certains chefs de projet sont de mauvais communicateurs. Si vous pensez faire partie de ce groupe,
vous devriez chercher à participer à des cycles de formation appropriés, pour vous améliorer.
Cependant, dans la plupart des cas, les problèmes de communication ne relèvent pas d’un manque de
qualification, mais d’un manque de concentration. Beaucoup de chefs de projet classent la
communication proactive à la fin de leur liste de priorités. Quand ils communiquent, ils tendent à être
brefs et pas très clairs, comme s’ils essayaient de le faire avec le moins de travail possible.
La clef de la communication c’est de rester focalisé sur le récepteur, pas sur l'émetteur. Essayez de
prévoir quels sont les besoins du récepteur en termes de communication et quelles informations lui
seront les plus utiles. Si vous élaborez un rapport d'avancement, incluez toutes les informations
nécessaires pour que le lecteur saisisse la situation réelle du projet, y compris les accomplissements, les
problèmes majeurs, les risques, les modifications du contenu, etc. Si vous allez avoir besoin d'une
ressource dans le futur, communiquez de manière proactive avec le gestionnaire des ressources dès
que possible. Puis, faites-lui des rappels au fur et à mesure que vous vous rapprochez de la date
prévue. Si vous étonnez quelqu'un lors d’un échange, c'est que vous ne communiquez pas
efficacement. (La seule exception est quand le chef de projet est également étonné.) Ce dernier doit
également communiquer clairement avec son équipe. Si vous vous apercevez que des membres de
celle-ci sont incertains quant aux dates limites, que certains effectuent un travail qu'ils n'ont pas besoin
d'effectuer, posez-vous la question de savoir si vous avez communiqué avec eux efficacement.
Une communication faible peut causer beaucoup de problèmes et en aggraver d'autres. Une
communication proactive peut aider à surmonter beaucoup d'erreurs. Ne considérez pas la
communication comme un mal nécessaire. Utilisez-la plutôt à votre avantage pour aider votre projet et
faire en sorte qu’il se déroule sans à-coups, avec moins de frustrations, moins d'incertitudes, et sans
surprises.
462
40.6 Problème #5 : Mauvais management de la qualité
Ce qu’il faut comprendre au sujet de la qualité c’est qu'elle n'est pas définie par le chef de projet ou son
équipe. La qualité est déterminée par le commanditaire du projet, votre client. On a parfois tendance à
croire que la ‘'qualité’’ signifie meilleur matériel, meilleur équipement et un niveau de défauts zéro.
Cependant, dans la plupart des cas, le client ne prévoit pas, et ne peut pas se permettre, une solution
parfaite. Une conception sans fautes et une solution sans défaut qui ne satisfont pas les besoins du
client ne seront pas nécessairement considérées de bonne qualité. Le but du management de la qualité
est d'abord de comprendre les attentes du client dans ce domaine, puis de mettre en place un plan
proactif et un processus pour répondre à ces attentes ou même les excéder.
Comme d’autres erreurs courantes de management de projet, les problèmes touchant à la qualité se
révèlent dans un certain nombre de secteurs. Par exemple:
 Le travail de reprise. C'est le problème important provoqué par un mauvais travail sur la
qualité durant le projet. Le travail de reprise signifie que vous devez effectuer le même travail
deux fois parce que le travail initial n'était pas satisfaisant. Prenons l’exemple des composants
d’un logiciel dans une grande application. Leur examen pas à pas ou par des collègues ne sera
pas considéré comme du travail de reprise, puisqu'il fait partie de la construction initiale du
composant. Quand vous dites que le composant est complet, c’est dans l’espoir qu’il n’y ait plus
de travail à faire. Cependant, si des erreurs surgissent lorsque votre composant est rattaché à
une application plus grande, un travail de reprise sera nécessaire. Ce travail est exigé parce que
la construction originale et le processus de tests n'étaient pas suffisamment complets et parce
que des erreurs qui existent toujours dans le produit livrable doivent être corrigées.
 Des coûts plus élevés d'entretien et de soutien. Si des erreurs sont décelées lors du
processus de développement, un coût lié au travail de reprise devra être pris en compte.
Cependant, beaucoup de problèmes de qualité apparaissent après que les livrables du projet
aient été réalisés et qu’ils soient entrés en production. Dans cette situation, on ne fait que
léguer le problème à l’équipe de support de l'entreprise. Les coûts d’un support élevé du fait
d’une solution de qualité inférieure sont un signe que l'équipe a volontairement fourni une
solution moins qu'acceptable, ou qu’elle a réalisé une qualité inférieure parce que ses processus
de test étaient tout aussi insatisfaisants.
 Le mécontentement du client. Si une solution est de qualité inférieure, le client ne sera pas
content. Encore une fois, une partie de ce mécontentement sera transférée vers l’équipe de
support. Conséquence plus grave : si le client a le choix, il ne commandera certainement plus
chez vous.
 Des dates limites et un budget dépassés. Dans de nombreux cas, les projets qui ne gèrent
pas bien la qualité, doivent réaliser un gros travail de reprise, ce qui les mènera à dépasser
leurs dates limites et à excéder leur budget. Cela peut causer un retard dans la réalisation des
bénéfices escomptés ou changer la valeur du projet tout entier.
 Un moral faible. Personne n’aime travailler pour une entreprise qui a des processus faibles ou
qui produit des solutions de qualité inférieure. Personne n’aime travailler sur des projets qui
dépassent leurs dates limites en raison du travail de reprise. Les gens veulent trouver de la
stimulation et des défis dans la création d’une solution. Leur niveau de motivation baisse
lorsqu’ils doivent continuellement réparer et retravailler des livrables qui ne fonctionnent pas
correctement. En plus d’un moral collectif faible, l’absentéisme augmentera, de même que les
mouvements de personnel, ce qui provoquera une baisse de productivité.
Qu’est-ce qui peut être fait?
Le management de la qualité n'est pas un fait ponctuel que vous devez considérer de temps à autre.
C’est, au contraire, un processus continu sur lequel l'équipe doit se focaliser tout au long du projet.
Quand le projet commence, le chef de projet doit préparer un plan de qualité global qui comporte trois
composants principaux :
1. Les critères d’acceptation. Nous avons dit plus haut que la qualité est déterminée par le
client – et non pas par le chef de projet. Cela place ce dernier dans une situation incommode,
puisqu'il peut ne pas être sûr des attentes du client. C'est à ce stade que les critères
463
d’acceptation entrent en jeu. L’équipe de projet et le client ont alors des attentes communes
concernant chaque produit livrable.
2. Le processus de contrôle qualité. Le contrôle qualité se rapporte aux activités continues
que l’équipe de projet exécute pour garantir que les livrables sont de bonne qualité. Cela peut
inclure des examens pas à pas des livrables, des tests des sous-composants, des check-lists
d’accomplissement, etc.
3. Le processus d’assurance qualité. Ce sont les activités conçues pour garantir que les
processus globaux créent des livrables de bonne qualité. Ces types d'activités incluent des
audits réalisés par des tiers, des check-lists pour s’assurer que toutes les parties d'un processus
ont été accomplies, des approbations de livrables, etc.
Chaque membre de l’équipe doit avoir un bon mental pour s'assurer que les travaux sont terminés dès
la première fois, avec une quantité minimale d'erreurs. Le chef de projet et l'équipe doivent comprendre
que le but premier du management de la qualité est de produire des livrables sans erreurs. Le
deuxième but est de déceler toutes les erreurs dès que possible.
D'un point de vue pratique, si vous pouvez élaborer des livrables avec aussi peu d'erreurs que possible,
puis trouver les erreurs dès que possible, votre projet global aura beaucoup moins de problèmes. Les
problèmes de qualité tendent à apparaître tard dans le projet - habituellement au cours du processus
de tests. Si vous avez un processus de bonne qualité en place, les tests devraient seulement confirmer
que tout fonctionne correctement. Vous pourrez alors vous occuper rapidement des approbations
finales, de la mise en application et avoir un cycle de production souple.
464
41.0 Définissez et planifiez le redressement du projet
Quand un projet a des problèmes, on fait habituellement appel à une partie extérieure pour aider à son
rétablissement. Cela ne doit pas obligatoirement être une personne appartenant à une entreprise
extérieure, mais juste quelqu'un qui ne fait pas partie du projet. Une tierce personne est impliquée soit
parce que les problèmes sont plus importants que ce à quoi s’attendait le chef de projet, soit parce
qu’ils sont trop graves pour que le chef de projet actuel puisse les prendre en main : si le chef de projet
avait des idées pour résoudre le problème, il l’aurait probablement déjà fait.
Résultats potentiels du rétablissement
Par définition, les projets en difficulté ont de sérieux problèmes. Ces problèmes peuvent être trop
graves pour être facilement surmontés. Il y a un certain nombre de scénarii potentiels pour remettre
sur pied un projet en difficulté.
 Le projet revient dans les marges de tolérance et il est mené à bien. C'est le meilleur
cas de figure, bien qu’il soit normalement impossible. Si, par exemple, vous avez un projet en
difficulté qui tend à dépasser son budget de 50%, vous ne pourrez normalement pas inverser la
tendance au point de revenir dans les limites de votre budget (en dessous de vos tolérances).
 De nouvelles attentes sont fixées et atteintes. C'est une mesure commune à prendre
pour un projet en difficulté. De nouvelles estimations sont réalisées et des attentes sont fixées ;
l'équipe tâchera d’y répondre.
 De nouvelles attentes sont fixées mais ne sont pas atteintes. C'est un résultat courant
si les causes profondes des problèmes ne sont pas identifiées et résolues. C'est le pire scénario
imaginable, puisque il ne permet pas à l’entreprise d’avancer. Le projet aura été un gaspillage
de fonds dans la mesure où ni les attentes initiales ni les nouvelles attentes n’auront abouti.
 Le projet sera annulé. Beaucoup de projets en difficulté sont tout simplement annulés et
l'argent déjà dépensé sera irrécupérable. Ceci peut se produire au moment où le projet est
validé comme étant en difficulté ou après que de nouvelles attentes aient été fixées. La valeur
marchande fixée par l’estimation originale du projet peut ne pas se réaliser si le coût est plus
élevé.
Naturellement, il y a d'autres éventualités. Par exemple, les attentes du projet peuvent être remises à
zéro, être manquées, puis remises à zéro une nouvelle fois. Le projet peut, parfois, être indispensable
et devoir être accompli, indépendamment du nombre d'attentes manquées.
Planifiez, puis agissez
La tendance normale adoptée par une personne arrivant sur un projet en difficulté est d’y sauter à
pieds joints, pour déterminer les causes des difficultés et élaborer les plans pour le remettre sur les
rails. Si le projet est petit, vous serez en mesure d’effectuer cette activité qui ne vous prendra
généralement pas trop de temps.
Supposons, maintenant, que le projet soit suffisamment grand pour que cela vaille la peine. Plutôt que
de se précipiter, la première chose à faire est de s’assurer que le travail pour récupérer le projet en
difficulté peut lui-même constituer un projet. Il faut ensuite définir ce travail. Le projet de
rétablissement a un début et une fin ; il nécessite des ressources, doit produire des livrables, etc. Il
remplit toutes les définitions classiques d’un projet. Puisque c'est un projet, il faut commencer par
mettre en place un processus de définition et de planification, comme cela est décrit dans les étapes 1
et 2 de la Méthodologie de Management de Projet TenStep. Comme pour un projet normal, vous devez
considérer les caractéristiques du projet de rétablissement afin de déterminer le niveau de l'effort de
travail requis. Si le rétablissement du projet est de taille moyenne, une charte et un échéancier abrégés
suffiront. Si le projet représente des dizaines de millions d’Euros, le projet de rétablissement devra lui-
même être substantiel. Dans ce cas, des définitions de projet et des plans de travail complets devront
être développés et approuvés. . Comme pour un projet régulier, la définition et le procédé de
planification vous donnent une opportunité de valider les éléments suivants:
 Le but du projet de rétablissement (Vue d’ensemble et objectifs)
 Les livrables à produire (le contenu)
465
 Les autres aspects du contenu comprenant la validation des organisations, les parties du projet
à récupérer, etc.
 Le commanditaire, le chef de projet et les autres parties prenantes principales du projet de
rétablissement (organisation du projet)
 La durée et le coût estimatifs du projet de rétablissement
 Les hypothèses et les risques associés au projet de rétablissement, et comment les risques
seront contrôlés
 Qui sera concerné par le projet de rétablissement (organisation du projet)
 Comment le projet initial se déroulera pendant le que le projet de rétablissement est en cours
(approche)
Une fois le projet de rétablissement défini et planifié, le commanditaire et les parties prenantes
appropriés devront approuver la charte du projet. Le chef de projet doit alors gérer le projet de
rétablissement conformément aux étapes 3 - 10 de la Méthodologie de Management de Projet TenStep.
Il doit se concentrer sur le travail convenu et s'assurer que les attentes sont remplies. La situation
globale pourra empirer au cas où le projet de rétablissement lui-même n'est pas mené à bien.
466
42.0 Évaluez le projet en difficulté
Une fois le rétablissement de projet défini et planifié (et aussi approuvé) la première étape est d’évaluer
le projet en difficulté. (Cela équivaut à la phase d'analyse, qui intervient généralement au début d'un
projet).
Vérifiez le background et les faits
La personne chargée de l'évaluation ne connaît pas forcément l’arrière-plan du projet. Dans de
nombreux cas, il s’agit d’une personne provenant de l’extérieur, qui a de bonnes qualifications en
matière d’évaluation et rétablissement, mais qui peut ne pas maîtriser le background du projet en
question. Que ce soit le cas ou pas, quand vous accomplissez l'évaluation, aucune hypothèse initiale ne
devra être écartée. Tout ce qui concerne le projet devra d'abord être validé.
Dans le cadre du briefing initial, vous devrez sûrement parler avec le commanditaire ou un haut
responsable. Ils vous feront certainement des recommandations sur le fond des problèmes. Cependant,
ils ne sont qu’une voix parmi d’autres. Les informations qui proviennent du commanditaire doivent être
validées et confirmées par d'autres parties, avant que les assesseurs ne prennent la moindre décision.
Consultez toutes les parties prenantes concernées
Certains rétablissements s’intéressent en particulier à l’équipe de projet, pour déterminer où résident
les problèmes. Cependant, ce groupe est trop restreint pour permettre une réelle évaluation. L’équipe
de projet ne dispose généralement pas d’une image suffisamment complète du projet. De plus, sa
compréhension des causes des problèmes peut être biaisée. Pour être efficace, l'évaluation doit inclure:
 L’équipe de projet
 Le commanditaire
 Les managers du client
 Les utilisateurs
 Les fournisseurs, commerçants et autres parties tierces ayant un degré élevé de participation
au projet
L'évaluation de toutes les principales parties prenantes permet d’avoir une vue plus équilibrée du
projet. Elle aide également à mettre en application le plan de rétablissement. Généralement, les
personnes tendent à mieux répondre à l'adversité et aux changements si elles pensent qu'elles ont été
consultées et que leur avis rentre en ligne de compte dans le processus de rétablissement.
Effectuez l'évaluation
Vous devriez avoir un plan d'attaque pour conduire l’évaluation. L'approche globale pour l'évaluation
devrait avoir été présentée dans la charte du projet de rétablissement. Un échéancier du projet initial
devrait également être mis en place. Cependant, l'évaluation va réclamer des compétences de
communication et de résolution des problèmes. Vous pouvez obtenir plus d'informations sur les
compétences en communication exigées, sur notre site Web LifecycleStep à l’adresse
www.lifecyclestep.com/411.1RequirementsElicitation.htm.
Le plan de rétablissement nécessitera également de bonnes compétences en matière de résolution des
problèmes. Il est important d'identifier les causes profondes des problèmes qui se posent. S'il y a des
problèmes multiples (et généralement il y en a), vous devez déterminer quels problèmes doivent être
résolus le plus rapidement. Vous pouvez passer en revue les techniques de résolution des problèmes en
vous référant aux parties suivantes:
4.2.1 Gérer les problèmes /Analyse des causes et des effets
4.2.2 Gérer les problèmes /L'analyse des causes profondes
4.2.3 Gérer les problèmes /Analyse de pareto
Causes communes
Chaque projet est unique et comporte un ensemble de circonstances uniques, elles aussi, qui posent
des problèmes. Quelques généralités peuvent guider l'évaluation lors de la recherche des causes
profondes de ces problèmes. Ce sont les suivantes:
467
 Définition en amont du projet
o Attentes peu claires, et différentes d’une partie prenante à l’autre concernant les objectifs du
projet
o Attentes peu claires ou différentes du contenu et des livrables du projet
o Des risques principaux n’ont pas été identifiés ou ont été pensés comme des hypothèses
initiales
o Manque de fermeté et de clarté du propriétaire et du commanditaire
o Toutes les parties prenantes principales du projet ne sont pas impliquées
o La charte du projet rend le travail trop volumineux ou trop complexe au lieu de le
décomposer en de plus petits lots de travaux
o Mauvaises estimations préalables du coût et de la durée
 L'échéancier du projet
o Les activités de projet ne sont pas décomposées à un niveau suffisamment réduit
o Le chemin critique n'est pas identifié et géré
o L’équipe de projet ne sait toujours pas sur quoi porte son travail
o Le travail est assigné à des membres de l’équipe n'ayant pas le niveau d’expérience requis et
la qualification adéquate
 Gestion courante de projet
o Les bons processus de management de projet et de cycle de vie ne sont généralement pas
suivis
o L'échéancier du projet n'est pas géré
o le contenu n’est pas géré efficacement
o Les problèmes majeurs ne sont pas résolus d'une façon opportune et les délais ont un
impact négatif sur le projet
o La communication entre le client et l’équipe de projet a été rompue ou est insatisfaisante
o Des risques du projet ne sont pas gérés
o Des risques ne sont pas réévalués
o Le projet ne suit pas les normes, les directives et les politiques de l’entreprise
o L'équipe n'est pas jugée responsable des dépassements des délais
o Les ressources pour gérer avec succès le projet définies dans la charte du projet ne sont pas
disponibles quand c’est nécessaire
o Il n'y a pas de compréhension commune des critères d'acceptation des livrables principaux
 Le personnel et les qualifications
o Les relations à l’intérieur de l'équipe ou les relations client-équipe ne fonctionnent pas
correctement
o Des problèmes interpersonnels et de diversité peuvent exister au sein d’une équipe de projet
multiculturelle
o L'équipe ou le client subissent un renouvellement constant des principales ressources
o Le chef de projet n’a pas les qualifications requises pour gérer le projet (il peut avoir de
bonnes qualifications générales, mais pas pour un projet présentant ces caractéristiques)
o L'équipe n'a pas les bonnes qualifications lui permettant de terminer les travaux selon les
attentes (qualifications techniques, professionnelles ou commerciales)
 Spécifications d'analyse et d'affaires
468
o L’échec de la définition des spécifications entraîne la construction de mauvais dispositifs et
fonctions
o L’échec de la définition des spécifications laisse clairement apparaître des lacunes
importantes empêchant d’atteindre des attentes du client
o Les besoins de toutes les parties prenantes, y compris les utilisateurs, les gestionnaires et le
commanditaire, n'ont pas été considérés dans leurs spécifications
o De nouvelles spécifications ne sont pas gérées (Problèmes de management du contenu du
projet)
 Conception et technologie
o Des nouvelles technologies ou des technologies dernier cri posent des problèmes imprévus
o Une mauvaise conception de la solution fait que les spécifications ne sont pas respectées, et
occasionne du travail de reprise
o le projet ne bénéficie pas d’une équipe ayant les qualifications requises
 Construction et tests
o Des spécifications et d'autres aspects du contenu ne sont pas gérés pour permettre au projet
d’être mené à bien
o Les composantes technologiques ne se combinent pas comme prévu
o De mauvaises techniques initiales de tests entraînent des erreurs et du travail de reprise lors
de tests ultérieurs
 Mise en application
o Formation non satisfaisante des utilisateurs de la solution
o La mise en application échoue et aucun plan de rétablissement n'est en place
o De mauvais tests globaux entraînent des erreurs majeures qui nécessitent de garder l’équipe
en place plus longtemps que prévu
Naturellement, il y a d'autres causes, qui peuvent être majeures ou mineures. L'évaluation peut viser
une cause profonde principale de difficulté pour le projet. Cependant, il est plus probable qu'un projet
en difficulté cumule plusieurs causes profondes, majeures et mineures, qui doivent être identifiées.
469
43.0 Développez un plan de redressement
Il est difficile de décrire un processus générique susceptible de développer un plan de rétablissement
parce que celui-ci se base sur les causes profondes spécifiques que vous mettez en évidence pendant
l'évaluation. Si la cause résulte de mauvaises estimations initiales, le plan de rétablissement inclura une
estimation nouvelle du travail restant. Si le problème est lié aux qualifications de l'équipe, le plan de
rétablissement sera différent.
Identifiez les alternatives et les recommandations
Une fois l'évaluation achevée, une liste d’alternatives devrait être établie, avec des recommandations.
Les alternatives changeront considérablement selon les causes repérées pendant l'évaluation. Quelques
alternatives sont, cependant, toujours prises en considération:
1. Arrêter le projet. Si un projet en difficulté justifie un rétablissement, l'équipe devra toujours
envisager la possibilité de son annulation. Beaucoup de raisons font que l'annulation est la
meilleure approche. Le produit peut avoir raté sa fenêtre d'opportunité sur le marché ; l'équipe peut
ne pas avoir les bonnes qualifications et l'entreprise peut ne pas disposer de personnes disponibles
pour les remplacer ; l'entreprise du commanditaire peut avoir des priorités plus importantes à cet
instant… Une proposition d'affaires qui n’est plus valide est une raison évidente d’annuler un projet
: un projet cohérent à un certain coût ne le sera plus si l'estimation des coûts révisée est supérieure
de 50% ou plus.
On hésite parfois à annuler un projet en raison de tout l'argent qui aura été gaspillé. Cependant,
vous devriez considérer l’argent déjà dépensé comme un coût perdu, c’est-à-dire généralement de
l'argent que vous ne reverrez plus. Le problème, dans un projet en difficulté, ne concerne pas
tellement les coûts perdus, mais les coûts restants. Est-ce que le projet va encore avoir un sens si
vous dépensez le coût estimatif pour le réaliser ? Si le coût estimatif pour accomplir le projet en
plus des coûts perdus, montre que le projet ne semble plus raisonnable d’un point de vue
commercial, alors le projet devrait être annulé. C'est généralement vrai même si vous avez déjà
dépensé 50% ou plus du coût révisé. Si le projet ne semble plus raisonnable d'un point de vue
commercial, vous ne voudriez pas qu’il vous coûte plus d'argent. Il vaudrait mieux consacrer
l’argent restant, même s’il ne représente que 50% ou moins, et l’utiliser dans un effort de travail
qui a une valeur marchande pour l’entreprise.
2. Laisser le projet continuer tel quel. Dans certains cas, le commanditaire peut décider que le
coût de rétablissement n'est pas envisageable. Par exemple, un projet peut être planifié pour être
accompli avec un budget supérieur de 50% par rapport à ce qui était estimé. Cependant,
l'évaluation peut déterminer une raison pour laquelle le coût du projet a été sous-estimé. Dans ce
cas, rien ne peut être entrepris pour sauver le projet. Le commanditaire est forcé d’accepter le coût
plus élevé du projet, de décommander le projet ou de revoir le contenu des livrables. Dans un autre
exemple, un projet peut durer 50% de plus que l’estimation originale. Mais ce dernier a pu
connaître des retards dans le recrutement des ressources, ce qui signifie que les coûts du projet
demeurent en deçà des tolérances. Le client peut décider d’accepter cette dernière date limite et de
ne pas prendre de mesure plus radicale.
3. Autres alternatives. Il y a beaucoup d'autres solutions de rechange couramment utilisées pour
sauver un projet en difficulté. Souvenez-vous que vous pouvez ne pas essayer d'accomplir le projet
dans les limites du budget et la date limite originale. Vous devez alors envisager un coût final plus
élevé et une date de livraison plus éloignée.
 Ajouter des ressources pour obtenir un effort de travail supplémentaire.
Ajouter des ressources peut être nécessaire pour accomplir le projet dans un calendrier
raisonnable. Une telle décision peut rallonger de manière conséquente le budget du
projet. Souvenez-vous qu'il n’y a pas que des avantages à l’ajout des ressources. Si
vous avez une équipe de cinq personnes et que vous en ajoutez une, vous n'obtiendrez
pas une augmentation de 20% du travail. Il y a un temps d’adaptation et de mise en
route qui prendra non seulement du temps à la nouvelle ressource, mais aussi aux
ressources existantes. Vous constaterez également une augmentation des
communications, une augmentation des malentendus au sein de l’équipe, du travail de
reprise, de la confusion, etc. Évidemment, vous obtiendrez un certain travail productif
en plus, mais pas au niveau de celui que vous attendiez. Par conséquent, vous
470
obtiendrez une augmentation du travail total de l’ordre de 15%. Si vous ajoutiez une
deuxième ressource à l'équipe, le gain d’accroissement pourrait être seulement de
12%. Une troisième ressource pourrait ne vous faire gagner que 8%, etc. Vous
arriverez rapidement à un point où ajouter plus de ressources finira réellement par vous
faire perdre du temps sur l'activité, en tout cas, plus de temps que si vous travailliez
avec moins de ressources.
 Ajouter des ressources pour offrir des qualifications supplémentaires. Vous
devriez ajouter des ressources avec un niveau nécessaire d'expertise ou de
compétence. Des conseillers expérimentés seront mis en renfort pour aider à réaliser
les activités à court terme pour lesquelles l’équipe de projet habituelle n'a pas le niveau
suffisant d’expertise.
 Payer des heures supplémentaires. Pour respecter un nouveau délai, vous pouvez
recommander des heures supplémentaires payées et des heures supplémentaires non
payées. Si vous payez les heures supplémentaires, cela coûtera plus d'argent au projet.
 Offrir des bonus incitatifs. Vous pouvez offrir des primes pour les membres de
l’équipe, les entrepreneurs et les fournisseurs pour obtenir que leur travail soit accompli
selon un calendrier plus agressif.
 Acheter des outils. Vous pouvez avoir besoin de nouveaux outils pour comprimer
l'échéancier. Ceux-ci coûtent généralement de l'argent, et vous devrez investir dans de
nouveaux cycles de formation. Vous pouvez toutefois vous dire qu'il y aura un
amortissement supérieur sur la durée restante du projet.
 Améliorer les processus. Plusieurs causes profondes des problèmes que rencontre
un projet doivent être résolues par des améliorations de processus. Si vous travaillez
sur un petit projet, vous pouvez ne pas avoir assez de temps pour apporter des
améliorations de processus avant la fin du projet. Pour de plus grands projets (comme
ceux qui ont besoin d’être sauvés) il reste habituellement assez de temps pour
introduire des améliorations de processus et aider au rétablissement du projet.
 Élaborer une dynamique de l’équipe. Si vous avez des causes profondes liées à la
cohésion de l'équipe, vous devriez investir dans des activités susceptibles d’ amener
l’équipe de nouveau à travailler en commun. Cette reconstruction de l’équipe peut
également s’étendre au client et au commanditaire. Sur beaucoup de projets en
difficulté, il y a des frictions entre le client et l’équipe. Cette situation doit être résolue
avant que le projet ne soit remis sur la bonne voie.
Si le projet n'est pas annulé, et qu’on autorise sa continuation, on peut, selon la cause profonde du
problème, suivre une myriade d'options. Bien que les alternatives réelles de rétablissement soient
différentes pour chaque projet, il y a un certain nombre d’éléments à garder à l'esprit.
 Assurez-vous que vous comprenez bien les différences de coût, de durée, et du contenu
(qualité). Dans de nombreux cas, un projet en difficulté aura des problèmes au niveau de plus
d'un de ces trois domaines. Un projet qui tend au dépassement de budget, par exemple, tendra
probablement au dépassement des délais. Les solutions de rechange pour le rétablissement
devraient aborder ses deux domaines. Vous aurez peut-être une alternative qui permettra de
ramener à la fois le budget et les délais dans les limites des attentes. Vous pouvez également
avoir des alternatives qui coûtent beaucoup plus d'argent mais qui permettent de livrer plus
rapidement, de même que celles qui permettent de livrer le projet plus tôt et qui sont meilleur
marché, mais avec moins de fonctionnalités, ou encore des solutions de rechange qui
aboutissent à un projet moins coûteux mais qui prend plus de temps. Si vous avez des options
multiples comme celles-ci, le commanditaire saisira mieux les effets que pourraient avoir les
différentes alternatives susceptibles de ramener le projet sur la voie.
 Recherchez des types d'interventions qui auraient comme conséquence une sauvegarde pure et
simple du projet. Un projet en difficulté est hors course au niveau d’un ou plusieurs secteurs
tels que le coût, la durée, la qualité, la satisfaction du client, etc. Si vous recommandez des
activités de redressement, vous voudriez vous assurer que les actions entraînent une
sauvegarde nette du projet. Par exemple, si vous estimez que l'effort de travail pour sauver le
projet est de 200 heures, vous devriez vous assurer que le résultat des activités vous fera
471
gagner plus de 200 heures par rapport à la tendance actuelle. Gardez à l’esprit les trois
contraintes. Vous pouvez assumer des frais supplémentaires en effort de travail et en coûts
pour comprimer l'échéancier. Mais vous ne voulez pas vous retrouver dans une position où le
coût d'intervention entraînera une augmentation nette de l'estimation révisée du projet, sans
l’intervention. Vous ne voulez pas non plus que les délais liés à l'intervention aient pour
conséquence le fait que le projet soit livré plus tard que si l’intervention n’avait pas eu lieu, ou
que la qualité soit plus mauvaise que s’il n’y avait pas eu d’intervention. Dans ces derniers
exemples, la meilleure alternative sera peut-être de laisser le projet se terminer tel quel.
Obtenez l’approbation du commanditaire
Au bout du compte, c’est le commanditaire qui doit décider du rétablissement du projet, en tenant
compte des différentes alternatives et recommandations. Il est possible que le commanditaire ait une
autre idée en tête, ce qui ne devrait pas être le cas s’il a été consulté lors de l'évaluation. Si une large
assistance a participé à la consultation pour la création des alternatives (commanditaire compris), il est
plus que probable que le commanditaire acceptera la recommandation proposée.
Remettez à plat les attentes avec une définition révisée du projet et de son
échéancier
Une fois que vous avez l'approbation du commanditaire sur l’approche globale de rétablissement, vous
devez revenir en arrière et mettre à jour la charte et l'échéancier original du projet. Vous devriez
remettre à plat les attentes pour les objectifs de projet, les livrables, les risques, les estimations de coût
et de l'effort de travail, etc. dans la charte du projet. Étant donné l'état du projet et les attentes
originales, il y aura probablement des révisions importantes à effectuer sur la charte du projet. Tout
comme la première fois, la définition révisée du projet devra être diffusée et approuvée par le
commanditaire du projet et les principales parties prenantes.
L'échéancier du projet doit également être mis à jour en fonction des changements qui ont été
approuvés. Il peut y avoir deux ensembles d'activités sur lesquels il sera nécessaire de travailler en
parallèle: un ensemble pour remédier aux causes profondes du problème et un ensemble différent axé
sur les activités initiales du projet. En d'autres termes, il se peut qu’il ne soit pas possible de suspendre
les activités du projet précédent pendant l’installation des modalités de rétablissement. Pendant cette
période, vous devriez mener les deux opérations en parallèle.
472
44.0 Activez le plan de redressement
A ce stade, vous avez développé des solutions de rechange pour sauver le projet et votre
commanditaire a approuvé un plan de rétablissement. Vous avez également mis à jour la charte initiale
du projet et l'avez fait approuver par le commanditaire et les autres parties prenantes concernées. Vous
avez élaboré un échéancier révisé du projet, qui inclut les activités nécessaires pour accomplir le projet
selon sa définition révisée.
Maintenant, l’équipe et vous-même devez exécuter cet échéancier du projet. Cela va exiger beaucoup
plus de concentration qu’auparavant. Il ne peut plus y avoir de retards. Toutes les personnes associées
à l'équipe doivent travailler de manière intensive sur les points suivants:
 Communiquer de manière proactive et gérer les attentes.
 Résoudre les problèmes majeurs rapidement et de manière appropriée.
 Se concentrer sur les spécifications minimales nécessaires à la satisfaction des besoins et
maintenir les demandes de modification du contenu à leur niveau minimal absolu. En même
temps, l’équipe de projet doit veiller particulièrement à faire passer toutes les demandes de
modification du contenu par le processus formel de modification du contenu.
 S'assurer que les bonnes ressources sont disponibles aux bons moments.
Vous ne voulez pas avoir un plan de rétablissement séparé du travail actuel du projet. Aussi, une fois le
plan de rétablissement développé, vous devriez déterminer les activités spécifiques requises pour
activer le plan de rétablissement. Ces activités devront être placées dans l'échéancier du projet pour
s’assurer qu’elles sont bien prises en charge, pendant que le reste du travail du projet progresse.
473
45.0 Evaluer et surveiller le plan de redressement
Il est important d’évaluer et de suivre de manière proactive le plan de rétablissement pour valider l’état
de la situation et celui du projet en général. Le pire résultat d'un redressement de projet est son échec.
Si cela se produit, non seulement le projet entier sera probablement annulé, mais il peut également y
avoir des répercussions pour tous ceux qui y sont impliqués (une perte de crédibilité, moins
d'opportunités à l'avenir, une rétrogradation, voire un licenciement).
Les éléments suivants feront partie d’une liste d’éléments à mesurer pour
surveiller le projet
 Une communication proactive, incluant des rapports d'avancement et des réunions de revue du
projet et de gestion des attentes est nécessaire. Si le projet a un plan de communication, il
devra également être mis à jour. Certaines des activités de communication qui ne fournissent
pas de valeur mesurable devront être arrêtées. D'autres activités de communication devront
être entreprises pour surmonter la perte de crédibilité dont le projet aura souffert.
 Des mises à jour méticuleuses de l’échéancier du projet, pour s’assurer qu’il présente toujours
une ligne nette aboutissant à l'accomplissement.
 Un suivi des coûts, de l'effort de travail, du travail de reprise et des erreurs du projet.
 Mesurez la satisfaction du client par rapport au plan de rétablissement, en lui envoyant de brefs
questionnaires de satisfaction, et en ayant des conversations directes avec les parties prenantes
principales pour s'assurer que leurs espoirs sont comblés.
Si ces mesures n’ont pas été mises en place, elles doivent être ajoutées au plan de rétablissement. Si
elles sont déjà en place, l'efficacité des processus doit être validée, et d’autres activités proactives
devront être ajoutées. Souvenez-vous que les anciens processus de surveillance et de mesure du travail
peuvent ne pas avoir été efficaces et avoir pu contribuer aux difficultés que le projet a pu connaître.
Une surveillance plus grande et des mesures supplémentaires peuvent être nécessaires pour le
rétablissement.
Selon la durée restante du projet, le chef de projet devrait employer des techniques de micro gestion.
Vous ne voulez pas être impliqué au niveau du détail dans les activités de travail de l'équipe. Mais lors
d’un rétablissement, vous pouvez avoir besoin d'exercer une surveillance et un suivi étroits sur tout le
travail qui reste à effectuer.
474
______________________________________________________________________
Glossaire
475
Glossaire
Activité – Dans le contexte de la Méthodologie TenStep de Management de Projet, une activité est la
plus petite unité de travail identifiée sur le plan de travail de projet. (Dans d'autres méthodologies, une
activité peut être divisée encore plus sur plusieurs tâches.)
Hypothèse – Il se peut que des circonstances extérieures ou des évènements doivent se produire pour
que le projet soit couronné de succès. Si vous pensez qu’un tel évènement est susceptible de se
produire, alors on parle dans ce cas d’une hypothèse (contrairement à la définition du risque). Si un
évènement est sous le contrôle de l’équipe du projet, et si cette dernière a bien achevé l’évaluation à
une date bien déterminée, c’est qu’il ne s’agit pas d’une hypothèse. Cela fait partie de l’approche. Si un
évènement a une chance d’occurrence de 100%, il ne s’agit pas d’une hypothèse, puisque qu’il n’y pas
de “probabilité” ou de risque encourus. Il s’agit juste d’un fait. Exemples d’hypothèses: 'les budgets et
les ressources seront disponibles au moment venu ...' ou ' la nouvelle version du logiciel sera disponible
pour utilisation lorsque la phase de construction va commencer'. Ceci est une définition simple de
l’hypothèse. Pour une définition plus exacte et pour plus d’informations voir 7.1.2.2 Hypothèses et
risques.
Client - La personne ou le groupe qui est le bénéficiaire direct d'un projet ou d’un service. Les gens
pour qui le projet est entrepris (les bénéficiaires indirects sont probablement les parties prenantes). Si
la personne ou le groupe appartiennent à votre entreprise, la méthodologie TenStep les désigne en tant
que «clients». S’ils n’appartiennent pas à votre entreprise, La méthodologie TenStep les désigne en tant
que «consommateurs».
Contraintes – Les contraintes sont des limites qui sont hors du contrôle de l'équipe du projet et qui
doivent être gérés. Ils ne sont pas nécessairement des problèmes et ne sont même pas nécessairement
des risques. Cependant, le chef de projet doit tenir compte des contraintes parce qu'elles se réfèrent à
des limites dans lesquelles le projet doit être exécuté. Les contraintes relatives à la date, par exemple,
impliquent que certains événements (peut-être la fin du projet) doivent avoir lieu à certaines dates. Les
ressources sont presque toujours une contrainte puisqu’elles ne sont pas disponibles d’une manière
illimitée. Par exemple, une fois le budget de votre projet défini, il devient une contrainte que le projet
doit faire avec.
Chemin Critique – Il s’agit de l’enchainement des activités qui doivent être achevées dans les délais
pour que l’ensemble du projet soit aussi achevé dans les délais. C'est le chemin le plus long à travers le
plan du travail. Si une activité sur le chemin critique est reportée d'un jour, l'ensemble du projet sera
retardé d'un jour (à moins qu'une autre activité sur le chemin critique puisse être accélérée d'un jour).
Facteur de Succès Critique - Un facteur de succès critique est tout événement qui doit se produire
pour que le projet atteigne ses buts et ses objectifs.
Consommateur - La personne ou le groupe qui est le bénéficiaire direct d'un projet ou d’un service.
Les gens pour qui le projet est entrepris (les bénéficiaires indirects sont probablement les parties
prenantes). Si la personne ou le groupe appartiennent à votre entreprise, la méthodologie TenStep les
désigne en tant que «clients». S’ils n’appartiennent pas à votre entreprise, La méthodologie TenStep les
désigne en tant que «consommateurs».
Livrable - Un livrable est tout résultat tangible qui est produit par le projet. Il peut s’agir de
documents, de plans, des systèmes informatiques, de bâtiments, d’avions, etc. Les livrables internes
sont produits à la suite de l'exécution du projet, et sont généralement requis par l'équipe projet
seulement. Les livrables externes sont ceux qui sont créés pour les clients et pour les parties prenantes.
Responsable Fonctionnel - Le responsable fonctionnel est la personne à qui vous rendez compte au
sein de votre organisation fonctionnelle. Typiquement, il ou elle est la personne qui effectue la revue de
votre rendement. Le chef de projet pourrait également être un responsable fonctionnel, mais cela n’est
pas nécessairement une obligation. Si votre chef de projet est différent de votre responsable
fonctionnel, votre organisation est probablement entrain d’utiliser un management de matrice.
Diagramme de Gantt - Un diagramme de Gantt est un diagramme à barres qui représente les
activités sous forme de blocs à travers le temps. Le début et la fin du bloc correspondent à la date de
début et de fin de l'activité.
Problème majeur – Un problème majeur est un problème qui entrave la progression du projet et qui
ne peut pas être résolu par le chef de projet et l’équipe de projet sans une aide extérieure.
476
Cycle de vie - Ce terme désigne le processus utilisé pour construire et soutenir les livrables produits
par le projet. (Puisqu’un projet a une date de début et de fin, le soutien d'une solution à long terme est
généralement effectué après l'achèvement du projet.) Pour le développement de logiciels, le cycle de
vie pourrait se composer de planification, d'analyse, de conception, de construction/ évaluation, de mise
en œuvre et de soutien.
Jalon – Un jalon est un événement d'ordonnancement qui signifie l'achèvement d'un livrable important
ou d’un ensemble de livrables connexes. Un jalon n’a pas de durée et ne nécessite aucun effort. Il n'y a
pas de travail associé à un jalon. Il s'agit d'un pavillon dans le plan de travail pour signifier que certains
autres travaux ont été achevés. Un jalon est souvent utilisé comme un check point pour le projet afin
de valider la façon avec laquelle le projet avance et à revalider les travaux restants. Ils sont également
utilisés comme des instantanés de haut niveau pour le management afin de valider la progression du
projet. Dans de nombreux cas il ya une décision qui doit être prise lors d'une étape importante. Les
jalons ne sont pas souvent fondés sur le calendrier. Ils sont généralement basés sur l'achèvement d'un
ou de plusieurs livrables.
Objectif – Une déclaration concrète décrivant ce que le projet cherche à atteindre. L'objectif devrait
être rédigé à un niveau faible, de sorte qu'il peut être évalué à la conclusion du projet pour voir s'il a
été atteint ou non. Un objectif bien formulé sera spécifique, mesurable, atteignable / réalisable,
réalistes et limités dans le temps (SMART). Pour plus d'informations, voir 1.3.1 Définir le travail / Buts
et objectifs.
Programme - Un programme est la structure faîtière créée pour gérer une série de projets connexes.
Le programme ne produit pas de livrables du projet. Ce sont les équipes du projet les produisent. Le
but du programme est de fournir une orientation générale, assurer une communication efficace entre
les projets, fournir un point central de contact et de se concentrer sur le client et les équipes de projet
et de déterminer comment les projets individuels devraient être définies pour s'assurer que tous les
travaux s’achèvent avec succès.
Responsable de programme - La personne disposant d’une autorité pour gérer un programme.
(Notez qu’il s’agit d’un poste. Il se peut que le responsable de programme soit également responsable
d'un ou de plusieurs projets au sein du programme. Il serait chef de projet sur ces projets ainsi que
responsable de toue le programme.) Le responsable de programme dirige la planification générale et la
gestion du programme. Tous les chefs de projet établissent des rapports pour le compte du
responsable du programme.
Projet – Une structure pour achever un livrable spécifique et définis ou un ensemble de livrables. Un
projet a une date de début et de fin spécifique, des objectifs spécifiques et des ressources spécifiques
prévues pour l’exécution du travail. Un chef de projet dispose d’une responsabilité globale et de
l'autorité sur un projet. Lorsque les objectifs sont atteints, le projet est considéré comme achevé. Pour
plus d'informations, voir 1.0.1 Qu'est-ce qu'un projet?
Chef de projet - La personne disposant de l’autorité pour gérer un projet. Cela inclut la conduite de la
planification et le développement de tous les livrables du projet. Le chef de projet est responsable du
management du budget et du plan de travail et de toutes les procédures de management de projet
(management du contenu, les problèmes majeurs relatifs au management, management des risques,
etc.) Voir 1.0.2 Le Rôle d'un chef de projet.
Phase de Projet - Une phase est un regroupement logique important de travail sur un projet. Une
phase représente également l'achèvement d'un livrable important ou d’un ensemble de livrables
connexes. Sur un projet de développement de logiciel les phases logiques pourraient être la
planification, l'analyse, la conception, la construction (y compris les tests) et la mise en œuvre.
Équipe du projet - L'équipe du projet se compose de personnel à temps partiel et à plein-temps,
affecté pour travailler sur les livrables du projet. Ils sont responsables de :
 Comprendre le travail à exécuter
 Planifier les activités assignées de manière plus détaillée si cela est nécessaire
 Achever le travail assigné dans le cadre du budget, de l'échéancier et des attentes relatives à la
qualité
477
 Informer le chef du projet des problèmes majeurs, des modifications du contenu, des risques et
des problèmes relatifs à la qualité
 Communiquer de façon proactive et gérer les attentes

L'équipe de projet peut consister de ressources humaines au sein d'une organisation fonctionnelle
comme elle peut consister de membres provenant de plusieurs organisations fonctionnelles différentes.
Une équipe multidisciplinaire regroupe des membres provenant de multiples organisations. Le fait
d’avoir une équipe multidisciplinaire est souvent un signe que votre organisation est entrain d’utiliser
une gestion matricielle.
Risques - Pour que le projet soit couronné de succès, certaines circonstances extérieures ou des
événements ne doivent pas se produire. Lorsque vous pensez qu’un tel événement est susceptible
d'arriver, alors dans ce cas on parle de risque. (Contrairement à la définition d'une hypothèse.) Le fait
d’identifier quelque chose comme un risque augmente sa visibilité et permet de mettre en place un plan
proactif de management des risques. Il s'agit d'une simple définition d'un risque du projet. Une
définition plus précise est disponible au processus 7.0 Gérer les risques.
Contenu – Le contenu est la façon avec laquelle vous décrivez les limites du projet. Il définit ce que le
projet livrera et ce qu'il ne livrera pas. Pour les projets les plus importants, il peut inclure les
organisations affectées, les transactions concernées, y compris les types de données, etc. Pour plus
d'information voir 5.0.1 Définir le contenu.
Accord de niveau de service – Il s’agit d’un contrat relatif à un niveau mesurable de service entre le
prestataire et le destinataire du service.
Commanditaire (commanditaire exécutif et commanditaire du projet) La personne qui détient
l'autorité ultime sur le projet. Le commanditaire exécutif assure le financement des projets, résout les
problèmes et les modifications du contenu, approuve les livrables importants et fournit une orientation
de haut niveau. Il ou elle milite également pour le projet au sein de son organisation. Selon le projet, et
le niveau organisationnel du commanditaire exécutif, il ou elle pourrait déléguer la gestion journalière à
un commanditaire de projet. Lorsqu’il est assigné, le commanditaire du projet représente le
commanditaire exécutif quotidiennement, et prend la plupart des décisions nécessitant l'approbation du
commanditaire. Si la décision est tellement importante, le commanditaire du projet la présentera au
Partie prenante – Des personnes ou des groupes spécifiques qui ont un intérêt dans l’aboutissement
du projet. Normalement, les parties prenantes viennent de l'intérieur de l'entreprise et pourrait inclure
des clients internes, le management, les employés, administrateurs, etc. Un projet pourrait également
comprendre des parties prenantes externes, y compris des fournisseurs, des investisseurs, des groupes
de sociétés et des organisations gouvernementales.
Norme – Une norme est une approche nécessaire pour mener une activité ou une tâche, en utilisant
un produit, etc. Généralement, une norme est une bonne pratique qui doit être suivie pour assurer de
meilleures chances de succès.
Comité de direction - Un comité de direction est généralement formé d’un groupe de parties
prenantes de haut niveau qui sont chargées de fournir des conseils concernant l'orientation stratégique
globale. Il ne remplace pas le commanditaire, mais contribuât à propager la contribution stratégique
pour une plus grande partie de l'organisation. Le Comité de direction est habituellement composé de
membres organisationnels. Il s’agit d’une combinaison de clients directs et de parties prenantes
indirectes.
Modèle – Les modèles sont des formulaires préétablis qui incluent un texte standard et des espaces
vides à remplir avec des informations standardisées. Les modèles aident à économiser du temps
puisque chaque personne n'a pas à créer le format de document par ses propres moyens. Grâce aux
modèles, les informations seront présentées dans des formats standardisés et reconnaissables par le
lecteur.
478

TenStepV10 Ebook FR

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

TenStepV10 Ebook FR

Transféré par

Droits d'auteur :

Formats disponibles

Methodologie TenStep de Management de Projet®

En Algérie au Cameroun en France au Maroc au Québec en Tunisie

La méthodologie TenStep de management de projet ("Méthodologie TenStep" ou "TenStep") a été

L’expression « management de projet » fait référence à la définition et à la planification, ainsi qu'à la

 A1 Les avantages d'une méthodologie de management de projet

o A1.1 La modularité de la méthodologie – un facteur-clé

 A2 Le style d’écriture de TenStep

 A3 Comment utiliser la méthodologie TenStep

 A4 Le contexte de la méthodologie TenStep

 A5 Déroulement de la méthodologie TenStep

o A5.1 Modèle CMMI de maturité des capacités

o A5.2 Management de projet par rapport au cycle de vie d'un projet

o A5.3 Management de projet par rapport à la gestion de produit

 A6 Comparaison de la méthodologie TenStep de management de projet, avec

o A6.2 La méthode Agile de développement de logiciels

o A6.3 ISO 10006

Et maintenant, commençons par l’étape 1.0 et que le jeu commence !

Votre entreprise présente-t-elle l’une des caractéristiques suivantes ?

 Le management de projet est réactif et on ne constate pas qu’il fournit de la valeur.

 Le management de projet est considéré comme « des frais généraux ».

 Les projets réussissent, malgré l’absence de planification et de management de projet, grâce à

Il en va de même pour le management de projet. Gérer un projet de manière proactive demande du

 Allez–vous communiquer de manière proactive ou supporter les conflits et les incertitudes

Il y a à cela différentes raisons :

 Cela nécessite un investissement préalable à la fois en temps et en effort. Nombreux

Options pour obtenir une méthodologie (A1.P3)

Certaines organisations considèrent qu’une méthodologie de management de projet occasionne des

Pourquoi certaines personnes et certains organismes considèrent-ils qu’une méthodologie de

Le reste de la méthodologie TenStep de management de projet fonctionne de la même manière.

Principes directeurs (A4. P1)

Les paragraphes qui suivent présentent un ensemble de principes directeurs de la méthodologie

 Application à tous les projets. La méthodologie TenStep de Management de projet est

 Développer le partenariat entre l’équipe de projet et le client. Pour réussir, un projet

 Etablir la méthodologie de management de projet au préalable. La méthodologie de

TenStep n’inclue pas le cycle de vie du projet (A4. P2)

TenStep n’inclue pas la collecte des exigences détaillées (A4. P3)

Le chef de projet dispose de l’autorité et de la responsabilité (A4. P5)

Reconnaitre l’objectif du dossier d'affaires et de la charte du projet (A4. P6)

Le rôle du commanditaire est très important (A4. P8)

Les « processus » n’impliquent pas un ordre séquentiel (A5. P1)

Le processus 3 est le processus clé d’intégration (A5. P2)

A5.2 Management de projet par rapport au cycle de vie d'un projet

A5.3 Management de projet par rapport à la gestion de produit

Les cinq niveaux du Modèle CMMI (A5.1. P2)

 Management de projet standardisé. Votre organisation a mis en place des processus de

 Développement standardisé de logiciel. Ce niveau implique le fait d’appliquer une

 Optimisation / amélioration continue. Vous avez une boucle fermée de processus

Le CMMI est-il fait pour vous ? (A5.1. P3)

 Ils ont tous un commencement et une fin.

 Les projets aboutissent à la réalisation d'un ou de plusieurs livrables.

Les projets par rapport aux produits (A5.3. P1)

 S’emparer de l’idée afin qu’elle puisse être explorée à fond

 Identifier les opportunités d’utilisation du produit

 Lancer l’idée à travers le processus de planification commerciale de la société pour savoir si

 Coordonner la diffusion du produit ou de nouvelles mises en vente

 Chercher où le produit a été distribué

 Recueillir continuellement les demandes du personnel au sujet de produits particuliers

 Incorporer et ajouter de nouveaux produits et de nouvelles mises en vente (produits vendeurs)

 S’assurer que le budget pour les achats et la maintenance est disponible

Management des lancements de produit

 Coordonner la certification de nouvelles mises en marché (produits internes et produits

 Déterminer le moment où un produit doit être retiré

 Planifier et gérer le produit