Forfait et Agilité

Points Clés

Cet article explique les différences entre le forfait et l’agilité, ainsi que les difficultés qui peuvent surgir lorsqu’on essaie de mettre en place un projet agile dans un cadre forfaitaire, il est crucial de prendre en compte les aspects spécifiques à considérer pour aborder les projets forfaitaires dans ce contexte.

Les points durs entre forfait et agilité

Rappel : le forfait

Il définit à l’avance 3 contraintes à respecter

Le périmètre

L’agilité, c’est la promesse faite au client de pouvoir changer librement d’avis
- En début de projet on ne sait pas à l’avance quel logiciel on aura à la fin
Problème: la contrainte du périmètre est une cible mouvante
Le système de troc devrait pourtant rassurer les clients. On part d’un Backog initial contractuel et on le fait évoluer avec un mécanisme de troc d’exigences.
Oui mais :
- Le client n’a pas nécessairement la compétence pour challenger les chiffrages
- Sans concurrence, le fournisseur pourrait chiffrer à la hausse
- Devoir supprimer des exigences est quelque chose de stressant pour un client
- Le périmètre fonctionnel ne peut pas être réduit à un nombre de Points d’Efforts

La collaboration

C’est l’une des 4 valeurs du Manifeste Agile

Faire un projet Agile comporte un certain nombre de risques pour le fournisseur :
- Spécifications produites en flux tendu => peut créer un déficit d’inputs pour l’équipe de dév
- L’Agilité c’est une certaine culture de l’oralité. En cas de litige, les écrits ne permettront peut-être pas de retracer toutes les décisions.
- Démarrer un projet avec une faible expression de besoin et sans spécifications détaillées peut ouvrir la porte à toutes les dérives en cas de malhonnêteté de l’une des Parties.

Avant de se lancer dans un projet Agile, il faut s’assurer de la capacité du client à collaborer honnêtement, et à dépasser les archétypes du Forfait dans lequel toutes les responsabilités sont déportées sur le fournisseur

commitment

Problèmes :
- Comment définir la « collaboration » dans un contrat ?
- Comment mettre en évidence un manquement à l’obligation de collaborer ?
- Contraindre des gens à collaborer a-t-il un sens ?

Niveau avancé:

Comment Contractualiser un Projet Agile

Bien démarrer le projet

Le niveau de maturité Agile des clients est souvent faible. Aussi, il faut porter une attention toute particulière à la phase de démarrage :

De poser les règles du jeu qui prévaudront tout au long du projet
De partager une vision commune du périmètre du projet

Choisir le Product Owner

Le choix du Product Owner est la décision la plus importante du projet.

Le Client et le fournisseur du service doivent tomber d’accord sur le choix du product owner. Ne pas hésiter à être « Lourd » avec le client si nous ne sommes pas convaincus du choix.

Qualités du Product Owner :
- Est une seule et unique personne
- Est la même personne tout au long du projet
- A un intérêt marqué à la réussite du projet
- Connait et sait expliquer les règles de gestion mises en jeu dans le projet
- Est dédié au projet – est disponible à tout instant pour l’équipe projet
- Est capable d’arbitrer, de décider dans des délais courts (< 1j en moyenne)
- Accepte le principe de troc des exigences (sait renoncer à des exigences)
- Est le décideur ultime sur les aspects fonctionnels et techniques du logiciel
  - tout en étant éventuellement assisté par des experts métiers et techniques
  - ses décisions engagent toute l’entreprise, incluant le payeur
- Est salarié de l’entreprise.

La vision du projet

Le client n’a pas de spécifications, mais il doit avoir une vision de son projet
La vision du client est le seul point de repère fixe du projet. Le reste changera tout le temps. Cette info est donc essentielle !
La vision devrait préciser (doit tenir sur 1 page recto)
- Une liste résumée des fonctionnalités clés de l’application
- Une vision du ROI de l’application
- Des objectifs et des motivations pour les atteindre
- Des risques

Template:

+Attentes : Ergo, perfs, qualité, conduite du projet, techniques, etc.

+Objectifs : Enjeux de dates, enjeux de périmètre, …

+Risques : Risques vus par le client

+Hors scope : Ce que le client ou le prestataire de service décident d’exclure du périmètre

“ Deriving scope from goals :

In the future, this will be one of most important software development topics, and I want to raise awareness about it. “

Specification by Example – How Successful Teams Deliver the Right Software – G. Adzic (Manning, 2011)

Le levier de souplesse

flexibility

Un projet est gouverné par 3 grandes contraintes : un budget, une date, un périmètre
Pour réussir un projet de ce type, ne laissez pas croire à votre client qu’il peut exiger un respect scrupuleux de ces 3 contraintes
Demandez à votre client d’indiquer quelle contrainte est :
- Non négociable
- Importante
- Négociable

Ce type de discussion avec un client est riche d’informations sur sa capacité à accepter les avantages et les contraintes de l’Agilité. S’il est totalement hostile à votre discours, ne faites pas d’Agilité

Décider le + TARD Possible

Il existe 2 stratégies en résolution de problèmes :

En largeur : approche en entonnoir
En profondeur : approche en tunnel

Souvent les gens préfèrent l’approche en Profondeur car elle permet de réduire rapidement la complexité

Inconvénient l’approche en Profondeur :

elle oblige à prendre des décisions structurantes très tôt

Approche en largeur:

La feature est entiérement implementé en une seule itération

Approche en profondeur:

La feature est implémentée sur plusieurs itérations

Avantages de l’approche en largeur :

Permet d’avoir toutes les grandes fonctionnalités (en version simplifiée) très rapidement => recette + intéressante
Permet de dé-risquer les projets fortement drivés par les délais
S’adapte mieux aux changement d’avis. Permet d’éviter le rework de code

Inconvénients de l’approche en largeur :

Approche non naturelle
Ne jamais faire de choix => bloquer les développeurs

Refaire le Backlog

Le Backog est l’instrument de pilotage le + important !

Or, celui soumis au client en phase de réponse à appel d’offre est souvent :

Truffé d’erreurs
Non lu par le client

C’est pourquoi, il faut le refaire avec le client en début de projet :

Lister les exigences
Chiffrer les exigences => oui avec le client !
Prioriser les exigences

Avantages de refaire le Backlog et le chiffrage avec le client :

Être sûr d’avoir une vision initiale partagée du logiciel
Mettre le client en confiance lors de troc d’exigences
Avoir une priorisation qui tient compte de la vraie valeur métier
Avoir un Backlog qui utilise le vocabulaire métier

Les erreurs souvent commises :

Mener les ateliers

Pour que le client tire profit d’une approche Agile, il faut accepter de lui laisser le temps de « maturer » sur son besoin

Bannissez les pratiques de :

faire un maximum d’ateliers en début de projet pour cadrer le besoin
forcer des prises de décision pour sécuriser vos chiffrages

Les bonnes pratiques pour mener les ateliers sont :

Faire les ateliers au fur et à mesure des sprints
livrer fréquemment du logiciel fonctionnel et faire tester par le client
expliquez que certains chiffrages sont des enveloppes budgétaires à respecter
ne pas laisser croire que chaque responsable de domaine a un droit de décision => le seul qui décide c’est le Product Owner (y compris les aspects techniques)
chercher la décision minimale sur laquelle tout le monde est d’accord et la développer (approche en largeur)

Démarrer les développements

Les chefs de projet ont tendance à faire démarrer les développements trop tard. Ils souhaitent avoir un maximum d’entrants avant de démarrer : storyboard, piste graphique, cadrage fonctionnel, etc.

Inconvénients :

Lourds investissements financiers sans aucune production de logiciel => risque !!!
Symptomatique d’une approche en profondeur : on veut tout simplifier dès le début du projet

Avantages de démarrer les développements relativement tôt :

Le fait d’avoir produit du code permet de cadrer naturellement le client.
Tant qu’aucune ligne de code n’a été produite, le client se sent libre de tout remettre en cause d’un atelier sur l’autre.
Dé-risquage du projet => un Logiciel opérationnel est la principale mesure d’avancement (7ième principe du Manifeste Agile)

Soigner votre relation client

Soignez la qualité de votre relation client !!!

Prenez un même projet et une même équipe

Cas 1 : le client est dans de bonnes dispositions envers vous
Cas 2 : client est dans de mauvaises dispositions envers vous
La différence entres les 2 c’est au moins 10% de marge

Comment développer une relation de qualité ?

Soyez prévisibles
Dites la vérité
Dites le même quand c’est dur
Dites le tôt
Choisissez vos mensonges, sinon vous vous pendrez avec
Une relation de confiance se créé au goutte-à-gouttes, mais se perd par litres

Soyez engagés

Parlez de vos pistes de solutions
Montrez votre engagement à trouver rapidement une solution

Développez la solidarité

Ne vous engueulez jamais avec un client !
Faites des rétrospectives d’équipes client / fournisseur
Trouvez des solutions aux problèmes de votre client, même sans contre partie immédiate
Impliquez votre client dans le recherche de solutions pour vos problèmes
Sortez des sujets polémiques avec une solution en 50 / 50
Soyez en mesure de négocier => définissez vos leviers de souplesse !

Soyez compétent : livrez un logiciel de qualité

Si votre équipe livre un logiciel de qualité, un budget, une date peuvent devenir négociables
Si vous livrez de la m**de, rien ne sera négociable !

Durant le projet

Votre objectif : la réussite du projet

Sur un projet qui va mal :
- La marge n’est plus pilotable ni prédictible
- Sur un projet qui va mal, il est très difficile de négocier un avenant / une rallonge
Pour faire de l’argent, votre projet doit bien aller, il doit réussir
Votre première préoccupation doit être : la réussite du projet

Définissez votre marge de manœuvre

La réussite oui, mais pas à n’importe quel prix
Définissez les seuils de tolérance avec votre agence, selon :
- L’historique de business avec ce client
- Le potentiel du client
- Le caractère stratégique du projet pour votre société
- Etc…
Traduisez ces seuils en souplesse sur la marge
Pilotez votre projet à l’intérieur de cette marge de manœuvre
Quand vous approchez la limite de cette marge, référez à votre agence

Surveillez l’équilibre des intérêts

Ayez temps en tout temps à l’esprit le respect des intérêts mutuels
Quand vous commencez à voir un déséquilibre dans la relation dites le, et agissez !
- Ex : vous êtes en dessous de vos objectifs financiers alors que la santé du projet est bonne
- Ex : vous êtes au dessus de vos objectifs, alors que le client a coupé 30% du périmètre

Limitez vos demandes d’argent

Avant de demandez de l’argent, trouvez d’autres solutions :
- Avec le client, supprimez régulièrement les exigences inutiles du backlog
- Soyez techniquement malins : proposez des solutions équivalentes, mais moins chères
- Troquez une exigence « peau de banane » contre un effet Whaouh pas cher
- Transférez des tâches chez le client
En dernier recours :
- Négociez un avenant / une rallonge
- Informez en le client tôt, qu’il ait le temps de trouver des solutions
- Vous ne pourrez pas le faire 50 fois. Alors choisissez bien quand et quoi demander

Pas de décalage planning

Faites tout pour atteindre vos objectifs de dates
Un report de date fait très mal à la marge
- Mieux vaut staffer 1 ICD maintenant, que prolonger 2 semaines 1 équipe complète
Sécurisez votre mise en prod avec l’approche en largeur

Le contrat

Un modèle de contrat

La contractualisation Agile est un sujet difficile auquel les juristes sont mal formés
Il n’existe pas de contrat Agile type qui fasse l’unanimité :
- Difficulté à définir les changements de périmètre
- Difficulté à faire de la collaboration en engagement fort
Le plus souvent ça fini avec :
- Un contrat au forfait plus ou moins traditionnel => risque porté par le fournisseur
- Un contrat en régie => risque porté par le client

Les points durs

J’ai longtemps tenté de rédiger un contrat Agile :
- Gestion du périmètre avec du troc de Points d’Efforts à ça ca va…
- Levier de souplesse, collaboration à c’est là que ça ne va plus
Les gens sont capables d’entendre qu’il faut un levier de souplesse, mais pas toujours de l’écrire :
- Le modèle du contrat au Forfait est encore très ancré !
- Si je projet dérape et qu’on s’aperçoit que j’ai signé un contrat comme ça, aïe aïe !
- Notre service juridique ne va jamais accepter une telle chose !
La collaboration :
- Comment définir la collaboration ? Comment définir la non collaboration ?
- Impossible d’invoquer une manquement aux obligations d’une des Parties sur un concept aussi difficile à définir

Alors quelle(s) solution(s) ???

2 types de contrats

Il n’existe pas de solution unique, mais un contrat adapté à chaque projet

Je vais vous parler :

d’un contrat signé avec un client
d’une alternative à ce contrat (non signé)

Premier contrat : client α

Le principe :
- La collaboration, c’est lorsque chaque Partie a le soucis des intérêts de l’autre (sans oublier les siens)
Un moyen pour y parvenir :
- Que chaque Partie soit libre de pouvoir mettre fin au contrat à tout moment

Deuxième contrat : client β

Le principe : le partage de risque
- Le budget est estimé au début du projet sur la base d’un nombre de Points d’Efforts à livrer pour une date donnée
- Si le périmètre est livré avant la date prévue => client et fournisseur se partagent l’économie
- Si le périmètre n’est pas livré à la date prévue => client et fournisseur continuent les développements en se partageant le surcoût
Garde-fous possibles :
- Si la raison du retard est exclusif à l’une des parties, pas de partage de responsabilité
- Le ratio de partage peut être déterminé par l’investissement initial que le client a mis :
  - – Dans la complétude de son Cahier des Charges
  - – Dans une phase de cadrage
- Au-delà d’un certain dépassement (X semaines) => arrêt du projet
  - – Evite que le client veuille profiter trop longtemps d’un TJM très avantageux

Important !

Pour que ces types de contrat soient signables par un client, il faut lui donner d’excellentes garanties sur la qualité des livrables.

L’avant-vente

Agilité : côté pile / côté face

Vous avez compris que dans un projet Agile, il y a des choses
- Que les clients aiment : changer d’avis, pas d’effet tunnel, …
- Que les clients aiment moins : le levier de souplesse, le partage de responsabilité, la liberté des parties, …

Mes conseils

Sans projet, pas d’Agilité => en AVV, votre priorité est de faire rêver votre client !!!
Et les sujets qui fâchent ? :
- La première fois évoquez le sujet lors d’une rencontre physique
- Voyez quel accueil le client réserve à ces propos
- Si le client est réceptif, ou connait l’agilité, ce type de discours devient un ATOUT !
- Si le client n’est pas réceptif, n’en parlez plus. Ré-ouvrez le sujet une fois le projet gagné