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),
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.
· 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.
Aucun commentaire:
Enregistrer un commentaire