Il vaut mieux prévenir que guérir. Cette locution pourrait résumer l’objectif de la gestion des risques au sein d’un projet ; anticiper les difficultés, tenter de les maitriser et ainsi éviter qu’elles deviennent de réels problèmes.
Néanmoins, malgré tous les efforts qui seront mis en œuvre dans la prévention, des problèmes surgiront, inévitablement.
Une détection au plus tôt permettra de réagir rapidement et limiter les impacts. C’est tout l’objectif de la gestion des alertes de projet que je vous détaille dans cet article.
Qu’est-ce qu’une alerte de projet ?
Une alerte de projet est avant tout un signal, émergeant d’une partie prenante du projet, adressé à l’équipe et plus particulièrement au chef de projet.
Ce signal, s’il est très explicite sur sa criticité, peut indiquer un danger immédiat pour le projet (la détection d’une non-qualité majeure sur un livrable ou encore le retard d’une tâche sur le chemin critique).
Mais de manière plus insidieuse, une simple information peut dissimuler une alerte. (Le mécontentement d’une partie prenante, la fatigue d’un membre de l’équipe, un début de démobilisation).
À noter que si l’article se concentre sur l’alerte à connotation négative, cette dernière peut néanmoins signaler un évènement positif pour le projet : par exemple une ressource disponible, une baisse de prix, une activité terminée plus tôt que prévue.
Ainsi, en lien avec la gestion de risque :
- Une alerte négative conduit à un risque ou un problème
- Une alerte positive conduit à une opportunité
Modèle de la Matrice des risques
Analyser et évaluez les risques projet avec une étude de cas.
Cette vidéo vous récapitule les points clés pour maitriser une alerte projet et quelles aptitudes adopter en cas de crise :
Quel type d’alerte faut-il prendre en compte ?
Périmètre, échéancier, budget, ressources, communication… Aucune facette du projet n’est épargnée par une alerte potentielle.
Et pour complexifier le tableau, les domaines du projet étant étroitement liés, le signal affectera le projet en cascade.
Prenons un exemple.
Concrètement, une alerte remontée sur le périmètre (un besoin oublié par exemple) affectera vraisemblablement le planning (nouvelles activités à considérer), les ressources (besoin de développement additionnel) et par conséquent le budget (hausse des coûts).
De la même manière, une alerte budget (restriction budgétaire demandée par la direction) pourrait avoir un impact sur le périmètre (diminution du périmètre) ou la qualité (baisse des tolérances) et ressources (redimensionnement de l’équipe).
Découvrez ici comment la triple contrainte d'un projet : périmètre, coûts, délais.
Enfin, en termes de fréquences, l’alerte peut être remontée à tout moment, quelle que soit la phase du projet, dès le kick-off, jusqu’à la clôture.
Sous quelle forme l’alerte est remontée à l’équipe ?
La remontée d'alerte fait partie de la gestion d'incidents.
Peu importe la manière de la remontée d'alerte de projet, du moment que le signal est entendu et intégré par l’équipe projet.
Nous sommes ici dans le domaine de la communication en mode projet. Celle-ci peut prendre deux formes différentes :
1) La communication formelle
Les réunions de comités projet (COPRO, COPIL, COSUI etc), les comptes rendus de réunions, le reporting.
Dans ce type de communication, l’alerte projet est souvent explicite et généralement vite intégrée pour les raisons suivantes :
- Elle est partagée avec un certain nombre de parties prenantes.
- Elle est clairement formulée et souvent mise en exergue dans les supports.
En savoir plus sur la comitologie de projet.
2) La communication informelle
On entend par là, les mails, téléphone, SMS, réseaux sociaux, discussions...
Alors que la remontée d'alerte projet lors d'une communication formelle est souvent bien explicite, elle est plus difficile à détecter lors d'une communication informelle.
Et ce, pour les raisons suivantes :
- Peu de parties prenantes sont intégrées dans la discussion/le message
- Le signal a été remonté à une personne extérieure au projet
- Le canal de communication pour remonter l’alerte est mal choisi
- Lors d’une conversation orale, certains signaux n’apparaissent que dans le langage corporel
Qui peut remonter une alerte projet ?
Remonter les alertes projet n’est pas la mission d’une seule personne.
Toutes les parties prenantes, qu’elles soient internes ou externes à l’organisation sont susceptibles de signaler une préoccupation, voire un danger.
Parties prenantes internes à l’organisation :
- Le chef de projet
- Un membre de l’équipe projet
- La direction
- Le bureau des projets (PMO)
- Le client
- Les utilisateurs finaux
- Les services transverses (commerce, RH, finance, achats)
Parties prenantes externes à l’organisation :
- Le client externe
- Les prestataires
- Les concurrents
- Les pouvoirs publics
Il est d’ailleurs intéressant de ne pas brider les signaux et en favoriser la remontée par un maximum d’acteurs.
En effet, il serait dommage de passer à côté d’une alerte structurante pour le projet.
Comment gérer les alertes d'un projet ?
Le caractère inopiné d'une alerte fait qu’il peut être difficile de maitriser sa gestion.
Néanmoins, il est recommandé d’organiser son pilotage, de la collecte jusqu’au traitement.
1) Collecter les alertes
Nous avons vu précédemment que la communication était importante dans le processus d’alerte.
C’est donc à la base, dans le plan de communication que l’équipe peut formaliser les modalités de collecte.
C’est-à-dire définir de quelle manière les parties prenantes vont remonter les signaux à l’équipe tout au long du projet.
Quelles étapes pour mettre en place la collecte des alertes projet :
- Lors du kick off, sur la base d’une matrice SWOT, collecter les premiers signaux
- Bâtir le plan de communication du projet et définir les règles de transmission des alertes
- Lors des comités de suivi et comités de pilotage, collecter les nouvelles alertes potentielles tout au long du projet.
À noter que ce plan d’action s’adapte particulièrement à la communication formelle.
La communication informelle est plus difficile à cadrer. Le chef de projet devra dédier du temps pour « capter » les signaux d’alerte :
- En externe, téléphoner aux clients, aux prestataires
- En interne, discuter fréquemment avec les parties prenantes, et déclencher des enquêtes de satisfaction
L’ensemble des remontées d'informations pourra être consigné dans un tableur avec les informations de base suivantes :
- Une description
- L’émetteur
- Le potentiel impact : périmètre, planning, coût, etc.
Modèle du plan de communication projet
Remontez les informations projet aux parties prenantes en utilisant la bonne stratégie.
2) Traitement des alertes
Après la collecte d’alerte, il existe deux issues principales :
- Soit l’alerte soulève un nouveau risque pour le projet
- Soit l’alerte vient matérialiser un risque déjà identifié ou non
2.1) Un nouveau risque pour le projet
Nous entrons dans le domaine de la gestion des risques.
Le chef de projet doit maintenant analyser le signal remonté à l’équipe et définir si celui-ci constitue un risque pour le projet.
Si tel est le cas, il devra apporter une réponse au risque :
- Analyser qualitativement et quantitativement : c’est-à-dire définir l’impact du risque (notamment financier) et définir la criticité et la probabilité
- Identifier les options de réponse au risque (élimination, transfert, atténuation, acceptation)
- Surveiller le risque (mettre en place les plans d’actions selon la réponse choisie et suivre son avancement)
Découvrez ici comment analyser et évaluer les risques projet.
2.2) La matérialisation d’un risque déjà identifié
C’est ce qu’on appelle un problème.
La gestion est similaire au risque, mais le caractère réel et immédiat le rend prioritaire dans le traitement.
Si un risque était déjà identifié au préalable, la criticité et l’impact sont déjà connus. Les options de réponse également. Il faut donc activer le plan d’action défini.
Si aucun risque n’était identifié, alors le problème devrait être traité d’une manière identique aux risques, mais avec un plan d’action immédiat.
Conclusion
Nous avons vu que la gestion des alertes de projet est très étroitement liée à la gestion des risques.
Mais avant tout, la communication au sein du projet a un rôle essentiel dans le processus de collecte.
Ainsi, pour détecter au plus tôt les risques et les problèmes potentiels, le chef de projet devra soigner son plan de communication, aller à la rencontre des parties prenantes et pratiquer une écoute active pour stimuler la remontée des alertes.
Le rôle du CP est de faire en sorte que tous les contributeurs partagent le même objectif : la réussite du projet. Cela nécessite l’exitence d’une vision commune du planning, du budget et du scope. Tout risque sur ces 3 éléments doit être remonté et traité.
A noter que certaines alertes peuvent être remontées de façon automatique en fonction des outils utilisés pour la gestion du projet.
Gérer un projet, c’est prévenir et c’est chercher à garantir la réussite et le développement de toute une nation mais sa réussite repose sur certaines principes.