|
J'ai dit ici ce que j'ai
compris de CMMI
afin de faire ressortir ses apports comme ses limites. Je serai reconnaissant à
ceux qui, comme l'ont fait MM. Didier Dulac et Jacques Printz, voudront bien
m'indiquer les corrections et compléments qui leur semblent nécessaires pour
améliorer cette analyse, qui s'appuie sur une lecture critique de la
documentation sur CMMI. Le mot critique doit être pris ici non au sens de dénigrement qu'on lui attribue
dans le langage courant,
mais au sens technique et précis de délimitation : il s'agit de délimiter ce
que CMMI apporte, ce qui implique d'indiquer ce qu'il n'apporte pas.
Jacques Printz m'a fait
observer que la toile de fond d'une telle lecture ne serait pas la même pour un
Américain ou pour un Français car les normes IEEE, la méthode de conduite de
projet PMBOK, le modèle d'estimation de coût COCOMO etc. font partie du bagage
de tout professionnel américain alors qu'ils sont moins bien connus en France.
Ainsi, dit-il, ce qui m'est apparu comme des lacunes de CMMI n'en serait pas
pour un Américain car il s'agit de choses qui, pour lui, sont évidentes et vont
de soi.
Jacques Printz m'a conseillé de
bien séparer la description du commentaire. J'ai donc mis les commentaires sur
un fond jaune, comme celui qui se trouve sous le présent paragraphe.
*
*
CMMI considère la réalisation
des projets, mais ce n’est pas une méthode de conduite de projet : CMMI est une
démarche qui vise à porter l’entreprise au niveau de
compétence (ou maturité) qui lui permettra de réaliser correctement ses projets, ce qu’indique
d’ailleurs exactement l’expression « capability maturity model ».
La réalisation des projets est,
parmi les thèmes relatifs aux systèmes d’information, celui qui fait couler le
plus d’encre et occupe le plus de place dans certains cours et formations. Certes ce thème est important
puisque beaucoup de projets échouent (cf. les statistiques que publie le
Standish Group (De l’Informatique,
p. 454), mais peut-être n'est-il pas le plus important. On peut en effet
estimer que :
- pour un système d'information
le plus important ne réside pas dans les projets, qui visent à le faire évoluer,
mais dans la bonne utilisation des ressources qu’il offre ;
- parmi les décisions qui
conditionnent le succès d’un projet, les plus cruciales se trouvent en amont
(délimitation du projet, qualité des spécifications) et aussi en aval (formation
des utilisateurs, animation du bon usage du produit).
La réalisation des projets est
cependant le thème qui se prête le mieux à des recettes, à des méthodes, à la
rigueur formelle, alors qu’il est sans doute plus difficile d'énoncer les règles
qui permettent d’atteindre l’alignement stratégique, la qualité sémantique,
la solidité de l’architecture.
Historique
Nota Bene : Je vais
devoir ici énumérer des acronymes, car c'est ainsi que l'on désigne les normes,
guides et recommandations. Que l'on veuille bien pardonner la lourdeur qui en
résulte dans cet historique !
CMMI
a été conçu par le DoD (Department of Defense) américain pour répondre
aux fréquents problèmes de qualité survenus dans l’ingénierie des logiciels et
pour mieux maîtriser les coûts et les délais.
Le SEI
(Software Engineering Institute)
a été créé à cette fin en 1984 et l’université Carnegie
Mellon a été choisie pour l’héberger. L’équipe a été dirigée par Watts Humphrey,
qui avait été chez IBM responsable du système d'exploitation MVS de l'IBM 360 et qui publiera notamment Managing the Software Process (Addison-Wesley
1989).
Le SEI a publié en 1988 la
méthode SCE (Software Capability Evaluation), en 1990 la méthode
SPA (Software Process Assessment), en 1991 la version 1.0 du
SW-CMM (Capability Maturity Model for Software), enfin en 2000 les
méthodes CMMI et SCAMPI (Standard CMMI Appraisal Method for
Process Improvement) qui sont l’aboutissement des travaux antérieurs.
Rapports avec les autres normes
CMMI est l’héritier de
SW-CMM. D’après Richard Basque (CMMI, Dunod 2004), CMMI est parent d’ISO
9001 et il est équivalent à ISO/IEC 15504 (SPICE). Il comporte
le cycle de vie défini par la norme ISO 12207.
PMBOK (Guide to the
Project Management Body of Knowledge), mis au point par le PMI (Project
Management Institute), est contrairement à CMMI une méthode de
conduite de projet. Les deux guides
pourraient converger utilement.
SA-CMM, mis au point par
le SEI, concerne la gestion des achats. Il sera vraisemblablement intégré dans
la version 2.0 de CMMI.
iCMM (Integrated
Capability Maturity Model) de la FAA (Federal Aviation Administration)
équivaut à l’ensemble formé par CMMI et SA-CMM.
SCAMPI, conçu lui aussi
par le SEI,
sert à évaluer la maturité d’une entreprise en regard de CMMI.
Démarche
La compétence que considère
CMMI est celle de l'entreprise tout entière, de l'organisation, et non celle des
individus. L'efficacité résultera de la
conjonction de la compétence de l'organisation et de la compétence des
individus.
CMMI classe les tâches que l’on
doit accomplir pour réaliser un projet selon une liste de 25 « domaines de
processus » (process area, que nous appellerons ici « processus » tout
court). Je proposerai une traduction en français de l’intitulé de chaque
processus.
A chaque processus CMMI associe
une intention (purpose) et des notes explicatives (introductory notes)
ainsi qu’une liste des autres processus qui sont en relation avec lui
(related process area). Puis il détaille le contenu du processus selon la
structure que nous décrirons ci-dessous.
Observons qu’ici le mot
« processus » n’a pas le même sens que celui qu’il a lorsque, dans la démarche
d’urbanisation du système d’information, on dit que l’on identifie puis
modélise le processus de production de
chacun des produits (final ou intermédiaire) de l’entreprise. Dans CMMI, la
liste des processus est une classification des tâches que comporte un projet.
Les deux présentations de CMMI
L’ensemble des processus est
lui-même classé selon deux présentations correspondant chacune à une démarche
particulière :
- dans la présentation continue
(continuous representation), les processus sont regroupés en quatre
grandes catégories : gestion de processus, gestion de projet, ingénierie, support. Si l’on suit la démarche à laquelle cette représentation correspond, on
attribuera à une entreprise une note dans chaque grande catégorie de processus
et on y suivra ses progrès séparément ;
- dans la présentation par
étapes (staged representation), on évaluera de façon globale la maturité
de l’entreprise, depuis le niveau 1 qui est le plus bas jusqu’au niveau 5 qui
est le plus élevé. Être qualifiée au niveau 2 ou au niveau 3, c’est pour une
entreprise comme acquérir un diplôme : une SSII ainsi qualifiée sera considérée
comme un fournisseur fiable. CMMI invite l’entreprise à parcourir les cinq
niveaux dans l’ordre pour améliorer la façon dont elle réalise ses
projets : il faut se rappeler que, comme le disait C. A. R. Hoare,
l'optimisation prématurée est la racine de tous les maux
.
Dans notre description de CMMI
nous suivrons l’ordre de la présentation par étapes car c'est celle semble la plus
utilisée en pratique. Nous nous interrogerons sur la pertinence de la
progression chronologique ainsi proposée.
Structure
Pour décrire chacun des 25
processus, CMMI les détaille en objectifs (goals), puis en pratiques
(practices), enfin en produits (typical work products). Chacun des
éléments de ces listes comporte une définition, des commentaires et
éventuellement des informations complémentaires (sous-pratiques etc.).
Selon un vocabulaire
malencontreux mais courant, CMMI distingue dans ce que fournit le projet des
produits et des services (products and services) alors qu’il aurait mieux
valu parler de biens et services (goods and services), puisque ce sont tous
également des produits (voir
A propos de la production).
Parmi les objectifs, CMMI
distingue des « objectifs généraux » (generic goals), que l’on retrouve
dans tous les processus, et des « objectifs particuliers » (specific goals)
propres à un seul processus. La description d'un processus obéit donc à la
structure arborescente ci-dessous :
Cette
structure a l’avantage de la simplicité mais elle ne facilite pas la mise en
évidence de l’importance relative des divers processus, pratique et produits.
Toute classification comporte
une part de convention et l’on ne peut pas être certain que deux équipes
différentes, usant des mêmes critères, seraient parvenues à la même
nomenclature : mais si c’est là un
inconvénient, il est mineur en regard de l’ordre que la classification procure
dans les idées et dans la documentation.
Par contre il est nécessaire, lorsqu’on
rencontre une classification, de connaître les critères qui ont conduit à
classer sous une même rubrique tel sous-ensemble d’éléments. Or CMMI n’indique
pas les critères qu’il a utilisés, comme si la nomenclature qu’il fournit était
« naturelle » et évidente.
Par ailleurs, il ne donne pas
d’indication sur la qualité des documents à élaborer ni sur la façon dont cette
qualité peut être contrôlée. Or dans la documentation d’un projet ou d’un
logiciel on rencontre souvent des textes incompréhensibles : le projet a produit
les documents que la méthode exige, mais n’a pas obéi à son esprit puisqu’ils
sont inutilisables.
Les objectifs généraux
D’un processus à l’autre, les
objectifs généraux sont à peu de chose près les mêmes : organiser la
planification du processus, puis le planifier effectivement ; lui fournir les
ressources nécessaires ; définir et affecter les responsabilités ; former ses
acteurs ; construire puis gérer sa documentation ; identifier et impliquer les
parties prenantes ; le conduire et le maîtriser (monitor and control) ;
évaluer son exécution ; enfin, rendre compte aux dirigeants.
Cette liste a le mérite de
rappeler des évidences : il arrive, dans la pratique, que l’on évoque à la
cantonade une tâche sans désigner celui qui en sera chargé, qu’on le désigne
mais néglige de lui attribuer les moyens nécessaires, que certaines parties
prenantes ne soient pas impliquées, que l’exécution ne soit pas évaluée etc.
Chacun des objectifs généraux
est décliné dans chaque processus par copier-coller, la seule modification
portant sur l’intitulé du processus.
Parfois la description manque
de précision : ainsi dans le processus « ingénierie des exigences » les
objectifs « désigner les responsables » et « identifier et impliquer les parties
prenantes » sont mentionnés, mais sans que CMMI ne précise le partage des rôles
entre le fournisseur et le client (maîtrise d’œuvre et maîtrise d’ouvrage) dans
la validation des exigences auxquelles le projet doit répondre. Or ce point-là
est crucial…
Un objectif comme « définir les
responsabilités » s’explicite, dans certains processus, par la rédaction d’un
contrat qui précise les engagements mutuels des parties prenantes et
identifie les responsables.
CMMI ne fournit pas de
contrat-type et n’indique pas l’identité des signataires, autre point crucial.
Pour « conduire et maîtriser »
le processus, il est utile de disposer d’un tableau de bord. L’expérience montre
que les tableaux de bord sont souvent fallacieux. CMMI n’indique pas comment
construire un tableau de bord correct. Pour « rendre compte aux
dirigeants » la pratique enseigne – mais CMMI ne le dit pas – qu’il vaut mieux
présenter le compte rendu sous forme de séries chronologiques que sous forme
d’alertes symbolisées par des feux de signalisation ou autres procédés. CMMI
précise cependant – et c’est là une excellente chose – qu’il faut suivre
l’exécution des décisions.
Les cinq niveaux de CMMI
Les cinq niveaux de la
présentation par étapes servent à qualifier la gestion des projets dans une
organisation (dans CMMI, ce mot désigne indifféremment une entreprise ou une
entité – direction, service – au sein d’une entreprise, bref une « personne
morale ». Pour simplifier, nous utiliserons ci-dessous le mot « entreprise »).
Le niveau 1, ou niveau
initial, c’est celui des entreprises qui ne gèrent pas leurs projets. Les
processus sont chaotiques, le succès ne peut être obtenu que par un effort
héroïque, budgets et calendriers sont souvent dépassés. Ce niveau a le numéro 1
qui, aux Etats-Unis, désigne le rez-de-chaussée d’un immeuble : c’est le ras du
sol.
L’entreprise qui est au niveau
2 (managed) sait gérer les exigences, planifier et gérer un projet,
répartir le travail entre les parties prenantes.
L’entreprise qui est au niveau
3 (defined) sait capitaliser l’expérience acquise d’un projet à l’autre
et dispose d’une méthode standard pour gérer ses projets. Ce niveau comporte en
outre des processus relatifs à l’amont et l’aval de la réalisation.
L’entreprise qui est au niveau
4 (quantitively managed) sait associer des indicateurs quantitatifs aux
processus clé de chaque projet et prendre des mesures correctrices si ces
indicateurs font apparaître une dérive.
L’entreprise qui est au niveau
5 (optimized) s’engage dans un cycle continu d’amélioration de ses
méthodes.
CMMI part ainsi de ce qui se
passe lors de la réalisation d’un projet (niveau 2), puis s’élargit vers l’amont
et l’aval (niveau 3) pour approfondir enfin la maîtrise quantitative puis
qualitative de sa méthode (niveaux 4 et 5).
Le passage d’un niveau à
l’autre n’est pas aisé : d’après les
statistiques que publie le
SEI, il faut à de 18 à 30 mois pour « décoller » du niveau 1 et atteindre le
niveau 2, puis encore de l’ordre de deux ans pour passer au niveau 3.
La description du niveau 1 ne
serait qu’une énumération de mauvaises pratiques : nous commencerons donc par
l’examen du niveau 2.
Le niveau 2
Pour être au niveau 2,
l’entreprise doit maîtriser sept des 25 processus :
Gestion des exigences (Requirements
Management)
Planification du projet (Project Planning)
Conduite et maîtrise du projet (Project Monitoring and Control)
Gestion des achats (Supplier Agreement Management)
Production et analyse des indicateurs (Measurement and Analysis)
Assurance qualité des processus et des produits (Process and Product Quality
Assurance)
Gestion de configuration (Configuration Management)
Une entreprise qui se trouve au
niveau 2 saura : (1) enregistrer et suivre les modifications du cahier des
charges demandées par le client durant la réalisation du projet ; (2) produire
des estimation argumentées de coût et de délai, planifier l’exécution et
négocier les engagements des intervenants ; (3) produire à cadence régulière des
rapports d’avancement fidèles à la réalité ; (4) proposer et suivre des actions
correctrices en cas de dérapage des délais, du budget ou de l’utilisation des
ressources.
Le niveau 2 contient ce qu’il
faut pour réaliser un projet une fois que l’on a défini ce que l’on voulait
faire.
Il n’y est pas question
d’urbanisme, d’alignement stratégique, de qualité de la formulation des
exigences : CMMI suppose ces questions-là déjà traitées, il ne s’interroge pas
sur la pertinence de l’expression de besoin, sa sobriété ou sa cohérence mais se
limite à organiser la réalisation.
Il ne mentionne pas non plus le
rôle que l’expression de besoins, texte court en langage naturel, doit tenir
durant la réalisation du projet : or il faut donner à celle-ci une place
bien en vue dans la documentation. Un grand projet abonde en complications qui
risquent de faire perdre de vue son but : le sens des priorités et des
proportions ferait alors défaut quand il faudra prendre des décisions en cours
de route. Il est utile alors de pouvoir se référer à l’expression de besoins
initiale.
Gestion des exigences
Par « gestion des exigences »,
CMMI entend la gestion de la cohérence entre les exigences et les produits de
sortie du projet, le fait que les exigences soient bien comprises par les
parties prenantes et que celles-ci s’engagent à les satisfaire, enfin la gestion
des modifications apportées aux exigences en cours de projet.
Cependant comme à ce stade les
critères de qualité des exigences n’ont pas été mentionnés le niveau 2 de CMMI
reste muet sur la façon dont on arbitrera en cours de projet – lorsqu’il faudra
par exemple, pour satisfaire des exigences nouvelles sous la contrainte de délai
ou de budget, sacrifier certaines exigences initiales.
Il est étonnant que l’on évoque
la gestion des exigences au niveau 2 alors que l’ingénierie des exigences (ainsi
que celle de la solution technique qui doit les satisfaire) est reportée au
niveau 3. Ainsi une entreprise certifiée au niveau 2 saurait gérer les exigences
une fois celles-ci formulées, mais ne saurait pas comment les formuler !
Planification de projet
Il s’agit de définir les
variables qui permettent de mesurer l’avancement du projet, après avoir
éventuellement découpé celui-ci en phases, et d’estimer chemin faisant les coûts
et délais restants prévisibles. L’accent est mis sur le caractère rationnel
des évaluations (elles doivent être quantitatives, on doit pouvoir les justifier
et les expliquer). Un plan de projet permettra de suivre la consommation
du budget et le calendrier de réalisation. Les risques, les ressources et les
connaissances nécessaires doivent être gérés. Les parties prenantes doivent être
impliquées et informées, notamment les responsables de ceux des autres projets
avec lesquels le projet considéré est en relation.
On ne trouve pas dans CMMI la
recommandation de découper la livraison en lots exploitables pour éviter
l’« effet tunnel » et tirer parti, en cours de réalisation, des indications
fournies par de premiers utilisateurs. CMMI ne met pas en garde non plus contre
les difficultés logistiques que comporte l’organisation des réunions avec des
parties prenantes qui ont d’autres priorités.
Conduite de projet
Il s’agit de suivre l’évolution
du projet selon le schéma construit lors de sa planification. Les décisions
prises en cours de route (corrective actions) sont définies et gérées.
C’est là un point important :
il arrive trop souvent, dans l'entreprise, que des décisions soient ignorées ou
indéfiniment remises en cause.
Gestion des achats
Les fournisseurs sont choisis à
partir d’une évaluation de leurs aptitudes (sans doute en s’appuyant sur
SCAMPI). Un contrat est passé avec chaque fournisseur, précisant les engagements
mutuels entre le client et lui. Enfin, le produit du fournisseur doit être
intégré dans l’architecture du système d’information et les équipes de
l’entreprise doivent être formées aux techniques particulières le concernant.
La présence de ce dernier
point, certes justifié, surprend dans le niveau 2 puisque la prise en
considération des contraintes propres à l’architecture technique de l’entreprise
relève du niveau 3.
Indicateurs
Les indicateurs dont il s’agit
sont ceux relatifs à l’avancement du projet et non au fonctionnement du produit
une fois qu’il aura été mis entre les mains des utilisateurs (ce fonctionnement
n’est pas pris en compte par CMMI).
Il est indiqué qu’il faut
« spécifier la façon dont les données seront analysées et diffusées ». Mais CMMI
ne donne ici aucune indication sur la façon de s’y prendre. Il faut arriver au niveau 4 pour découvrir les techniques statistiques qu’il suggère, et qui
posent d’ailleurs quelques problèmes (voir ci-dessous).
Assurance qualité
Il s’agit de vérifier que les
processus et les produits sont conformes aux normes et aux exigences.
La vérification des produits
fait apparaître des anomalies (noncompliance issues). Celles-ci doivent
être identifiées, qualifiées, et leur correction doit faire l’objet d’un suivi.
Parmi les divers indicateurs,
celui qui rend compte de la convergence de la correction des anomalies est l’un
des plus précieux : si l’on voit que le nombre d’anomalies à corriger ne décroît
pas ou même augmente, il convient de s’interroger sur la qualité de la
réalisation, sur la solidité de l’architecture sous-jacente. CMMI n’insiste pas
assez, me semble-t-il, sur l’importance de cet indicateur.
Gestion de configuration
Ce processus consiste à
identifier et décrire les produits que le projet doit fournir : il faut donc en
construire le référentiel (définition des identifiants et des attributs), puis
alimenter et tenir à jour la description des produits – et le référentiel
lui-même, en cas de changement.
Le « référentiel » dont il
s’agit ici n’est donc pas celui de l’application que le projet vise à mettre
entre les mains des utilisateurs (avec la définition des données, objets etc.
que cette application traitera) mais seulement celui des produits du projet.
La construction du
référentiel
de l’application (modèle conceptuel de données si l’on est merisien, modèle
UML
en modélisation par objets) n’est évoquée nulle part dans CMMI.
Le niveau 3
Pour être au niveau 3,
l’entreprise doit maîtriser les sept processus du niveau 2 et, en outre,
quatorze autres processus (soit en tout 21 des 25 processus) :
Expression des besoins (Requirements
Development)
Solution technique (Technical Solution)
Intégration du produit (Product Integration)
Recette technique (Verification)
Recette fonctionnelle (Validation)
Gérer l’organisation des processus (Organizational Process Focus)
Définition de l’organisation (Organizational Process Definition)
Formation à l’organisation (Organizational Training)
Gestion multidisciplinaire de projet (Integrated Project Management for IPPD)
Gestion des risques (Risk Management)
Gestion d’une équipe intégrée (Integrated Teaming)
Intégration de la gestion des achats (Integrated Supplier Management)
Méthode de prise de décision (Decision Analysis and Resolution)
Organisation de l’intégration (Organizational Environment for Integration)
On trouve ainsi dans ce niveau
une accumulation de choses que l’on peut regrouper sous les thèmes suivants :
- l’ingénierie des exigences, de l’expression des besoins aux spécifications et
à la recette ;
-
le perfectionnement de la gestion de
projet ;
- la « personnalisation » de la gestion de chaque projet et la capitalisation de
l’expérience d’un projet à l’autre ;
- les méthodes de prise de décision.
Notre commentaire portera sur
ces regroupements de processus.
Ingénierie des exigences
Ce thème recouvre les processus
Requirements Development, Technical Solution, Product Integration,
Verification et Validation.
CMMI ne parle pas de ce que
l’on appelle « gestion du portefeuille de projets ». Or cette gestion est
susceptible de comporter des erreurs : on n’aura pas par exemple regroupé des
projets qui se conditionnent mutuellement ou qui s’enchaînent dans le temps
(certaines entreprises délimitent un projet pour le développement d’un produit,
puis un autre pour sa vérification d’aptitude, un autre pour son déploiement, un
autre encore pour la formation de ses utilisateurs…). CMMI suppose donc les
projets convenablement délimités a priori.
Perfectionnement de la gestion de projet
Ce thème recouvre les processus
Integrated Project Management for IPPD, Risk Management,
Integrated Teaming, Integrated Supplier Management et
Organizational Environment for Integration.
On rencontre ici des choses qui
font classiquement partie de toutes les méthodes de conduite de projet, et l’on
retrouve des choses qui nous sont familières : explication des exigences (to
elicit needs), spécifications générales (customer requirements et product requirements), validation des
spécifications, spécifications détaillées (technical solution) et
spécifications techniques (technical data package), qui aboutissent à ce
que nous appelons un cahier des charges. Ensuite viennent la réalisation,
le codage proprement dit (implementation) et la rédaction de la
documentation destinée à l’utilisateur, puis enfin l’intégration, l’assemblage,
la livraison, la vérification.
CMMI dit que les
spécifications doivent être validées, mais il n’indique pas qui doit
faire cette validation. S'il s’agit de s’assurer que les spécifications
répondent bien aux besoins des utilisateurs la responsabilité de leur validation
appartiendra à la maîtrise d’ouvrage (à l’exception de la solution technique, qui relève de la maîtrise d’œuvre).
L’expérience montre combien il est difficile de présenter les spécifications de
telle sorte que l’on puisse obtenir, de la part de la maîtrise d’ouvrage, une
validation authentique (c’est-à-dire une validation qui engage
véritablement son expertise professionnelle et sa responsabilité).
On ne voit pas apparaître dans
CMMI les étapes de modélisation (MCD ou UML) pourtant
nécessaire pour assurer la qualité sémantique des données et des référentiels ;
les revues de pairs (peer reviews) sont, étrangement, mentionnées après
la livraison du produit alors qu’elles sont surtout utiles lors de la conception
de la solution.
CMMI consacre plusieurs
processus à la gestion d’une équipe intégrée, à la relation avec les
fournisseurs etc. Les responsabilités doivent être clairement définies, la
communication doit être assurée entre les diverses composantes de l’équipe etc.
Il serait utile d’insister ici sur le
commerce de la considération, si
utile à la bonne réalisation des grands projets, et qui peut se décliner en
règles très simples (anticiper les problèmes et les régler à froid par
production et publication d’indicateurs ; interdire le dénigrement des personnes
absentes, etc.). Il ne suffit pas d’évoquer des incentives.
Personnalisation et capitalisation de la méthode
Ce thème recouvre les processus
Organizational Process Focus, Organizational Process Definition et
Organizational Training. Les leçons acquises lors de la réalisation des
projets, les documents types, les statistiques, sont stockés dans une
documentation afin de faciliter la capitalisation des méthodes et compétences
d’un projet à l’autre. Cela facilite la personnalisation de la gestion de
chaque projet : pouvant accéder à la mémoire de l’entreprise, le chef de projet
sera en mesure de définir sa propre méthode.
Ces recommandations sont
salubres. Cependant, dans les faits, leur application rencontrera des
résistances – sauf, peut-être, dans les SSII qui étant impliquées dans de très
nombreux projets ont tout intérêt à capitaliser sur leurs outils et documents.
Dans la plupart des entreprises, même très grandes, on préfère à la fin d’un
projet oublier ce qui s’est passé lors de son déroulement et « laisser les
cadavres dans les placards ».
Méthode de prise de décision
Rien n’est dit dans CMMI sur la nature de
la relation entre expert et décideur, ni sur le suivi des décisions ; aucun
exemple n’est donné, ni de critère permettant d’évaluer les décisions. On peut
donc,
tout en suivant CMMI à la lettre sur ce point, s’égarer longtemps dans l’erreur…
Il
est pourtant crucial de définir, quand on parle de décision, qui est légitime
pour décider, la démarche que le décideur doit suivre, la nature des
informations qui doivent lui être communiquées par les experts pour qu’il puisse
préparer sa décision.
Les niveaux 4 et 5
Au niveau 4, il
faut maîtriser les processus du niveau trois et en outre deux autres processus
(soit en tout 23 des 25 processus) :
Performance des processus (Organizational
Process Performance)
Gestion quantitative du projet (Quantitative Project Management)
On se focalise ici sur la
productivité, sur la performance lors de la réalisation des projets, et
non sur la performance de l’entreprise elle-même, à laquelle les projets doivent
contribuer : cela résulte de la focalisation de CMMI sur les projets et non sur
leurs résultats.
Il s’agit de recueillir et de
comparer les statistiques relatives à chaque projet. Mais si les techniques
changent (par exemple, par introduction d’un nouvel AGL, d’un nouvel outil de
gestion de la documentation) les données sur la productivité risquent de devenir
obsolètes plus vite qu’elles ne s’accumulent.
Les techniques statistiques
suggérées par CMMI sont inspirées du contrôle de la qualité dans la production
industrielle, qui distingue les « causes normales » et les « causes spéciales »
de variation et agit pour repérer et corriger les causes spéciales.
Mais cette technique n’est
applicable que si l’on peut considérer un nombre de projets suffisant pour
estimer des moyennes et des écarts-types que l’on utilisera ensuite comme référence pour
le suivi de chaque projet particulier. Si l’entreprise n’est pas au niveau 4, ou
si elle ne réalise pas assez de projets pour pouvoir estimer des moyennes et
écarts-types significatifs, il faudra se contenter d’une description claire de
l’avancement du projet et s’en remettre au bon sens pour savoir si l’on dérape
ou non.
Au niveau 5
l’entreprise maîtrise les 25 processus décrits par CMMI ; pour passer du niveau
4 au niveau 5, elle doit donc acquérir la maîtrise des deux processus suivants :
Innovation organisationnelle
(Organizational Innovation and Deployment)
Analyse causale et solution des problèmes (Causal Analysis and Resolution)
Alors que le niveau 4 était
consacré à la statistique, le niveau 5 est celui de la modélisation : on
s’efforce de remonter du constat à la causalité, et d’agir sur les causes pour
accroître encore la performance. Cette démarche est confortée par une veille
technologique et une politique d’innovation.
Conclusion
Principaux apports de CMMI
CMMI encourage l’entreprise à
capitaliser, d’un projet à l’autre, les enseignements de l’expérience : « règles
de pouce », documents types, évaluations quantitatives. C’est là sans doute son
apport le plus précieux : le responsable d’un projet nouveau pourra trouver dans
une base documentaire un ensemble d’outils et de références qui lui éviteront d’avoir à réinventer la roue.
Associé à SCAMPI, CMMI fournit
une référence qui permet à chaque entreprise d’évaluer sa maturité en conduite
de projet et de la faire progresser.
CMMI définit, sous le nom de
« processus », les diverses responsabilités qui interviennent dans la
réalisation d’un projet ainsi que leur articulation ; il détaille selon une
nomenclature arborescente le contenu de ces responsabilités en « pratiques » et
« produits ». Cette énumération permet à ceux qui la consultent de ne rien
oublier d’important. Les auteurs précisent qu’elle n’est qu’indicative : on
peut, si l’on a de bonnes raisons pour cela, décider de ne pas mettre en œuvre
tout ou partie de certains processus.
Toutefois CMMI n’évoque pas les
« règles de pouce » de bon sens qui permettraient de faire ce choix.
Limites de CMMI
Rappelons que CMMI n’est pas
une méthode de conduite de projet : c’est une méthode de
qualification de l’entreprise en conduite de projet.
Les définitions qu’il fournit
comportent parfois des incohérences. Ainsi, le cycle de vie d’un produit est
défini d’abord, de façon correcte (p. 30), comme « une période de temps qui
commence quand le produit est conçu et s’achève quand il n’est plus
utilisable ». Mais le paragraphe suivant précise les phases du cycle de vie :
« (1) conception, (2) étude de faisabilité, (3) développement, (4) production,
(5) phase finale » : cela correspond au cycle de vie d’un bien industriel vu par
l’entreprise qui le produit, mais non à celui d’un service ni d’un logiciel car
il manque dans cette liste la phase d’utilisation – souvent la plus
longue, et qui demande elle aussi du travail.
C’est que CMMI est destiné aux
directions des études et aux SSII, et non aux maîtrises d'oeuvre et maîtrises
d'ouvrage même si celles-ci ont intérêt à le connaître pour évaluer leurs
fournisseurs. CMMI ne considère pas la mise en place des référentiels,
l’arbitrage entre les divers projets, la façon dont les métiers définissent
leurs processus de production et les outils d'aide aux utilisateurs, l’alignement des dépenses avec les priorités
des métiers, ni la traduction d'un problème technique en impacts pour la
production ou les clients.
CMMI ne regarde ni vers
l’amont, ni vers l’aval du projet. Il ne parle ni d’urbanisme du système
d’information, ni de modélisation des processus de production de l'entreprise
(il donne au mot « processus » un tout autre sens), ni d'animation du bon
usage : il suppose donc tout cela fait par ailleurs, et bien fait.
CMMI décrit les processus
qu'il est opportun de maîtriser pour conduire un projet, mais ne dit rien des pièges que ces
processus permettent d’éviter. Or comme certains pièges sont plus
dangereux que d’autres, les divers processus n’ont pas une importance égale : la
présentation de CMMI manque de relief à cet égard.
CMMI ne fournit pas d’exemples
de document bien rédigé, de processus bien mis en œuvre : il dit
seulement « il faut écrire tel document », « il faut mettre en œuvre tel
processus». Or il existe par exemple une grande
différence entre un document bien rédigé (clair, lisible) et un document
incompréhensible. Il ne suffit donc pas d’avoir défini le thème d’un document,
il faut encore lui associer des critères de qualité et savoir les appliquer : CMMI ne
fournit pas de tels critères.
Précautions à prendre
Il ne convient pas de prendre
CMMI au pied de la lettre, c’est d’ailleurs ce que disent ses auteurs eux-mêmes.
Il
serait en effet peu raisonnable pour une entreprise d’attendre des mois ou
années avant d’introduire des indicateurs quantitatifs dans la gestion de
projet, et certains des processus qui relèvent des niveaux 3 ou 4 sont donc de
ceux que l’entreprise doit maîtriser en tout premier, notamment la qualité de
l’expression de besoins et le suivi quantitatif de la réalisation. Il faudra en
fait les mettre en œuvre dès le début, donc sans respecter exactement l’ordre
prescrit par CMMI.
Les niveaux les plus
substantiels de CMMI sont les niveaux 2 et 3, qui font le plus souvent l’objet
d’une certification et contiennent le plus grand nombre de processus.
Les
niveaux 4 et 5 relèvent, pour l’essentiel, d’un perfectionnement que l’on peut
juger superflu et qui est peut-être impossible : les projets que réalise une
entreprise ne sont pas nombreux au point que l’on puisse fonder sur eux une
statistique représentative, encore moins une analyse causale en bonne et due
forme.
Enfin, l’entreprise qui adhère
à CMMI risque peut-être de négliger ce que CMMI ignore, ou suppose déjà fait et
bien fait : la gestion du portefeuille de
projets, la sobriété des exigences, l’observation et l’animation de l’usage des
produits. Si elle se focalise sur sa maîtrise de la « gestion de projet », seule chose que CMMI
considère, et non sur la qualité de son SI, elle risque de lancer de nombreux
projets sans percevoir que la pluie de nouveautés qui en résulte peut déstabiliser
ses agents opérationnels et son organisation.
|
