Un projet, quelle que soit sa
nature, n’est pas spontanément organisé. Si on n’y prend pas garde rapidement
il risque de devenir assez confus et cela va se traduire par des micro-conflits
et finalement des pans entiers du projet qui sont oubliés. Pour éviter ces
dérives il est nécessaire de répondre aux cinq questions de base : Qui
fait Quoi, Où, Comment et Quand. C’est le classique QQOCQ.
Pour rendre la gestion du projet
efficace il est nécessaire de définir une organisation adaptée. Si elle n’est
pas mise en place il n’y a aucune raison pour qu’il arrive à atteindre spontanément
ses objectifs. Si le dispositif de pilotage n’est bien conçu si les objectifs
ne sont pas clairs ou si l’enchainement des opérations se déroulent dans le
désordre le projet risque de dériver et finalement d’échapper à tout contrôle. Il
tend alors à s’enkyster et il finit par devenir un projet perpétuel. En effet il
n’a aucune raison pour qu’il se termine or, par définition, un projet est une
organisation temporaire encadrée par un planning et un budget.
Pour ces raisons il est indispensable
de commencer le projet en définissant son organisation. Dès que le chef de
projet est nommé sa première tâche consiste à définir l’organisation à mettre
en place. Ce travail est indispensable afin de rendre le projet pilotable. Si les
petits projets sont simples et faciles à organiser, par contre les grands
projets sont nettement plus complexes et difficiles à mettre en œuvre. Ce qui
va suivre dans ce post concerne les grandes et moyens projets. Il ne concerne
pas le flux de petits projets qui est le quotidien des services informatiques.
Fixer les objectifs du projet et de l’application
La première étape de toute démarche
d’organisation du projet consiste à lui fixer des objectifs. Ils peuvent
concerner le projet proprement dit ou la future application. Bien sûr ils
peuvent être communs aux deux. Mais la plupart du temps ils sont différents. Les
objectifs du projet reviennent à assurer son bon déroulement alors que les
objectifs de l’application est d’améliorer la rentabilité de l’entreprise,
augmenter sa réactivité ou réduire le nombre de non-qualité.
Pour que le projet se déroule sans
peine il est nécessaire que des objectifs du projet soient clairs et
effectivement atteignables. Ce sont, par exemple, une date de mise en place à
respecter ou des performances transactionnelles à atteindre. Très souvent on
constate que l’objectif d’un projet est son budget ou la charge de travail qui
lui est allouée. Mais il faut être prudent face à ce type d’indicateurs car ce
ne sont pas de vrais objectifs mais des ressources mis à la disposition du chef
de projet.
Le choix des objectifs est très
important car il permet de structurer le projet. Il est pour cela recommandé d’avoir
des objectifs quantifiables car il est ainsi possible de mesurer qu’ils sont
effectivement réalisés. On peut ainsi évaluer de manière simple sa capacité à
atteindre ses objectifs. Il existe aussi des objectifs qualitatifs. Ils sont intéressants
mais plus difficiles à évaluer et peuvent prêter à interprétation. Il est pour
cela préférable de ne pas les utiliser.
Il est de même recommandé de ne
pas avoir comme objectif des indicateurs de ressources sans cela les objectifs
et les ressources finissent par se confondre. Il est toujours préférable de
choisir des objectifs liés aux performances de la future application.
Les objectifs sont souvent
fixés très tôt, lors du lancement du projet. Ils doivent ensuite être validés
lors de l’étude de faisabilité (étude d’expression des besoins, étude d’opportunité,
….) est terminée. Les objectifs ont une influence sur le planning du projet,
son budget et l’évaluation de ses gains. De plus, ces objectifs ont un effet
important sur les choix de solution technique et fonctionnelle adoptés.
Dans tous les cas ces objectifs
doivent être validés par le management concerné et le maître d’ouvrage. Ils ont
la responsabilité de s’assurer à ce que qu’ils existent et qu’ils soient
raisonnables. L’absence d’objectif ou le choix d’objectifs inadéquates est une cause
fréquente de dérive des projets. Il doit ensuite s’assurer que les ressources
disponibles sont adaptées aux objectifs recherchés.
Quoi qu’il en soit l’absence
d’objectif a pour effet de rendre difficile pour qu’un projet permet d’obtenir des
résultats satisfaisants.
Etablir un planning avec des livrables clairement définis
Une fois les objectifs fixés la
deuxième étape de la démarche consiste à découper le projet en phases et en
étapes. Ce travail est indispensable car un projet peut comporter plusieurs
centaines de tâches, voire plusieurs milliers. Or, il est très délicat de
suivre chaque tâche et il est difficile d’arriver à avoir une vue d’ensemble de
toutes les tâches. On a pour cela pris l’habitude de les regrouper dans des ensembles
homogènes appelés phases, étapes ou lots. Généralement ils correspondent à un
découpage temporel des opérations : la conception, la réalisation, les
tests, …. Cela peut aussi être des ensembles d’opérations confiées à une autre
équipe ou à un sous-traitant.
L’établissement de ce découpage
n’est pas évident. Il existe autant de découpages possibles qu’il y a de chefs
de projets. Chacun a son approche. L’observation montre que certains sont bien
conçus alors que d’autres sont franchement mal organisés. Dans ce domaine l’expérience
des chefs de projet ou des maîtres d’ouvrage joue un rôle important.
C’est toujours un travail
délicat nécessitant un véritable savoir-faire. Il est important de veiller à ce
que les étapes ne soient ni trop longues ni trop courtes. La durée raisonnable d’une
étape est comprise entre deux ou trois mois. Si elle dure plus longtemps, on a
intérêt à la couper en deux. Ainsi une étape qui dure 6 mois est mieux
contrôlée s’il existe un livrable intermédiaire fournis au bout de 3 mois. Un
découpage bien conçu permet de détecter rapidement des retards et même de
mesurer l’ampleur de la dérive.
Déterminer les rôles et les responsabilités
La troisième étape de la
démarche consiste à définir le rôle des différents intervenants et de préciser
qui fait quoi et quand de définir ils doivent le faire. On va pour cela établir
un tableau RACI. Le sigle RACI veut dire R pour « responsible », responsable,
A pour « accountable »
qui peut être traduit par « autorité » mais en fait on vise ceux qui
doivent rendre des comptes, C pour « consulted », consulté, et I pour « informed », informé. Ce tableau permet
d’avoir en ligne les différentes tâches, ou des groupes de tâches, à accomplir
et en colonne les différents intervenants et dans les cases on indique qui est
responsable, qui doit rendre des comptes, qui est consulté ou qui est simplement
informé. Généralement on établit ce type de tableau au début de chaque étape pour
identifier les tâches à effectuer et le rôle des différents intervenants.
Les tableaux RACI est le cœur
des notes de cadrages. Ce type de
document est établi par le chef de projet au début de chaque étape du projet. Cas
particulier : lors du lancement du projet permettant d’initialiser l’étude
de faisabilité ce document est rédigé par le maître d’ouvrage. (Pour en savoir
plus sur les notes de cadrage voir sur ce blog : « N'oubliez pas
la note de cadrage ». Pour lire le texte cliquez ici ).
La rédaction d’une notre de
cadrage à chaque étape du projet est un minimum mais il est possible d’aller
plus loin est mettre en place des dispositifs plus puissants comme les PMP, les
PDP, les PDL ou les PAQ :
-
Le PMP (Plan de Management de Projet) est un document
couvrant l’ensemble du cycle du projet et mettant côte à côte les différentes notes
de cadrage qui seront établies au cours du projet. Pour éviter les répétitions un
certain nombre de dispositifs communs aux différentes étapes sont détaillées à
part comme le fonctionnement du comité de pilotage, le suivi de l’avancement,
le budget du projet, les principaux choix techniques, … A chaque étape du
projet le document est remis à jour en détaillant le chapitre correspondant à
la prochaine étape.
-
Le PDP (Plan de Développement de Projet). Dans
le cas des grands projets complexes il est possible d’aller plus loin et de
définir l’organisation des différents groupes de travail ou des comités les
relations entre ces différents organes, la structure des documents à produire, …
-
Le PDL (Plan de Développement de Logiciel).
C’est une démarche voisine du PDP. Elle est plus orientée vers la production du
code et la manière dont il doit être organisé et testé. Cette démarche est
surtout adaptée à la production de programmes complexes et de grande taille
comme les applications militaires et spatiales, les logiciels systèmes, …
-
Le PAQ (Plan d’Assurance Qualité). C’est la base
de toute démarche Qualité. Elle est basée sur la norme ISO 9001. Le PAQ s’attache
à définir la manière dont va être produite et validé le code produit. De même
il définit les documentations à établir et la manière dont le système Qualité
va les produire et les valider. C’est une démarche plus ambitieuse que la mise
en place de notes de cadrage ou un PMP mais assez voisine des PDP ou des PDL.
Quelle que soit la démarche adoptée
il est indispensable de définir l’organisation à mettre en place. C’est le rôle
des notes de cadrages comme des PAQ. Si ce n’est pas fait il ne faut pas
s’étonner de constater que des facteurs très importants concernant la réussite
du projet ne sont pas pris en compte et on risque alors d’assister à la multiplication
des conflits de compétence entre les différents intervenants concernés par le
projet (informaticiens, maitrise d’ouvrage et utilisateurs).
N’oubliez pas les gains
La troisième étape de la démarche
du projet est de réfléchir aux gains liés à la future application. C’est
essentiellement la responsabilité des métiers et des maîtres d’ouvrage. Il fut
un temps, pas si lointain, où il était possible de lancer des projets conséquents
sans déterminer ces gains. Aujourd’hui la plupart des projets sont dotés dès l’étude
de faisabilité d’un budget. Celui-ci est plus ou moins bien correctement
calculé mais il comprend au minimum la charge de travail des informaticiens. On
trouve moins fréquemment l’ensemble des coûts de la maîtrise d’ouvrage et des
utilisateurs participants au projet. Souvent les frais généraux liés au projet
sont sous-évalués voir ignorés. On progresse même s’il reste encore des efforts
à faire en matière de budget.
Par contre la situation est nettement
moins satisfaisante en ce qui concerne l’évaluation des gains. Rares sont les
projets ayant une évaluation prévisionnelle de qualité de ces gains. Cette
situation est due à la conjonction de plusieurs facteurs.
La cause la plus grave est liée
la difficulté éprouvée par un certain nombre de maîtres d’ouvrage de s’engager
sur ces estimations. Les informaticiens maîtrisent assez bien leurs coûts, par contre
les utilisateurs et leur hiérarchie ont plus de mal à imaginer ce que seront le
détail des gains futurs et surtout de donner une estimation raisonnable de ces
montants. Or, dans un projet, le plus important ne sont pas les coûts mais les
gains et la rentabilité du projet. Cette prudence excessive explique le fait qu’un
nombre élevé de projets une fois réalisés font apparaître des gains faibles
voir nuls. Il serait de bonne pratique de les supprimer mais on risquerait
alors de devoir faire face à un certain nombre de réactions hostiles y compris
de la part des décideurs. Ceci explique en grande partie la prudence excessive constatée
en ce domaine.
L’évaluation des gains est
compliquée par le fait qu’il n’existe pas de barème des gains permettant d’effectuer
des estimation rapides et fiables. Cela oblige à chaque fois d’effectuer des
calculs complexes et un peu fragile.
Enfin les décideurs et les
maitres d’ouvrage ont tendance à privilégier des évaluations analytiques et
détaillées. Ils répugnent à effectuer des évaluations globales qui sont
pourtant, l’expérience le monte, plus fiables que les évaluations analytiques.
L’importance du contrôle interne
Enfin, quatrième étape de la
démarche, il est nécessaire qu’un projet soit régulièrement contrôlé pour
éviter toutes les différentes dérives possibles. Il est notamment très
important de s’assurer que les bonnes pratiques de la gestion de projet sont
effectivement appliquées. Pour cela on doit de s’assurer que les projets respectent
les règles de contrôle interne adaptés au contexte de la gestion de projet. C’est
le rôle de l’audit de projet.
Bien entendu il existe des particularités
propres aux projets mais la plupart des règles à appliquer sont de bonnes
pratiques générales s’appliquant aux entreprises et notamment en matière
d’investissement. Celles-ci sont largement connues mais elles ne sont pas pour
autant appliquées. Compte-tenu des enjeux il est souhaitable de s’assurer
qu’elles le sont. C’est une condition nécessaire afin d’améliorer la qualité de
la gestion de projets.
Quelques règles de contrôle interne à appliquer
Parmi les nombreuses bonnes
pratiques concernant les projets dix règles sont particulièrement
importantes :
1.
A chaque
étape il doit exister au minimum une note de cadrage. Cela peut aussi être un
PMP (Plan de Management de Projet), un PDP (Plan de Développement de Projet) ou
un PDL (Plan de Développement de Logiciel) ou un PAQ (Plan d’Assurance
Qualité). La note de cadrage est une solution minimum et elle est souvent
suffisante. (Pour en savoir plus sur les notes de cadrage voir sur ce
blog : « N'oubliez pas
la note de cadrage ». Pour lire le texte cliquez ici). Dans le cas des projets importants et complexes il
est nécessaire de recourir à des dispositifs plus rigoureux.
2.
Chaque
étape du projet se termine par un livrable et il doit y avoir un contrôle suffisant
des livrables pour s’assurer que ce qui est livré est conforme à ce qui était
prévu et s’assurer que rien ne manque. Le but de ce contrôle est de vérifier que
le livrable est complet. La validation détaillée proprement dit du livrable est
une opération plus conséquente, notamment celle de l’analyse fonctionnelle et
du code développé. Souvent, c’est une étape spécifique.
3.
L’existence
d’un comité de pilotage. Il est composé par les décideurs directement concernés
par le projet. Il doit se réunir aux différents moments clés du projet pour prendre,
si c’est nécessaire, les décisions qui sont nécessaires. Ils doivent avoir
l’autorité nécessaire afin de prendre les décisions qui s’imposent. L’objectif
n’est pas d’organiser tous les mois des réunions du comité de pilotage car les
décideurs n’ont pas le temps disponible et si c’est le cas ils ont tendance à
déléguer à des collaborateurs qui n’ont pas forcément l’autorité nécessaire
pour prendre les décisions qui s’imposent.
4.
Des réunions
périodiques autour du projet. Indépendamment des réunions du comité de
pilotage. Il est nécessaire d’informer toutes les personnes concernées sur le
contenu de la future application et l’avancement des opérations. Il est pour
cela souhaitable d’organiser des réunions autour du projet. On va pour cela d’organiser
des comités projet mensuel, des comités d’avancement, des comités de
validation, des groupes de travail, …
5.
L’existence
d’un tableau de bord mensuel. Les décideurs doivent recevoir périodiquement
une information synthétique sur l’avancement du projet concernant le planning, la
charge, les dépenses, l’avancement détaillée, … Il doit être établi dans les
premiers jours qui suivent la fin du mois précédent et diffusé à la maîtrise
d’ouvrage et aux membres du comité de pilotage.
6.
L’étude
de faisabilité ou l’expression des besoins. Quelle que soit la méthode de
développement utilisée (classique ou agile) il est nécessaire de commencer la
conception de la future application par une étude permettant de définir son périmètre
fonctionnelle (voir sur ce sujet dans ce blog le post : « Le problème
du périmètre fonctionnel ». Pour le lire cliquez ici ). Il est de même nécessaire de fixer le planning et
le budget du projet.
7.
L’évaluation
des coûts du projet (strict et complet) et sa rentabilité. Trop souvent les
coûts du projet sont sous-évalués. Ceci se traduit inéluctablement par des
dérives budgétaires qui sont généralement mal vécues par le management. (Voir
sur ce sujet dans ce blog le post : « Estimer
correctement le coût des projets informatiques ». Pour le lirecliquez ici )
8.
L’existence
d’un planning et d’un suivi périodique. C’est l’outil de base pour
piloter le projet et détecter d’éventuels retards. Un premier planning doit
être établi lors du lancement du projet. C’est la « baseline ». C’est
la base de référence. Ensuite, au fur et à mesure, on note les dates des
livrables et des « milestones ». Ceci permet d’évaluer le retard du
projet.
9.
La
validation de l’analyse fonctionnelle. Une fois que l’analyse fonctionnelle
est terminée elle doit être validée par l’ensemble des responsables concernés.
Il est pour cela nécessaire de s’assurer d’un consensus suffisant. Ceci ne
concerne pas les développements faits à l’aide de méthodes agiles car il n’y a
pas d’étape d’analyse fonctionnelle. Dans ce cas les développements sont
effectués de manière itérative avec les utilisateurs concernés. On doit dans ce
cas s’assurer que ces derniers ont largement participé à la réalisation du
projet.
10. Distinguer les tests techniques, les tests
utilisateurs et la réception. Trop souvent, pressé par le temps, ces
différents types de tests sont effectués ensemble. Cela risque d’être
insuffisant. Il est nécessaire de s’assurer qu’après une série de tests
techniques permettant de s’assurer que l’application est opérationnelle les
utilisateurs doivent effectuer des tests fonctionnels suffisants pour s’assurer
que l’application est conforme à l’analyse fonctionnelle. On peut alors
organiser sa réception qui aboutit un PV (Procès-Verbal) de réception et le cas
échant une liste de réserve.
Ces dix bonnes pratiques
permettent d’avoir une assurance raisonnable que le mode projet est
correctement maîtrisé. Il est bien sur possible d’aller plus loin en se basant
sur d’autre bonnes pratiques. Mais est-ce nécessaire ? Si aujourd’hui déjà
tous les projets respectaient ces dix bonnes pratiques il est probable que leurs
dérives seraient moins fréquentes et le cas échéant elles seraient de moins grande
ampleur.
Pour s’assurer que les projets
sont correctement maîtrisés il est nécessaire de les auditer périodiquement. Un
projet de grande taille doit être systématiquement audité à une de ses étapes
clé, en particulier à la fin de l’analyse fonctionnelle. Comme les enjeux concernant
les projets de taille moyenne sont moins importants il n’est pas nécessaire de
tous les audités. Il suffit d’en contrôler chaque année quelques-uns pour s’assurer
que les projets se déroulent sans difficultés particulières.
