En formation Scrum, nous discutons également de la gestion de projet. Et notamment des coûts, délais et scope. Dernièrement, alors que nous abordions ces sujets, un participant m’a parlé d’un outil que je ne connaissais pas et que j’ai adoré: « La matrice des compromis« . J’ai proposé à ce participant d’en faire un billet et il a, à ma grande joie, accepté. Ce billet est donc l’œuvre d’un blogueur invité, Jacques LABATTE.

Le monde de l’IT n’échappe pas à la règle : nos clients sont exigeants ! Ils veulent des applications capables de tout faire, et cela au meilleur prix, et dans les meilleurs délais.

Dans ce cadre, un grand nombre de projets démarrent avec un triptyque (coût, délai, périmètre) difficile voire impossible à tenir. Et lorsqu’il est tenu, c’est parfois au détriment de la qualité.

Le « CHAOS Report » du Standish Group, publié en 2012, montre que seuls 39% des projets informatiques sont réalisés à temps, au coût prévu, et avec le périmètre fonctionnel attendu. A l’inverse, 43% des projets informatiques sont livrés hors délai, avec un surcoût ou un périmètre inférieur à celui attendu.

16 années d’expérience dans le monde de l’IT m’ont appris que le « tout-figé » (date de livraison, budget et contenu fonctionnel) au démarrage d’un projet informatique est clairement utopique.

Dès lors, il est préférable de connaître nos variables d’ajustement dès le démarrage d’un projet et surtout de les partager avec tous les acteurs du projet, plutôt que de se poser ces questions lorsque le projet sera en crise !

La matrice des compromis est un outil qui offre une représentation simple des variables d’ajustement d’un projet. Compréhensible par tous, elle fait partie intégrante de la charte du projet.

Elle identifie la contrainte forte d’un projet et quelles seront les variables d’ajustement en cas de dérive. Elle peut être éventuellement revue en cours de projet en fonction de certains évènements : rallonge ou coupe budgétaire, nouvelle urgence de livraison, …

Clefs de lecture :

• La règle de remplissage est simple : une seule croix par ligne et par colonne !
• La qualité est systématiquement fixe, car elle ne doit jamais être une variable d’ajustement.
• La contrainte forte du projet est par définition ferme. Elle permet de savoir si le projet est piloté par le coût, le délai, ou le périmètre.
• A l’inverse, la contrainte du projet la plus flexible est celle qui changera sûrement. Elle identifie le type d’arbitrage qui sera effectué prioritairement en cas de dérive sur le projet.
• Si les premiers arbitrages ne sont pas suffisants pour redresser le projet, il est alors possible d’arbitrer ce qui pourrait changer.

Remarque : Les contraintes d’un projet sont forcément liées. Par exemple, un projet qui décale une date de livraison pour terminer le périmètre attendu est un projet qui va coûter plus cher puisque l’équipe continue à travailler sur une période de temps supérieure à celle qui était initialement prévue.

Panorama des différentes configurations possibles :

1) les projets pilotés par le coût (coût ferme) :

Ces projets sont réalisés avec une enveloppe budgétaire non négociable. C’est le cas lorsqu’une entreprise alloue chaque année une enveloppe budgétaire permettant de traiter les demandes d’améliorations les plus prioritaires d’un produit. Pour ces projets, qualifiés de « budget-box », c’est en général le périmètre qui sera arbitré en premier (matrice 1.A). Le périmètre non embarqué sera éventuellement priorisé au sein d’une version ultérieure.

2) les projets pilotés par le délai (délai ferme) :

Ces projets sont à livrer à une date donnée, qui ne peut pas être décalée (livraison indispensable avant Noël, fonctionnalités attendues par d’autres projets, eux-mêmes en délai contraint, etc). En cas de dérive, une première solution est la diminution du périmètre fonctionnel (matrice 2.A), à condition que ce périmètre diminué reste viable (il peut partir en production). Une autre solution peut consister à renforcer l’équipe (matrice 2.B) pour tenir à tous prix le délai (attention, renforcer une équipe n’apporte jamais la garantie de sauver un projet)

3) les projets pilotés par le périmètre (périmètre ferme) :

Ces projets sont fréquents dans les entreprises du monde bancaire qui doivent produire de nouvelles fonctionnalités pour répondre à des directives européennes (projets réglementaires). En cas de dérive, l’équipe va devoir malgré tout implémenter le périmètre en entier, quitte à décaler dans le temps sa mise en production (matrice 3.A). Ce décalage aura aussi un impact sur le coût. Une autre solution consiste à renforcer l’équipe, et donc à augmenter le coût du projet pour limiter au mieux le retard de livraison (matrice 3.B).

A propos de l’auteur : Jacques LABATTE

Ingénieur INSA en informatique, j’ai passé une dizaine d’années en tant qu’architecte Java EE, avec une appétence forte pour l’industrialisation des développements.

Par la suite, j’ai pris un rôle de Scrum Master sur divers projets. Dans ce cadre, j’ai pris goût très rapidement aux valeurs et aux pratiques agiles !

Depuis 2010, je suis coach agile chez Orange Applications for Business. J’accompagne aujourd’hui des équipes et des organisations qui souhaitent devenir agiles, dans des secteurs d’activités très variés.