Bloc d'activités : Clôture du projet

Entreprise : OFB

Client : idem

Projet : Internalisation des applications hébergées par nos prestataires de services et partenaires

Dates/Durée : Avril 2020 / 30 jours

Réalisation : Industrialisation d'une infrastructure système GNU/Linux avant internalisation d'applications métiers

La démarche de clôture a été entreprise peu de temps avant la terminaison officielle du projet, elle fût sanctionnée par la remise d’un livrable défini dans le cahier des charges : une infrastructure GNU/linux évolutive et opérationnelle pour receuillir des serveurs métiers.

Planification et vérification de la recette du projet

Avec le groupe du projet (également exploitant technique de cette nouvelle infrastructure) nous avions établi, initialement, que la démarche de clôture du projet démarrerait au moment où nous commencerions à mettre en service (test, recette puis prod.) des serveurs répondant aux normes établies dans notre cahiers des charges via le nouvel outillage déployé.

Ainsi le 1 juin 2020 nous avons livré deux serveurs utilisés pour les besoins internes du pôle infrastructure :

Nous avons réalisé tout une série de tests anfin de nous assurer que ces 2 serveurs étaient totalement en conformité avec les fiches serveurs.

Cette livraison intervenait donc après une série de test de recette sur d'autres serveurs du pôle SPED de notre établissement.

Livrable pour clôturer le projet

Nous avons rédigé un rapport de clôture sur le projet.

Ce dernier nous a permis de synthétiser les enjeux du projet, ses résultats et les processus qui ont permis d’aboutir à ces résultats. Outre le bilan technique, le rapport de clôture nous a permis de scruter les écarts constatés par rapport au plan de projet initial.

Nous nous sommes posé les questions suivantes afin de nous permettre d’effectuer un bilan méthodologique :

  • Méthode de management de projet utilisée ?

    méthodes agiles, avec des sprint ...

  • Planning  :

    • Quel fût l’écart moyen de réalisation des tâches au par rapport à l’échéancier initial ?

      Il fût peu important à part sur quelques tâches très techniques, clairement identifiées dés le début du projet (architecture Ansible, architecture HAproxy et des bastions de sécurité) ou j'ai du prendre le relais de mes co-équipiers.

    • Le chemin critique a-t-il subi des modifications ?

      Non, dans notre diagramme de Gantt les tâches qui risquaient de ne pas tenir les délais prévues n'ont pas posé de souci particulier.

  • La gestion des tâches :

    • était-elle adapté au pilotage du projet ?

      oui car leur répartition, décidé ensemble, nous à permis d'avancer assez rapidement.

    • A-t-elle subi des modifications en cours de projet (réorganisation, ajouts) ?

      Oui cf. planning.

    • A-t-elle été bien approprié par l’équipe projet ?

      Oui tout à fait.

    • L’avancement du projet était-il suffisamment outillé (tableau de bord) ?

      Pour un projet interne sans intervention de prestataire extérieur : oui.

      De plus notre hierarchie nous a laissé une autonomie totale, avec un objectif clair et un délai par contre très serré : elle n'a jamais exigé la présentation de multiple tableau de bord.

  • Gestion des risques :

    • les risques identifiés en début de projet avaient-ils été pertinemment identifiés ?

      oui en partie, car je diposais d'une solide expèrience dans le domaine de l'hébergement d'aplicatifs métier sur des serveurs GNU/Linux.

    • Certains ont-ils été sous-estimés ou sous-estimés ?

      Oui : le principal étant le niveau de compétence mais aussi la capacité de travail de chacun, mais aussi l'atout d'avoir une équipe constituée de personnes passionnées par les logiciels libres et positives.

    • Quelles conséquences financières (provisions, dérapage) ?

      Financières : aucune, néanmoins il y eu des fois où les séances de travail se terminaient assez tard ... (heures sup. ? .. cela n'existe pas dans notre fonction publique).

Ensuite nous avons du faire une check-list de clôture de projet.

Ainsi nous avons créer une liste de tâches et de livrables à produire en fin de projet pour acter définitivement la fin du projet dans de bonnes conditions.

Elle s'est décliné en 2 axes :

  • Gestion documentaire : rapport de fin de projet, archivage, propositions de modifications du référentiel de management de projet;

  • Satisfaction client : liste des exigences satisfaites et non satisfaites, retours formels (formulaire transmis en fin de mission, CRM) et informels du client, libération du site ou des locaux le cas échéant…

Remarque : nous n'avons pas eu à produire de document concernant la gestion contractuelle (dernières factures, derniers paiements, derniers livrables à remettre, état des services faits réalisé par le donneur d’ordres) , car ce projet était interne sans intervention de prestataires externes ou commandes particulières de matériels, licences etc.

Cette check-list nous a permis de clôturer « physiquement » le projet, avec par exemple l’archivage des dossiers.

En général la clôture du projet en bonne et due forme envoie également un signal aux activités permanentes, qui peuvent éventuellement reprendre le contenu du projet sous la forme opérationnelle ou récupérer des ressources humaines dans certains cas.

Réaliser la clôture du projet

La cloture a propremement parlé de ce projet a été effectué le 23 juillet 2020.

Un réunion a été menée par moi-même en mode « ouvert », c’est-à-dire que tous les membres ont pu s’exprimer sur leur ressenti et réaliser leur propre bilan du projet que ce soit sur le plan :

  • technique,

  • managérial,

  • méthodologique.

Ce fût aussi l’occasion de reconnaître la contribution de chacun aux résultats du projet, quelle qu’en soit l’issue ... qui fût bonne, donc positive sur tous les plans pour nous tous.

Les documents préparatoires de la réunion (synthèse du rapport de clôture, présentation des résultats) ainsi que l’ordre du jour ont été co-construits avec l’ensemble de l’équipe.