Toute tâche n’est pas un projet, de même de simples activités ne sont pas de projets bien que désignées volontairement parfois comme tels de manière exagérée. Lorsque que des tâches rudimentaires sont réalisées suivant le mode projet il en résulte des charges inutiles au regard de la simplicité de la solution.
A l’inverse minimiser la complexité de la tâche qui relève d’une réelle gestion de projet peut conduire à beaucoup de désagréments.
Qui ne s’est pas félicité après- coup de ne pas avoir cédé à la facilité et la pression d’exécution induites par les propos du client, demandeur ou commanditaire du genre :
-
"Ce n’est qu’un petit projet pas la peine d’y consacrer trop de temps".
-
"J’ai besoin de modification et d’amélioration sur mon système de facturation des temps, tu peux me le faire pour quand" ?
-
"Pourquoi dois-je vous fournir une description précise de mon besoin, de ce que j’attends ; habituellement quand je demandais quelque-chose, on le faisait comme ça entre nous sans avertir la hiérarchie. Je ne vois pas l’intérêt de procéder à toutes ces étapes et cette documentation car j’ai besoin de pouvoir disposer de ces nouvelles fonctionnalités très rapidement".
Or par expérience un projet ne se fait pas en mode va-vite, dans un coin, sur un bout de table, sans communiquer, sans interactions, en gommant la notion de planification, de budgets (typiques des projets interservices au sein d’un groupe), voire de période ou phases de tests, mais bien d’une manière structurée avec une méthodologie propre, adaptée, commune qui décidera de la charge de management, des méthodes, des ressources et des outils à mettre en œuvre.
Quelle méthode ? Pour quoi faire ? Dans quels cas ?
Bien sur la procédure employée érigée au rang de la méthode dépend des caractéristiques « Projet » (taille, complexité, type, etc…) mais aussi de l’attitude adoptée souvent dans le domaine du développement informatique.
N’avez-vous pas été parachuté sur des projets en cours où l’attitude des programmeurs était de faire fonctionner le logiciel à tout prix en s’amendant de spécifications, de commentaires du code, en exauçant directement les demandes du client lequel s’exprime avec eux directement au téléphone ou par mail ? Derrière cette apparence de légèreté, de travail sans filet pour certains, qui si elle ne se bornait qu’à cela serait dangereuse, gage d’échec et d’insatisfaction du client, il y a là une méthode baptisée « d’Extreme Programming » qui ralliera la famille des méthodes agiles.
Isaac Newton : "Les hommes construisent trop de murs et pas assez de ponts"
L’entreprise doit avoir l’agilité du banc de poisson qui agit et réagit avec vitesse, simultanéité et précision disait en 2006 Jean-Pierre Chardon, P-DG Schneider Electric France.
Pendant longtemps un grand nombre de projets ont été réalisés en ayant uniquement recours à une approche classique de gestion de projet, « en cascade » ou « en V » où les activités sont envisagés qui sont regroupées en phase ou bloc projet sont enchainées séquentiellement : ainsi on recueille le besoin, on définit le produit ou le service , on procède à son développement puis on teste cette conception avant de livrer le produit ou la solution au client. Dès lors il est nécessaire de tout planifier, « tout doit être prévisible » en tout début de projet. Cette approche est qualifiée de « prédictive ». Un livrable projet par exemple « plan de qualité projet » consigne comment et quand le travail sera réalisé par qui avec les modalités d’exécution, de test, de formation, de suivi et de clôture du projet.
Piloter le projet par les plans rendait tout processus de changement ou de modification difficilement envisageable car ces plans figeaient un cadre auquel il fallait rester conforme.
En fonctionnant sur ce mode la réalisation du projet se heurtait parfois avec gravité aux contraintes du marché qui demandaient à l'entreprise et aux organisations de savoir faire preuve de réactivité, d'adaptation et de souplesse.
Pour répondre à ces besoins d'adaptation, facilitant l'agilité de l'entreprise, il fallait trouver des méthodes moins prédictives.
La gestion de projet méthodes classiques vs méthodes agiles
Traditionnellement les méthodes de gestion de projet utilisent le cycle en V ou en cascade avec un découpage projet en une succession de blocs à enchainer de manière ordonnancée et des livrables associés dont l’importance est plus ou moins grande selon la taille du projet.
Le début de ce cycle commence par une émission de la part du client d’une expression du besoin, qui une fois reformulée en cahier des charges détaillé par le Chef de projet fonctionnel/Consultant fonctionnel, puis validé par les deux parties prenantes servira de base contractuelle à l’élaboration du projet. Ce qui alors n’est pas prévu fonctionnellement donnera naissance par la suite à des évolutions, lesquelles seront prises en compte dans de futurs lots de développements, réalisés et déployés ultérieurement à la livraison de produit ou du service provenant du Cahier de charges initialement validé. Dans le meilleur des cas si ces besoins supplémentaires sont détectés en phase de recette par la contribution nécessaire et la forte implication du client ou de son représentant (key user par exemple) alors des nouvelles fonctionnalités pourront être rajoutées, spécifiées puis développées par les développeurs de l’équipe de la MOE (maîtrise d’œuvre). Dans ce cas précis, le délai de mise en production sera bien souvent différé et le budget de réalisation du projet augmenté en tenant compte de ces variations. Dans d’autres cas, ces changements fonctionnels seront consignés en mise à jour dans des documents de type Change Control et donneront lieu à leur tour à des développements post-production. Quoiqu’il en soit tout changement reste lourd à appréhender et à mettre en œuvre avec toujours le risque de compromettre la relation cliente. De plus il n'est pas rare que certaines fonctionnalités demandées se révèlent finalement inutiles à l'usage, obsolètes alors que d'autres, découvertes en cours de route, auraient pu donner plus de valeur au produit. Combien de chef de projet ont regretté de ne pas avoir accordé assez d’importance à la validation du cahier des charges ou des spécifications fonctionnelles lorsqu’il s’avère au final qu’il y a déphasage entre le besoin du client, sa demande et l’application réalisée et que cette inadéquation qui se mesure par l’insatisfaction du client n’est palpable que bien trop tard c’est-à-dire lors de l’utilisation du produit livré. (Le pire des scénarii source de conflits divers !). Quoique pour ma part j’ai un outil qui me permet de ne pas tomber dans ce déphasage et ce pour toutes les phases du projet mais encore faut-il le posséder dans sa boîte à outils et prévoir la charge pour le mettre en œuvre.
C’est précisément dans ces situations et pour toutes ces raisons que la méthode ou l’approche agile a du bon en donnant davantage de visibilité, en impliquant le client du début à la fin du projet et en adoptant un processus itératif et incrémental qui intégre et supporte le changement. Pragmatiques et éprouvées, les méthodes agiles sont là pour répondre au besoin de réaliser "le bon produit au bon moment". Pour autant, leur adoption et leur maîtrise se révèle dans certain cas un véritable challenge.
Quoiqu'il en soit les méthodes de gestion de projets vont bien sur dépendre de la taille des projets et aussi de la complexité des projets.