Comment acheter un projet agile ?

Vous êtes sur le point de contractualiser avec un prestataire : l’équipe projet est d’accord sur la méthode, le delivery prestataire est prêt à lancer le projet, il reste maintenant à formaliser la collaboration.

Sur la table, plusieurs points d’attention à anticiper : l’utilisation d’unités d’oeuvres agiles, l’utilisation de packs de jours, la consommation au fur et à mesure, l’achat de sprints…

Sur tous ces sujets, l’acheteur voudra maîtriser sa dépense, le commercial s’assurer que son delivery sera rémunéré … Il faut faire “matcher” le contrat et la méthode projet, rien à voir avec Tinder 🙂

La définition du périmètre du contrat

Avant de formaliser le contrat, tout le monde doit être aligné sur un point fondamental : le périmètre d’un projet agile est variable.

Dans le cadre d’une mission de régie, ou la mise en oeuvre d’un plateau de développement, il y a des prérequis sur lesquels l’acheteur et le prestataire doivent être en phase.

La priorisation du backlog 

Le product owner doit être en mesure de prioriser les besoins des sponsors. Qu’ils soient déjà clairement définis ou pas, lister les besoins et les prioriser permet dès le début de voir les principales attentes des sponsors du projet. Garder en tête les fonctionnalités les plus importantes permet d’aiguiller les équipes et de garantir la livraison d’un produit qui satisfera toutes les parties.

Le fonctionnement en trade in / trade out

C’est le principe de remplacement d’un besoin par un autre de même envergure. Sans cela, ce n’est même pas la peine d’envisager d’aller plus loin. Si vous n’êtes pas d’accord avec ça dès le début, votre contrat sera une véritable usine à gaz, car cela présuppose de définir tous les cas d’évolution possibles et laisse donc la porte ouverte à d’éventuels avenants… ce qui nous rapproche d’un projet au forfait et nous éloigne de la souplesse du scrum.

Si le commercial et l’acheteur s’entendent sur ces deux points, ils ont déjà fait le plus gros du travail.

La notion d’engagement en agilité

Qui dit agilité, dit changement de périmètre. Qui dit changement de périmètre, dit périmètre variable… Alors à quoi bon parler de forfait ? Il faut faire la distinction entre un forfait qu’on peut allotir et des ressources à disposition pour mener le projet.

• Le forfait induit des spécifications claires dès le démarrage, avec une vision définie et maîtrisée du projet. C’est donc pour le prestataire un engagement de résultat par rapport au besoin qui est clairement explicité.
• La mise à disposition de ressources dédiées, qu’elles soient physiquement avec les équipes projet ou à distance, permet de co-construire le périmètre du projet et de l’affiner au fil du temps, en fonction des itérations, des évolutions des attentes des sponsors, des technologies, des attentes métiers, etc. C’est ce qu’on appelle une approche agile 😉

Si vous êtes dans le premier cas, on ne parlera pas d’agilité dans le contrat.

Définir les drivers du projet

Une fois qu’on sait tous qu’on va jouer à Tetris avec le périmètre et investir dans pas mal de Post-it, il faut définir comment piloter le projet. Est-ce que le meilleur driver sera le périmètre, le délai et/ou le budget ?

Le budget / planning

Il y a un délai à respecter ? Une enveloppe financière à ne pas dépasser ? Ces deux éléments permettent de dimensionner un projet et donnent à la fois à l’acheteur et au prestataire une vision claire des coûts et de la mobilisation des ressources. C’est le compromis parfait entre une volonté d’agilité et les impératifs du projet.

Le périmètre

Pas de lancement en grande pompe ? De deadline impérative ? De budget gravé dans le marbre ? C’est le graal ! Même si on ne peut pas dépenser à l’infini, ni avancer sans cap, laisser le périmètre driver le projet a l’avantage de permettre aux équipes d’avancer sereinement, de favoriser l’interactivité et le challenge. Nous voulons tous des résultats : montrer son expertise digitale, prouver sa maîtrise des coûts, garantir la satisfaction des sponsors… tout le monde y gagne. Bien sûr, il faudra prioriser les besoins, car sans cela le projet risque de s’enliser et vous aurez du mal à apprécier les efforts investis (humains et financiers).

Comment choisir le mode d’achat ?

En mode agile, il existe deux possibilités de contractualisation :

Les unités d’oeuvre agiles 

A la base, une unité d’oeuvre est une unité qui décrit une prestation pour un prix forfaitaire (par exemple la création d’un wireframe dans un projet de refonte de site web correspond à une unité d’oeuvre dont le prix est défini en amont).

Elles sont très prisées des administrations publiques qui n’ont pas le droit de commander de jour.homme.

C’est l’organisation de l’équipe qui définit le suivi financier quand le contrat est lancé :

• Soit les équipes respectent les charges (j.h) qui constituent les unités d’oeuvres.
• Soit on considère ces unités d’oeuvres comme des enveloppes “financières” utilisées pour couvrir une charge différente de celle à la base des unités d’oeuvres.

La bonne vielle rate card

Encore appelée grille tarifaire/prix, elle est bien souvent dégressive suivant le nombre de jours/heures commandés ou le mode contractuel (forfait/temps passé).

Avec elle, on constitue plus précisément une équipe (par exemple : un chef de projet, 2 développeurs, un ingénieur qualité, un DevOps…), dont on connaît très précisément la charge et l’investissement. Les ajustements de staffing sont plus simples qu’avec les unités d’oeuvres : par exemple, si on s’aperçoit au cours du projet que le temps passé du développeur sera plus conséquent que ce qui a été estimé au démarrage, on peut réduire celui du chef de projet pour en allouer davantage au développeur, sans dépasser le budget. Cette méthode s’avère généralement plus fluide dans le suivi opérationnel.

Ma recommandation se porte sur le second mode d’achat :

• D’un côté l’équipe client a un suivi très fin des temps provisionnés, réalisés et de la mobilisation des ressources du prestataire et du coût de son investissement.
• De l’autre, l’équipe du prestataire peut ajuster en toute transparence son dimensionnement, suivant la complexité des sujets et sans recourir à des avenants qui peuvent parfois freiner l’avancement du projet.

Ce qu’il faut retenir de la contractualisation “agile” :

• Le périmètre est variable.
• C’est un engagement de ressources, pas de résultats.
• Le mode de contractualisation est variable, mais la clé d’un contrat agile qui aura la vertu de satisfaire toute les parties se trouve dans la transparence <3.