« Le déploiement d’une nouvelle méthodologie de gestion de projet doit être considéré comme un projet à part entière : ce projet a des objectifs, des moyens, un sponsor, des risques, des acteurs. »
La liste des qualités que doit avoir un bon chef de projet est très longue. Trop longue même : rigueur, disponibilité, pragmatisme, sens du leadership, diplomatie, proactivité, ouverture.
Ce que résume Véronique Messager Rota par : « Dans un environnement complexe, contraint par le time to market, il doit (faire) développer un produit au moindre coût dans des délais de plus en plus courts avec une qualité irréprochable. » A ces multi-compétences s’ajoute le fait que le chef de projet est souvent seul.
« Seul lorsqu’on lui demande d’estimer pour hier le coût d’un projet sur la base d’un e-mail de quelques lignes, seul lorsqu’il demande une ou deux ressources supplémentaires et qu’aucune n’est disponible, ou lorsque l’on affecte sans délai l’un de ses collaborateurs à un autre projet plus urgent », souligne l’auteur. Cela explique peut-être pourquoi seulement 25 à 30 % des projets sont considérés comme des succès.
Gestion de projet, vers les méthodes agiles, par Véronique Messager Rota, Eyrolles, 2007, 252 pages.
Certitude de l’incertitude
Manager un projet, c’est avoir « la certitude de l’incertitude », qui s’exprime dans tous les domaines : les exigences des clients, la psychologie des individus, leur productivité, la maturité des technologies, la dérive des plannings… S’il faut « accepter l’incertitude », il importe surtout de s’adapter et anticiper.
L’un des axes d’action réside dans le choix des méthodologies de gestion de projet : faut-il privilégier les méthodes traditionnelles ou opter pour les méthodes agiles ? Depuis des décennies, nous explique l’auteur, « les projets sont gérés avec une approche classique, en cascade ou en « V », basée sur des activités séquentielles » : recueil des besoins, définition du produit, développement, test et livraison.
L’un des travers de cette approche réside dans la nécessité de tout planifier, d’où son nom « d’approche prédictive ». Autre effet pervers : « Cela conduit les acteurs d’un projet à redouter, voire à s’opposer systématiquement à tout changement, dans le contenu, le périmètre, le processus de développement ou les membres de l’équipe.
La rigidité de l’approche en cascade ne permet pas des retours en arrière. Et elle crée des effets tunnel : Un projet dure un an, la phase de recueil des besoins dure deux mois et le client ne vit le résultat que neuf mois plus tard ! ». Sans parler d’une détection tardive des risques et de la nécessité de produire « une documentation pléthorique. »
Pour l’auteur, les méthodes agiles, popularisées aux Etats-Unis au début des années 2000, constituent une alternative à ce contexte de rigidité. Elle les définit comme des « approches itératives et incrémentales, qui sont menées dans un esprit collaboratif, avec juste ce qu’il faut de formalisme ».
Principe : on découpe un projet en plusieurs étapes d’une durée de quelques semaines. Pour chaque itération, une version minimale du projet est développée puis soumise, dans sa version intermédiaire, au client pour validation. « Chaque itération est un mini projet en soi qui comporte toutes les activités de développement, menées en parallèle. »
Au terme de la dernière itération, on obtient le produit final. Cette démarche présente, selon l’auteur, plusieurs avantages : « La communication est de meilleure qualité, de même que la visibilité, la qualité est évaluée en continu, les risques sont détectés plus tôt, l’équipe prend confiance et les coûts sont contrôlés. »
Désigner un projet pilote
Selon le Manifeste pour le développement logiciel agile, ces méthodes se caractérisent par la priorité donnée aux individus sur les processus et les outils, aux fonctionnalités opérationnelles sur la documentation, à la collaboration sur la contractualisation et sur l’acceptation du changement concernant la conformité aux plans.
Il existe plusieurs méthodes de développement agile, dont les plus connues sont ASP (Adaptative Software Development), Crystal, DSDM (Dynamic Software Development Method), RAD (Rapid Application Development), Scrum, UP (Unified Process) et XP (eXtreme Programming). Toutes ces approches ont en commun un « apport supérieur de valeur ajoutée, une amélioration de l’adaptabilité, de la visibilité, une réduction des risques et une meilleure qualité logicielle », résume l’auteur. Comment faire pour adopter une méthode agile ?
Avant tout, conseille Véronique Messager Rota, « le déploiement d’une nouvelle méthodologie de gestion de projet doit être considéré comme un projet à part entière : ce projet a des objectifs, des moyens, un sponsor, des risques, des acteurs ». La démarche conseillée regroupe quatre grandes étapes.
La première consiste à dresser l’état des lieux (recenser les zones de dysfonctionnement, poser les bonnes questions, identifier les facteurs clés de risques et de réussite). La seconde phase fixe les objectifs, avec deux questions clés : comment mesurer le succès de la démarche et quels sont les symptômes de l’échec de la démarche ? Troisième étape : le démarrage.
Sur ce terrain, l’auteur conseille de désigner un projet pilote, de nommer un « champion », de bien choisir la méthode, les pratiques et les outils, en veillant aux aspects évaluation, adaptation et communication.
Enfin, la quatrième phase correspond à l’initialisation du changement (qui convaincre, quelles objections vont être formulées, comment vaincre les résistances ?). Il faut, conseille également l’auteur, « faire simple : en introduisant de nouvelles pratiques une par une, vous avez le temps d’expérimenter chacune d’elles et d’en analyser l’effet ».
Dix idées à retenir
- Une démarche adaptative, basée sur le feedback du client, l’expérience, le constat, l’analyse tout au long du projet, l’humilité et la simplicité pour reconnaître qu’on ne sait pas tout, porte ses fruits.
- Parmi les sources d’échecs figure la faible professionnalisation de la maîtrise d’ouvrage. En général, celle-ci est peu sensibilisée à la complémentarité de son rôle. Elle n’a pas toujours conscience de l’importance de l’implication et de la disponibilité des utilisateurs.
- L’approche en cascade est trop rigide pour permettre des retours en arrière : elle suppose que l’on fasse bien du premier coup.
- Afin de se prémunir contre les risques, l’approche en cascade s’attache à la production d’une documentation importante. La documentation permet de repousser le moment où il va falloir aborder la phase de codage, phase irréversible.
- Les itérations se succèdent et ne peuvent être parallélisées : elles correspondent à des « tranches de temps » ou des « boîtes de temps » dont la date de fin est fixe.
- La nature des relations entre les acteurs est source de mauvaise communication : les relations contractuelles sont érigées comme un rempart en cas de litige. L’énergie est alors consommée pour savoir « comment faire pour que l’échec ne me soit pas imputé », alors qu’elle serait utilement exploitée à déterminer les moyens de faire en sorte que le projet n’échoue pas.
- Une sous-estimation initiale entraîne un sous-effectif et des retards et/ou une dégradation de la qualité globale des livrables. A l’inverse, une surestimation augmente le coût et la durée du projet, car les marges de sécurité sont toujours consommées.
- Ne pas confondre charge et durée : si l’effort nécessaire pour une tâche est estimé à 5 jours-hommes, sa durée peut varier selon le nombre de ressources affectées à cette tâche.
- Ce n’est pas parce que l’on affecte le double de personnes que le projet dure deux fois moins longtemps. Pour estimer le délai, on peut utiliser la formule de McConnell : délai en mois = 2,5 x [(charge exprimée en mois-hommes) puissance 1/3]. Par exemple, pour une charge de 41 mois-hommes, la durée est de 8,6 mois.
- Une démarche vers l’agilité n’est pas incompatible avec la contractualisation au forfait, ni une certification CMMI, ni un projet offshore.