Where Have You Been? It's alright we know where you've been Pink Floyd

Objectifs de nos articles

Nos articles visent à partager avec nos lecteurs les méthodes et les pratiques que Lato Sensu Management applique tous les jours à la conduite des projets dans les secteurs bancaire, des télécoms et de la pharmacie. Ils ambitionnent également de susciter le dialogue et l'échange d'idées.

Lorsqu'un article est affublé de l'avertissement « à paraître » cela indique qu'il n'est pas disponible ou qu'il n'est pas encore finalisé.

2008-12-23 à 10:19:01

Écrire le rapport de clôture de projet

clôture de projet

2008-12-23 – 10:00

2008-12-23 – 20:00

2008-12-23 – 10:00

Lorsqu'un projet se termine, quelques activités de clôture doivent encore être exécutées. Fragmentairement, on peut énumérer les éléments suivants :

  • Identification des actions de suivi
  • Évaluer le projet

Cet article explique la partie d'évaluation du projet, à savoir l'écriture du Rapport de clôture du projet.

Qu'est-ce qu'un rapport de clôture de projet ?

En deux mots, le Rapport de clôture de projet doit permettre de :

  1. Clôturer officiellement le projet
  2. Tirer les enseignements du projet

Clôturer officiellement le projet

Le Rapport de clôture de projet doit servir à pouvoir clôturer le projet de manière officielle. Il doit donc permettre au Senior Management de prendre une décision éclairée (sur base de faits tangibles et, dans la mesure du possible, mesurables) pour pouvoir officiellement déclaré le projet clos.

Toutes les organisations peuvent avoir leurs propres critères objectifs pour établir le bilan du projet. Lato Sensu Management s'adapte à chaque client et aux procédures mises en place. Cependant, nous reprenons systématiquement les données suivantes :

  • Budget et contingence
  • Planification (ligne de temps)
  • Risques et problèmes (Risks & Issues)
  • Défauts du projet
  • Adhésion à la gouvernance

L'ensemble des critères du bilan est présenté dès la phase de Business Case (phase d'Initiation du projet), c'est-à-dire dès le début du projet (généralement dans ce qu'on appelle le Project Quality Plan). Nous insistons sur ce fait car nous voyons trop souvent des projets où les critères d'évaluation sont établis à la fin, et sont donc choisis en fonction de résultats connus. Nous nous opposons fermement à cette manière de procéder, mais, naturellement, c'est au client de décider ce que son organisation veut bien entendre.

Des mesures simples et efficaces peuvent être utilisées pour les critères que nous venons de présenter. Par exemple, d'un point de vue budgétaire, sommes-nous sous le budget initial, à fleur de budget, ou au-dessus du budget alloué ? Vous pouvez même descendre dans le détail en attribuant une note positive supplémentaire aux projets qui ne « mangent » pas toute leur contingence (mesure de maturité).

Pareil pour la ligne de temps : le projet est-il terminé avant la date prévue, à la date prévue, après la date prévue initialement ?

Pour ce qui est de la gestion des risques et problèmes, nous vous suggérons de prendre comme mesure le nombre de risques et problèmes qui restent ouverts et d'établir un tableau de pondération suivant leur impact potentiel. Une mesure plus précise peut être obtenue en calculant la vitesse de réaction aux risques (temps mitoyen entre la prise en compte du risque et sa clôture) … mais pour ce faire, vous devriez disposer d'une base de données qui regroupe ces éléments.

Pour les défauts enregistrés sur le projet, pourquoi ne pas utiliser le nombre de défauts ouverts (bugs ou defects), conjugués à leur sévérité ?

Enfin, l'adhésion à la gouvernance peut se mesurer très simplement également : chaque délivrable exigé a-t-il été créé, a-t-il été revu, a-t-il été approuvé ? Tenez à jour un tableau et présentez-en le score final.

Pour élémentaires que ces critères soient, ils n'en permettent pas moins de tirer un bilan chiffré du projet (… et si les choses ne peuvent être présentées en chiffres, il n'y a pas de science : seulement des opinions !). Il vous appartient d'affiner les paramètres pour rendre des conclusions plus détaillées, plus subtiles, probablement plus exactes. L'objectif est d'obtenir une notation, un score global que vous représenterez sous forme de matrice {{{RAG}}} (Red, Amber, Green).

Tirer les enseignements du projet

Le rapport de fin de projet doit permettre au chef de projet de tirer le bilan général du projet ainsi que les enseignements que la conduite du projet a révélés. Lesdits enseignements doivent être consolidés dans le grand grimoire des chefs de projet, ce qu'on appelle la {{{PKB}}}, la Project Knowledge Base.

Ce bilan serait entièrement inutile, réduit qu'il serait à un simple travail administratif — et disons-le tout de suite, il est souvent résumé à cette gabégie — s'il ne servait plus tard à éviter les pièges et écueils connus. Le bilan de fin de projet, le rapport de clôture de projet donc, doit avoir des côtés pratiques évidents. Il ne doit donc pas être conciliant, pas plus qu'il ne doit servir à régler des comptes. Il est donc essentiel que l'information qui s'y trouve résumée soit basée sur des faits et que des solutions pratiques soient dégagées.