L’efficacité de
la gestion de projet se mesure. Elle s’apprécie en grande partie par la
capacité du chef de projet à tenir son planning. C’est un enjeu fondamental. Un
planning bien conçu s’exécute sans peine et permet de mieux maîtriser le
déroulement du projet. A contrario un planning mal conçu est difficile à tenir.
Cela se traduit par un projet chaotique et finit par aboutir à des dérives
significatives.
Une fois le
planning établi il est nécessaire de s’attacher à le suivre. Au fur et à mesure
de son déroulement il est nécessaire de détecter des écarts notamment entre les
dates prévues et la date réelle. Ce suivi est un moyen efficace de pilotage des
projets permettant de détecter d’éventuelles dérives et de réagir rapidement.
La gestion du
planning est un outil de pilotage indispensable car il met à la disposition du
chef de projet et du management un outil de suivi des opérations qui permet de détecter
un éventuel dysfonctionnement. La crédibilité des informaticiens et notamment
des chefs de projet se jouent sur leur capacité à établir et à gérer le
planning des projets qui leur sont confiés.
Les conséquences de la complexité des projets
Vu de l’extérieur
un projet peut paraître simple. Mais en réalité ce n’est jamais le cas. C’est toujours
une opération complexe car de nombreux intervenants sont concernés, une grande
variété d’activités est mise en œuvre, un nombre élevé de tâches sont effectuées
et surtout le déroulement des opérations peut s’étaler sur des mois ou des
années. Un projet de taille moyenne comprend des centaines, voire plusieurs
milliers, d’événements significatifs. Très vite les intervenants sont noyés
dans ces masses d’informations.
Une partie significative
de ces événements est constituée par les débuts et les fins de tâches. Lorsque le
nombre de tâches croit on passe de quelques centaines à des milliers de faits à
gérer. La croissance du nombre de tâches est un facteur expliquant la complexité
des projets. Plus la taille projet est importante plus la probabilité de dérive
est élevée. Ceci explique la difficulté particulière ressentie à maîtriser les
projets de grandes tailles.
Les analyses du
Standish Group ([1])
montrent très clairement que les grands projets ([2])
sont particulièrement fragiles : plus d’un projet sur 3 échoue (38 %).
C’est un chiffre très élevé surtout si on le compare au taux d’échec des petits
projets qui n’est que de 4 %. A cela s’ajoutent le fait que la moitié des
grands projets dérivent (52 %). En conséquence : seulement 10 % des grands
projets arrivent dans les délais et avec le budget prévu alors que 76 % des
petits projets réussissent à tenir la charge, le budget et le planning.
Petits et grands
projets
|
Moyenne
|
Petits projets
|
Grands projets
|
Succès
|
39 %
|
76 %
|
10 %
|
Dérive
|
43 %
|
20 %
|
52 %
|
Echec
|
18 %
|
4 %
|
38 %
|
Taux de succès,
de dérive et d’échec des petits et des grands projets
Source : Chaos Manifesto
2013 : The Standish Group
Casser la complexité des projets
Pour la Standish
Group il y existe deux solutions permettant de sortir de cette situation :
·
Casser les grands projets en une série de plus
petits projets. L’idée est intéressante, faut-il encore que cela soit possible !
Or certaines applications, de par leur nature, ne peuvent pas être découpées en
plusieurs projets. Cependant ce n’est pas la règle générale et il existe effectivement
de grands projets qui peuvent être décomposés en phases.
·
Réduire la complexité fonctionnelle de ces
applications en se concentrant sur les fonctions essentielles. L’idée est de repousser
les options et les cas particuliers qui représentent 80 % du code mais ne
répondent qu’à 20 % des utilisations. Il serait ainsi possible de réduire le
volume de travail nécessaire et obtenir plus rapidement des applications
opérationnelles.
Ces
solutions sont intéressantes mais dans la pratique elles ne sont pas évidentes
à mettre en œuvre. Ce n’est pas sans rappeler l’idée d’Alphonse Allais de
mettre les villes à la campagne. Souvent les concepteurs n’ont pas le choix.
Par exemple, la mise en place d’un ERP est un bloc et il est difficile de
découper l’opération en tranches. De même il est difficile d’éliminer les cas
particuliers d’une application car cela risque de la rendre difficilement utilisable.
Les architectures intégrées poussent à avoir des projets de grande taille.
La
bonne nouvelle est qu’il y a de moins en moins de projets de ce type car la
plupart des grandes entreprises ont déjà mis en place leur ERP et aujourd’hui les
projets portent surtout sur la migration d’une version à l’autre ou sur la généralisation
d’un système à l’ensemble de l’entreprise, notamment en cas de rachat de
nouvelles entreprises et de fusion au sein d’un même groupe de filiales. De
plus la basse conjoncture observée depuis 2008 a énergiquement réduit le nombre
des grands projets.
Faire simple n’est déjà pas si simple que
ça
Il est certain
que pour maîtriser les projets il est nécessaire de chercher à réduire leur complexité.
Le nombre de solutions n’est pas infini. En fait il n’y en a que deux :
soit réduire le nombre de fonctions et de sous-fonctions mises en œuvre, soit
améliorer la technique de gestion de projet. Comme la première solution n’est
pas réaliste, il reste la seconde.
Pour y arriver on
a pris l’habitude de regrouper un ensemble de tâches concourant au même
résultat en étape encadrés par une date de début et une date de fin. Ce sont,
par exemple, l’expression des besoins, l’analyse fonctionnelle, l’analyse détaillée,
la définition de l’architecture technique, la programmation, les tests,…. Elle
a représenté une innovation majeure dans la gestion de projet. Elle n’est pas
spécifique à l’informatique. On la retrouve dans tous les projets :
industriels, de recherche et développement, de travaux publics,… Les étapes
portent des noms différents mais les concepts mis en œuvre sont les mêmes.
C’est une notion importante
car elle permet de simplifier considérablement la gestion de projet. Au lieu de
gérer des centaines, voire des milliers, de dates on ne gère que quelques étapes
ou quelques dizaines avec, à chaque fois, la date de début et la date de fin ([3]).
La gestion des étapes représente un progrès significatif. Autre avantage, l’existence
des étapes est un moyen simple et rapide permettant de mesurer l’avancement du
projet ([4]).
Dans ces conditions un projet, même complexe commence à devenir maîtrisable.
Rôle du planning global
Sur cette base on
établit un planning global. Généralement c’est un graphique de type Gantt avec
en abscisse le temps, chaque étape étant représentée par un trait allant de sa
date de début à sa date de fin. Le graphique à barre n’est pas la seule
représentation possible. Il existe de nombreux types de graphiques comme par
exemple un réseau (Pert), le schéma du type chemin de fer, une représentation en
cercle, une représentation à base d’histogramme, un tableau en mode radar, ...
Le graphique de
type Gantt a l’avantage d’être un document facile à lire et à comprendre. Il
est généralement remis aux décideurs pour leur permettre de comprendre le
déroulement des opérations. Il est ainsi possible de répondre à la plupart des
questions habituelles : « où est-on ? », « quel est le
retard moyen ? », « dans ces conditions quand est-ce que l’application
sera effectivement opérationnelle ? »,…
Au départ ce
schéma est un outil de communication. Mais, au cours de projets, son rôle évolue.
Au fur et à mesure du déroulement du projet on note la date réelle des
événements des projets. Il est ainsi possible de mesurer l’avancement du projet
(4). Ceci fait que le planning devient un outil de pilotage du projet.
Mais il est
possible d’aller plus loin. En rapprochant pour quelques dates clés les dates
prévues et les dates réelles on est capable d’évaluer le retard moyen du projet
([5]).
Le planning devient ainsi un outil d’alerte permettant de détecter des dérives
significatives du projet.
Les illusions d’un planning détaillé
Très souvent on
cherche à établir le planning global du projet à partir du planning détaillé
décrivant l’ensemble des tâches à effectuer. Cela parait logique. Mais en pratique
il est assez illusoire de vouloir identifier un ou deux ans à l’avance le
détail de toutes les opérations qu’il sera nécessaire d’effectuer alors qu’on ne
sait pas encore ce qu’il sera nécessaire de réaliser. Au départ on ignore tout
sur le projet l’étape d’expression des besoins a justement pour but de
connaître le périmètre fonctionnel et déterminer ce qu’il va être nécessaire de
réaliser puis de tester.
En fait, il n’est
pas possible de définir le détail des tâches de réalisation avant que l’analyse
fonctionnelle soit terminée. Ensuite il est nécessaire de définir le détail des
opérations de test généralement appelé le plan de tests. Mais ceci n’est
possible qu’à partir du moment où une partie de l’application est en cours de réalisation.
Dans ces conditions l’idée de définir dès le lancement du projet l’ensemble des
tâches qui devront être effectuées est assez irréaliste.
Même si on était
capable d’identifier toutes les tâches d’un projet et leur enchainement
(enclenchement) le résultat serait un immense tableau ou un graphique qui
ferait plusieurs pages ([6])
et qui ne serait pas très lisible. Le décideur à qui on remettrait ce type de
document serait très vite perdu et il lui serait difficile d’avoir une vision
d’ensemble du projet.
Par contre le
planning détaillé est très utile pour pointer la réalisation des tâches : celles
qui ont été effectuées, celles qui sont en cours et celles qui sont en attentes.
Ces listes sont très utiles pour animer les réunions de l’équipe projet mais
elles ne sont pas adaptées pour informer les décideurs de l’état du projet et
ce qui reste encore à faire.
Pour répondre aux
attentes du management la règle simple : on raisonne sur les étapes et on
ignore le détail des tâches. Une étape est en cours ou elle est terminée. Une
étape qui serait presque terminé mais pour laquelle on consomme encore des
jours-homme est classée « en cours ». On considère qu’elle est
terminée à partir du moment où il n’y a plus d’intervention imputée à cette
étape.
Gérer les événements clés
Le pilotage d’un
projet se fait à partir d’un ensemble de ses dates clés. Elles sont peu
nombreuses. Dans le cadre d’un projet ce sont d’abord les dates de début et de
fin d’étape mais ce sont aussi les dates de remise de documents importants, les
réunions du comité de pilotage, la date de livraison d’un matériel ou d’un
ensemble de logiciels, le moment où un système est opérationnel, … Parmi ces
dates il y a des événements qui sont des points de passage obligé : ce
sont les jalons. Ils vont permettre de suivre, nous l’avons vu, le rythme de
progression du projet et le cas échéant mesurer le retard du projet.
L’objectif est
d’avoir en moyenne un jalon tous les deux mois. Ainsi une étape qui dure 6 mois
sera suivie à l’aide de quatre évènements clés : ses dates de début et de
fin auxquelles on ajoute deux jalons intermédiaires. Par exemple la remise d’un
document important ou une réunion d’orientation du comité de pilotage.
Multiplier le nombre de dates clés n’améliore pas de manière significative le
contrôle des opérations. Par contre il a tendance à alourdir ce suivi.
La baseline du
projet repose sur le découpage du projet en phases, en étapes, en lots, en
itérations ([7]),
en run, … Il est ainsi possible de dégager une série de dates clés. C’est la
base permettant ensuite de suivre l’évolution du projet et, éventuellement de
détecter des retards.
Une fois que le
planning est défini on dispose d’une métrique permettant de mesurer
l’avancement du projet et de calculer son retard moyen. S’il n’existe pas il est
délicat de suivre le projet.
Le rôle du journal de bord
Pour bien comprendre
le déroulement du projet il est nécessaire d’avoir une trace des opérations
effectuées. Or, les activités effectuées dans le cadre d’un projet changent régulièrement.
Or, quelques semaines après qu’un événement soit survenu il est très difficile
de se rappeler ce qui s’est exactement passé. Au bout de quelques mois, ce qui
n’a pas été enregistré, est oublié.
Pour arriver à
reconstituer ce qui s’est passé il est toujours possible de recourir aux comptes-rendus
des réunions d’avancement ou des réunions de l’équipe projet ([8]).
C’est notamment le cas si une partie des travaux est sous-traitée à une société
de service. Ces réunions périodiques sont très utiles car elles permettront de
constater qu’à un moment précis tel ensemble d’opérations est terminé et que
les autres sont encore encours ou restent à lancer. C’est pratique mais ce
n’est pas suffisant car dans ce type de document on ne note pas tout, ce qui
fait que certaines événements clés peuvent avoir été oubliées.
Pour éviter cette
situation il est souhaitable que le chef de projet prenne l’habitude de noter au
jour le jour les événements significatifs qu’il observe : les incidents,
les livraisons, les réunions, les problèmes apparus,…. Pour cela il est
nécessaire qu’il mette en place un livre de bord du projet. Il est ainsi
possible de suivre le détail des opérations et, le cas échéant, de voir
apparaître les dérives. Faut-il encore que le chef de projet ait la discipline
de noter tous les soirs avant de quitter son bureau les événements clés qui
sont survenus au cours de la journée. Ce document peut être rédigé à l’aide
d’un cahier mais la plupart du temps il est tenu grâce à un programme de
traitement de texte.
Mesurer les décalages constatés sur le projet
Le suivi régulier
des dates des événements clés est très utile. Il permet de comparer les dates
prévues et les dates réelles. Le suivi de ces dates est très instructif et
montre qu’il existe en matière de retard deux situations possibles :
·
Le décalage constant. On note au départ du
projet un décalage de X jours (ou X semaines) et celui-ci reste le même pendant
toute la durée du projet. Cela veut dire qu’on a pris du retard au début du
projet mais qu’ensuite il se déroule normalement. On constate que la
productivité de l’activité d’études (conception, programmation, tests) est bien
celle qui été prévue.
·
Le décalage croissant. Plus le temps passe plus
le retard augmente. On a, par exemple, au début du projet un retard de 10 jours
mais 3 mois plus tard on est à 20 jours, … Chaque mois on perd trois jours.
C’est une situation inquiétante. Cela veut dire que la productivité des études
et de la réalisation est insuffisante où que le planning prévisionnel a été mal
fait.
On peut espérer
qu’à l’inverse que le retard diminue avec l’avancement du projet. Mais il ne
faut pas rêver : « le temps perdu ne se rattrape guère » ([9]).
Il est très rare que le retard constaté au début du projet soit ensuite
rattrapé.
Pour piloter efficacement
le projet il est nécessaire de mesurer régulièrement le retard moyen du projet
et essayé d’évaluer la date probable de fin du projet.
Etre capable de réagir rapidement à toute
dérive
Le suivi du
planning est le dispositif central de la gestion des projets. Il est ainsi
possible de détecter et de suivre d’éventuelles dérives des projets. Il permet d’alerter
rapidement les décideurs d’une dégradation de la situation de sorte qu’il est
possible de prendre rapidement les bonnes décisions. C’est la base d’une réelle
réactivité.
L’idéal est d’arriver
à réagir à toute dérive en moins de 48 heures, même à des incidents qui peuvent
avoir de graves conséquences comme, par exemple, le fait qu’un collaborateur
important du projet tombe gravement malade ou le constat de la défaillance soudaine
d’un fournisseur. Ce délai est mesuré entre le moment où le problème survient
et celui où la solution de remplacement est mise en place.
Souvent le délai
de réaction est de l’ordre d’une semaine. C’est encore acceptable mais c’est un
peu lent car entre temps il peut se passer de nombreux d’événements. Mais si la
structure de pilotage du projet est lourde, avec de nombreux organes de
décision ou de consultation il est difficile de réagir plus vite. Souvent cette
complexité est due à celle de l’entreprise. Avant de faire quoique ce soit il
faut consulter de nombreux organes et avoir l’avis de toutes les « huiles »
possibles. Dans ce cas il est difficile d’améliorer la situation.
Lorsque la
réaction prend plus d’une semaine on est face à un management de projet peu
efficace. Ceci ne concerne pas seulement le chef de projet. En effet, très
souvent la solution ne peut pas venir uniquement de la maîtrise d’œuvre ou du
chef de projet mais relève plutôt du maître d’ouvrage ou du comité de pilotage.
Les délais de réaction sont plus longs car la concertation prend toujours plus
de temps. Comme on le voit le délai de réaction du projet à toute dérive de
planning est un critère de bonne gestion.
Heureusement, grâce
à une bonne organisation il est possible de réduire ces délais et de se
rapprocher d’une réaction en 24 ou 48 heures. C’est l’idéal car cela évite que
le projet prenne du retard.
[1]
- Chaos Manifesto 2013, Standish Group. Ces études font référence en matière de
gestion de projet informatique.
[2]
- Selon le Standish Group, les grands projets ont des budgets en charge de
développement supérieurs à un million de dollars, ce qui me parait être un
seuil très élevé. Il me semble que le seuil est plutôt de l’ordre de 1.000
jours soit de l’ordre de 500.000 dollars.
[3]
- De plus, si on s’y prend bien la date de fin d’une étape et la même que celle
de début de l’étape suivante. C’est une réduction de moitié du nombre de dates
à gérer.
[4]
- Pour cela il suffit de compter le nombre d’étapes terminées, de les pondérer
par la charge de chacune de ces étapes et de le rapporter au nombre total
d’étapes à effectuer.
[5]
- Par exemple la validation du cahier des charges était prévue pour le 12
avril. Elle a été terminée le 15 juin. Le projet a donc 2 mois de retard.
[6]
- Le graphique Pert d’un projet de plusieurs milliers de tâches peut faire
plusieurs mètres carrés.
[7]
- Les itérations sont un des éléments clé des méthodes agiles. Elles reposent
sur un découpage de la phase de conception réalisation en itérations qui ont
une durée fixe et qui se terminent par la livraison d’une partie du code.
[8]
- S’ils ont été rédigés !
[9]
- Comme le chantait Barbara.