La communauté CMMI, d’une façon générale, adhère à l’idée que le CMMI et les méthodes agiles sont compatibles. Je ne suis pas entièrement d’accord avec cette position. Sans aucun doute, le cycle de vie itératif, ou les méthodes de travail que préconisent XP et autres Scrum sont applicables dans un environnement CMMI. Par contre, sur un autre front, l’agilité se définit elle-même comme une démarche peu formaliste, en opposition nette avec le CMMI sur ce point : anti-documentation, anti-planification, anti-contractualisation et anti-processus, pour reprendre les quatre axes du manifeste agile, et même si celui-ci tempère sa position en post-scriptum.

Ce à quoi les auteurs d’un article au caractère officiel, et auquel participe le SEI, “CMMI or Agile : why not embrace both !”, répondent que le CMMI est adaptable au contexte de chaque organisation ou projet : déterminer d’abord le juste degré de formalisme pour le contexte en question, et construire un système autour.

Sauf que, pour le moment, et je prends uniquement l’exemple de la documentation, une évaluation Scampi de niveau 3 examine en moyenne 400 types de documents. Selon Dalton (sur une présentation que l’on peut trouver sur le site de l’ASQ), un projet agile produit en moyenne 39 artefacts. Dalton estime que par consolidation on peut passer de 400 à 70 types de documents pour CMMI. Pour qu’il y ait compatibilité entre CMMI et agilité, il faudra que les évaluateurs CMMI acceptent cette consolidation, d’une part, et d’autre part que les agilistes acceptent de produire deux fois plus de documents, passant de 39 à 70, tout en se trouvant toujours “agiles”. Ce n’est pas rien, et je ne crois pas que l’on y soit encore.

Plus généralement, la question d’un “juste degré de formalisme pour un contexte donné” ne peut pas être résolue de façon purement analytique : même en s’aidant d’une liste de critères détaillée il restera toujours une large part de subjectivité dans le choix que l’on pourra en faire. Simplement, certains individus sont naturellement portés au formalisme, d’autres moins. Et je n’ai pas pu observer dans la pratique que les premiers étaient forcément de meilleurs chefs de projets que les seconds, ou qu’ils se voyaient confier les projets les plus critiques au sein de leur organisation. Pour cette raison, je crois qu’il restera toujours une tension, et une alternance, au sein des organisations comme dans la recherche, entre tendances formalistes et non formalistes.

Dans l’immédiat, l’agilité a donné un coup de boutoir au CMMI, obligeant le SEI à s’occuper des excès qui, selon les auteurs même du “why not embrace both”, ont alimenté la révolte agile.

Selon ces auteurs, les excès bureaucratiques de certains déploiements CMMI proviennent de ce que certaines organisations se sont intéressées au CMMI non pour améliorer leurs pratiques, mais pour obtenir l’évaluation. Je trouve cette analyse trop courte, simplement parce que le CMMI, pour le meilleur ou pour le pire, est un modèle nativement formalisateur : les 400 types de documents dont nous parlions plus haut sont une moyenne, ce ne sont pas que les organisations en course pour la médaille.

D’une façon plus générale, là où le CMMI fut conçu comme un modèle de performance, c’est-à-dire optimisant le rapport qualité-prix, pour un contexte donné, il est aujourd’hui perçu, en tout cas dans les organisations que j’ai connues, comme un modèle de qualité au sens étroit. En d’autres mots, on ne se pose pas suffisamment la question de la valeur ajoutée des procédures que l’on met en place au nom du CMMI. Le SEI devrait davantage inciter les organisations à mener cette réflexion au quotidien. Et les évaluateurs ne devraient pas donner une évaluation positive à des organisations trop bureaucratiques pour le contexte qui est le leur. La médaille CMMI a deux faces, et il ne faut pas négliger l’une pour l’autre.

Pour faire un bon accompagnement il me semble qu’il faut justement s’y prendre de façon inverse : “vous êtes chefs de projets, dans votre secteur, avec ses problématiques propres, depuis x années. Je vais vous aider à formaliser cette somme de connaissances, à la partager avec vos collègues chefs de projets, à vous unir sur des modes de fonctionnement communs, et pour ma part je vous permettrai de confronter vos approches avec un modèle que je connais bien, CMMI, pour les enrichir”.

Autre chose que de l’humilité, et les gens se braquent, c’est normal. Dans l’idéal trouvez un consultant qui ait en effet une longue expérience de la gestion de projets sous CMMI mais soit capable de dire, et le pense, “la façon dont vous faites les choses est passionnante, et j’apprends tous les jours de nouvelles choses sur la gestion de projets à votre contact”. Voilà un discours dynamisant. A l’opposé, les experts, formateurs et autres coachs dans l’âme créent de la résistance. En fait ils connaissent bien CMMI et le métier de chef de projets, mais ils sont relativement incompétents pour mener un projet d’amélioration, parce qu’ils n’en font pas un projet collectif.

A chaque fois ce commandement me fait penser à cette histoire du passant qui, de nuit, voit un homme accroupi sous un réverbère et lui demande ce qu’il fait, l’autre lui répond qu’il a perdu ses clefs, et ils se mettent tous deux à chercher jusqu’à ce que le premier demande au second s’il les a bien perdues dans cette zone-là, et l’autre de lui répondre “je n’en suis pas sûr, mais en tout cas ici il y a de la lumière”.

Sans aucun doute, on gère mieux ce que l’on mesure. Et l’objet de systèmes type TQM, CMMI et autres 6 Sigma est justement d’étendre le périmètre éclairé par nos réverbères, jusqu’à tout éclairer, dans l’idéal.

Mais je crois que les temps ne sont pas encore proches où nous comprendrons tout de la nature qui nous entoure, où nous saurons de quoi demain sera fait. En attendant, il faut aussi explorer les zones d’ombre. Et à cela l’intellect ne suffit pas, il faut aussi un peu de courage.

Vous trouverez peut-être mes textes assez critiques envers un modèle (CMMI) que je promeus pourtant. Je crois que le CMMI est un excellent modèle de bonnes pratiques de gestion de projets et qu’il apporte des bénéfices avérés aux organisations qui l’implémentent (les chiffres sont sur le site du SEI, éditeur du CMMI). Mais j’ai rencontré suffisamment de clients “traumatisés du CMMI” pour m’être fait une idée sur la façon dont il ne devrait pas être déployé. Et puis, si on écrit, ce n’est pas pour évoquer les points sur lesquels on est de toutes façons d’accord avec le discours établi.

C’est dans l’air : “le CMMI n’est qu’un modèle, pas une norme, le CMMI ne vous dit pas que faire ou comment le faire, il ne fait que poser des questions, il ne fait qu’énumérer les conditions qu’un bon processus devrait remplir, à vous de définir le processus le plus adapté à votre organisation”.

Désolé, mais quand je lis le modèle, je ne vois pas quelle grande marge de manœuvre il peut rester. Une fois réalisé tout ce que le modèle demande, je ne vois pas ce qu’une organisation ou un projet individuel pourraient vouloir ajouter qui les différencie notablement d’une autre organisation ou d’un autre projet.

Or il n’y a aucun mal à ce qu’un référentiel soit prescriptif. La gestion de projet se ressemble beaucoup d’un contexte à un autre. J’ai lu un certain nombre de référentiels d’entreprise, et ils se ressemblent tous. Certaines pratiques sont plus essentielles, et donc plus développées, dans certains contextes que dans d’autres, mais c’est toute la différence.

Alors pourquoi ne pas l’assumer et dire “le CMMI est un modèle qui vous dit que faire et comment le faire, mais avec une assez grande marge pour être adaptable à tout type de contexte” ?

Peut-être parce que dans ce cas le CMMI ne pourrait prétendre au statut de “méta-modèle” dans lequel le SEI, c’est mon sentiment, souhaiterait l’installer, c’est-à-dire “au-delà de tous les autres”. C’est du pur marketing, une stratégie dans le marché concurrentiel des référentiels qualité.

Mais au final, une fois tombée la rhétorique, et même s’il est très adaptable aux différents contextes d’application, le CMMI vous dit précisément que faire et comment le faire.

CMMI demande aux projets un gros effort pour recueillir et valider les exigences clients. Dans un contexte où il y a peu de clients cela génère des résultats fiables. Mais quand il y a de très nombreux clients, par exemple lors du développement de produits grand public, les équipes de développement passent par un interlocuteur intermédiaire, le marketing (ou la MOA pour les projets informatiques), qui a, lui, la tâche de recueillir les besoins des consommateurs, de les synthétiser, de faire des projections sur l’avenir, et des arbitrages stratégiques. CMMI amène les projets à approfondir et systématiser le dialogue entres les équipes de développement et ce client intermédiaire. Mais si ce dernier n’a pas suffisamment bien fait sa part d’écoute consommateurs, ou si les choix stratégiques marketing sont mal inspirés, le produit final aura quand même des résultats décevants. Alors quel est le plus difficile, marketing ou réalisation projet ?

En passant du niveau CMMI 2 au 3 les projets d’une organisation passent d’un système dans lequel ils définissent eux-mêmes les règles qu’ils vont appliquer à un système dans lequel ils ajustent les règles définies par l’organisation à leurs propres spécificités.

En prenant un peu plus de hauteur on pourrait considérer que ce serait également un progrès de passer d’un système dans lequel chaque entreprise se définit son propre référentiel de gestion de projets (règles, guides, procédures …) à un système dans lequel chaque organisation reprend un référentiel défini par des professionnels des bonnes pratiques de gestion de projets pour l’adapter à ses spécificités propres.

Schématiquement :

Après plusieurs projets CMMI vous constatez que :

-        les référentiels de gestion de projets des entreprises se ressemblent tous

-        mais que malgré tout, à chaque fois, les consultants CMMI conseillent que l’entreprise forme des groupes de travail pour définir le référentiel “maison”

Pourquoi ? Parce que ainsi le référentiel sera mieux accepté quand il s’agira de le déployer.

Il ne fait aucun doute que des référentiels génériques comme CMMI ou Spice ne peuvent pas être repris tel quel, qu’ils doivent être adaptés aux spécificités des organisations une par une. Mais pourquoi réinventer la roue à chaque fois ? Les référentiels génériques ont été construits par des équipes expérimentées, des “professionnels du référentiel de gestion de projets”. Quels moyens une entreprise individuelle, même une grande, a-t-elle à opposer à cela ? D’ailleurs ces référentiels maison paraissent souvent bancals. Parfois ils sont aussi très bons mais justement, on perçoit l’effort immense qu’ils ont nécessité, et on se dit que cette énergie aurait aussi bien pu être consacrée au métier de l’entreprise.

Alors c’est vrai que construire un référentiel “à nous”, en impliquant de nombreuses personnes de l’entreprise, permet de paver la route pour le déploiement ultérieur. Mais je ne crois pas que ce soit la méthode la plus efficace pour parvenir à l’acceptation - il y en a d’autres qui n’impliquent pas que l’on réinvente tout un référentiel.

Dire que les troupes n’accepteront pas un référentiel étranger est faux également, à mon avis : nous acceptons bien les ordinateurs Dell ou HP que nous utilisons chaque jour, le bâtiment que nous n’avons pas construit, et le café que nous n’avons pas récolté nous-mêmes.

Alors oui, le référentiel est quelque chose d’un peu plus “sensible” que nos ordinateurs, notre bâtiment et notre café. Notre référentiel, c’est notre façon de travailler, ce sont nos lois, c’est ce qui nous “gouverne”, et ça, il faut que nous puissions le choisir pour l’accepter. Au-delà, notre référentiel est une partie de notre identité. D’ailleurs nous lui donnons un petit nom, c’est bien le nôtre.

Est-ce cela notre identité : une entreprise refermée sur soi, des individus jaloux de leur petit territoire ?

Il est vrai que créer notre propre référentiel nous permet d’exister, et d’exister en tant que groupe, avec une identité propre. A l’extrême, nous préférerions avoir également construit notre propre bâtiment, fabriqué nos propres ordinateurs, et que notre café vienne de nos propres plantations. Mais tout cela aurait un coût. Et je crois qu’un référentiel de gestion de projets fait partie de ce qui est trop cher à faire soi-même, par rapport à la satisfaction que nous pourrions en retirer, et le sens que cela donnerait à notre action d’entreprise.

Donc je recommanderais à une entreprise de choisir un référentiel générique existant et de le reprendre en l’adaptant à son activité spécifique. Le SEI permet que l’on reprenne le CMMI, qui est disponible sur son site. Rajoutez juste cette mention que votre référentiel d’entreprise est basé sur le modèle CMMI.

Le CMMI ne veut pas de héros. Mais que peuvent bien faire les héros alors si on leur ferme maintenant le monde des projets ? Pourquoi veut-on faire du projet ? Parce qu’il y a de l’incertitude, du challenge, du risque. Parce que si on veut de l’aventure, et en équipe, c’est cela qu’il faut faire.

Avec le CMMI, terminé. Les bureaucrates ont gagné.