Gestion de projet - PMBOK® 4th Edition

Gestion de projet - PMBOK®
4th Edition
Cycle de vie du projet
STS SA
Av. de la Gare 10
1003 Lausanne
021 351 86 86
[email protected]
www.sts.ch
www.sts.ch
Cycle de vie du projet
Théorie
Les points clés:
Cycle de vie d’un produit:
En général, un projet concerne un produit et ce dernier a un cycle de vie propre qui va
de sa création à son retrait de service:
Le management de projet est impacté par le cycle de vie des produits.
Les projets réalisés pendant la phase de mise en place d’un produit peuvent avoir
d’importantes contraintes de délais, alors que ceux liés à la fin de vie du produit
souffrent de ne pas être prioritaires.
Cycle de vie d’un projet:
Le cycle de vie d’un projet comporte plusieurs phases principales, correspondant
chacune à un livrable clé du projet.


Dans le domaine de la construction, ces livrables peuvent être par exemple le
permis de construire, le choix du site, les ouvrages eux-mêmes et aussi les
conditions d’achèvement (règlements, levées de garantie, etc.).
Dans le domaine logiciel, les livrables peuvent être l’étude de faisabilité, les
spécifications fonctionnelles, l’architecture technique, le code, les résultats de
tests, la recette et la mise en production.
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
2
Cycle de vie du management de projet:
Le plus souvent «Cycle de vie du projet» et «Cycle de vie du management de projet»
sont parallèles: dès la fin des premières études (c’est un livrable du projet), le plan de
management des coûts du projet est établi (c’est un livrable du management de projet).
Pour faire aisément la différence, il suffit de se poser la question: que doit fournir
l’équipe de projet (c’est alors un livrable du projet) et que doit fournir le chef de projet
(c’est alors un livrable du management de projet)?
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
3
Pour des grands projets, ou pour des projets très spécifiques, le cycle de vie du
management de projet s’applique intégralement à chaque phase du projet, de sa
planification à sa clôture.
Ce découpage du projet peut être utile lorsque:
 chaque phase a un objectif spécifique et est pilotée par une équipe différente;
 il y a un jalon de décision à chaque fin de phase, pour décider de la poursuite
du projet;
 le projet ne peut pas être entièrement planifié en une seule fois du début à la
fin.
Projets multi-phases:
Vous pouvez identifier ces projets à l’aide des 3 questions suivantes:
 Pourrai-je planifier toutes les activités, du début à la fin du projet?
 Y a-t-il des jalons de décision “go/no go” prévus?
 Est-ce que l’équipe projet et/ou les activités du projet diffèrent
significativement d’une phase à l’autre?
Si toutes les activités ne peuvent pas être planifiées (ni être identifiées, ni même
décrites) du début à la fin du projet, alors il y a des chances que le projet comporte
plusieurs phases: comment pourrions-nous planifier la construction d’une maison avant
d’avoir fini d’en faire la conception?
Dans ce cas, le livrable de la clôture de la première phase (acceptation de la conception
de la maison) devient la donnée d’entrée du démarrage de la phase suivante (énoncé
des travaux).
Lorsqu’il y a un jalon de décision “go/no go”, le livrable réalisé avant le jalon est évalué
(par exemple: évaluation de la géologie) et puis l’autorisation est donnée de continuer le
projet (par exemple: construire un pont).
En général, chaque période de temps avant et après le jalon de décision est considérée
comme une phase. Dans ce cas, le livrable de la première phase est inclus dans la
charte de projet de la phase suivante en tant que contrainte ou élément de décision.
Pour l’exemple du pont, la charte de projet de la phase de construction va lister les
contraintes géologiques en tant que contraintes environnementales ou contraintes
externes.
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
4
Bibliographie:
PMBOK® Guide
4ième édition:
1.3 Qu’est-ce que le management de projet?
2.1 Le cycle de vie du projet
Comment faire
Comment définir efficacement les phases de votre projet?

Conformez-vous à la structuration habituelle des plannings de projet dans votre
entreprise: les phases principales sont souvent utilisées par le management pour
suivre les projets dans l’entreprise. Si le management est habitué à voir les
plannings sous une présentation donnée, il sera plus facile de gérer votre propre
projet avec le même phasage.

Consultez les archives de projets similaires.
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
5

Le premier niveau de votre structure de découpage du projet peut-il être une
structure des phases?

Identifiez clairement les livrables: les plus importants peuvent constituer des
phases.

Une phase peut s’achever par un jalon de décision. Identifiez toutes les décisions
requises par votre entreprise. Par exemple, si à la fin des études de faisabilité
une réunion est prévue pour décider de la continuation (go/no go), alors vous
pouvez définir la réalisation des études de faisabilité comme étant une phase.

Listez les activités (par exemple, les estimations de coûts et délais) qui ne
peuvent pas être réalisées tant que certains documents ne sont pas établis ou
certaines analyses conduites. Il y a habituellement 2 phases dans ce genre de
situation: la construction des ouvrages ne peut pas être planifiée tant que
l’architecte n’a pas fait approuver les plans par le client. Dans cet exemple, il y a
2 phases: l’élaboration des plans et la construction des ouvrages, avec les 2
étapes de planification correspondantes.
Exemple
Une société informatique a détaillé le cycle de vie d’une interface Internet (qui est
considérée ici comme un produit). Ce produit est le résultat de 7 projets, qui se répartissent
de la mise en place jusqu’au retrait (y compris la migration des clients vers le nouveau
portail Web).
Le projet 5 (Robustesse) vise à améliorer la maturité de l’interface Internet en le rendant
capable de supporter l’accroissement de la charge.
Ce projet est découpé en 5 phases:
Note: Ne pas confondre cycle de vie du produit et cycle de vie du projet: le cycle de vie d’un
produit est composé de nombreux projets (un projet pour l’implémentation du produit, un
autre pour son retrait et entre les deux, divers autres projets pour les améliorations du
produit). Le cycle de vie d’un produit comprend habituellement 5 états: introduction,
croissance, maturité, déclin et retrait.
Une autre société vient juste de démarrer un projet de construction. Le livrable principal du
projet est un pont au-dessus du lac Léman. Cet ambitieux projet peut se découper en
plusieurs phases:
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
6






études d’impact (enquêtes publiques, études environnementales, etc.)
étude de faisabilité et réalisation d’un prototype à 1/1000e
travaux préparatoires (drainage du lac, transport de matières premières)
construction du pont
revue de la qualité de l’ouvrage
mise en service pour usage public
Check-liste
 Avez-vous réalisé une représentation graphique du cycle de vie du projet et l’avez-vous
incorporée au plan du projet (Convention/Accord cadre du projet)?
 Est-ce qu’une méthodologie de management de projet a été approuvée pour ce projet?
 Avez-vous établi un planning de synthèse de la phase qui engage le management?
 Pour la phase de projet en cours, avez-vous établi un planning détaillé pour piloter
l’équipe projet?
 Avez-vous créé un dossier pour la documentation du projet (par exemple, un classeur
pour un petit projet, ou une base de données – système d’information du projet – pour
un grand projet)?
Pièges
 Ne réinventez pas la roue: utilisez une méthodologie de management de projet
éprouvée!
 Ne confondez pas phase de projet et processus de management de projet! Les phases
de projet décrivent ce qui est requis pour atteindre les résultats du projet, alors que les
processus de management de projet décrivent ce qui est requis pour manager le projet.
 Ne confondez pas le plan du projet avec l’échéancier du projet (diagramme à barres)! Le
plan du projet regroupe tous les éléments de la planification, comme le périmètre des
livrables, les coûts et les jalons, ainsi que les conventions et les engagements. De ce
fait, il s’appelle aussi convention de projet.
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
7
Processus et Groupes de processus
Théorie
Les principes clés:
De nombreuses activités de management sont nécessaires dans tout projet. Ces
activités (ou processus) sont regroupées en 5 « groupes de processus ». Les principaux
processus de chacun des groupes de processus sont :





Démarrage (Autoriser un projet)

Identifier les parties prenantes ;

Définir les objectifs du projet ;

Designer un chef de projet ;

Elaborer la charte du projet.
Planification (Déterminer les livrables du projet et planifier le travail à réaliser)

Recueillir les exigences ;

Décomposer le contenu en livrables (lots de travail) et activités ;

Elaborer l’échéancier et le budget de référence ;

Définir les responsabilités ;

Identifier les risques ;

Obtenir une approbation formelle du Plan de projet.
Exécution (“Faire” le travail)

Sélectionner les fournisseurs (si nécessaire) ;

Constituer l’équipe de projet ;

Réaliser le travail (affecter les tâches, etc.);

Mettre en œuvre les modifications ;

Diffuser les informations entre les parties prenantes.
Surveillance & Contrôle (Suivre l’avancement et les écarts pour décider des
actions nécessaires)

Mesurer l’avancement et les écarts;

Auditer les risques ;

Rendre compte de la performance du projet ;

Rejeter ou approuver les modifications du Plan de projet.
Clôture (Formaliser l’achèvement par une acceptation formelle et archiver les
documents du projet)

Obtenir l’acceptation formelle du client que les objectifs du projet sont
atteints ;

Clôturer les contrats ;

Enregistrer les leçons apprises du projet ;
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
8

Libérer l’équipe de projet.
Les groupes de processus organisés par ordre chronologique.
Une autre présentation des processus existe. Ils sont regroupés en domaines de
connaissances : intégration, contenu, délai, coûts, qualité, risques, ressources
humaines, achats et communication.
Certains domaines de connaissance, comme par exemple les achats, sont pris en charge
par un département spécialisé de l’entreprise.
Bibliographie:
PMBOK® Guide 4ième
édition:
3.1 Interaction entre processus de
management de projet
3.2 Groupes de processus de management
de projet
Comment faire
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
9
Comment déterminer quels sont les processus nécessaires pour mon projet?

La première chose est de savoir si tous les domaines de connaissance sont entre
vos mains : en fonction des pratiques de votre entreprise, est-ce que les achats
sont gérés par le chef de projet? Et l’allocation des ressources? Qu’en est-il du
management des risques?

Collecter auprès de votre management et du sponsor du projet leurs exigences
et attentes sur les livrables du management de projet. Souhaitent-ils lire et
approuver un plan détaillé de management des coûts ?

Vérifier auprès de l’équipe Qualité, ou après du PMO, quels sont les procédures
et modèles applicables à votre projet. Ceci vous donne une bonne
compréhension des livrables attendus!
Exemple
Il n’y a pas d’exemple disponible pour cette leçon.
Check-liste



Avez-vous adapté l’application des processus à la taille de votre projet?
Avez-vous discuté avec votre équipe des processus de management de projet qui seront
utilisées?
Avez-vous fait la promotion du management de projet, de façon que l’équipe de projet
et les parties prenantes comprennent vos besoins et attentes et leurs justifications?
Pièges
 N’utilisez pas systématiquement tous les processus dans tous vos projets : c’est une
décision d’équipe que de sélectionner les processus adaptés au projet !
 Adaptez les processus de management de projet aux besoins de votre entreprise ou de
votre projet plutôt que l’inverse.
 Ces processus sont un cadre et non une recette toute faite !
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
10
Interactions entre processus et cartographie
Théorie
Les principes clés:
Les groupes de processus (démarrage, planification, exécution, surveillance & contrôle
et clôture) ont 2 degrés d’interaction :

Premièrement, pour un projet à plusieurs phases, le groupe de processus de
clôture d’une phase (comme les études préliminaires) est intimement relié au
groupe de processus de démarrage de la phase suivante (comme la conception).
Ceci s’applique principalement aux projets complexes ou grands.

En second lieu, dans une phase (ou un projet, lorsqu’il n’est pas par phase), les
groupes de processus se chevauchent les uns les autres.
Interactions dans une phase (ou dans un projet simple):
Les 5 groupes de processus (démarrage, planification, exécution, surveillance &
contrôle et clôture) ne sont pas indépendants.
Pendant l’exécution, il arrive que des activités de planification soient nécessaires par
exemple du fait d’une modification du contenu ou bien pour intégrer une action
corrective au plan du projet.
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
11
Beaucoup d’autres processus sont inter reliés : le livrable (en sortie) de l’un des
processus est en entrée d’un autre.
Par exemple, la SDP (Structure de découpage du projet) produite par le processus
« créer la SDP » est une donnée d’entrée d’autres processus.
Pour facilité leur lecture, tous les processus ont été regroupés d’une part en groupes
de processus et d’autre part en domaines de connaissances comme le management
du contenu, des délais et des coûts.
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
12
Avez-vous repérer le processus « créer la SDP » ?

Est-ce bien une activité de planification ?

De ce fait, vous le trouverez dans le « groupe de processus de planification » et
dans le « domaine de connaissances du management du contenu ».
Bibliographie:
PMBOK® Guide 4ième
édition:
3.1 Interactions entre processus de
management de projet
3.2 Groupes de processus de management de
projet
Comment faire
Comment s’assurer d’une bonne application des processus ?

Vérifier le tableau de cartographie:
o
Associer à chaque domaine de connaissance l’entité responsable au sein
de votre entreprise! Identifiez clairement les devoirs du chef de projet.
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
13
o
Renommer si nécessaire les processus décrits pour s’adapter à la culture
de votre entreprise : en tant que communiquant, vous avez besoin
d’utiliser un langage commun pour être bien compris.

Adapter le niveau de détail de chaque processus aux besoins de votre projet: par
exemple, pour un projet simple, les activités de planification du contenu seront
considérablement simplifiées. N’oubliez pas: c’est de votre responsabilité de chef
de projet de choisir les outils et techniques les mieux adaptées aux besoins de
votre projet !

Un tel cadre doit être mis en œuvre avec délicatesse dans l’entreprise. La
révolution déclenche toujours la guerre! Vous feriez mieux d’implémenter ces
connaissances par itérations. Ainsi, si vous démontrez son efficacité, toute
méthode sera mieux acceptée…
Exemple
Il n’y a pas d’exemple disponible pour cette leçon.
Check-liste
 Avez-vous pensé à la manière de mettre en œuvre ce cadre méthodologique dans votre
projet ? Soyez flexibles dans la manière d’appliquer ces processus : ceci est un
ensemble de bonnes pratiques généralement reconnues comme telles. Il n’est pas
exhaustif et peut être inutile dans certaines situations.
 Partagez vous vos connaissances ? C’est une bonne manière de développer l’équipe de
projet que de discuter du management de projet. Ceci va clarifier vos attentes et aussi
montrer votre ouverture d’esprit.
 Avez-vous expliqué pourquoi vous voulez telle ou telle données d’entrée pour vos
activités de management de projet?
Pièges
 N’imposez pas une liste rigoureuse et détaillée de processus de management de projet si
la culture de votre entreprise n’y est pas prête ! Les grands changements demandent du
temps et de la délicatesse pour être acceptés.
 En lieu et place de processus complexes, faire une liste détaillée des livrables du
management de projet (charte du projet, échéancier, référence de coûts, etc.) : ceci est
concret et porte du sens pour l’équipe de projet.
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
14
Identifier les parties prenantes et manager leurs
attentes
Théorie
Les points clés:
Qu’est qu’une partie prenante?
Les parties prenantes du projet sont les individus ou les
organisations qui sont activement impliqués dans le projet, ou
dont les intérêts peuvent êtres positivement ou négativement
affectés par la mise en œuvre ou par l’achèvement du projet. Ils
peuvent aussi exercer une influence sur le projet ou ses
résultats. Les parties prenantes sont typiquement:

Le chef de projet;

Le sponsor du projet;

Les clients ou les utilisateurs des produits du projet;

Les membres de l’équipe projet;

Les fournisseurs de biens et services;

Le gouvernement, les lobbies ou tout groupe d’influence.
Identifier les parties prenantes:
Les projets impliquent des parties prenantes ayant différents besoins et attentes.
Pour assurer le succès du projet, le chef de projet doit identifier toutes les parties
prenantes, déterminer et analyser leurs intérêts, attentes, influences et autorités
(Analyse des parties prenantes).
Les exigences non mesurables conduisent à de la subjectivité. Si la compréhension
de la partie prenante n’est pas la même que celle de l’équipe projet, alors il y a là
une source de conflits et de frustrations!
Les parties prenantes ont un intérêt fondamental dans le succès du projet mais
peuvent avoir des objectifs en conflit avec ceux du projet. Trouver des solutions
appropriées à ces différences et suivre l’évolution des situations peut être un défi
important du management de projet et requérir beaucoup de communication.
L’analyse des parties prenantes prend en compte non seulement les parties
directement concernées, mais aussi les influences indirectes de sources externes,
comme les lois, réglementations et normes, l’impact social, les facteurs politiques.
L’analyse des parties prenantes va permettre de détecter des risques à traiter (voir
Identification des risques du projet).
Pour chaque partie prenante, le chef de projet doit trouver les détails suivants:
 Position dans la société / pouvoir relatif et niveau de décision
 Relation vis-à-vis du projet (supporter/neutre/opposant)
 Niveau de connaissance (du projet) / niveau de détails à partager
 Intérêt dans le projet (positif/négatif)
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
15

Attentes / exigences
A partir de ce registre des parties prenantes, le chef de projet doit définir l’approche à
adopter pour maximiser les bénéfices (et minimiser les impacts négatifs) pour le projet.
Dans un grand projet, le chef de projet va s’intéresser particulièrement à certaines
parties prenantes en fonction de leur influence/pouvoir, de leurs intérêts et de leurs
appréciations du projet.
Le registre des parties prenantes est enrichi par une stratégie de management qui définit
la façon dont l’équipe de management du projet va gérer les parties prenantes. Cette
stratégie de gestion des parties prenantes peut être formalisée en une matrice…
… ou en un graphique.
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
16
La matrice et le graphique sont donnés ici à titre indicatif et doivent êtres adaptés aux
besoins de chaque projet.
Gérer les attentes des parties prenantes:
Au cours du projet, le chef de projet doit constamment gérer et influencer les
attentes des parties prenantes. Pour ce faire, il est important de s’appuyer sur les
livrables du projet qui ont été définis et convenus.
Ceci explique pourquoi il est important de disposer d’exigences mesurables de la part
des parties prenantes: «Augmenter les ventes en Asie» n’est pas une exigence
suffisamment claire (où en Asie? quels produits sont concernés? de quelle ampleur
doit être l’accroissement? et pour quand?).
L’absence ou la mauvaise définition des exigences conduisent à l’insatisfaction des
parties prenantes: celles-ci peuvent avoir sur les résultats attendus du projet une
compréhension différente de celle de l’équipe projet.
La meilleure manière d’arriver à une compréhension mutuelle est la communication.
Si vous ne communiquez pas correctement sur la structure de découpage du projet
(avec le bon niveau de détails), il n’y aucun chance que les attentes de la partie
prenante (en termes de périmètre) et la réalité du projet correspondent.
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
17
L’influence des parties prenantes est
maximale au début du projet (principalement
parce que le coût des modifications
augmente avec l’avancement du projet).
Pour mieux servir les intérêts des parties
prenantes, il est important de les impliquer le
plus tôt possible dans le projet.
Il est important de traiter les préoccupations
et problèmes de chaque partie prenante dès
leur apparition.
D’un autre côté, le chef de projet à la
responsabilité de préserver les objectifs du
projet (contenu, coûts et délais) des impacts
de modifications non nécessaires.
Autres concepts liés:

Planification: Constituer l’équipe projet

L’équipe projet: Communication

Identification des risques
Bibliographie:
Vous trouverez d’autres informations sur le sujet dans les ouvrages suivants:
PMBOK® Guide 4ième
édition:
2.3 Parties prenantes
10.1 Identifier les parties prenantes
10.4 Manager les attentes des parties prenantes
Comment faire
Comment pourrais-je savoir si un individu ou une organisation rencontrés dans
l’environnement du projet est une partie prenante?
L’individu ou l’organisation est une partie prenante si l’une des questions suivantes
génère une réponse positive:
 Est-ce que l’individu ou l’organisation sont activement impliqués dans le projet?
 Est-ce que les intérêts de l’individu ou de l’organisation sont positivement ou
négativement affectés du fait de la mise en œuvre ou de l’achèvement du projet?
 Est-ce que l’individu ou l’organisation exercent une influence sur le projet et sur ses
résultats?
Les parties prenantes sont typiquement:

Le chef de projet
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
18

Le client

L’entreprise réalisatrice du projet

L’équipe projet

Le commanditaire (mandant, sponsor)

Les consultants (internes ou externes)

L’utilisateur final (utilisateur ou consommateur des produits du projet)

D’autres, comme les financeurs, les fournisseurs, les entrepreneurs, les
détenteurs de brevets, les groupes d’intérêt collectif, les agences
gouvernementales, ou la société civile au sens large.
Comment faire l’analyse des parties prenantes?




Identifier les parties prenantes potentielles:

Identifier les parties prenantes directement impliquées dans le projet (client,
maître d’ouvrage, direction de l’entreprise, …)

Identifier les influences indirectes existantes dans l’environnement du projet
(utilisateurs finaux, gouvernement, réglementation, …)
Identifier les attentes des parties prenantes:

Recadrer les objectifs du projet avec l’aide des parties prenantes (prioriser et
catégoriser les besoins, désirs et attentes, etc.)

Faire apparaître les conflits entres différentes attentes des parties prenantes
Analyser les caractéristiques des parties prenantes:

Quel est le rôle de chaque partie prenante dans le projet?

Quels sont les compétences et le savoir de chaque partie prenante?

Quelles parties prenantes sont critiques pour la réussite du projet?

Quelle est le domaine d’influence (de pouvoir) de chaque partie prenante?

Quelles sont les motivations, forces et faiblesses des parties prenantes?
Identifier les stratégies des parties prenantes à partir de leurs rôles et en décrivant
leurs actions possibles.
Comment gérer les attentes des parties prenantes?
Après avoir réalisé complètement une analyse des parties prenantes:

Assurez-vous que les intérêts des parties prenantes qui ne sont pas
activement impliquées dans le projet sont bien représentés, par exemple les
utilisateurs finaux par un représentant des utilisateurs.

Dès le début du projet, résolvez les conflits sur les objectifs et les attentes, et
si nécessaire en faveur du client.

Utilisez les capacités des parties prenantes dans le projet de manière à les
motiver à y participer.

Utilisez la motivation et la prévention des crises comme critères principaux de
la planification des communications.
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
19

Définissez clairement les objectifs que le plan de management de la
communication doit atteindre pour chacune des parties prenantes.

Tout au long du projet, ajustez périodiquement le plan de management de la
communication aux évolutions de la situation.
Note: Ne pas oublier que manager un projet est aussi une affaire de marketing. Vous
devez continuellement vendre vos idées aux parties prenantes.
Exemple
Traitement des réclamations sur dommages automobiles
Après un accident d’automobile, le propriétaire du véhicule avertit
sa compagnie d’assurance, envoie le constat d’accident et amène
sa voiture dans un garage. Le garage envoie alors une réclamation
à la compagnie d’assurance. A la suite de l’acceptation de cette
réclamation, la compagnie d’assurance ouvre un dossier. Un
contrôleur interne détermine si le véhicule endommagé doit être
inspecté sur site, sélectionne un inspecteur interne ou externe à
partir d’une liste de partenaires. Cet inspecteur renvoie un rapport
final d’estimation des réparations à la compagnie d’assurance.
Celle-ci émet alors une autorisation de réparation au garage. Le
garagiste établit une facture qu’il envoie en retour à l’assureur qui
établit le règlement via la banque.
Le comité exécutif de la compagnie de traitement des réclamations sur dommages
automobiles, ClaimsPro, a décidé d’utiliser les technologies de l’information pour
automatiser et accélérer le processus entre les différentes parties prenantes. La
compagnie d’assurances AllInsure finance le développement. Le comité exécutif charge
le département informatique du projet, le département d’assurance qualité étant chargé
du contrôle qualité. Le Directeur informatique choisit Sandra comme chef de projet et
attire son attention sur les lois concernant la préservation des informations personnelles
dont elle doit tenir compte.
Dès le début du projet, Sandra commence l’analyse des parties prenantes. Dans une
réunion de brainstorming avec l’équipe de projet, elle détermine qui a un intérêt dans le
projet et identifie, en plus d’elle-même et de l’équipe de projet, les parties prenantes
suivantes:
 Les clients sont les compagnies d’assurance,
d’inspection, chacun avec des besoins différents.
les
garages,
les
bureaux
 AllInsurance est le comanditaire du projet de développement et aura à fournir un
représentant des assurances à l’équipe de projet.
 ClaimPro est le maître d’ouvrage, représenté par son Comité exécutif.
 Le département informatique est l’organisme en charge du projet, représenté par
le Directeur informatique.
 Sandra est chef de projet.
 Les propriétaires des garages et les inspecteurs sont les utilisateurs finaux, mais
ne participent pas activement au projet. De ce fait, un représentant des
utilisateurs doit être désigné au sein de l’équipe de projet pour protéger les
intérêts des garagistes et des inspecteurs.
 Un représentant du Département qualité va assurer le contrôle qualité.
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
20
 Un expert externe de la sécurité et de la protection des données personnelles
sera nécessaire.
 Les parties prenantes indirectes sont les automobilistes, la police et les
banques.
A la fin de la session de brainstorming, le graphique des parties prenantes est
établi comme suit:
L’équipe de projet comprend Sandra, les développeurs de logiciels, l’expert de la sécurité
des données, ainsi que les représentants des assureurs et des utilisateurs.
Check-liste
 Est-ce que les parties prenantes directes et indirectes sont identifiées?
 Y a-t-il un représentant désigné de chacune des parties prenantes qui ne participent
pas activement au projet?
 Est-ce que les objectifs du projet correspondent aux attentes des parties prenantes?
 Est-ce que les attentes sont claires et objectivement mesurables?
 Est-ce que les attentes contradictoires sont résolues?
 Est-ce que les capacités des parties prenantes ont été évaluées dans le contexte du
projet?
 Est-ce que les stratégies probables des parties prenantes ont été identifiées?
 Communiquez-vous régulièrement et de façon adaptée avec les parties prenantes?
 Existe-t-il formellement un plan de management de la communication fondé sur
l’analyse des parties prenantes, et est-il finalisé?
Pièges
 Parler uniquement à une catégorie de personnes peut conduire à omettre d’inclure
toutes les parties prenantes dans le projet.
 N’omettez pas d’inclure un représentant des utilisateurs finaux dans l’équipe de
projet.
 N’oubliez pas d’identifier clairement les conflits entre les attentes des différentes
parties prenantes.
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
21
 N’oubliez pas d’anticiper les actions des parties prenantes, comme leur agenda
caché, leurs résistances, leurs ambitions, les politiques d’entreprises, etc.
 L’absence de communication avec les parties prenantes conduit à des divergences
entre leurs attentes et la réalité.
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
22
Les influences organisationnelles
Théorie
Les points clés:
Tout projet est initié par un organisme (société, institution, agence gouvernementale,
etc.) qui a une grande influence et beaucoup d’interactions sur ledit projet.
Les principaux impacts d’un organisme sont en relation avec le management des
ressources, les modalités de prise de décision, les processus et procédures, ainsi que la
tolérance aux risques.
La majorité des entreprises a une organisation matricielle. Elles sont organisées par
ligne, spécialités ou unités fonctionnelles (division financière, département des ventes,
service électricité, etc.) et le chef de projet emprunte les ressources de ces entités pour
la durée du projet.
Lorsqu’une organisation matricielle possède une entité dédiée au management de projet,
elle est appelée «organisation matricielle forte».
Les autres modes d’organisations existants sont présentés à la fin de cette page.
En fonction de l’organisation de son entreprise, le chef de projet va avoir plus ou moins:

de pouvoir et d’autorité;

de responsabilité sur le budget;

de ressources disponibles et allouées au projet.
Les modes d’organisations les plus fréquents:
Organisation
Fonctionnelle
Description du positionnement du chef de projet
1) La société est organisée en unités fonctionnelles (“silos”).
2) L’initiative appartient principalement aux unités fonctionnelles.
Lorsqu’une initiative transversale apparaît, elle est coordonnée
par les responsables des unités fonctionnelles concernées.
Matricielle
1) Dans ce type d’organisation vont commencer à émerger les
chefs de projets. C’est alors une fonction reconnue mais
dispersée dans les différentes unités fonctionnelles. Parfois, le
management de projet peut être dans une entité indépendante.
2) Le pouvoir (gestion des ressources, contrôle du budget
notamment) est partagé entre les chefs de projet et les
responsables d’unités fonctionnelles. C’est à eux que les
équipiers des projets rendent compte.
3) Le chef de projet doit porter beaucoup d’attention à la
communication.
Par projets
1) Ce type d’organisation se retrouve dans certains domaines
économiques où toutes les activités de la société sont gérées
par projets (consultants, entreprises de construction, etc.).
2) Le chef de projet a une maîtrise totale sur le budget et dispose
d’une équipe totalement dédiée.
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
23
3) Ce type d’organisation est efficace d’un point de vue de
l’organisation du projet, mais ne gère pas les carrières des
équipiers du projet ni n’optimise l’utilisation des ressources.
Bibliographie:
PMBOK® Guide 4ième
édition:
2.4 Les influences organisationnelles sur le
management de projet
Comment faire
Comment adapter le management de projet?
Dans une organisation fonctionnelle, le management de projet est assuré par la ligne
managériale.
Dans une organisation matricielle faible, le chef projet (ou le coordinateur de projet) à la
responsabilité de:
1) prendre ses instructions de son supérieur hiérarchique et lui rendre compte de
l’état d’avancement;
2) gérer les ressources dans sa ligne managériale;
3) fournir les accords de règlement (procès verbaux de réception) à son
management;
4) collecter les détails justificatifs pour rendre compte à son management.
Dans une organisation matricielle équilibrée ou forte, le chef de projet va:
1) gérer la définition des objectifs à partir d’une bonne analyse des parties
prenantes;
2) rendre compte de l’état d’avancement du projet au management, au maître
d’ouvrage, à ses pairs et à l’équipe de projet (une communication à 360°);
3) négocier les allocations de ressources avec les responsables hiérarchiques
(ressource humaines, finances et logistique);
4) manager les contrats, habituellement en relation avec le département des achats
(établissement des contrats) et les services de contrôle (factures, règlements).
Dans une organisation par projets, le chef de projet doit:
1) gérer la définition des objectifs à partir d’une bonne analyse des parties
prenantes;
2) gendre compte de l’état d’avancement du projet au management, au maître
d’ouvrage et à l’équipe de projet;
3) élaborer ses besoins en ressources et les acquérir;
4) mettre en place les espaces de travail pour l’équipe de projet;
5) manager les contrats avec son équipe de projet (la délégation est possible).
Exemple
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
24
La banque Alpha est une organisation matricielle avec un département dédié au
management de projet.
Pour assurer l’efficacité du management de projet, les règles de fondamentales ci-dessous
ont été mise en place sur le management des parties prenantes et l’allocation de
ressources:
Management des parties prenantes:
Action
Avantages
Le chef de projet et le sponsor vont
établir ensemble une liste de parties
prenantes qu’ils ont identifiées et la
diffuser
pour
approbation
aux
différents responsables d’unité.
Il est difficile d’établir la liste des parties prenantes,
notamment lorsque le chef de projet est nouveau
dans la société. Ce processus simple, permet de
s’assurer qu’aucune partie prenante n’est oubliée.
Le sponsor est en charge de
collecter les exigences des parties
prenantes du business. Le chef de
projet est quant à lui en charge des
exigences relatives à la qualité et au
management du projet.
La responsabilité sur le management du contenu est
répartie et les exigences des parties prenantes sont
rationalisées (stream-lined).
Le comité de pilotage du projet
comprend le chef de projet, le
sponsor,
l’acheteur
affecté
au
projet, le directeur des opérations,
le directeur de l’unité du sponsor, et
toute autre personne pertinente
(relevant CxO) en fonction de
l’importance du projet.
Le but est d’avoir les parties prenantes essentielles
pour faciliter la prise des décisions au sein du
comité de pilotage.
Allocation des ressources:
Action
Avantages
Le chef de projet décide des besoins
en ressources nécessaires au projet
et transmet ses demandes de
ressources à la ligne managériale.
Aucune ressource ne doit travailler
plus d’une heure par semaine sur un
projet tant que la demande n’est
pas acceptée.
Les activités courantes de l’entreprise sont
protégées de la perturbation des projets tant qu’une
allocation officielle n’est pas faite.
Toute personne qui travaille plus
d’un mois sur un projet verra son
bonus annuel calculé en fonction des
performances
du
projet,
en
proportion du temps passé.
L’évaluation des performances et des bonus sont
effectués par le responsable hiérarchique et le chef
de projet en fonction du temps passé sur les
projets.
Une ressource ne doit pas être
allouée à plus de 80% sur un projet.
Si de plus elle occupe une fonction
de support, elle ne peut alors être
allouée à plus de 50%.
La disponibilité des ressources est plus proche de la
réalité lorsque ces ratios sont respectés.
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
25
Check-liste
 Qui
1.
2.
3.
4.
est responsable de coordonner les projets?
La ligne hiérarchique/les directeurs  organisation fonctionnelle;
Un adjoint dans la ligne hiérarchique/du directeur  organisation matricielle faible;
Un chef de projet dans une unité fonctionnelle  organisation matricielle équilibrée;
Un chef de projet dans un département de management de projet  organisation
matricielle forte.
 A qui rendent compte les membres de l’équipe de projet?
1. Ils ont un seul patron, leur responsable hiérarchique  organisation fonctionnelle ou
matricielle faible;
2. Ils ont deux patrons, leur responsable hiérarchique et le chef de projet 
organisation matricielle équilibrée ou forte;
3. Ils ont un seul patron (ou pas de patron du tout lorsqu’ils ne sont pas sur un projet)
 organisation par projets.
 Est-ce que les canaux de communication sont bien clarifiés (dans une organisation
matricielle)?
 Est-ce que des modalités d’allocation des ressources existent (particulièrement dans une
organisation matricielle)?
 Est-ce que les modalités d’allocation des ressources traitent de leur libération?
Pièges
 N’attendez pas plus de pouvoirs que ceux que l’organisation peut vous donner.
 N’oubliez pas d’adapter le processus de prise des décisions au type d’organisation dans
lequel vous évoluez.
 Ne sous-estimez pas les besoins en communication dans une organisation matricielle.
 Attention: dans une organisation matricielle, vous êtes responsable du projet, mais vous
n’avez pas un contrôle direct sur le personnel. Vous dépendez de la bonne volonté des
responsables hiérarchiques – cette situation conduit évidement à des conflits sur
l’allocation des ressources.
 Dans une organisation matricielle, il y a un risque majeur: celui que le personnel soit
embarqué dans son travail quotidien, qui est souvent urgent, et néglige ses tâches sur le
projet. Suggérez-leur de changer de bureau lorsqu’ils travaillent sur le projet.
 Dans une organisation par projets, le personnel peut être au chômage à la fin du projet.
Vous devez donc prévoir un plan de démobilisation des ressources et faire attention à
leurs préoccupations.
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
26