Figure 12 : processus de gestion des risques
Comme toute méthode de projet qui se respecte, le GPP d’AIRBUS comprend une partie gestion des risques, très détaillée et très structurée.
Cette gestion des risques, comme c’est souvent le cas, est très inspirée du CMMi.
Le management et les responsables qualité AIRBUS sont très attachés à la gestion des risques. Et ce que disent les correspondants qualité aux chefs de projet c’est « si vous ne devez faire qu’une chose en matière de gestion de projet, c’est gérer vos risques ».
Je me rappelle également que lors de mon entretien de sélection sur ce poste de chef de projet, on m’avait posé la question suivante : quels sont selon vous les risque principaux qui pèsent sur ce type de projet et que quelles actions proposeriez-vous pour gérer ces risques ?
J’ai toujours pensé que ma réponse avait pesé de manière importante dans mon recrutement. J’avais répondu que chaque migration unitaire prise séparément était assez facile. Mais que la difficulté du projet résidait principalement dans le nombre d’applications à prendre en charge en simultané.
Je proposai donc de lisser l’activité de migration dans le temps en commençant par les applications les plus simples à migrer. Le processus de migration vous sera présenté en détail Chapitre 6.
La gestion des risques chez AIRBUS est normalement formalisée par le responsable de projet, qui agrège l’ensemble des risques d’un projet, dans un livrable du GPP, le RIA (risk, issue, action follow up).
Figure 13 : liste des risques identifiés sur le projet
Il suit également les actions qui en découlent et communique sur ces risques aux responsables métier et à la hiérarchie. Dans un premier temps, mon action en matière de gestion des risques, a été d’identifier les risques pesant sur mon activité avec le responsable du projet et mes collègues, et de proposer des actions ou des procédures pour gérer ces derniers.
J’étais juste responsable de prendre en compte et de minimiser l’impact et l’occurrence des risques pesant sur mon domaine d’activité en suivant et coordonnant les différentes actions de mitigations validées.
Chaque responsable de Work package devait s’acquitter de la même activité sur son périmètre. Dans ce document nous suivions également l’ensemble des tâches importantes du projet, même si elles n’étaient pas liées à des risques.
Figure 14 : liste des taches suivies sur le projet
Chaque tâche avait un work package de rattachement et une personne responsable de son bon déroulement
Lors de notre point projet hebdomadaire, nous suivions l’ensemble des actions ouvertes. Nous faisions un point d’avancement pour chacune, discutions si nécessaire de la meilleure façon de prendre chaque tâche en charge. Le document était mis à jour en séance et chacun prenait note des actions qui lui revenaient et de leurs échéances.
Lorsque nous n’avons plus eu de responsable de projet, plus personne ne s’occupait de la gestion des risques. Il m’a alors été demandé de remplir cette fonction.
J’ai donc eu un certain nombre d’entretiens avec des correspondants qualité afin de connaître en détail les processus, outils et documents utilisés chez AIRBUS pour gérer les risques.
Puis, j’ai initié et suivi la gestion des risques sur l’ensemble du projet.
A ce moment-là, il ne restait que quelques tâches d’infrastructure à réaliser en plus des activités liées à mon domaine : la migration des applications.
C’est donc moi qui lors de nos comités de pilotage balayait l’ensemble des actions encore en cours, je présentais l’ensemble des tâches que j’avais réalisées dans la semaine, et vérifiais, demandais aux autres personnes en charge de parler de leur activité dans ce domaine. Je mettais également à jour notre document de suivi. Je clôturais les actions terminées et rajoutais les nouvelles actions et les nouveaux risques.
Figure 15 : gestion des actions dans l’espace SharePoint projet
Avec les responsables qualité et notre manager, nous avons décidé de gérer les risques et les actions dans le SharePoint projet plutôt que sur fichier Excel.
Cela nous offrait une solution plus souple et collaborative. Et cela me permettait de travailler avec les derniers outils disponibles en la matière chez AIRBUS.
Une expérience réutilisable lors de mes prochains projets.
J’ai ainsi notamment découvert les workflow pré définis dans SharePoint et notamment les workflows de validation de document. Ce workflow est utilisable pour tous les documents présents sur l’espace SharePoint projet.
Comme il n’est utilisable qu’avec des personnes ayant accès au SharePoint projet, il n’aurait pas été utilisable pour suivre mon activité de migration qui impliquait environ 400 personnes différentes.
Par contre cet outil aurait été utile pour toutes les validations internes à l’équipe projet. Les livrables des différents Jalon et les différents processus que nous avons mis en place.
5.1 Exemples d’actions de couverture des risques
Risque 0 : trop d’application à gérer en même temps, impact sur la qualité du support, la capacité à réaliser les migrations. Action associée pour couvrir le risque
Figure 16 : risque et action associée
J’ai proposé de couvrir ce risque par l’utilisation d’un processus de migration dont le détail vous est présenté ci-après
Ma préoccupation principale en définissant ce processus était, comme durant la phase de maquette, de garantir un niveau de support optimal tout en lissant la charge pesant sur les équipes du centre de compétence Citrix. Je souhaitais également lisser les migrations dans le temps afin d’adapter le nombre de serveurs nécessaires au planning de livraison.
Risque 8 : Impact d’un retard sur la mise en place du processus de gestion des accès externes sur la migration des applications. Action associée pour couvrir le risque
Figure 17 : risque et action associée
La non-disponibilité des accès externe des accès externes aurait empêché l’entrée et service des applications avec des utilisateurs en dehors du LAN AIRBUS. Or les premières applications que j’avais choisi de migrer étaient impactées. Elles étaient pilotes tant pour le projet RDSEVo que pour les accès externes. Leur migration était peu complexe, mais elles avaient absolument besoin
J’ai donc suivie de manière particulièrement fine la mise en place de ces accès. Le risque et l’action sont clôturés car à ce jour les accès externes ont été validés pour tous les pilotes.