Introduction

Exécution des projets

Le modèle de phases constitue l'épine dorsale du projet. Il structure le cycle de vie du projet et crée les conditions préalables à une compréhension commune des participants concernant le déroulement du projet. Le modèle de phases HERMES représenté à la Figure 11 comprend quatre phases:

1. Initialisation
2. Conception
3. Réalisation
4. Déploiement

Chaque projet commence par la phase Initialisation, au jalon Mandat d'initialisation du projet, et se termine à la fin de la phase Déploiement, au jalon Clôture du projet.

Chaque fin de phase est déterminée par un jalon qui met en évidence la décision concernant la suite des opérations. Les jalons correspondent à des quality gates lors desquels l'état du projet et la qualité de sa planification et de son exécution sont vérifiés. On y assure également la coordination avec les stratégies et objectifs généraux de l'organisation permanente. L'atteinte des jalons est vérifiée au moyen de listes de contrôle qui sont complétées par des critères spécifiques au projet. En complément des jalons de fin de phase, des jalons spécifiques au scénario constituent d'autres quality gates, p. ex. pour la décision sur le choix du modèle.

Le reporting est réalisé tout au long des phases et des jalons selon un contenu et une fréquence conformes aux consignes de l'organisation permanente.

Le modèle de phases constitue aussi une base pour le pilotage financier du projet. Lors de la libération d'une phase, les moyens (finances, personnel, infrastructure) nécessaires pour la phase suivante sont débloqués par le mandant de projet.

Projets dans un programme

Le modèle de phases facilite la coordination et le pilotage des projets dans un programme (voir Figure 12). Il constitue un préalable à l'intégration des projets dans la gestion du portefeuille de projets de l'organisation permanente. Ainsi, les projets peuvent être pilotés de manière générale par l'organisation permanente.

Application du modèle de phases

En principe, les projets traversent successivement les différentes phases. Toutefois, en fonction de l'objet du projet, certains composants d'un système global doivent déjà être mis en æuvre pour qu'un essai à la troupe puisse être effectué. La figure montre, par exemple, qu'un sous-projet "   Système informatique " doit déjà avoir franchi les phases Conception et Réalisation pour que le système informatique soit disponible pour effectuer un essai à la troupe. Le projet global se trouve encore en phase Conception.

Description des phases

Ci-après, les phases sont décrites avec les priorités de chacune d'elles:

1. Initialisation
2. Conception
3. Réalisation
4. Déploiement

Modèle de phases et exigences

La définition des exigences et le développement du système interviennent tout au long des phases du projet.

Les exigences sont d'abord élaborées sommairement dans l'optique du mandat d'initialisation du projet (résultat des exigences générales voir phase de cycle de vie Planification militaire générale). Elles sont concrétisées dans les phases suivantes selon le principe de l'affinement progressif.

La Figure 14 montre schématiquement les résultats de la définition des exigences et du développement système du système/matériel et de l'informatique.

1. Pendant la phase Initialisation, lors de l'étude du projet, les objectifs sont définis et les exigences sont concrétisées de manière à ce que l'on puisse former et évaluer des variantes. Le mandat de projet est établi sur la base de la variante choisie.
2. Dans la phase Conception, les exigences techniques sont détaillées et complétées sur la base des exigences. Elles servent de base contraignante pour les demandes d'offres.
3. Dans le cas de systèmes informatiques, la spécification détaillée est définie et le système est développé sur la base de l'offre du fournisseur et des exigences système. Ceci inclut également les tests comme condition préalable à la décision de réception.
4. Pour un système/matériel, celui-ci est créé sur la base de la spécification. Il est alors réceptionné selon la spécification.
5. Dans la phase Déploiement, le système est lancé et remis à l'exploitant.

En matière d'exigences, il convient de distinguer entre les exigences fonctionnelles, les exigences de qualité (exigences non fonctionnelles) et les contraintes. Les exigences devraient toujours décrire le besoin ou la propriété d'un système et non la solution qui pourrait préjuger du choix du modèle. Le champ des solutions peut éventuellement être restreint par des contraintes. Ce serait par exemple le cas en présence de Government Furnished Equipment (GFE) ou d'interfaces déjà spécifiées avec des systèmes environnants ou des services existants. Les exigences se distinguent également en fonction de leur caractère juridiquement contraignant. On différencie à cet égard les exigences contractuelles contraignantes (DOIT), celles fortement recommandées (DEVRAIT) et les exigences à venir (SERA). Pour des raisons économiques, les exigences souhaitables ne sont pas prises en considération. Les exigences de type DOIT doivent être satisfaites par les soumissionnaires (exigences vitales). Dans le cas des exigences de type DEVRAIT, les soumissionnaires sont libres de ne pas respecter l'une ou l'autre exigence. C'est pourquoi il faut toujours veiller à ce que toutes les offres aient une valeur d'utilité minimale. Il est également recommandé de hiérarchiser et de pondérer les exigences de type DEVRAIT. Les exigences de type SERA sont prospectives et ne sont pas communiquées aux soumissionnaires. Elles sont documentées afin d'être disponibles à une date ultérieure. Concernant ces exigences, il convient de noter que dans certains cas leur prise en compte dans les exigences non fonctionnelles peut être nécessaire dès le départ. Elles peuvent par exemple influencer la structure de conception du système.

La méthode du Requirements Engineering (RE) est utilisée pour spécifier et gérer les exigences de manière systématique et rigoureuse. Il est recommandé d'opter pour le standard IREB (International Requirements Engineering Board ) à cet effet. De même, une formation initiale ou continue assortie d'une certification est conseillée (Certified Professional for Requirements Engineering SAQ/IREB).

Le Requirements Engineering vise à améliorer la qualité des exigences et des documents d'exigences. Après détermination et documentation des exigences, la qualité doit être contrôlée et harmonisée sur la base de nombreux critères. Parmi les critères importants figure entre autres l'exhaustivité: elle doit garantir que les exigences implicites - le type d'exigence le plus risqué - sont elles aussi identifiées et documentées. Dans le contexte complexe des nombreux rôles et responsabilités changeantes au cours des phases du projet, la traçabilité des exigences joue également un rôle central. Il est essentiel pour les utilisateurs de comprendre que le Requirements Engineering n'est pas simplement une méthode supplémentaire mais un moyen d'obtenir de meilleures exigences et donc un meilleur système. Outre la formation mentionnée plus haut, l'utilisation du Requirements Engineering nécessite beaucoup d'expérience pratique et de patience. L'utilisation d'outils peut appuyer le Requirements Engineering mais ne constitue pas une garantie de qualité. Une formulation rigoureuse des exigences et un contenu complet conformément au Requirements Engineering restent déterminants.

La Figure 15 montre schématiquement le chemin menant des exigences générales aux spécifications, à travers les phases du projet, tout au long du caractère contraignant.

Cette présentation est d'application générale mais de légers ajustements sont exceptionnellement possibles. Toutefois, les aspects suivants doivent absolument être pris en compte:

1. Le caractère contraignant et la pondération des exigences, ainsi que les exigences elles-mêmes, peuvent être modifiés dans le cadre d'un processus de gestion des modifications jusqu'au moment de la demande d'offres. Dans HERMES, cela se fait avec la tâche " Conduire la gestion des modifications ". L'objectif est de soutenir formellement le principe de l'affinement progressif mentionné plus haut.
2. Les exigences techniques sont les exigences auxquelles les fournisseurs doivent ou devraient satisfaire. Lors de la décision d'adjudication, les exigences de type DEVRAIT à mettre en æuvre sont clairement définies sur la base du cahier des charges ou de l'offre du fournisseur sélectionné. La spécification peut ainsi être définitivement élaborée et devenir partie intégrante du contrat. Dans les projets de développement, les exigences techniques et le cahier des charges de l'offre font partie intégrante du contrat.
3. Le mandat ou la réalisation signifie la transmission des exigences au producteur. Dans le cadre de la phase Réalisation, c'est ce dernier qui se charge des travaux spécifiés par la méthode RE-D. Ceux-ci sont réalisés dans son propre environnement et à l'aide de ses propres outils. Au plus tard lors de la réception du système, les données du Requirements Engineering sont restituées à l'acheteur sous la forme convenue (champ des solutions).

Processus de décision

Généralités

Dans le cadre de l'exécution d'un projet, des décisions doivent être prises. Elles sont définies comme tâches dans les modules. Les tâches menant à une décision se terminent par un jalon.

HERMES fait la distinction entre les décisions prises par le pilotage et/ou l'organisation permanente et celles qui le sont par la conduite du projet et par des spécialistes. La libération d'une phase est par exemple le fait du mandant de projet et de l'organisation permanente (pilotage).

À la fin d'une phase, le pilotage et l'organisation permanente vérifient si les décisions techniques requises ont bien été prises. Si ce n'est pas le cas, la phase suivante n'est pas libérée. Le pilotage ne prend ainsi aucune décision sans disposer des compétences techniques requises.

Les tâches et les processus de décision dans HERMES sont accomplis à l'aide de la liste de contrôle.

La Figure 16 montre, à titre d'exemple, les décisions du pilotage ainsi que de la conduite et de l'exécution dans le scénario Acquisition dans la défense.

Figure 16: Décisions dans le scénario Acquisition dans la défense

Décision du pilotage et de l'organisation permanente

Au niveau du pilotage, la décision revient au mandant de projet et/ou à l'organisation permanente. Ils décident de la libération du projet, de la libération des phases, de la clôture du projet ainsi que d'autres jalons. Le cas échéant, le mandant du projet est soutenu par d'autres rôles, tels que le comité de pilotage, qui le conseillent.

Le tableau suivant montre les jalons lors desquels le mandant de projet et/ou l'organisation permanente prennent des décisions, ainsi que les résultats, états et documents nécessaires à la prise de décision.

Décision concernant la libération du projet

La libération du projet intervient à la fin de l'initialisation. Elle est décidée d'un commun accord par le mandant de projet et l'organisation permanente, dans le cadre de la gestion du portefeuille de projets.

Ils décident si

1. la phase Initialisation est clôturée ou si d'autres résultats doivent être élaborés,
2. le projet est libéré,
3. le projet n'est pas libéré pour le moment et sera de nouveau proposé ultérieurement,
4. le projet n'est pas libéré et est arrêté.

Décision concernant la libération d'une phase

À chaque libération d'une phase, les objectifs du projet sont coordonnés avec les stratégies de l'organisation et les consignes en vigueur. L'orientation sur les objectifs du projet ainsi que sa rentabilité sont vérifiées.

Ils décident si

1. la phase est clôturée ou si d'autres résultats doivent être élaborés avant sa clôture,
2. la phase suivante est libérée,
3. le projet est arrêté.

En fin de phase, le mandant de projet vérifie si les organes de prescription et de contrôle de gestion et les spécialistes ont procédé aux réceptions requises des résultats et si ces derniers correspondent à ses attentes.

La Figure 17 illustre un processus de décision typique en prenant pour exemple la libération de la phase Conception.

La Figure 17 montre que la réception du rapport de phase et la clôture de la phase Conception ont lieu au niveau du pilotage. Auparavant, au niveau de la conduite et de l'exécution, les résultats du projet sont coordonnés avec les parties prenantes et les organes de prescription et de contrôle de gestion ou vérifiés par ceux-ci. Si les conditions préalables sont remplies, le mandant de projet libère la phase Conception.

Décision concernant la clôture du projet

Au terme de la phase Déploiement, le mandant de projet et l'organisation permanente prennent la décision concernant la clôture du projet.

Ils décident si

1. le projet est clôturé ou si d'autres résultats doivent être élaborés avant sa clôture,
2. l'organisation de projet est dissoute.

Décisions de la conduite et de l'exécution

Décisions concernant les résultats du projet

La vérification et la réception des résultats techniques sont effectuées par la conduite et l'exécution, c'est-à-dire par les spécialistes respectifs des aspects concernés.

Le chef de projet planifie les tâches décisionnelles en tenant compte des consignes des organes de prescription et de contrôle de gestion de l'organisation permanente.