Quelle est votre fonction actuelle, quelles sont vos missions ?

Je suis gérant de la société unipersonnelle Oraone. Je suis consultant sénior, chef de projet et formateur. Historiquement, j’ai un diplôme d’ingénieur en informatique qui m’a permis de développer ces métiers.

Comment avez-vous connu AgilePM, quel était votre besoin initial ?

Je souhaitais élargir mes connaissances sur la partie agile de la gestion de projet. j’avais déjà commencé à étudier et appliquer les Bonnes Pratiques en gestion de projet comme PMP puis PRINCE2, en mode plutôt traditionnel, mais je souhaitais découvrir le monde agile et voir ce que ces méthodes et techniques pouvaient m’apporter dans le cadre de mes projets.  J’ai suivi un cursus de formation PSD mais j’étais resté sur ma faim, au niveau de la gestion de projet, notamment en ce qui concerne la gouvernance. J’ai alors suivi une formation AgilePM, basée sur le framework DSDM, où j’ai pu retrouver le côté rigoureux de la méthode PRINCE2 mais avec les spécificités d’une gestion de projet agile.

Avez-vous utilisé la méthode AgilePM, suite à votre formation, pour gérer certains projets ? 

Oui absolument, je peux citer l’exemple de mon premier projet avec AgilePM, qui est d’ailleurs toujours d’actualité. C’est un projet de moyenne envergure, dans le secteur de l’aéronautique et qui perdure dans le temps. Ce projet avait démarré selon la méthode PRINCE2, qui se prêtait particulièrement bien aux besoins et exigences de l’époque. Cependant, nous avons rencontré pas mal de problèmes tout au long du projet, notamment des problèmes d’interconnexion avec l’IT,  mais également des problématiques de performance, de sécurité… Pour y remédier, l’équipe informatique de mon client s’est formée à la méthode AgilePM, ce qui a permis d’améliorer la collaboration entre les différents services et de définir de nouveaux rôles, nécessaires au bon déroulement du projet. Un business analyst du département IT a par exemple été mis en place et détaché sur la business unit aviation. A partir de là, tout s’est simplifié, aussi bien le travail, que l’intégration entre l’IT et les métiers.

Une fois le premier produit livré, il y a eu des mises à jour tous les ans, d’où l’utilité de passer en mode agile pour gérer la suite du projet, puisque l’agilité se positionne très bien sur la mise à jour d’un existant, son amélioration continue. Attention cependant, agilité ne veut pas dire aucun contrôle et c’est là la force d’AgilePM. En effet, la méthode nous a permis, aussi bien à moi, consultant/fournisseur externe, qu’au service informatique ainsi qu’à  la business unit avion,  de garder une documentation rigoureuse, de mettre en place un processus de suivi efficace et de ne pas perdre toute la rigueur mise en place sur la première version du produit. Nous avons également tiré parti des réunions régulières agiles, ce qui nous a permis de mieux travailler ensemble, en équipe.

Quelles étaient vos contraintes, vos challenges ?

D’une part, il y avait le challenge d’améliorer les relations de travail avec le service informatique, pour que l’intégration et les mises à jour du produit se passent bien. La formation AgilePM de l’équipe a permis d’apporter une vision et des valeurs fondamentales communes, de faciliter les relations, crée un lien entre les différents services et business unit et d’accélérer, de fluidifier le projet.

D’autre part, AgilePM a facilité le fait de passer en amélioration continue, ce qui nécessite de travailler sur un backlog d’améliorations possibles, donc une liste d’exigences priorisées. AgilePM est la méthode idéale pour cela puisqu’elle inclut ces techniques Agile : la priorisation MoSCoW et le Timeboxing. Au début de chaque version, nous pouvions prendre ce backlog et prévoir ce que l’on allait faire sur le prochain incrément.

Finalement, lorsqu’on travaille sur l’amélioration continue, l’agilité devient presque une nécessité, du moins elle se prête parfaitement aux besoins. Le cadre Scrum aurait peut-être pu faire l’affaire pour ce projet mais ne permettait pas la rigueur imposée par AgilePM. De plus, il y a 3 rôles dans Scrum, alors qu’AgilePM en compte une dizaine, ce qui permet de bien positionner des rôles qui seraient du côté IT, des rôles fournisseurs, clients, et métier. On voit très bien cette déclinaison des différents rôles qui sont très importants à partir du moment où on est dans un projet. Si on ne fait que du développement, sur des produits existant avec des petits backlogs de produits à corriger, alors on peut faire du Scrum mais pour la gestion de projet, je préconise la méthode AgilePM, qui permet l’interaction de différents rôles, de bien savoir qui fait quoi et de pouvoir s’interconnecter. Si je prends mon exemple, en tant que fournisseur et également soutien en gestion de projet, j’avais besoin d’avoir des SPECs précises sur les exigences et une rigueur de gestion.

Comment s’est passée l’implémentation de la méthode ?

L’implémentation s’est passée assez facilement puisque l’équipe IT avait été formée et l’équipe de la business unit avion connaissait la méthode (je pouvais également les aider dans ce sens). Nous avons pu commencer immédiatement à définir clairement les rôles, à décomposer la liste des exigences, à suivre les progrès lors des réunions périodiques d’avancement, tout en maintenant la documentation mise en place, à jour.

Le business analyst à joué un rôle clé dans le succès du projet, en étant disponible pour soutenir le projet et faciliter la compréhension entre tous les départements (IT et métier).

Je trouve important d’insister sur ce rôle, que l’on retrouve dans AgilePM et pas forcément dans d’autres méthodes agiles. Etant donné qu’il y avait eu, initialement, quelques difficultés de communication entre l’IT interne et la business unit aviation (l’entreprise étant grande, le département IT doit interagir avec de nombreuses business unit, pas seulement la partie aviation) le choix du business analyst à été crucial. Le business analyst en question comprenait très bien les enjeux des diverses parties prenantes dont  les besoins de la BU avion notamment de modernisation de leur documentation (favorisé par le fait qu’il était sur le site) et les besoins/limites/contraintes du service informatique.

Comment la méthode AgilePM vous a-t-elle aidée ? Quelle partie vous a été la plus utile ?

Divers éléments de la méthode nous ont aidé, d’une part la rigueur imposée par AgilePM pour maintenir la qualité de la documentation, mais également les valeurs fondamentales communes à tous, qui ont facilitées la communication et la collaboration des équipes. A cela s’ajoute l’importance des rôles, nécessaires à la répartition des tâches mais surtout des responsabilités. Enfin et c’est le point clé de la méthode, selon moi, l’efficacité des techniques agiles “MoSCoW” et le “Timeboxing” sur lesquelles s’appuie AgilePM.

En effet, AgilePM repose sur la combinaison MoSCoW/ Timeboxing, que l’on peut retrouver ou utiliser en dehors d’AgilePM, mais au moins cette méthode a le mérite de clairement définir ces techniques  comme essentielles. Sans la technique MoSCoW, les équipes ne peuvent pas livrer à temps à la fin de la timebox. Ces techniques permettent de définir la durée d’une timebox et de s’engager à livrer les “MUST” à la fin du temps défini. Cela oblige le client à structurer son besoin, à l’explicité en termes de fonctionnalités “absolument nécessaires” (vitales), “devraient être faites” (essentielles), “pourraient être faites (cerise sur le gâteau) et “ne seront pas faites cette fois mais peut-être plus tard”. Avec AgilePM, la durée est fixe alors qu’avec les méthodes traditionnelles, on a tendance à repousser la date de livraison lorsque le temps manque. Par conséquent, avec AgilePM, l’équipe livre, peut-être un peu moins à la fois, mais en temps, les éléments prioritaires.

Avez-vous rencontré des réticences au changement et à la transformation agile ?

Nous avons fait face à une réticence classique à l’agilité, c’est à dire que le sponsor, qui joue un rôle financier et donne son accord pour le budget, souhaite très souvent que toutes les priorités soient des “MUST”. Il y a donc une réticence à comprendre qu’il va payer pour des choses qui “pourraient” seulement être livrées. Dans le cadre de notre projet, par exemple, la responsable de la documentation devait proposer le projet et le budget pour qu’il soit accordé par la direction (le sponsor). Il s’est avéré qu’il était difficile de faire comprendre et accepter un budget  si on a pas évangélisé en amont sur l’agilité au niveau des décisionnaires et expliqué comment fonctionne l’état d’esprit de la gestion de projet agile.

Avez-vous des conseils pour les professionnels du secteur ?

On se rend compte qu’un projet comme celui-ci, qui aurait peut-être pu être réalisé purement en mode traditionnel d’un seul trait, sur deux ou trois ans, n’aurait pas été aussi efficace au bout du compte. En effet, grâce à l’agilité, ce projet à été effectué sur cinq ans, de manière incrémentale, en accueillant les feedbacks clients après chaque version, ce qui a conduit à de gros changements stratégiques, à des améliorations continues créant de la valeur et à une solution parfois éloignée de celle pensée au départ, mais qui finalement correspond et répond parfaitement au besoin du client. Ceci n’aurait pas forcément été le cas en suivant une méthode de travail traditionnelle.