lundi 8 septembre 2014

Tenir le planning des projets informatiques


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.