5.1 Clore la dernière phase et l’ensemble du projet
Clore la dernière phase et l’ensemble du projet
Cette section explique les particularités de la clôture de la dernière phase du projet qui coïncide avec la clôture de l’ensemble du projet.
La vérification de l’acceptation et de la transition des livrables accomplis, l’évaluation des performances, les décisions concernant la poursuite du projet, la libération de ressources et les autres activités de clôture administrative déjà expliquées, sont effectués à chaque porte de phase. Cependant, à la fin de la dernière phase, lorsqu’il s’agit également de la fin du projet, Il n’est pas aisé de déterminer quelles activités de clôture correspondent à la dernière phase et quelles autres correspondent à la clôture du projet dans son ensemble. Analysons donc les particularités de la clôture de la dernière phase et du projet global, partie par partie
La vérification de l’acceptation et de la transition des livrables accomplis et l’évaluation des performances.
Un critère d’évaluation d’une phase ou du projet est la réalisation des objectifs. Et les objectifs se réfèrent à la livraison du périmètre défini, dans les délais et dans le budget établis, et conformément à tout autre critère de succès défini.
Concernant le périmètre de livraison de la dernière phase, cette dernière phase accomplit le périmètre de livraison du projet. L’acceptation et la transition du périmètre livré dans la dernière phase a un double caractère. D’une part, il délivre un livrable de phase, par exemple la formation des utilisateurs à la manipulation de la solution du projet.
Mais, puisqu’il n’y a plus rien à livrer, cette dernière livraison doit être associée à l’acceptation et à la transition du livrable final du projet. Les exigences fonctionnelles et les attributs de qualité du périmètre livré dans la dernière phase doivent satisfaire aux exigences de produit complet du projet. La ou les réunion(s) de revue du produit à la fin de la dernière phase, doivent démontrer non seulement que les sessions de formation pour apprendre à utiliser la solution ont été un succès. Il doit aussi être démontré que la solution complète est conforme aux exigences du produit. Par conséquent, en ce qui concerne la vérification de l’acceptation et de la transition de livrables, il s’agit à la fois du livrable de la dernière phase et du livrable clé complet de l’ensemble du projet.
Quant à l’évaluation des performances des délais et des coûts à la fin du projet, elles sont mieux évaluées à l’aide de la référence de base de l’échéancier et la référence de base des coûts. La raison n’est pas évidente. Essayons de la comprendre.
L’analyse de la valeur acquise est en fin de projet pas très utile. Son principal avantage est d’être un indicateur précoce des tendances. Mais à la fin du projet, la valeur acquise et la valeur planifiée sont toujours égales à 100 %, sauf si le projet a subi une résiliation anticipée sans fournir la solution. Mais si vous avez livré la solution, le travail effectué correspond à 100 % du travail prévu. Ainsi, à la fin du projet il n’y a pas d’écart de délais et l’indice de performance des délais est toujours égal à 1, même si le projet s’est terminé en retard.
Par conséquent, l’analyse de la valeur acquise n’est pas utile pour mesurer la performance des délais à la fin du projet.
En ce qui concerne les coûts, l’analyse de la valeur acquise peut être utilisée pour mesurer la performance des coûts, car vous compareriez la valeur acquise – qui est égale au budget total approuvé à l’achèvement – et vous diviserez la valeur de ce budget à l’accomplissement par les coûts réels encourus. Par exemple, si vous avez livré l’ensemble du périmètre, budgétisé à 100 €, mais vos coûts réels étaient de 140 €, alors l’indice de performance des coûts de 0,71 (c‘est à dire 100 divisé par 140), montrerait de manière réaliste le dépassement du budget.
En raison de cette anomalie de l’analyse de la valeur acquise, la meilleure pratique à la fin du projet consiste à comparer la date de livraison réelle et les coûts réels avec la référence de base de l’échéancier la référence de base des coûts.
Cependant, si ces références de base ont changé au cours du projet, il est discutable de savoir dans quelle mesure vous devez les comparer aux toutes premières références de base. Disons qu’à la suite des procédures de maîtrise des changements, les références de base ont été mises à jour au cours du projet, pour refléter les changements qui se sont avérées nécessaires pendant l’exécution. Si ces changements étaient approuvés par l’autorité de maîtrise des changements, elle aurait aussi approuvé l’impact de ces changements, sur la référence de base de l’échéancier, et la référence de base des coûts.
Dans ces circonstances, avez-vous – néanmoins – à comparer aux références de base originaires ? On peut soutenir que non. Que la performance réelle doit être comparée à la dernière version de la référence de base. Cependant, parfois, nous écoutons dans les nouvelles à la télévision : « … Le projet X (normalement un projet financé par l’État) a été terminé avec un dépassement budgétaire de 400 % par rapport à son budget initial, et trois ans plus tard que prévu… ». Il s’agit d’une comparaison des coûts réels et des dates réelles avec les références de base originaires, indépendamment de tout ce qui s’est passé et qui a fait changer le projet. Non seulement des explications seront nécessaires à la fin d’un tel projet. Des compétences politiques seraient aussi d’une grande utilité. Mais, si vous avez survécu en tant que chef de projet à un tel projet, vous avez probablement les compétences politiques pour démontrer que le projet a réussi. Et si le chef de projet a été remplacé à mi-chemin et que vous êtes le nouveau, il est clair qui sera tenu pour responsable des dépassements, d’un point de vue politique. Nous voyons rarement les commanditaires assumer la responsabilité des échecs de leurs projets. Il est beaucoup plus fréquent de voir le chef de projet au bûcher.
L’évaluation de la satisfaction des parties prenantes. Cette évaluation est un élément standard à la fois pour la clôture de la phase et la clôture du projet. Pour les parties prenantes qui ont participé à l’ensemble du projet, vous pouvez combiner l’enquête de satisfaction pour la dernière phase et pour l’ensemble du projet en une seule. Pour les parties prenantes qui ne sont intervenues que dans la dernière phase, l’enquête ferait partie de la clôture de la phase.
Les retours d’expérience, font également partie d’une clôture de phase, et d’une clôture de projet. Concernant la dernière phase, il y a des retours d’expérience spécifiques, au type de travail effectué dans la dernière phase. Lorsque vous les rassemblez, vous clôturez en fait la dernière phase. Il y aura probablement des conclusions à tirer des travaux de la dernière phase. Par exemple pour la formation des utilisateurs à utiliser la solution, lors d’une phase finale de déploiement. Il est utile de les rassembler, et de les répertorier. Ils n’aideront pas à améliorer les phases suivantes, car il n’y a pas de phase suivante à la fin du projet. Mais l’organisation, en bénéficiera certainement, lorsqu’un autre projet similaire, exécute une phase similaire de déploiement.
Les retours d’expérience avec une perspective du projet global peuvent ou non avoir quelque chose à ajouter à ce qui a déjà été saisi à chaque clôture de phase. Sinon, le travail principal à la fin du projet est de rassembler les retours d’expérience qui ont déjà été répertoriés à la clôture de chaque phase. Distiller les plus importants avec une perspective du projet complet est probablement une bonne valeur.
Un rapport de clôture de projet comprendra les domaines décrits d’évaluation, c’est-à-dire les degrés d’achèvement des objectifs du projet, de livraison du périmètre défini, les performances temporelles et budgétaires, la satisfaction des parties prenantes et un résumé des retours d’expérience. Une liste d’activités de suivi est également une bonne idée, par exemple pour lister les exigences facultatives qui n’ont pas été mises en œuvre par le projet qui s’achève, mais qui pourraient l’être par un projet ultérieur. Ou toute autre activité de suivi à effectuer par le nouveau propriétaire du livrable clé du projet.
Les décisions concernant la poursuite du projet
Toutes les phases précédentes comportaient un processus de planification et d’approbation de la phase suivante. À la clôture de la dernière phase, il n’y a pas de phase suivante à planifier. Ainsi, cet aspect de la maîtrise aux portes de phase n’est pas effectué pour la dernière phase.
Le processus comparable du point de vue de l’ensemble du projet consisterait à planifier un projet de suivi. Et vous ne devez pas planifier un projet de suivi à la fin du projet qui s’achève. La décision concernant un éventuel projet de suivi doit passer par un processus de gestion du portefeuille qui est régi au niveau de la gouvernance de l’organisation. Peut-être que la direction de l’organisation a d’autres priorités que de mener un projet de suivi pour répondre à certaines exigences qui ont été mises en attente pendant le projet qui se termine maintenant.
Si le projet qui s’achève fait partie d’un programme, il est fort probable qu’un autre projet du programme utilisera le livrable clé du projet en question comme un ingrédient nécessaire ou un catalyseur, mais cela fait partie de la discipline de management de programmes.
Ainsi, cet aspect de la clôture ne s’applique ni pour la dernière phase d’un projet, ni pour un projet dans son ensemble à sa clôture. Du moins pas du point de vue du management d’un projet. Peut-être, oui, du point de vue du management d’un programme si le projet qui s’achève n’est pas le dernier projet du programme.
La clôture administrative
À la fin de la dernière phase du projet, vous devez mener des activités de clôture administrative spécifiques à la dernière phase. Comme il s’agit également de la fin du projet, elles peuvent ressembler à des activités de clôture de projet, mais – d’un point de vue conceptuel – il s’agit d’une clôture de phase.
Par exemple : lors de la libération des ressources utilisées dans la dernière phase, c’est la clôture de la phase. Idem pour les fournisseurs spécifiques à la phase. Les évaluations se font comme vous le feriez à la fin de toute autre phase.
Si vous avez des ressources et des fournisseurs qui ont travaillé tout au long du projet, alors vous ne les avez pas libérés à la fin des phases précédentes. Vous les libèrerez maintenant à la fin du projet. Conceptuellement, cela ferait partie de la clôture du projet. Cela n’empêche pas l’équipe de management du projet de les avoir évalués à la fin de chaque phase précédente.
S’il y a des réclamations ouvertes, certainement à la clôture du projet, vous devez les régler ou les remettre au service juridique car le projet n’existera plus après sa clôture.
Archiver les informations du projet et s’assurer que tous les registres du projet sont mis à jour, ces deux dernières activités de clôture de phase sont également effectuées à la fin de la dernière phase. Une perspective de clôture globale du projet pour ce type d’activités consisterait à consolider et de nettoyer tous ces fichiers et de les migrer vers le repositoire organisationnel correspondant.
Le degré de succès du projet
Il y a deux questions à la fin du projet auxquelles il faut répondre. Le projet a – t – il été couronné de succès ? Et y a-t–il plus de choses à faire ?
Pour répondre à ces questions, il convient de revisiter la charte du projet, qui contient les critères de réussite du projet et les exigences commerciales.
La question concernant la réussite du projet est répondue par les éléments d’évaluation que nous avons expliqués.
Quant aux exigences commerciales formulées dans la charte du projet, il s’agit des capacités que l’organisation avait l’ambition d’acquérir lors de l’initialisation du projet. Un oui à cette question dépend de la qualité de la définition du périmètre du projet. Attention, nous venons de dire la qualité de la définition du périmètre, pas la qualité du périmètre livré. Nous avons évalué dans quelle mesure, quand et pour combien le périmètre défini a été livré. Mais la question sur la satisfaction des exigences commerciales, nous invite à demander dans quelle mesure ce périmètre a été bien défini dans le but d’obtenir les capacités commerciales souhaitées par l’organisation.
Si nous avons fait du bon travail lors de l’élaboration de la charte du projet, la réponse sera un « oui ». S’il y avait une inadéquation entre les exigences commerciales et le livrable clé défini, censé fournir ces capacités, alors nous aurons, dans le meilleur des cas, un périmètre livré selon les exigences du produit, dans les délais et dans le budget, mais qui n’a pas produit toutes les capacités envisagées par l’organisation. Il s’agirait d’un périmètre mal défini mais bien livré. Un autre projet serait nécessaire pour combler le vide. Et le projet qui s’achève recevra une évaluation moins que parfaite, bien qu’il ait livré le périmètre défini dans les délais et le budget.
Autre et dernier aspect à considérer : les bénéfices. Cela peut être un piège pour le chef de projet. Ne tombez pas dedans. L’analyse de rentabilité utilisée pour justifier le projet peut montrer un retour sur investissement attendu du projet, de – par exemple – 16%.
Vous ne devriez pas avoir dans votre charte de projet un retour sur investissement de 16% comme critère de réussite du projet. Parce qu’à la fin du projet, vous ne pouvez pas l’avoir atteint. Les critères de réussite de votre projet doivent être réalisables avec le périmètre de livraison du projet.
Cependant, du point de vue d’un commanditaire, l’entreprise s’attendra au retour sur investissement de 16% et/ou à d’autres bénéfices définis dans l’analyse de rentabilité. Mais cela peut se produire, ou moins en partie, en dehors du périmètre du projet individuel qui s’achève. Peut-être que certains bénéfices sont réalisés durant l’exécution ou à la fin du projet. Mais dans beaucoup de cas, la réalisation de tous les bénéfices et atteindre des objectifs organisationnels dépasse le périmètre d’un projet individuel. C’est une question de management de programmes et de portefeuilles. Les deux comprennent les opérations courantes de l’organisation. C’est dans les opérations courantes où doivent se produire les changements que les projets permettent afin de réaliser les bénéfices cherchés par l’organisation. Le management de programmes est spécifiquement conçu pour obtenir des bénéfices qui ne peuvent être atteintes par des projets individuels. Et atteindre les buts et objectifs de l’organisation est la finalité spécifique du management de portefeuilles.
Du point de vue du chef d’un projet individuel, si le projet a été livré conformément à la référence de base du projet, et conformément aux autres critères de succès définis dans la charte, y compris les exigences commerciales et les exigences en gestion de projet, alors, l’équipe de projet et l’équipe de management du projet peuvent et doivent mesurer et célébrer le succès en conséquence.
À propos de célébrer : vous avez atteint la fin de ce cours.
Bravo ! Toutes nos félicitations !