L’art d’organiser un projet

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.

N'oubliez pas la note de cadrage

Un projet informatique d'une certaine taille est toujours une opération complexe faisant appel à de nombreuses compétences. Ceci est dû au fait que dans le cadre d'un projet il est nécessaire de recourir à de nombreuses activités différentes. De plus un nombre élevé de personnes sont concernées directement ou indirectement par un projet. Souvent elles ont des démarches différentes et des points de vue assez éloignées les uns des autres. Pour ces raisons il est nécessaire de mettre ces personnes et ces activités en bon ordre pour mener le projet dans les délais et les budgets prévus. C'est le rôle des notes de cadrage.

Pour organiser un projet on commence par s'efforcer d'identifier l'ensemble des tâches le constituant. Ce sont des activités précises confiées à une personne en lui accordant un délai de réalisation déterminé. C'est par exemple l'animation d'un groupe de travail, la mise au point d'un document ou la rédaction d'un programme. Un projet informatique comprend plusieurs centaines de tâches, voir dans le cas des grands projets plusieurs milliers de tâches. Pour mener à son terme le projet dans le délai prévu il est nécessaire de mettre en ordre ces tâches. Pour cela on a pris l'habitude de les regrouper en étapes ou en phases.

Les étapes sont de natures très différentes. Elle concerne des opérations de conception, de réalisation, de tests et de mise en place. Très souvent on décompose les étapes trop lourdes et trop complexes en étapes plus courtes et donc plus facile à maîtriser. Ainsi il est habituel de décomposer l'étape de conception en deux : conception globale (généralement appelée l’expression des besoins) et conception détaillée (souvent appelée analyse fonctionnelle). Selon les projets il y a entre 5 et 10 étapes. La difficulté de cet organisation tient au fait que ce ne sont pas toujours les mêmes personnes qui participent à ces différentes opérations et donc il faut gérer les passages de relais entre les différentes équipes.

Au cours d'une même étape de nombreux participants interviennent simultanément. Mais pour que leurs actions soient efficaces il est important de déterminer dans quel ordre ils agissent et de manière plus générale comment sont coordonnées leurs opérations. C'est le premier objectif de la gestion de projet. Il est ainsi possible d'améliorer de manière significative son déroulent.

Les risques de dérives des projets sont nombreux

Naturellement les projets informatiques ont tendance à dériver. D'ailleurs si ce risque n'existait pas il est probable qu'on aurait jamais eu l'idée d'organiser les développements de logiciels en mode projet.

Les origines de ces dérives sont nombreuses. Une des causes les plus fréquente est le fait que les différents intervenants s’attendent les uns les autres. Une personne attend qu'une autre lui délivre un document mais ce dernier l'ignore et pendant ce temps il fait autre chose sans se rendre compte qu'il risque de mettre tout le projet en retard. Un projet est une succession de passages de balles qui doit doivent se faire sans anicroche.

Trois situations critiques peuvent survenir et se traduire par des dérives significatives :

·      Détecter les tâches qui peuvent avoir été oubliées. Au cours d'une étape une ou plusieurs tâches importantes sont oubliées mais on ne s'en aperçoit que plus tard lorsqu'on a besoin de leurs résultats et on constate leur absence. Il est alors nécessaire de les réaliser toutes affaires cessantes. Cela ne peut que se traduire par un allongement des délais et une dérive des coûts.

·   Effectuer certaines tâches trop en avance sur le planning théorique. Une faible coordination se traduit par des initiatives individuelles qui aboutissent à réaliser des travaux en avance par rapport à des dates plus raisonnables pour les effectuer. Dans ces conditions on est amené à présumer certains résultats. Or ils peuvent ensuite être infirmés par les travaux qui sont ensuite effectués. Dans ces conditions certains travaux doivent être refait.

C'est par exemple le cas lorsqu'on effectue la définition de l’architecture technique en même temps que les travaux d’expression des besoins. Or, on le sait bien, l'architecture technique ne peut être définie que lorsque l’analyse fonctionnelle est terminée. Dans ces conditions il alors nécessaire de refaire la définition de l'architecture technique.

·      Eviter que certaines tâches soient faites en double.  Il arrive que le même travail soit fait à la fois par les utilisateurs et par les informaticiens, par exemple la définition des écrans et des états. C'est une lourde charge de travail et qui pèse sur les délais. Il est important de veiller à ne faire qu'une seule fois le travail et à bien le faire.

Comme on le voit les risques de dérives sont importants. Pour les limiter il est nécessaire d'identifier les tâches à effectuer, décider qui va les accomplir et à quel moment il va le faire. Leur identification et leur affectation est un point clé de la gestion de projet. 

Se poser les bonnes questions

Pour organiser efficacement une étape d’un projet on commence par identifier les différentes tâches qui doivent être effectuées et ensuite on va les affecter aux différents participants concernés. Pour cela on s'efforce de répondre aux cinq questions traditionnelles :

·      Qui fait,

·      Quoi,

·      Où,

·      Comment

·      Quand.      

Ces questions se résument par le sigle traditionnel : QQOCQ. Certains préfèrent le QQOQCCP correspondant à : Qui, Quoi, Où, Comment, Combien et Pourquoi. Effectivement il peut être intéressant de répondre aux questions : Combien et Pourquoi. A mon avis cela n'apporte pas grand-chose mais dans certains cas cela peut être utile.

Le sigle QQOCQ est une traduction du sigle anglais 5 W pour Who, What, Where, When et Why. En français ce sont : Qui, Quoi, Où, Quand et Pourquoi.

Cette démarche n'est pas nouvelle. Elle remonte à l'antiquité. C'est une méthode d’exposé des circonstances d’une situation définie proposée par un professeur de rhétorique grec : Hermagoras de Temnos et reprise quelques siècles plus tard par Saint-Augustin. En latin On considère : le Quis, Quid, Quando, Ubi, Cur, Quem ad modum, Quibus adminiculs qu'il est possible de traduire par : Qui, Qu’est-ce, Quand, Où, Pourquoi, De quelle façon, Ce qui permet.

De manière concrète pour chaque tâche on va s'attacher à répondre à ces cinq questions. On établit pour cela un tableau avec en ligne les différentes tâches identifiées qui doivent être effectuées au cours de l'étape et en colonne les différentes questions de base : Qui fait Quoi, Où, Comment et Quand. Ceci permet d'identifier sans ambiguïtés toutes les tâches à effectuer et les différents acteurs concernés.

Bien entendu, d'une étape à l'autre la liste des tâches sont différentes par contre d'un projet à l'autre on retrouve à peu près la même liste de tâches. Il est pour cette raison utile d’avoir une liste des tâches standard. 

Définir la règle du jeu de l’étape

On va reprendre de ce tableau la liste des tâches et les responsables à qui elles sont affectées. C'est la base de la note de cadrage. On va indiquer pour chaque tâche le rôle que va jouer chaque intervenant. On appelle ce tableau un RACI car on indique dans chaque case du tableau le rôle de chacun à l'aide des quatre lettres suivantes :

Exemple RACI

·      R : responsible. : responsable

·      A : accountable : ou peut le traduire par « autorité » mais ce sont ceux qui doivent rendre des comptes

·      C : consulted. : consulté

·      I : informed : informé.

Exemple de tableau RACI

On s'aperçoit souvent qu'il n'est pas toujours simple d’identifier sans ambiguïté le responsable à chaque tâche. Des fois il n'a aucun responsable et des fois il y en a plusieurs. Ceci explique les confusions parfois constatées.

A partir de cette liste de tâches il est possible de fixer pour chacune la date de début, la durée probable et en déduire la date de fin. Il est aussi possible d'estimer la charge de travail nécessaire en nombre de jours en distinguant celle des informaticiens (la maîtrise d'œuvre) et celles des utilisateurs (la maîtrise d'ouvrage). C’est le cœur de la planification des projets.

Le contenu de la note de cadrage

Une note de cadrage est un document court. Généralement elle fait 2 à 3 pages. Elle est généralement rédigée en une demi à une journée par un professionnel expérimenté. Ce document a pour premier objectif de définir le qui fait quoi (^[1]). Pour cela on établit deux listes et un tableau:  

·   La liste des tâches en se basant sur des listes de tâches standard qui sont adaptées aux particularités du projet,

·      La liste des participants au projet : informaticiens et utilisateurs (maîtrise d’œuvre et maîtrise d’ouvrage),

·       Le tableau d’affectation des tâches aux personnes. C’est le rôle du tableau RACI.

Ces deux listes et ce tableau est la base de la note de cadrage.

Il est possible de leur ajouter différents tableaux complémentaires :

·      Une évaluation de la charge de travail nécessaire pour réaliser l'étape. Cette estimation peut être faite globalement ou détaillée par tâche. Elle peut concerner exclusivement le personnel de l'équipe informatique (la maîtrise d'œuvre seule) ou l'ensemble des personnels concernés y compris les utilisateurs participants aux opérations au cours de cette étape (la maîtrise d'œuvre et la maîtrise d'ouvrage).

·     Les délais de réalisation des différentes tâches en tenant compte de leurs dates de début et dates de fin. Cela peut être une évaluation globale ou une estimation tâche par tâche. Il est ainsi possible de fixer une date probable de fin de l'étape.

Ces informations sont très utiles pour informer les différents intervenants la charge de travail qui leur est affecté et les contraintes de délai qu'ils doivent respecter.

On peut envisager d'ajouter à ces données quelques informations générales concernant le projet :

·       Le domaine de la future application (à qui et à quoi elle servira).

·       Les objectifs à atteindre qui ont été fixés à l'origine du projet.

·       La démarche suivie et notamment la liste des étapes (le découpage du projet).

·       La description des livrables de l'étape (par exemple le plan des documents à livrer).

Il n'est pas nécessaire d'en faire des pages mais de rappeler quelques orientations qui permettront d'éviter d'éventuelles dérives.

Quelques règles simples

Pour établir la note de cadrage il est nécessaire d’appliquer quelques règles de simples comme par exemple :

·      Rédaction de la note de cadrage. Généralement elle est rédigée par le chef de projet. C'est la première chose qu'il doit faire lorsque un projet lui est confié. Il peut arriver que la note de cadrage soit établie par le maître d’ouvrage ou par un assistant à maître d'ouvrage ([2]). La première note de cadrage qui est établie au moment où on décide de réaliser une étude de faisabilité est un cas particulier. Elle est généralement appelée la note de lancement et elle est, très souvent, rédigée par le décideur demandeur du projet.

·    Validation du document. Les différentes notes de cadrage sont validées par le comité de pilotage pour s'assurer du consensus de l’ensemble des parties prenantes. Au début du projet le comité de pilotage n'a pas encore été désigné. Il est alors difficile de trouver une instance de validation. Ce travail peut être confié au comité de direction ou à une commission informatique. Ce n’est pas la meilleure solution mais c’est mieux que l’absence de validation.

·   Clarté du texte. Il est important d'avoir un document court et clair. Un document trop volumineux ne sera pas lu par les décideurs. De plus il sera long à rédiger or, au moment d'un lancement d'une nouvelle étape, il faut aller vite. Il ne faut pas que la note de cadrage dépasse 3 pages. Au-delà c'est déjà un document d'analyse qui risque d'anticiper sur des travaux qui seront effectués ultérieurement. 

·      Avoir un modèle de référence. Pour aller vite il est pratique que le rédacteur ait à sa disposition un modèle de référence de la note de cadrage et qu'il adapte au cas particulier qu'il va prendre en charge. Cette collection de notes de cadrages de référence couvrant les différentes étapes du projet doivent être maintenu par la direction des études de la direction des systèmes d'informatique, et plus particulièrement par le responsable méthode, s'il existe.

·       Liste des tâches standards. D'un projet à l'autre on retrouve à peu près les mêmes tâches aux différentes étapes du projet. Il est pour cette raison souhaitable de mettre à la disposition des chefs de projets une liste des tâches standard correspondant à chaque étape (^[3]). A défaut on peut s’inspirer du découpage d’un projet analogue.

·      Trouver la bonne maille. Il est recommandé de ne pas décomposer l'étape en tâches trop petites. En moyenne elles durent de 1 à 5 jours par tâche, rarement plus. On commence la rédaction d'un programme le lundi, on le test et le termine le vendredi. On a intérêt à regrouper les opérations voisines en une seule tâche par exemple la programmation, les tests techniques et la documentation d'un programme est une même tâche et non en trois. De même si un groupe de travail se réunit une fois par semaine pendant trois mois, soit environ 10 réunions, on considère que ce ne sont pas dix tâches mais une seule. Par contre la rédaction du cahier des charges, qui représente une grosse charge de travail, peut être décomposé en plusieurs tâches par exemple une tâche par chapitre important.

·     Ne pas oublier le style. Une attention particulière doit être portée au style de la note de cadrage. Il doit être simple et direct. On doit éviter d'employer des termes trop généraux car ils sont souvent source d'ambiguïté et donc de confusion.

·    S’assurer du consensus. Il est important de s'assurer qu'il existe un réel consensus de l’ensemble des intervenants et des différentes parties prenantes. Il est nécessaire qu'il y ai un accord sur les objectifs recherchés, les délais de réalisation et de mise en place. Enfin un accord explicite doit exister concernant la charge de travail nécessaire pour mener à bien l'étape.

·      Limiter le volume de travail. L'expérience montre qu'il n'est pas souhaitable de passer trop temps à établir la note de cadrage. Un professionnel expérimenté disposant d'un modèle et d'une liste des tâches standard n'a pas besoin de plus d'une journée de travail. Par contre il peut arriver qu'il passe plus de temps ensuite à la faire valider par l'ensemble des parties prenantes, surtout si elles sont réticences au projet.

Ces différentes règles sont simples à appliquer et ne posent pas de problèmes. Faut-il encore les appliquer. Or, très souvent, croyant bien faire, on en fait trop. On finit pas faire de la rédaction de la note de cadrage une étape avant celle qui est à réaliser. Ce n’est pas raisonnable. Il est nécessaire d’aller vite.

Rédaction et validation de la note de cadrage

Dans le cadre d'un projet il est nécessaire d'établir au moins quatre notes de cadrage  correspondant aux principales étapes :

·       L’expression des besoins souvent appelé l'étude de faisabilité ou business case. Dans certains cas on l’appelle la note de lancement.

·       Le cahier des charges correspondant à l'étape d'analyse fonctionnelle.

·      La réalisation. Elle peut comprendre une ou plusieurs étapes. Il peut y avoir aussi plusieurs itérations dans le cas de démarches agiles avec des livrables intermédiaires. 

·       Les tests. Cette note de cadrage particulière s’appelle souvent un plan de tests.

Mais souvent dans un projet il peut y avoir un nombre supérieur à quatre étapes. Dans ce cas on a un plus grand nombre de notes de cadrage.

L'expression des besoins et le cahier des charges peuvent être regroupés en une seule étape comme c'est notamment le cas dans les méthodes agiles. On note que chaque méthode s'est attachée à donner un nom particulier à cette étape : la phase d'exploration, l'initialisation, l'établissement de scénarios, le backlog, l'inception, le use case,... En fait ce sont tous des études de faisabilité plus ou moins complètes.

La maîtrise d’ouvrage a la responsabilité de s'assurer qu'avant le début de chaque étape une note de cadrage a été établie. S'il n'y a pas de chef de projet ou s'il a "oublié" de la rédiger le maître d'ouvrage peut rédiger ce document à sa place. Il arrive parfois que la direction informatique rédige la note de cadrage notamment pour les étapes de réalisation et de tests. Ce n'est pas la meilleure solution mais parfois "faute de grives on mange des merles".

Dans tous les cas le comité de pilotage joue un rôle important. Il a pour mission de s'assurer qu’à chaque étape une note de cadrage est rédigée par le chef de projet et qu'elle est conforme aux baselines du planning et du budget du projet. En cas de dérive par rapport à ces objectifs il est à même de prendre alors des décisions de redressement.

Aller plus loin que la note de cadrage

Dans le cas de projets complexes ou comportant des risques élevées on peut avoir une démarche plus structurée. C'est le rôle des Plans de Management de Projet souvent appelés PMP. C'est un document reprenant les différentes notes de cadrages correspondant aux différentes étapes du projet. Il est lancé au départ du projet. L'étape à venir est détaillée et les suivantes sont plus sommaires. Au fur et à mesure de l'avancement du projet des versions successives sont établies éliminant les étapes terminées et complétant le texte des étapes à venir. Souvent on isole en tête du document les dispositifs communs aux différentes étapes : le comité de pilotage, l'instance de coordination, la mesure de l'avancement, le suivi du budget, le tableau de bord du projet, ...

On peut aller plus loin avec les PDL, Plans de Développement de Logiciel, ou les PDP, Plans de Développement de Projet. Ce sont des documents plus ambitieux avec une définition de l'organisation du projet et de ses différentes instances de coordination, la définition des différents livrables, leurs règles de validation,.... Cette démarche concerne des projets complexes réalisés par plusieurs équipes se trouvant dans des pays différents et parlant des langues différentes, ayant des méthodes de travail différentes, …. On trouve des PDL ou des PDP dans le cas de développement de systèmes d'exploitation, des logiciels de gestion de bases de données ou des systèmes d'armes.

Au-delà de la note de cadrage

Il est aussi possible d'aller plus loin en mettant en place d’un PAQ : Plan d’Assurance Qualité. Dans ce cas on quitte le management de projet pour s'approcher d'une démarche qualité. Les deux approches sont assez voisines mais elles n'ont pas les mêmes objectifs ni les mêmes coûts. En effet la mise en place d'un PAQ a un coût non-négligeable. Il est de l’ordre de 10 % du coût du projet soit une somme équivalente au coût du management de projet. Mais si les risques de dérives ou de non-qualités sont élevés ce surcoût est parfaitement justifié. Ceci fait qu'on ne mettra en place un PAQ que si on estime que c’est nécessaire. Il est pour cela important d’évaluer les risques et les enjeux.

Mais dans la plupart des projets on n'a pas besoin de PMP, de PDL, de PDP ou de PAQ. Une simple note de cadrage par étape est largement suffisante. Par contre l'absence de ces notes de cadrage est une grave faiblesse qui peut se traduire par de graves dérives de charge, de délais et de coûts. L'absence de note cadrage explique les fragilités de nombreux projets trop souvent constatés. Les auditeurs chargés d'évaluer des projets le savent bien. La plupart des projets rencontrant de graves difficultés n'ont pas de note de cadrage. C'est un point d'audit bien connu.  

---

^[1] - Par analogie avec le théâtre on parle de "la distribution des rôles". Ainsi chacun sait ce qu'il doit faire.

[2] - Cette solution peut poser quelques problèmes car lorsque le chef de projet est nommé il arrive qu’il constate qu’il n’a pas forcement la même vision des travaux à effectuer

^[3] - Les entreprises ayant défini un découpage WBS (Work Breakdown Structure) standard il suffit de le reprendre tel quel.