Une équipe de projet d'une commune de taille moyenne consacre sa première réunion sur un nouveau système de gestion des dossiers à la question de savoir si le projet suivra Prince2 ou une variante Scrum allégée. On vote ; à la fin de la réunion, la méthode figure déjà sur la première diapositive de la présentation. À ce moment-là, la liste des exigences pour le système lui-même se résume à trois puces sur une demi-page : aucun critère d'acceptation, aucun responsable par exigence, aucune distinction entre exigences indispensables et souhaitables. Trois semaines plus tard, quand le premier sprint démarre, il s'avère que personne ne s'accorde sur ce que signifie réellement « un aperçu de dossier fonctionnel ».
Cet ordre, la méthode d'abord, les exigences ensuite, revient plus souvent qu'on ne le pense. Et la recherche montre que c'est le mauvais ordre.
Ce que montre la recherche
Dvir, Raz et Shenhar ont étudié en 2003 ce à quoi la réussite d'un projet est réellement corrélée. Leur constat : la réussite est corrélée à la qualité de la définition des exigences, à la précision avec laquelle est consigné ce que le projet doit livrer, et non au degré de mise en œuvre d'un processus de gestion de projet formel. Le choix de la méthode elle-même, aussi minutieusement élaborée soit-elle dans un manuel ou un modèle, y est à peine corrélé. Les exigences, si.
C'est une conclusion inconfortable pour qui consacre beaucoup de temps à choisir et documenter une façon de travailler. Un plan de projet avec une structure Prince2 rigoureuse, des rôles, des transitions de phase, un PID, tout dans les règles, a l'air professionnel. Mais si la liste des exigences en dessous reste vague, le commanditaire achète une fausse certitude : la forme est en ordre, le contenu ne l'est pas.
La nuance qui l'accompagne
Ce n'est pas un plaidoyer pour abandonner la gouvernance et les accords de processus. D'autres recherches, de Serrador et Turner en 2015, trouvent bien des liens positifs entre la maturité des processus et la réussite des projets. « Le contenu avant le processus » n'est donc pas une loi universelle, les deux courants de recherche se contredisent sur ce point. Ce qui reste vrai : la définition des exigences ne doit pas disparaître derrière une discussion méthodologique, même quand cette discussion est elle-même utile.
Ce que cela signifie pour le démarrage d'un projet
Concrètement : si un plan d'approche consacre ses premières semaines surtout à la question de la méthode à suivre, quel cadre, quels modèles, quelle structure de réunions, pendant que la liste des exigences reste un espace réservé, l'ordre est inversé. Le choix de la méthode peut très bien intervenir tôt, mais pas à la place de la consignation des exigences. Une exigence qui compte a un responsable, est vérifiable (on peut contrôler après coup si elle a été satisfaite) et est indépendante de la manière dont le projet est piloté.
Pour qui évalue un plan d'approche avant le lancement, c'est une question concrète à ajouter à celle sur la gouvernance et le phasage : les exigences sont-elles là, indépendamment de la façon de travailler choisie ? Un plan qui obtient d'excellents résultats sur l'organisation des processus mais dont les exigences ne dépassent guère une déclaration d'intention mérite sur ce point un regard critique. Non pas parce que le processus ne compte pas, mais parce qu'un processus rigoureux peut masquer l'absence d'exigences précises, et c'est exactement ce qui a mal tourné avec le système de gestion des dossiers.
Une étape concrète
Lors de la prochaine session sur le plan d'approche, placez la liste des exigences en tête de l'ordre du jour, avant la discussion sur la méthode à suivre. Faites en sorte que chaque exigence ait un responsable et un critère d'acceptation avant que l'équipe ne passe à la question du cadre à construire autour. Cela coûte une heure à un moment où la discussion porte de toute façon encore sur la forme, et cela évite qu'une méthode bien documentée ne finisse par reposer sur une fondation vide.