Phases
Introduction
Cycle de vie du projet
La méthode de gestion de projet HERMES utilise un modèle de phases qui permet une approche classique ou agile. Le modèle de phases proprement dit repose sur le cycle de vie du projet. Il crée les conditions requises pour que toutes les parties prenantes comprennent le déroulement du projet de la même manière. Les phases déterminent la structure du projet.
La figure 12 montre le cycle de vie d'un projet HERMES.
Figure 12 Cycle de vie de projet HERMES
Le cycle de vie de projet HERMES se divise en trois parties: début du projet , création de la solution et fin du projet.
Le début du projet est consacré à l'ortientation du projet selon les visions, les besoins et les objectifs. Très souvent, l'accent est mis à la fois sur l'urgence d'agir et sur l'influence d'instances externes (législateur, politique, accord international, règles d'association, etc.) ou prépondérantes (organisation permanente, programme ou portefeuille).
La création de la solution selon l'approche classique ou agile présuppose que l'exécution du projet est validée.
La fin du projet clôture le projet en cours sur le plan organisationnel et formel; elle prépare la transition vers l'organisation d'application.
Début du projet
Le début du projet comprend toujours la phase d'initialisation . La figure 13 montre le déroulement et les résultats de l'initialisation.
Figure 13 Diagramme des résultats de la phase d'initialisation
Lors de l'initialisation, les bases spécifiques du projet et les variantes de solution sont élaborées, comparées et évaluées. Le choix de la variante détermine également si la méthode de développement sera classique ou agile. Cette décision doit être motivée par des raisons professionnelles et techniques et ne doit pas simplement dépendre d'un effet de mode. La procédure est proposée en fonction des conditions préalables du projet et de la variante choisie.
Création de la solution
Les approches classique et agile se distinguent dans la méthode de création de la solution par l'approche de développement choisie. La plupart des éléments de la méthode sont à peu près identiques dans les deux approches; ce qui diffère, ce sont l'organisation et la structure du projet, et par conséquent l'approche de développement et, finalement, en partie aussi le contenu de la méthode, le contenu technique et formel des résultats obtenus.
Dans la gestion du développement agile , les changements constituent une partie fondamentale du processus. L'équipe de développement axe son travail sur les effets prescrits et souhaités et réagit en s'adaptant activement à l'évolution des exigences plutôt que de suivre un plan défini. Le développement et le déploiement se font de manière itérative et incrémentale. Une structure de phases n'a pas de sens dans cette procédure. C'est pourquoi la phase de mise en æuvre ne peut pas être subdivisée davantage.
Une fois que l'exécution du projet est libérée, la création de la solution se déroule soit
- de manière classique
avec les phases Conception , Réalisation et Déploiement , soit - de manière agile
avec la phase Mise en æuvre ,
et elle se termine par la phase Clôture , quelle que soit la méthode choisie.
Les interfaces avec l'organisation permanente restent en grande partie les mêmes, de même que les documents requis pour la clôture du projet.
Fin du projet
La phase de clôture se situe toujours à la fin du projet. C'est la dernière phase du projet et elle y met définitivement un terme. L'accent y est particulièrement mis sur la documentation de projet, qui est contrôlée formellement et, le cas échéant, complétée et classée. En outre, cette phase permet de régler la transition organisationnelle et administrative de l'organisation de projet vers l'organisation d'application, de désactiver ou de supprimer les anciens systèmes, d'archiver toutes les données de projet conformément aux dispositions de l'organisation permanente et, le cas échéant, de transférer la responsabilité de la solution.
La phase de clôture a notamment pour but de garantir que les interfaces de transfert et de transition organisationnelles et administratives du projet (par rapport à l'organisation permanente, au programme, au portefeuille, à l'organisation de l'application, éventuellement à l'organisation d'exploitation, etc.) restent identiques, quelle que soit l'approche choisie.
Aperçu des phases
Le modèle des phases HERMES
Le modèle de phases HERMES est conçu pour répondre aux exigences élevées que posent les différents types de projets traités dans diverses organisations permanentes à plusieurs niveaux hiérarchiques et décisionnels selon des approches classiques et agiles . La figure 14 représente le modèle de phases pour les projets menés selon l'approche classique ou agile.
Figure 14 Modèle de phases HERMES pour procédures classiques et agiles
Le modèle de phases
- présente toujours la même structure de projet à l'organisation permanente, offre des interfaces uniformes,
- couvre les besoins usuels de la direction en matière de contrôle et de reporting,
- s'intègre pleinement dans une organisation permanente favorisant l'approche classique ou agile,
- exploite les synergies et évite les redondances, et
- est facile à utiliser.
Le tableau montre le modèle de phases avec une approche de développement classique et agile .
| Phases HERMES développement classique | Cycle de vie du projet | Phases HERMES développement agile |
|---|---|---|
| Initialisation | Début du projet | Initialisation |
| Conception | Création de la solution | Mise en æuvre |
| Réalisation | ||
| Déploiement | ||
| Clôture | Fin du projet | Clôture |
Structure de projet uniforme
La première et la dernière phase sont communes à tous les projets, qui commencent systématiquement par la phase d'initialisation et se terminent par la phase de clôture. L'uniformité de la structure et du cycle de vie du projet est ainsi garantie. Les interfaces de projet avec l'organisation permanente, le contrôle de gestion, le programme, le portefeuille, etc. sont connectées de la même manière, quelle que soit la procédure. Les transitions vers l'organisation d'application et l'organisation d'exploitation sont canalisées de la même manière.
La structure de projet est en outre soutenue par les jalons décrits au chap. 4. Au cours du projet, les jalons marquent les principales décisions de la conduite et du pilotage de projet. La Figure 15 montre qu'il y a des jalons au début et à la fin de chaque phase. Lors de la libération, le mandant valide les ressources (finances, personnel, infrastructure) pour la phase suivante. D'autres jalons facultatifs peuvent être définis durant la phase agile de mise en æuvre pour la libération d'un release (version).
Figure 15 Jalons au début et à la fin de chaque phase et à la libération d'une release
Ces jalons relatifs à la structure du projet correspondent à Quality Gates, avant la réalisation desquelles résultats et la suite du projet sont décidés. À chaque jalon, on vérifie que le projet respecte les directives et qu'il correspond aux objectifs stratégiques de l'organisation permanente.
Déroulement des phases
La phase d'initialisation constitue une base pour la planification et le pilotage du projet. Une fois la phase d'initialisation terminée, la création de la solution commence avec les phases Conception, Réalisation et Déploiement (approche classique) ou avec la phase Mise en æuvre (approche agile). La phase de mise en æuvre englobe la méthode de développement agile et sert à intégrer au cadre HERMES une méthode agile de développement, quelle qu'elle soit.
La phase Clôture permet de prendre toutes les mesures nécessaires pour supprimer l'ancien environnement produit ou système, y compris l'infrastructure qui n'est plus nécessaire, et pour arrêter systématiquement le projet y compris toutes les mesures administratives et organisationnelles.
Au cours des phases, il existe d'autres jalons spécifiques qui correspondent à des décisions déterminantes pour la réussite du projet. Ces jalons dépendent de la nature du projet. La Figure 16 montre par exemple les jalons de pilotage et de conduite pour des projets de développement informatique selon les approches classique et agile.
Figure 16 Jalons pour projets de développement informatique classiques et agiles
Le jalon Suite du projet et d'autres jalons prennent en compte la réalisation des objectifs de durabilité (voir chap. 7) comme critère d'évaluation.
Tout au long du projet, les rapports sont établis conformément aux directives de l'organisation permanente pour ce qui est du contenu et, dans la mesure du possible, de la fréquence (voir chap. 7).
Explications concernant la description des phases
La description de chaque phase est construite sur le modèle suivant:
- description de la phase, caractères gras en couleur
- énumération et description sommaire de ce qui doit être fait pendant la phase
- description de la clôture de la phase, caractères gras en couleur