La gestion de projet agile avec un engagement au forfait

Pourtant, différentes variantes contractuelles sont possibles pour apporter de fortes garanties de résultat au commanditaire.

Dans cet article, nous vous présentons une petite revue de la vision d'Adimeo. 😊

La gestion de projet au forfait vs agile : Une opposition étymologique

Les prestations au forfait reposent sur la définition préalable d'un cahier des charges, à partir duquel le prestataire s'engage à livrer ce qui y est décrit pour un coût et un délai fixe. C'est la traditionnelle gestion de projet cycle en V.

Les méthodes agiles reposent sur un fonctionnement incrémental, avec des cycles courts, s'adaptant à l'évolution des besoins et des fonctionnalités au fur et à mesure des développements. À lire également notre article "Réussir sa transition vers des méthodes agiles".

Qui dit agile dit nécessairement que l'un des trois engagements du forfait, le périmètre fonctionnel, soit abandonné. Et, dans le meilleur des mondes agiles, les questions de délai et de budget ne sont plus des impératifs.

Aussi, il est de coutume d'affirmer qu'on ne peut faire de gestion de projet agile avec un engagement forfaitaire, et vice-versa.

Dans leurs philosophies mêmes, les contrats agiles et au forfait s'opposent : le contrat au forfait fixe les modalités d'application d'un projet web - le contrat agile définit les modalités de collaboration entre les parties prenantes.

Pourtant, comment répondre à des demandes croissantes de la part des clients, qui sont séduit par les méthodes agiles, mais ont un besoin de réassurance fort et doivent sortir des produits dans des budgets, périmètres et délais contraints ?

S'appuyer sur le backlog et sur la variation de celui-ci : L'engagement sur le point de complexité dans la gestion de projet

On l'a vu, ce qui fait défaut dans un contrat agile, c'est l'impossible engagement de résultat sur un périmètre fonctionnel dans un cadre budgétaire fixe. Pourtant, dans nombre de gestion de projets agiles (à lire également : les grandes étapes d'un projet Web), le backlog (équivalent simplifié d'un cahier des charges) est déjà partiellement connu au moment de la contractualisation. Il est donc possible, selon les principes de planning poker (ou d'évaluation de charge plus classique), de réaliser une première évaluation de complexité et potentiellement des jours-hommes nécessaires.

Dans ce contexte de besoin déjà partiellement défini, il est alors possible de s'engager de manière forfaitaire sur le périmètre identifié. Et de mettre en place des outils d'ajustement des coûts :

• Si une fonctionnalité devient plus complexe ou plus simple, les réunions de début de chaque sprint font évoluer à la hausse ou à la baisse les points de complexité attribués à la fonctionnalité ;
• Chaque point de complexité (ou chaque fonctionnalité unitaire) correspond à une unité d'oeuvre à laquelle le contrat a attribué un coût forfaitaire. Ex : 1 point de complexité = xxx € ;
• La facturation repose donc sur le nombre total de points de complexité progressivement actualisé dans le product backlog. La vélocité effective de l'équipe permet de calculer le budget ;

Les points de vigilance / risques d'une telle méthode de gestion de projet Web agilisée :

• Connaître précisément le coût d'un point de fonctionnalité est hasardeux en début de projet, quand les équipes ne se connaissent pas. Une période de rodage est impérative, sur minimum 2 à 3 sprints ;
• Rattacher la métrique de vélocité (points de complexité par sprint) à une variable budgétaire peut avoir des effets pervers sur l'amélioration de la vélocité de l'équipe et l'enjeu d'amélioration continue des méthodes agiles ;
• Ce type de fonctionnement est valable pour des projets dans lesquels l'incertitude technique / fonctionnelle n'est pas particulièrement élevée, et où justement l'évaluation de la complexité d'une demande fonctionnelle est peu sujette à l'erreur ;
• Une confiance partagée, certes nécessaire dans tous les projets, est encore ici de mise : il ne faut pas que l'équipe ait tendance à sur-complexifier des user-stories pour sur-facturer.

Le budget est fixe et le périmètre s'ajuste : la voie vers le MVP dans la gestion de projet

Dans cette logique, qui répond à des besoins d'engagement budgétaires de certaines organisations, l'engagement budgétaire est connu à l'avance. Aussi, la priorisation du backlog s'attache réellement à définir le MVP (most valuable product), puisque lorsque le budget sera épuisé, il ne sera plus possible d'y revenir. En bon français, on parle de "target cost". Les principes d'une telle démarche fixent :

• La vision du produit final dans les grandes lignes ;
• Les premiers sprints développent réellement les fonctionnalités à plus forte valeur ajoutée ;
• Les ajouts au backlog doivent être contrebalancés par une suppression de user stories de complexité équivalente ;
• Chaque sprint doit réellement aboutir à une version intermédiaire pour permettre de requalifier plus facilement le sprint suivant ;

Les risques d'une telle démarche peuvent être :

• Si le budget initial est trop restrictif, le projet devient infaisable ;
• Si le prestataire n'a qu'une faible motivation pour tenir l'objectif initial, le MVP peut être fortement dégradé ;

Pour inciter le prestataire à tendre vers une plus grande productivité, il est possible "d'incentiver" sa production et proposant une marge plus élevée dans le cas où l'effort effectif est moindre que prévu.

Forfaitiser chaque itération du projet

C'est une des alternatives les plus fréquentes. Chaque itération fait l'objet d'un engagement contractuel indépendant et le donneur d'ordre a la possibilité d'arrêter au bout de chaque sprint et de récupérer les travaux menés. C'est intéressant en termes de partage de risques, mais peu sécurisant pour le donneur d'ordre, qui risque de se retrouver en bout de course avec une application difficile à reprendre rapidement avec une nouvelle équipe. Dans ce genre de contexte, il est essentiel de valider en amont les conditions de séparation et l'engagement d'accompagnement du prestataire en cas de sortie.

Une telle contractualisation nécessite une confiance mutuelle, des obligations respectives et un suivi précis d'indicateurs.

Quelle que soit la méthode retenue, il faut retenir que la contractualisation agile, qu'elle soit avec une logique de forfait ou non, doit s'appuyer sur des engagements mutuels forts de :

• Réactivité : du prestataire et du fournisseurs dans tous leurs échanges et demandes mutuelles ;
• Visibilité : des développements en cours, des besoins émergeants, des attentes des utilisateurs, etc. ;
• Collaboration : entre chaque membre de chaque équipe et au sein des organisations ;
• Confiance : sur l'engagement du prestataire et du client à donner le meilleur ;
• Transparence : des informations et des données fournies de part et d'autre ;
• Communication permanente et efficiente ;
• Implication de toutes les parties pour faire du projet une réussite.

Poursuivez votre lecture avec les 10 points clés d'une gestion de projet web réussie.

Chaque contrat agile au forfait doit s'accompagner d'indicateurs précis de qualité (indicateurs classique d'agilité comme la vélocité, backlog visuel, etc.), adapté au type de contractualisation.