Méthodologie Projets (MPRO)

• 1. Présentation générale
• 1.1 Introduction à la MPRO
• 1.2 Gouvernance
• 1.3 Organisation et rôles
• 1.4 Rôles du métier
• 2. Project Management
• 2.1 Introduction
• 2.2 Pilotage et conduite du projet
• 2.3 Phase d’initialisation
• 2.4 Phase de mise en œuvre
• 2.5 Phase de clôture
• 2.6 Après-projet (exploitation)
• 3. Business Analyse
• 3.1. Business Analyse
• 4. Quality Management & Testing
• 4.1. Quality et testing
• 5. Change Management
• 5.1. Gestion du changement
• 6. Annexes
• Annexe 1: Terminologie et acronymes
• Annexe 3: Outils informatiques du chef de projet
• Annexe 4a: Référentiel des livrables (Mission)
• Annexe 4b: Référentiel des livrables (Projet)
• Annexe 4c: Référentiel des livrables (Programme)

1. Présentation générale

1.1 Introduction à la MPRO

Présentation des notions de base et des différents types de projets.

Notions de base

Un projet est un ensemble finalisé d’activités et d’actions entreprises dans le but de répondre à un besoin défini par un contrat dans des délais fixés et dans la limite d'une enveloppe budgétaire allouée.

Un projet s’oppose par nature à un processus métier, qui est un ensemble d'activités corrélées ou en interaction qui contribue aux finalités des affaires d'une organisation – autrement dit, le travail de tous les jours. Le cœur de la notion d’un processus est la capacité à répéter les activités pour obtenir le même résultat.

Les projets servent ainsi à accompagner et à soutenir les changements effectués dans une organisation:

Extrait du PMBOK: Figure 1-1. Organizational State Transition via a Project

La nature de ces changements peut être variée, comme:

• Une modification d’une solution informatique existante
• La mise en place d’une nouvelle solution informatique
• La réalisation d’une nouvelle offre ou service pour sa communauté (ex. un nouvel enseignement)
• La modification de l’organisation interne d’une entité existante, d’une équipe, etc.
• Et beaucoup d’autres changements de nature unique

Les projets s’inscrivent dans un cadre bien défini. A l’UNIL, cette structure se retrouve de la manière suivante:

• Les orientations stratégiques de l’informatique de la Direction de l’UNIL sont définies dans le Plan directeur du Centre informatique (PDCi).
• Le portfolio des demandes d’évolution du système d’information institutionnel de l’UNIL (SI UNIL) est piloté par le Centre informatique via l’intermédiaire du comité de priorisation des projets (COPRO) selon les processus et critères de priorisation en vigueur.
• Les programmes, les projets et les missions sont ensuite réalisés selon les phases régies par la méthodologie de projets (MPRO, voir ci-dessous).
• Les opérations correspondent enfin à l’exploitation et à la maintenance des solutions mises en place qui influent sur le fonctionnement des affaires des unités de l’UNIL.

La gouvernance du système d’information institutionnel de l’UNIL est décrite dans la Directive 6.10 et sert de base à la gestion des projets informatiques.

Qu’est-ce que la MPRO

Il existe diverses méthodologies de gestion de projet dans le monde, entre autres celles proposées par PMI, PRINCE2 et HERMES. Toutes apportent des méthodes, des techniques et des outils spécifiques à la réalisation des différentes étapes du projet, dont l’objectif est d’en assurer le bon déroulement et à en atteindre les résultats selon les objectifs, les délais et les coûts prévus.

Le Centre informatique a fait le choix de prendre la méthodologie HERMES, promue par la Confédération Suisse, pour gérer l’ensemble de ses projets informatiques. La flexibilité de cette méthodologie a permis de l’adapter aux besoins et pratiques de l’UNIL, dont la version résultante est la MPRO.

A qui s’adresse la MPRO

La MPRO s’adresse avant tout aux chef·es de projets, de programmes et de missions informatiques de l’UNIL. Elle définit les bonnes pratiques de gestion, offres des outils et des aides pour conduire, planifier et suivre les projets, et propose une démarche concrète qui couvre l’ensemble des activités à réaliser du démarrage à la clôture du projet.

La MPRO s’adresse également à toute personne impliquée dans un projet informatique à l’UNIL, en proposant une définition claire des rôles des parties prenantes, tout en proposant des outils annexes nécessaires à la bonne marche des projets dans des domaines comme l’analyse métier, la gestion de la qualité et des tests, et la gestion du changement.

Différents types de projet

A l’UNIL, les projets informatiques peuvent se décliner en trois types:

• Les projets sont des projets ayant pour objectif de répondre à un besoin ou à une demande spécifique d’un métier en lui apportant une solution informatique adaptée.
• Les missions sont des projets peu complexes, ne nécessitant par conséquent que d’une gestion de projet simplifiée. En règle générale, les tâches du projet sont réduites à leur strict minimum, et le nombre de documents de projet est limité à l’essentiel. En principe, la charge de travail n’excède pas une vingtaine de jours.
• Les programmes sont des ensembles de projets et de missions visant tous un objectif global ou stratégique commun. Les programmes garantissent ainsi un pilotage et une conduite harmonisés entre les projets et les missions qui, eux, permettent d’atteindre différents sous-objectifs.

1.2 Gouvernance

Présentation des principes et organes de gouvernance de la MPRO.

Organisation générale

La méthodologie de projets (MPRO) est celle proposée par le Centre informatique pour la gestion des projets IT à l’UNIL. Afin de lui permettre d’évoluer de manière cohérente et concertée auprès de ses principaux bénéficiaires, une organisation spécifique a été mise en place intégrant différentes personnes de ce service.

Bureau des projets (CoPMO)

Le bureau des projets est représenté par le Comité du Project Management Office (CoPMO). Il a notamment pour mission d’identifier les besoins en termes d’évolution de la MPRO et de coordonner et suivre le cas échéant les initiatives lancées par le CoMPRO.

Membres

Le CoPMO est composé:

• D’un membre de la direction du Centre informatique
• Du ou de la responsable du Pôle Projets IT
• Du ou de la responsable PMO IT

Ces membres font partie de l’organisation permanente du Centre informatique.

Fréquence

Le CoPMO se réunit de manière hebdomadaire, de sorte à pourvoir traiter de manière proactive toutes les problématiques remontées par les utilisateurs et utilisatrices de la MPRO.

Comité de consultation (CoMPRO)

Le Comité MPRO (CoMPRO) forme un comité de consultation qui représente les bénéficiaires de la MPRO. Il a pour mission générale d’identifier les besoins, de proposer et de prioriser les évolutions visant l’amélioration de la MPRO. Il a pour principales tâches de:

• Représenter sa division sur les sujets en lien avec la MPRO
• Se tenir informé sur les évolutions de la MPRO, le cas échéant y être formé ou en être utilisateur
• Proposer des évolutions de la MPRO basées sur ses retours d’expérience et ceux de sa division
• Prioriser les demandes d’évolution de la MPRO soumises au comité
• Contribuer à la réalisation des demandes d’évolution de la MPRO qui auront été priorisées, incluant la mise à jour de la documentation pour validation/publication sur le wiki
• Agir en tant qu’ambassadeur·drice de la MPRO auprès des membres de sa division

Membres

Il est composé à minima d’un membre de chaque division du Centre informatique, à savoir:

• D’un·e représentant·e de la Division DSM
• D’un·e représentant·e de la Division DSSH
• D’un·e représentant·e de la Division DI
• D’un·e représentant·e du Groupe Projets IT

Ces membres sont désignés pour une année, renouvelable selon une procédure laissée libre à chaque division concernée. Chaque membre est par principe un·e chef·e de projet ou de mission, et donc est utilisateur·trice de la MPRO.

Fréquence

Le CoMPRO est convoqué en principe trois fois l’an : en septembre/octobre, en février/mars et en juin/juillet. Ces convocations sont fixes et indépendantes des réalisations des demandes d’évolution de la MPRO.

1.3 Organisation et rôles

Présentation des rôles obligatoires ou importants dans la gestion de projet.

Rôles des parties prenantes

Les parties prenantes d’un projet sont organisées spécifiquement pour interagir dans le projet, avec des rôles et des règles hiérarchiques qui diffèrent généralement de celles en vigueur au sein de l’organisation permanente.

Les rôles présentés ci-après sont basés sur les rôles de la méthodologie HERMES 2022, mais adaptés au contexte de l’UNIL. Ceux marqués d’un astérisque (*) ne sont pas des rôles HERMES, mais font partie des rôles habituellement présents dans les projets. A noter que les parties prenantes peuvent endosser plusieurs des rôles présentés ici durant un même projet.

Rôles principaux

Ces rôles principaux sont obligatoires dans tous les projets.

Mandant (MAN)

Le rôle de mandant comprend la responsabilité des résultats du projet et de l'atteinte des objectifs fixés dans les conditions cadres. Il garantit que les objectifs correspondent aux stratégies, aux prescriptions et aux objectifs supérieurs de l'organisation permanente et met à disposition les ressources (finances, personnel, infrastructure) et en garantit une utilisation efficiente. Il est ainsi la personne qui prend les décisions de pilotage tout au long du projet, approuve les livrables et les résultats proposés par l’équipe de projet. Il est généralement secondé par un Comité de pilotage qu’il préside.

Dans les projets informatiques de l’UNIL, ce rôle est généralement assuré par un membre de la Direction de l’UNIL si le projet impacte plusieurs facultés et/ou services, ou par un·e responsable d’une unité, si le projet n’impacte que la faculté ou le service en question.

Chef de projet (CPR)

Le rôle de chef de projet consiste à diriger et coordonner le projet indépendamment de l'orientation technique de la solution et de l'approche de développement choisie, sur mandat du mandant. Il prend les décisions opérationnelles tout au long du projet, planifie et évalue les délais, les ressources et le budget, gère l’équipe de projet, rend compte de l’avancement du projet au mandant. Il participe et anime les Comités de pilotage et les Comités opérationnels.

Dans les projets informatiques de l’UNIL, ce rôle est assuré par un·e professionnel·le de la gestion de projet (collaborateur·trice du pôle Projets du Centre informatique), s’il s’agit d’un projet métier, ou par un·e Chef·fe de pôle du Centre informatique, s’il s’agit d’une mission (projet technique ou maintenance évolutive).

Selon le type de projet, la dénomination du rôle change. Nous parlerons ainsi de chef de mission (CMI) dans le cadre des missions, ou de chef de programme (CPG) dans le cadres des programmes.

Référent métier (RM)

Le rôle de référent métier consiste à représenter les utilisatrices et utilisateurs et leurs intérêts dans le contexte du projet. Ce rôle est central dans le déroulement d’un projet, car il est responsable de la solution qui sera déployée au terme du projet.

Dans les projets informatiques de l’UNIL, ce rôle est assuré par un·e spécialiste métier concerné·e par le projet au sein de la faculté ou du service impacté. Dans le cas de projets transverses impactant plusieurs unités, ce rôle peut être pris par un·e Responsable des systèmes d’information (RSI).

Autres rôles importants

D’autres rôles interviennent généralement dans le déroulement d’un projet. Sans être exhaustif, voici ceux que nous rencontrons fréquemment dans un projet informatique à l’UNIL.

Business Analyst (BA)

Le rôle de business analyst détermine, vérifie, analyse et priorise les besoins et les exigences des utilisateurs sur la base des processus et de la structure de l’organisation, et les transforme en exigences organisationnelles et/ou fonctionnelles.

Quality Analyst (QA)

Le rôle de quality analyst soutient le ou la mandant·e en évaluant le projet de manière indépendante et en lui recommandant des mesures pour atteindre plus facilement les objectifs du projet.

Test Manager (TM)

Le rôle de test manager conçoit, planifie et coordonne les tests. Il s'assure que les bases de test sont élaborées conformément au concept de test et transmet les tests à l'exploitation.

Change Manager (CM) *

Le rôle de change manager est responsable d’accompagner le changement au sein des unités impactées par le projet.

Utilisateur clé (Key User, KU) *

Ce rôle est celui d'un·e utilisateur·trice final qui reçoit une formation spécifique à l’utilisation de la solution déployée par le projet, afin qu’il puisse à son tour former et aider ses homologues.

Utilisateur final (End User, EU) *

Ce rôle est celui d'un·e utilisateur·trice à qui bénéficie principalement la solution déployée par le projet.

Organisation d’un projet

Un projet informatique standard à l’UNIL est généralement représenté par l’organigramme ci-dessous.

Exemple d'un organigramme d'un projet avec les rôles standards

Comité de pilotage (COPIL)

Le Comité de pilotage est l’instance de pilotage du projet qui prend les décisions stratégiques et budgétaires. Il se réunit régulièrement à la demande du ou de la mandant·e, ou à la demande du ou de la chef·fe de projet, et se compose à minima des membres suivants:

• Du ou de la mandant·e, qui préside le comité
• Du ou de la chef·fe de projet, qui organise et anime la réunion
• Du ou de la référent·e métier, qui représente la voix des utilisateurs·trices
• D’un·e référent·e IT (ou architecte IT), qui représente la voix du Centre informatique

Les réunions de ce comité font l’objet d’un ordre du jour défini à l’avance, ainsi que d’un procès-verbal décisionnaire qui protocole les décisions (ou non-décisions) prises par les membres du comité.

Comité opérationnel (COMOP)

Le Comité opérationnel est l’instance de conduite du projet qui prend les décisions opérationnelles du projet, et prépare les propositions à valider en comité de pilotage. Il se réunit régulièrement à la demande du ou de la chef·fe de projet, et se compose à minima des membres suivants:

• Du ou de la chef·fe de projet, qui préside le comité
• Du ou de la référent·e métier
• D’un·e responsable des développements
• D’un·e représentant·e de chaque prestataire externe

Les réunions de ce comité sont généralement récurrentes et font l’objet d’une prise de notes partagée au sein de l’équipe de projet. Les décisions opérationnelles sont également protocolées dans le log des décisions du projet.

Autres comités

D’autres comités existent également dans certains projets et viennent compléter les deux comités principaux du projet, par exemple:

• Le Comité stratégique (COSTRA), qui complète et conseille le Comité de pilotage sur les bonnes décisions stratégiques à prendre pour le projet
• Le Comité d’initialisation (COMINI), dont les membres représentent les différents domaines techniques (infrastructure, sécurité, architecture, développements, …) afin d’être consultés sur les variantes techniques des solutions envisagées par le projet
• La Commission consultative (CC…), dont les membres représentent les utilisateurs·trices finaux afin d’être consultés sur certains choix métiers à prendre par le projet

Le ou la mandant·e et/ou le ou la chef·fe de projet peuvent demander la mise en place de ces comités complémentaires.

Le Comité de priorisation des projets (COPRO) n’est pas un comité propre à un projet, mais un organe de décisions pour la priorisation des demandes d’évolution du système d’information institutionnel de l’UNIL.

1.4 Rôles du métier

Description des parties prenantes identifiées comme « métier » et leurs rôles.

Qui est le « métier » ?

La notion de métier est régulièrement utilisée dans notre documentation projet, mais aussi dans ce wiki. On entend par ce terme toute équipe, groupe ou autre entité, qui réalise un certain travail au quotidien. Cette notion s’applique donc autant aux facultés et services de l’UNIL, mais aussi à chaque entité qui les compose (secrétariat, affaires étudiantes, etc.).

Généralement, le métier sait comment il travaille, selon quels processus et quelles règles (explicites ou non). Ce contexte doit pouvoir être compris et pris en compte par l’équipe du projet, et les solutions doivent y être adaptées.

Le métier est ainsi systématiquement représenté par un·e référent·e dans le cadre d’un projet, qui agit en tant qu’agent du changement, mais aussi comme porte-parole des utilisateurs·trices de l’organisation qu’il représente.

Tâches attendues du métier

Dans le cadre d’un projet, plusieurs tâches incombent aux parties prenantes de l’organisation impactée par le projet. Ces tâches s’étalent sur l’ensemble du cycle de vie du projet.

Ces tâches ont principalement pour objectif de définir et préciser les objectifs et les exigences vis-à-vis des résultats à fournir par le projet, mais aussi définir et valider les indicateurs qui permettront de vérifier que les résultats obtenus soient en accords avec les besoins et les attentes du métier. Elles seront détaillées dans les pages dédiées aux phases d'un projet.

De par leur importance pour la réussite du projet, il est essentiel que les représentant·es du métier impliqué·es dans le projet puissent consacrer le temps nécessaire à la réalisation de ces tâches.

Certaines tâches sont également attendues hors projet de la part du métier, notamment en phase de préinitialisation, avec la rédaction et le dépôt d’une Demande d’évolution du système d’information (DESI), ou après le projet lorsque la solution est en exploitation.

Le temps et la charge de travail du métier impliqué dans un projet sont souvent sous-estimés. Ajouté aux tâches quotidiennes, c’est un effort supplémentaire parfois important à fournir, qui sera possiblement difficile de maintenir sur toute la durée du projet. Il est donc fortement recommandé de bloquer des plages horaires dans son agenda qui soient dédiées entièrement au projet dès le début de celui-ci, afin d’assurer sa disponibilité lors des moments clés du projet et permettre d’en réduire sensiblement la durée.

2. Project Management

2.1 Introduction

Description du cycle de vie d'un projet selon que la méthode soit classique ou agile.

Cycle de vie du projet

Selon HERMES, un projet se déroule selon différentes phases, selon s’il s’agit d’un projet classique ou d’un projet agile.

Déroulement d'un projet selon HERMES 2022

Son cycle de vie se résume donc à trois grandes étapes:

• Le début du projet, qui permet de définir les objectifs et les exigences métiers, mais aussi tout le périmètre du projet (choix des variantes, planification des délais et des coûts initiaux, ...)
• La création de la solution, qui, comme son nom l’indique, permet de concevoir et réaliser la solution répondant aux exigences métiers
• La fin du projet, qui permet d’assurer la transition vers l’exploitation de la solution implémentée

Classique vs. Agile

Déroulement d’un projet: Classique (en bleu) et Agile (en rouge)

Un projet classique (ou waterfall) se déroulera avec trois phases spécifiques : conception, réalisation, déploiement. Chacune de ces phases est dépendante de la précédente, et ne peut être exécutée tant que la phase qui précède n’est pas terminée et les résultats approuvés.

Un projet agile se déroulera avec une seule phase : mise en œuvre. Durant cette phase, plusieurs releases de la solution seront implémentées et déployées, permettant plus de souplesse et de rapidité dans la livraison d’une solution partielle mais utilisable.

A l’UNIL, nous avons fait le choix de privilégier le modèle de projet agile, tout en nous laissant la liberté de composer des projets avec des modèles hybrides.

Cas particulier: la préinitialisation

A l’UNIL, nous avons créé une phase de préinitialisation pendant laquelle les demandes d’évolution du système d’information institutionnel de l’UNIL sont traitées et priorisées. Bien que ne faisant pas partie de la méthodologie HERMES, et que durant cette phase, un projet n’est pas encore actif, plusieurs travaux préparatoires sont entrepris pour permettre le démarrage du projet.

Pour plus d’information à ce sujet, merci de consulter le wiki Demande d’évolution du système d’information (DESI) consacré à ce sujet.

2.2 Pilotage et conduite du projet

Description des activités de pilotage et de conduite du projet.

Introduction

Le pilotage (décisions stratégiques) et la conduite (décisions opérationnelles) du projet sont gérés et suivis tout au long de la durée du projet, en fur et à mesure de l’avancement de ses phases.

Piloter le projet

Le pilotage du projet est assuré par le ou la Mandant·e du projet, avec le soutien du ou de la Chef·fe de projet. Cette tâche consiste principalement à:

• Effectuer un contrôle régulier de l'avancement du projet, notamment en comparant les objectifs et la situation réelle, évaluant les prévisions, analysant les écarts, identifiant les actions qui s'imposent et en prenant les mesures nécessaires
• Gérer les risques, en les analysant et en comparant ceux inhérents au projet et aux affaires, à prendre les décisions concernant les mesures de mitigation et à vérifier leur mise en œuvre
• Planifier et piloter les processus décisionnels (orientations stratégiques, choix des variantes, demandes de modifications, …)

Tâche HERMES: Piloter le projet

Conduire le projet

La conduite du projet est assurée par le ou la Chef·fe du projet, avec le soutien de l’équipe du projet. Cette tâche consiste principalement à:

• Planifier les tâches, les résultats et les ressources et établir les mandats
• Rédiger des rapports sur l'état du projet conformément aux directives et préparer des séances, les organiser, en assurer le suivi et rédiger des procès-verbaux, consigner les décisions
• Coordonner en permanence le déroulement du projet et les conclusions importantes avec le ou la Mandant·e
• Diriger l’équipe du projet et assurer l'orientation vers les objectifs et la compréhension commune en ce qui concerne la procédure et les résultats
• Mettre à jour les exigences envers la solution, les spécifications générales et détaillées et le plan des releases

Tâche HERMES: Conduire et contrôler le projet

Rapport sur l'état du projet

L’avancement du projet fait l’objet d’un suivi régulier de la part du ou de la Chef·fe de projet. Sa communication est faite aux différentes parties prenante au travers de divers canaux et support:

Public cible	Support	Contenu
Mandant·e, Comité de pilotage	Présentation des séances du COPIL	Etat actuel du projet, et prévision pour la période suivante
Mandant, Bureau des projets, RSI	Rapports flash	Météo et tendance, récapitulatif des faits marquants de la période écoulée, problèmes rencontrés et prochaines étapes
Burau des projets, RSI (COPRO)	Revue des projets (RDP)	Etat actuel des projets, prochains jalons importants

Il est par ailleurs fortement recommandé que le ou la Mandant·e et le ou la Chef·fe de projet se rencontrent régulièrement en séance bilatérale, ceci afin de faire un point d’avancement du projet et éventuellement se coordonner sur des mesures correctives à prendre sans forcément avoir besoin de solliciter une intervention du Comité de pilotage.

2.3 Phase d’initialisation

Cette phase permet de fixer les objectifs et le périmètre du projet.

Selon HERMES, le début du projet comprend toujours une phase d'initialisation. Celle-ci est consacrée à définir l'orientation et le périmètre du projet selon les visions, les besoins et les objectifs. Elle constitue une base pour la planification et le pilotage du projet.

Les tâches et jalons clés

Désignation du ou de la Chef·fe de projet

Une fois la décision prise de démarrer un projet, le ou la Responsable du Pôle Projet désigne un ou une Chef·fe de projet. La DESI, ou document équivalent (mandat de mission, mandat de travail), est le document sur la base duquel les travaux vont débuter.

Séance d’initialisation

Une séance d’initialisation entre le ou la Responsable du Pôle Projet, le ou la Mandant·e, et le ou la Chef·fe de projet est organisée au plus tôt afin de passer en revue les documents à disposition et de s’aligner sur les objectifs, le périmètre et les contraintes de la phase d’initialisation du projet.

Tâche HERMES: Décider de la libération de l’initialisation du projet

Élaborer le mandat d’initialisation

Le mandat d’initialisation décrit la situation de départ, et permet de formaliser les objectifs et les ressources nécessaires pour réaliser la phase d’initialisation. Le procès-verbal de la séance d’initialisation en est la base.

Prendre en main les outils projet

Parallèlement à l’élaboration du mandat d’initialisation, le ou la Chef·fe de projet met en place son environnement de travail en déployant ses outils, notamment:

• Orchestra pour la planification
• Teams pour la communication et la gestion documentaire
• GitHub et ZenHub pour les spécifications

Kick-Off d’initialisation

Une fois le mandat d’initialisation validé, un Kick-Off d’initialisation est organisé par le ou la Chef·fe de projet avec les membres de l’équipe qui sera à l’œuvre durant la phase d’initialisation. Le but de cette séance est de s’aligner sur les objectifs, le périmètre et les contraintes du projet, ainsi que sur la méthode de projets (MPRO) qui sera appliquée.

Élaborer l’étude

L'étude permet entre autres de fixer les objectifs, de définir les exigences générales ainsi que d'élaborer et d'évaluer des variantes de solutions de sorte que la décision sur la suite du projet puisse être prise. Cette décision est également documentée dans l'étude.

Tâche HERMES: Élaborer l’étude

COMINI: Choix de la variante

Le COMINI (Comité d’initialisation) est une séance organisée en interne au Centre informatique par le ou la Chef·fe de projet à l’issue de l’élaboration de l’étude.

Le but de la séance est de présenter les conclusions de l’étude aux Responsables de Divisions ou de Pôles du Centre informatique afin de s’accorder sur la faisabilité du projet, de se prononcer sur les variantes si plusieurs sont disponibles et de préparer le COPIL de fin de phase d’initialisation. La variante y est choisie par le ou la Mandant·e, sur la base des préconisations du COMINI.

Tâche HERMES: Décider de la suite du projet

Élaborer le mandat d’exécution

L'élaboration du mandat d'exécution crée les conditions nécessaires pour prendre la décision de libérer l'exécution et donc de poursuivre le projet avec l'élaboration de la solution. Il sert de contrat entre le ou la Mandant·e et le ou la Chef·e de projet sur la base duquel la mise en œuvre du projet sera effectuée.

Tâche HERMES: Élaborer le mandat d'exécution

COPIL de fin de phase

La séance du COPIL de fin de phase est organisée par le ou la Chef·fe de projet et réunit tous les membres du Comité de pilotage du projet. Le but de la séance est de valider les points de contrôle afin de prendre une décision sur la libération de l’exécution du projet.

Tâche HERMES: Décider de la libération de l'exécution

Lors de cette séance, il est tout à fait envisageable de décider de ne pas libérer l’exécution du projet si les conditions de mise en œuvre ou éventuellement d’exploitation post-projet ne sont pas réunies (ex. budget insuffisant, architecture technique trop complexe, ressources indisponibles).

L'implication du métier

En phase d’initialisation, le métier a pour responsabilité de fournir toutes les informations utiles permettant de définir le périmètre du projet. Ceci implique notamment de définir les exigences générales sur lesquelles se basera l’évaluation des résultats obtenus par le projet, sur la base de la modélisation des processus métiers actuels et, si déjà définis, les processus métiers cibles.

2.4 Phase de mise en œuvre

Cette phase permet de concevoir, réaliser et déployer la solution.

Selon HERMES, durant la phase de mise en œuvre, la solution est implémentée par l’équipe de projet en respectant les objectifs et les exigences métiers établies et validées lors de la phase d’initialisation.

Les tâches et jalons clés

La phase de mis en œuvre peut être réalisée selon trois modèles distincts, mais tous regroupant les mêmes tâches détaillées ci-après.

• Le modèle sans release consiste à réaliser et livrer la solution en une seule fois avec une mise en service unique. Elle est similaire à l’utilisation du modèle classique d’HERMES, même si les tâches décrites ci-après ne sont pas regroupées par phases.
• Le modèle avec releases consiste à réaliser et livrer la solution en plusieurs parties avec des mises en services multiples.
• Le modèle avec release et conception préalable permet de décrire de manière générale le fonctionnement attendu de la solution, mais de réaliser et livrer cette dernière en plusieurs parties avec des mises en services multiples.

Le choix du modèle utilisé est en principe décrit dans le mandat d’exécution du projet.

Élaborer les spécifications générales

Les spécifications générales permettent de décrire la solution avec une vision « métier » des fonctionnalités attendues, et contiennent notamment:

• Une expression claire des besoins du métiers, en reprenant les exigences envers la solution établie durant l’étude
• Une description sommaire des processus et des interfaces utilisateurs
• Une description générale des règles métiers

La forme de ces spécification utilise un langage commun et compréhensible par le métier et les développeurs. Leur objectif est de permettre l’alignement des attentes entre les parties prenantes du projet, afin de servir de base pour l’élaboration des cas de tests métiers.

Tâche HERMES: Élaborer les exigences envers la solution

Élaborer les spécifications détaillées

Les spécifications détaillées permettent de décrire la solution avec une vision « technique » des fonctionnalités attendues, et contiennent notamment:

• Une description détaillée des processus et des interfaces utilisateurs
• Une description détaillée des règles métiers par fonctionnalité de la solution
• Une indication des sources des données utilisées

La forme de ces spécifications utilise un langage technique compréhensible par les développeurs. Leur objectif est de servir de base de travail pour le développement de la solution, ainsi que pour l’élaboration des cas de tests fonctionnels.

Tâche HERMES: Réaliser le système

Développer la solution

Cette tâche consiste à implémenter la solution sur la base des spécifications fournies au développeurs. Elle comprend également la rédaction de la documentation technique de la solution, ainsi que la réalisation de tests unitaires.

Tâche HERMES: Réaliser le système

Tester la solution

Cette tâche consiste à vérifier que le fonctionnement de la solution développée soit en adéquation avec les spécifications, plus généralement, avec les exigences du métier envers la solution.

On considère généralement quatre types de tests à cette étape de la mise en œuvre:

• Les tests fonctionnels, qui permettent de vérifier le comportement de chaque fonctionnalité de la solution par rapport aux spécifications fournies
• Les tests métiers, qui permettent de vérifier si la solution répond aux attentes du métier
• Les tests de performance, qui permette de vérifier si la solution tient la charge, en cas de forte sollicitation par les utilisateurs
• Les tests de régression, qui permettent de vérifier que le fonctionnement de la solution préalable aux développements est maintenu, dans le cas où les développements auraient consisté à faire évoluer une solution déjà existante

Les résultats des tests sont consignés dans un procès-verbal des tests qui sert de base à la décision de mise en production.

Tâche HERMES: Effectuer les tests

Mise en production (MEP)

La mise en production consiste à déployer la solution sur l’environnement de production. A partir de ce moment, la solution peut être exploitée par le métier.

Tâche HERMES: Décider de la préréception

Mise en service (MES)

La mise en service consiste à lancer l’exploitation de la solution par le métier auprès des utilisateurs. A partir de ce moment, la solution est en exploitation et des règles opérationnelles s’appliquent.

Tâche HERMES: Décider de la mise en service

COPIL de fin de phase

La séance du COPIL de fin de phase est organisée par le ou la Chef·fe de projet et réunit tous les membres du Comité de pilotage du projet. Elle a en principe lieu une fois la dernière mise en service effectuée et a pour but de valider les points de contrôle afin de prendre une décision sur la libération de la clôture du projet.

Tâche HERMES: Décider de la libération de la phase de clôture

Des séances de COPIL intermédiaires sont également possibles, voire conseillées, par exemple pour prendre la décision de mise en production ou de mise en service d’une release qui a été livrée conformément aux exigences du métier.

L'implication du métier

En phase de mise en œuvre, le métier est impliqué principalement dans des tâches de documentation et de validation, notamment:

• Participer à la préparation et à la rédaction des spécifications détaillées (maquettes des interfaces, critères d’acceptation, …) et à la modélisation des processus métiers cibles
• Participer aux tests fonctionnels de la solution
• Valider la réception de la solution implémentée

Il est également responsable d’engager les utilisatrices et utilisateurs finaux tout au long du projet, afin d’accompagner le changement au sein de son organisation. Ceci inclut notamment:

• La communication régulière de l’avancement du projet aux personnes impactées
• La rédaction des manuels utilisateurs
• La formation des utilisatrices et utilisateurs clés et des utilisatrices et utilisateurs finaux
  

2.5 Phase de clôture

Cette phase permet de tirer le bilan du projet et clore les activités résiduelles.

Selon HERMES, la fin du projet comprend toujours une phase de clôture. Celle-ci offre une structure pour terminer un projet de manière systématique, avec un contrôle qualité du projet et des livrables, ainsi qu’un bilan du déroulement du projet.

Les tâches et jalons clés

Préparer la clôture du projet

La préparation de la clôture du projet se déroule généralement en deux temps.

1. Rétrospective du projet

Il s’agit de collecter et documenter les expériences acquises de l’équipe de projet dans une optique d’amélioration continue. Le résultat de cette rétrospective permet de compléter l’évaluation finale du projet.

2. Évaluation finale du projet

Il s’agit de tirer le bilan du projet en termes d’objectifs, de délais, de coûts, de ressources, et d’expériences acquises. Les travaux résiduels sont également indiqués, ainsi que ceux qui devront être éventuellement réalisés hors projet. L’évaluation finale du projet constitue la base de la décision concernant la clôture du projet.

Tâche HERMES: Préparer la clôture du projet

COPIL de fin de phase

La séance du COPIL de fin de phase est organisée par le ou la Chef·fe de projet et réunit tous les membres du Comité de pilotage du projet. Le but de la séance est de valider les points de contrôle afin de prendre une décision sur la clôture du projet, et ainsi permettre la dissolution de l’organisation de projet.

Tâche HERMES : Décider de la clôture du projet

Traitement du reste à faire

Selon les décisions prises lors du COPIL de clôture, certaines actions résiduelles sont encore réalisées, le cas échéant planifiées par le ou la Chef·fe de projet sous forme de travaux de maintenance.

Clôture administrative

Ces travaux purement administratifs sont réalisés par le ou la Chef·fe de projet et visent à clore et à archiver le dossier du projet (PPM, livrables, etc.).

L'implication du métier

En phase de clôture, le métier a pour tâche principale d’assurer que l’exploitation de la solution au sein de son organisation soit pleinement opérationnelle. Autrement dit, il doit avoir intégré le résultat du projet dans son quotidien.

Il participe également à la rétrospective et à l’évaluation finale du projet qui permettent de tirer des expériences précieuses sur le déroulement du projet, et qui fait partie intégrante de l’amélioration continue des équipes de projet.

2.6 Après-projet (exploitation)

Ce chapitre décrit la mise en exploitation de la solution et sa gestion.

Gestion en exploitation

Une fois la solution mise en service, le projet fait progressivement place à une période plus ou moins longue d’exploitation de la solution par le métier et par le Centre informatique.

En règle générale, les modalités de l’exploitation sont définies et validées en cours de projet et permettent une transition projet à exploitation en douceur. Ceci implique notamment que:

• Les rôles et les personnes responsables de l’exploitation ont été définies et seront correctement impliquées le moment venu.
• Le budget d’exploitation a été correctement défini.

La gestion du budget d’exploitation répond à des critères précis. Ainsi:

• Le budget d’une solution faisant partie intégrante du système d’information institutionnel de l’UNIL est pris en charge par le Centre informatique qui finance ainsi les coûts de licences et de maintenance auprès des prestataires externes.
• Le budget d’une solution spécifiquement implémentée pour un métier est pris en charge par ce dernier. Néanmoins, certains coûts de licence ou de prestation de maintenance peuvent être pris en charge par le Centre informatique.
• Le budget des solutions implémentées par le métier pour le métier n’est pas pris en charge par le Centre informatique.

Différents types de maintenance

Une fois la solution en exploitation, plusieurs types de maintenance sont prévus.

Maintenance corrective

La maintenance corrective a pour but d’effectuer des corrections sur des anomalies de fonctionnement d’un système existant détectés en cours d’exploitation. Ces maintenances font l’objet de l’ouverture d’un ticket dans le système OTOBO via un contact avec le HelpDesk du Ci, et sont traitées en best effort par les équipes de développement concernées.

Maintenance évolutive

La maintenance évolutive a pour but d’apporter des modifications plus ou moins importantes à un système existant. Ces maintenances font l’objet d’une demande d’évolution du système d’information (DESI) et sont traitées et priorisées avant leur réalisation sous la forme d’un projet ou d’une mission selon la complexité de la demande.

Ressources utiles pour l’exploitation

Les ressources suivantes sont également utiles pour bien comprendre comment sont gérées les solutions du système d’information institutionnel de l’UNIL:

• Directive sur la gouvernance du Système d’information institutionnel de l’UNIL (6.10)
• Ticketing et gestion des demandes: OTOBO
• Demande d’évolution du système d’information (DESI)
• Helpdesk du Centre informatique
  

3. Business Analyse

3.1. Business Analyse

Cette page est en cours de préparation. Merci pour votre patience.

4. Quality Management & Testing

4.1. Quality et testing

Cette page est en cours de préparation. Merci pour votre patience.

5. Change Management

5.1. Gestion du changement

Ce chapitre décrit la gestion du changement dans un projet.

La gestion du changement, en bref

Tout projet vise à faire évoluer une situation existante : outils, processus, organisation ou pratiques de travail.

La gestion du changement consiste à accompagner les personnes concernées pour qu’elles comprennent ces évolutions, s’y engagent et les intègrent durablement dans leur quotidien.

Concrètement, il ne suffit pas que la solution fonctionne techniquement. Les bénéfices d’un projet ne sont atteints que si les personnes concernées adoptent réellement la nouvelle manière de faire.

La gestion du changement complète donc la gestion de projet:

• La gestion de projet livre la solution.
• La gestion du changement permet son appropriation.

Le rôle clé du ou de la référent·e métier

Dans notre organisation, le ou la référent·e métier est l’acteur ou l’actrice central·e de la gestion du changement pour son projet.

Son rôle consiste notamment à:

• Représenter les besoins et contraintes du métier
• Identifier les impacts du projet sur les personnes et les pratiques
• Anticiper les résistances ou incompréhensions possibles
• Contribuer à une communication claire et utile pour les bénéficiaires
• Soutenir l’adoption du changement dans la durée

Le niveau d’implication attendu dépend de l’impact du changement, évalué dès la demande de projet.

Évaluer l’impact du changement dès la DESI

Toute demande d'évolution du système d'information (DESI) inclut une grille d’évaluation de l’impact du changement.

Cette grille permet d’estimer notamment:

• Le nombre de personnes impactées
• Le nombre d’unités concernées
• L’homogénéité ou non des impacts selon les groupes
• L’impact organisationnel (réorganisation ou non)
• Les impacts sur les processus
• L’intérêt et l’attente des bénéficiaires vis-à-vis du projet

Chaque critère est noté. Le résultat global correspond à un niveau d’impact: faible, modéré ou élevé.

Le ou la RSI s’assure que le management de l’entité concernée a connaissance de ce niveau d’impact avant la transmission de la DESI en commission.

Le PMO informe le groupe eChange si une DESI est soumise avec un résultat d'évaluation avec impact élevé, pour leur préconisation dès la préanalyse sous la forme d'un commentaires à enregistrer sous la section 6, rubrique Coordination & Change Management (indication des j/H estimés et commentaires).

Qui fait quoi selon le niveau d’impact ?

Selon le niveau d’impact identifié dans la grille d’évaluation, il est recommandé d’appliquer les mesures suivantes:

Impact faible

La gestion du changement est assurée entièrement par le ou la référent·e métier.

Des actions simples et ciblées sont suffisantes (information, communication de proximité, accompagnement informel).

Impact modéré

La gestion du changement reste à la charge du ou de la référent·e métier.

Des aménagements spécifiques peuvent être mis en place selon le projet: temps dédié, appui ponctuel d’un·e change manager, conseils méthodologiques, etc.

Impact élevé

Un tel projet ne peut pas démarrer tant qu'une ressource de gestionnaire du changement n'est pas identifiée. Une ressource externe est possible, mais le budget est à la charge de l'entité demandeuse de la DESI.

Le ou la référent·e métier reste impliqué·e, en lien étroit avec cette personne, pour garantir l’ancrage métier des actions menées.

Quand intervenir ?

La gestion du changement ne se limite pas à la fin du projet.

Elle commence avant même le lancement en estimant l’impact du changement via la grille d’évaluation, se poursuit pendant le projet et se prolonge après la mise en production.

Si le projet a été estimé avec un impact élevé, le ou la mandant·e du projet devra être impliqué·e pour l’allocation des ressources en gestion du changement.

Dès le démarrage du projet, le ou la chef·fe de projet et le ou la référent·e métier échangent sur:

• Le niveau d’impact identifié
• Les actions de gestion du changement à prévoir
• Les soutiens éventuellement nécessaires

Le groupe eChange peut être sollicité pour conseil à l'adresse email: echange[at]unil.ch.

Et après le projet ?

L’adoption d’un changement prend du temps.

La mesure des bénéfices et de la réussite du projet ne peut pas toujours être faite immédiatement à la clôture.

Des critères et modalités d’évaluation post-projet sont en cours d’élaboration au sein du groupe eChange et seront intégrés progressivement dans les pratiques.

Un « kit de survie » pour les projets à impact faible ou modéré

Pour les projets simples, une première boîte à outils est mise à disposition afin d’aider les référent·e·s métier à structurer leur démarche:

• Identifier les personnes impactées → cartographie des parties prenantes.
• Décrire le changement comme un passage de A à B → ce qui change concrètement, ce que cela implique, ce qui est attendu.
• Anticiper les réactions → qu’est-ce que chacun·e a à y gagner ? (WIIFM – What’s in it for me?)
• Communiquer de manière utile → messages clairs, au bon moment, via les bons canaux.
• S’appuyer sur des modèles simples → par exemple un template de plan de communication.

Ces documents sont accessibles dans la Boîte à outils de l’équipe Teams eChange.

6. Annexes

Annexe 1: Terminologie et acronymes

Cette page est en cours de préparation. Merci pour votre patience.

Annexe 3: Outils informatiques du chef de projet

Liste non exhaustive des outils

Les outils informatiques suivants sont utilisés à l’UNIL de manière transverse :

Nom (et lien URL)	Description d’utilisation	Droits d’accès
Microsoft Teams	Plusieurs fonctions clefs de communication :  Un chat avec l’accès au répertoire des intervenants de l’UNIL Une Visioconférence Une accessibilité aux informations du calendrier de MS Outlook Une accessibilité aux informations de MS OneDrive et des applications de la suite Office 365 Les règles de ces fonctions sont décrites ci-après : Une plateforme GED via MS SharePoint via les « équipes » pour le partage de documents et informations pendant la réalisation du projet. Note : Il serait possible d’implémenter des processus de validation des livrables projet dans l’outil. Des canaux de communication de type « news »	Il faut un accès à MS Office 365 Pour les équipes, il faut avoir été autorisé à l’accès de l’équipe
Microsoft Outlook	Deux fonctions principales : Gestion des courriels Gestion du calendrier	Il faut un accès à MS Office 365
Microsoft Office 365	Réalisation de documents et stockage de documents avec OneDrive	Il faut un accès à MS Office 365
GitHub	Gestion des cartes descriptives des demandes de développement pour les équipes internes	Il faut travailler avec les équipes de développement
ZenHub	Outil de visualisation Kanban sur la base des cartes GitHub.Ce dernier possède des outils de workflow pour assurer l’automatisation des mises à jour entre les Kanban.	Il faut travailler avec les équipes de développement & les équipes projets
Orchestra	Outils de gestion de projet en ligne permettant principalement : La réalisation du calendrier projet (GANTT) La gestion des ressources du projet La gestion des risques du projet Le lien avec les documents selon la MPRO Les rapports d’état/Flash report des projets avec des vues selon les besoins (projet, programme, portfolio)	Il faut un compte SWITCHedu-ID Il faut travailler avec les équipes projets
GEDUNIL via Microsoft SharePoint	Gestion Electronique de Documents (GED) servant principalement pour l’archivage, notamment pour les documents projets à la clôture du projet. Note : C’est un doublon du SharePoint des équipes dans MS Teams	Il faut un accès à MS Office 365 Pour les espaces de stockage, il faut avoir été autorisé à l’accès.
Unil.ch	Intranet et extranet de l’université de Lausanne comprenant les informations d’organisation de l’UNIL. Pour la partie projet, il faut se référer aux lien CI ainsi qu’aux directives concernant le CI.	Extranet, accès libre Intranet avec un compte SWITCHedu-ID
Wiki de l’UNIL	Contient les différentes documentations internes de l’UNIL comme des procédures RH, maintenance informatique, contacts, et autres.	Extranet, accès libre Intranet avec un compte SWITCHedu-ID
DoodleOu FramaDateOu Calendly	Pour la réalisation de sondage de disponibilité pour les organisations de séances avec de nombreux participants de différentes facultés.	Gratuit, avec une inscription en ligne Non géré par l’UNIL
QTest Link	Outil de gestion des tests	TbC
Plug-in QTest	Plug-in de simplification de documentation de workflow de test ou de documentation de changements de l’existant.	Gratuit

Optimisation : Les règles de documentation ne sont pas encore assez définies, des informations pourraient donc se dupliquer dans les équipes de Teams, GEDUNIL, Wiki UNIL et unil.ch mais aussi entre les modèles des documents Hermès. Chacun doit donc garder cela à l’esprit pour ne pas dupliquer l’information mais bien la lier.

Optimisation : Lors de l’arrivé de nouveau participants, comme des renforts dans les équipes ou des externes, merci d’utiliser ce tableau pour les demandes de droits d’accès.

Orchestra

Les attentes de communication avec Orchestra, hors de la planification du projet, sont les suivantes :

• Enregistrement régulier, au plus tard hebdomadaire, des heures investies sur les projets par activité
• Enregistrement régulier, au plus tard avant une revue de projet, des statuts et données des projets
• Pour les gestionnaires de projet, un rapport flash Hebdomadaire, donnant les informations sur le statut et l’évolution du projet

 

GEDUNIL SharePoint

L’utilisation de GEDUNIL est tolérée en connexion lecteur réseau.

Ce type de connexion crée cependant beaucoup de fichiers cachés lié au système d’exploitation, de la machine connectés, qui se retrouvent alors dans l’espace de stockage. Après la déconnexion du lecteur réseau, il faut nettoyer ces fichiers qui sont alors visible directement dans la version Web.

 

MS Outlook & MS Teams

La gestion des courriels doit se réduire à sa plus simple expression afin de respecter les consignes UNIL.

Le standard pour l’équipe projet est d’indiquer son lieu de travail journalier dans Outlook par le biais d’une tache sur la journée & Dans MS Teams par le menu « Set work location ».

Les réunions personnelles sont typées « out-of office » et ils sont caractérisés comme « privé ». Préciser dans le calendrier le lieu de travail. Préciser toute réunion externe comme « out-of office » & privée.

 

Annexe 4a: Référentiel des livrables (Mission)

Ce document contient la liste des livrables documentaires prévus dans le cadre de la gestion des missions. Ils sont basés et adaptés à partir des résultats selon HERMES 2022.

Merci de télécharger les documents et ne pas les éditer directement depuis le dépôt SharePoint online.

L'information [CODE ABVMI] présente dans l'en-tête des pages est à modifier dans la propriété "Objet" des documents.

Les documents marqués par un (*) sont des documents communs quelque-soit le type (mission, projet, programme).

Phase: Conduite

Conduite de la mission (*)

Ce livrable générique est un regroupement de plusieurs livrables HERMES utiles, voire requis, pour la gestion et le suivi de la mission. Chacun de ces livrables est présenté sous la forme d'un référentiel (tableau) avec des exemples de contenu.

Référence HERMES 2022: Expériences acquises, Liste de l'état des modifications, Liste Décisions de conduite, Liste Décisions de pilotage, Liste des parties prenantes

Recommandation MPRO: facultatif pour le suivi des activités et des décisions de la mission

Règle de nommage: CODE_ABVMI_ConduiteMission.xlsx

Lien de téléchargement: 0-Commun

Rapport sur l'état de la mission (*)

Ce rapport permet de fournir périodiquement des informations sur l'état de la mission, son avancement et les prévisions concernant la suite de son déroulement. Il y a lieu d'appliquer les directives de l'organisation permanente en ce qui concerne le contenu et la fréquence des rapports.

Référence HERMES 2022: Rapport sur l'état du projet

Recommandation MPRO: obligatoire

Règle de nommage: N/A

Ce rapport d'état est à saisir directement dans l'outil Orchestra sous Reporting > Rapports Flash.

FRAT - Fiche de registre des activités de traitement/fichier (*)

Ce document sert à déclarer le traitement de tous types de données personnelles réalisé au moyen de la solution déployée dans le cadre d'une mission. Sa validation par le responsable du traitement est requise pour la mise en service.

Référence HERMES 2022: spécifique UNIL, voir Protection des données à l'UNIL

Recommandation MPRO: obligatoire pour toute solution traitant des données personnelles

Règle de nommage: aaaammjj_FRAT_Entite_NomTraitement.docx

Lien de téléchargement: 0-Commun

Formulaire pour l'évaluation d'une solution Cloud (*)

Ce document sert à évaluer la conformité de la solution envisagée avec la doctrine Cloud de l'UNIL sur l'utilisation de solutions déployées dans le Cloud. Son utilisation est requise avant toute conclusion de contrat avec le fournisseur de cette solution.

Référence HERMES 2022: spécifique UNIL, voir Protection des données à l'UNIL

Recommandation MPRO: obligatoire pour toute solution envisagée dans le Cloud

Règle de nommage: aaaammjj_XXX_FormulaireEvaluationCloud.docx

Lien de téléchargement: 0-Commun

Phase: Initialisation

​Mandat d’exécution​ de la mission

Le mandat d'exécution sert de cadre et de base contraignante pour l'élaboration de la solution ainsi que pour la clôture subséquente de la mission et permet la poursuite de cette dernière. Il contient toutes les données essentielles spécifiques à la solution ainsi que des indications sur la manière de procéder dans les phases suivantes. Il s'agit d'un accord contraignant entre le mandant et le chef de mission.

Référence HERMES 2022: Mandat d'exécution

Recommandation MPRO: obligatoire pour libérer la phase de mise en œuvre de la mission

Règle de nommage: CODE_ABVMI_MandatExecMission.docx

Lien de téléchargement: 1-Initialisation

Phase: Mise en œuvre

Aucun livrable référencé.

Phase: Clôture

Évaluation finale de la mission

L'évaluation finale de la mission constitue la base de la décision concernant la clôture de la mission. Elle fournit au mandant une comparaison entre les objectifs visés et les objectifs atteints concernant les contenus, les délais, les coûts et la procédure. Les contenus des résultats des expériences acquises sont documentés sous forme de résumé. Le contenu et les délais pour le contrôle de la réussite de la mission sont définis.

Référence HERMES 2022: Évaluation finale du projet

Recommandation MPRO: obligatoire pour valider la clôture de la mission

Règle de nommage: CODE_ABVMI_EvalFinaleMission.docx

Lien de téléchargement: 3-Cloture

Annexe 4b: Référentiel des livrables (Projet)

Ce document contient la liste des livrables documentaires prévus dans le cadre de la gestion des projets. Ils sont basés et adaptés à partir des résultats selon HERMES 2022.

Merci de télécharger les documents et ne pas les éditer directement depuis le dépôt SharePoint online.

L'information [CODE ABVPR] présente dans l'en-tête des pages est à modifier dans la propriété "Objet" des documents.

Les documents marqués par un (*) sont des documents communs quelque-soit le type (mission, projet, programme).

Phase: Conduite

Conduite du projet (*)

Ce livrable générique est un regroupement de plusieurs livrables HERMES utiles, voire requis, pour la gestion et le suivi du projet. Chacun de ces livrables est présenté sous la forme d'un référentiel (tableau) avec des exemples de contenu.

Référence HERMES 2022: Expériences acquises, Liste de l'état des modifications, Liste Décisions de conduite, Liste Décisions de pilotage, Liste des parties prenantes

Recommandation MPRO: obligatoire pour le suivi des activités et des décisions du projet

Règle de nommage: CODE_ABVPR_ConduiteProjet.xlsx

Lien de téléchargement: 0-Commun

Rapport sur l'état du projet (*)

Ce rapport permet de fournir périodiquement des informations sur l'état du projet, son avancement et les prévisions concernant la suite de son déroulement. Il y a lieu d'appliquer les directives de l'organisation permanente en ce qui concerne le contenu et la fréquence des rapports.

Référence HERMES 2022: Rapport sur l'état du projet

Recommandation MPRO: obligatoire.

Règle de nommage: N/A

Ce rapport d'état est à saisir directement dans l'outil Orchestra sous Reporting > Rapports Flash.

Présentation pour le COPIL (*)

Ce livrable est un modèle de présentation standard pour les comités de pilotage.

Référence HERMES 2022: N/A

Recommandation MPRO: obligatoire pour les séances de comité de pilotage, à adapter selon le contexte de la séance

Règle de nommage: CODE_ABVPR_CoPil_aaaammjj_Presentation.pptx

Lien de téléchargement: 0-Commun

Présentation pour le COPIL extraordinaire (*)

Ce livrable est un modèle de présentation adapté pour les comités de pilotage extraordinaire.

Référence HERMES 2022: N/A

Recommandation MPRO: facultatif, à utiliser en remplacement si besoin de la présentation au format standard ci-dessus

Règle de nommage: CODE_ABVPR_CoPil_aaaammjj_Extra_Presentation.pptx

Lien de téléchargement: 0-Commun

Procès-verbal (*)

Le procès-verbal documente d'une part les décisions prises et les mandats qui ont été donnés ou pris lors d'une réunion ou d'une discussion, et d'autre part les processus de conduite et d'exécution importants qui devront être retracés ultérieurement si nécessaire. Les points importants de discussion et d'action sont consignés. Les mandats définis dans le procès-verbal sont gérés dans une liste des points en suspens. De manière générale, le recueil de tous les procès-verbaux permet d'assurer la traçabilité des décisions, des procédures et des processus.

Référence HERMES 2022: Procès-verbal

Recommandation MPRO: obligatoire pour les séances de comité de pilotage, facultatif pour les autres (mais notes obligatoires)

Règle de nommage: CODE_ABVPR_[TypeSeance]_aaaammjj_PV.docx (remplacer [TypeSeance] par le type de séance, ex. CoPil)

Lien de téléchargement: 0-Commun

​Plan de gestion du projet

L'élaboration initiale du plan de gestion du projet est marquée par la décision en matière de variantes et d'approches dans la phase d'initialisation. Le choix de l'approche, qu'elle soit classique ou agile, influence en particulier l'exécution des tâches ainsi que la structure et le contenu des résultats. Le plan de gestion du projet contient la planification générale du projet ainsi que les principales dispositions concernant les méthodes, les techniques, les rôles et les outils qui sont définis spécifiquement pour le projet. Il sert de base d'action unique pour tous les participants du projet. Dans le cadre de l'organisation du projet, il garantit que les responsabilités et la répartition des tâches entre les bénéficiaires de prestations, les fournisseurs de prestations internes et, le cas échéant, les fournisseurs externes sont clairement définies et documentées. Il est précisé et actualisé en continu pendant le projet selon le principe de la planification et du pilotage continus. En cas de développement agile de la solution, le calendrier de la phase de mise en æuvre est combiné avec le plan de release (agile). Ce plan de release indique l'étendue des releases et le moment où l'exploitation est activée par release. Il est en outre précisé si la décision (facultative) de libération du release est prescrite ou non dans le projet. À la clôture d'une phase, le plan de gestion du projet est adapté aux nouvelles conditions pour le déroulement de la phase suivante. Avant que la phase de clôture ne soit libérée, il est en outre préparé et adapté en conséquence en vue de la clôture du projet.

Référence HERMES 2022: Plan de gestion du projet

Recommandation MPRO: facultatif

Règle de nommage: CODE_ABVPR_PlanGestionProjet.docx

Lien de téléchargement: 0-Conduite

FRAT - Fiche de registre des activités de traitement/fichier (*)

Ce document sert à déclarer le traitement de tous types de données personnelles réalisé au moyen de la solution déployée dans le cadre d'un projet. Sa validation par le responsable du traitement est requise pour la mise en service.

Référence HERMES 2022: spécifique UNIL, voir Protection des données à l'UNIL

Recommandation MPRO: obligatoire pour toute solution traitant des données personnelles

Règle de nommage: aaaammjj_FRAT_Entite_NomTraitement.docx

Lien de téléchargement: 0-Commun

Formulaire pour l'évaluation d'une solution Cloud (*)

Ce document sert à évaluer la conformité de la solution envisagée avec la doctrine Cloud de l'UNIL sur l'utilisation de solutions déployées dans le Cloud. Son utilisation est requise avant toute conclusion de contrat avec le fournisseur de cette solution.

Référence HERMES 2022: spécifique UNIL, voir Protection des données à l'UNIL

Recommandation MPRO: obligatoire pour toute solution envisagée dans le Cloud

Règle de nommage: aaaammjj_XXX_FormulaireEvaluationCloud.docx

Lien de téléchargement: 0-Commun

Phase: Initialisation

​Mandat d'initialisation du projet​

Le mandat d'initialisation du projet constitue la base formelle pour la libération de la phase d'initialisation. Il s'agit d'un accord entre le mandant et le chef de projet pour la phase d'initialisation.

Référence HERMES 2022: Mandat d'initialisation du projet

Recommandation MPRO: facultatif, selon les dispositions prises en amont du démarrage du projet

Règle de nommage: CODE_ABVPR_MandatInitProjet.docx

Lien de téléchargement: 1-Initialisation

Étude

L'étude décrit la solution visée en définissant les objectifs généraux sur la base de la situation, en énumérant les variantes de solutions possibles et la procédure proposée, puis en les évaluant. Elle correspond au business case et montre l'utilité commerciale du projet ainsi que la relation de ce dernier avec la stratégie et les objectifs de l'organisation permanente. Tous les aspects qui ont une influence sur la solution envisagée ou qui peuvent être influencés par la solution sont mentionnés dans l'étude. En outre, on choisit le scénario approprié (voir chap. 2 Scénarios), on établit éventuellement un scénario personnalisé et on estime la valeur que le projet aura. L'étude n'est détaillée que dans la mesure où l'orientation du projet envisagé apparaît clairement et que la décision relative à la suite projet peut être prise. La procédure rigoureuse s'applique en particulier à l'évaluation de la situation, afin de ne pas prolonger inutilement la phase d'initialisation. La décision relative à la suite du projet documentée dans l'étude sert de base pour préparer la décision de poursuivre ou non un projet. L'étude est la condition nécessaire à l'élaboration du plan de gestion du projet et du mandat d'exécution.

Référence HERMES 2022: Étude

Recommandation MPRO: facultatif, mais fortement recommandée si une analyse métier est requise

Règle de nommage: CODE_ABVPR_EtudeProjet.docx

Lien de téléchargement: 1-Initialisation

Organigramme du projet

L'organigramme du projet présente l'organisation mise en place au niveau du pilotage et de la conduite du projet.

Référence HERMES 2022: N/A

Recommandation MPRO: facultatif en tant que document annexe, mais obligatoire dans le mandat d'exécution

Règle de nommage: CODE_ABVPR_Organigramme.vsdx

Lien de téléchargement: 1-Initialisation

Mandat d’exécution​

Le mandat d'exécution sert de cadre et de base contraignante pour l'élaboration de la solution ainsi que pour la clôture subséquente du projet et permet la poursuite de ce dernier. Il contient toutes les données essentielles spécifiques à la solution ainsi que des indications sur la manière de procéder dans les phases suivantes. Il s'agit d'un accord contraignant entre le mandant et le chef de projet.

Référence HERMES 2022: Mandat d'exécution

Recommandation MPRO: obligatoire pour libérer la phase de mise en œuvre du projet

Règle de nommage: CODE_ABVPR_MandatExecProjet.docx

Lien de téléchargement: 1-Initialisation

Phase: Mise en œuvre

Analyse des besoins de protection

L’analyse des besoins de protection, également appelée analyse SIPD, documente les exigences en matière de sûreté de l’information et de protection des données.

Référence HERMES 2022: Analyse des besoins de protection

Recommandation MPRO: facultatif, selon les dispositions prises lors de la libération de l'exécution du projet

Règle de nommage: CODE_ABVPR_AnalyseSIPD.docx

Lien de téléchargement: 2-MiseEnOeuvre

Note: Le chapitre 4 et ses sous-chapitres sont préremplis avec les informations légales de base pour l'analyse SIPD. En principe, elles sont à jour et sont valables pour tout type de projet.

Architecture de la solution

L’architecture de la solution se fonde sur le concept du système et divise ce dernier en sous-systèmes et en leurs composantes. Elle décrit la structure et les interfaces du système. Elle donne un aperçu complet du système. Suivant le résultat et l’étendue du projet, elle contient plusieurs éléments et modèles d’architecture, par exemple le modèle des processus d’affaires, le modèle des fonctions (par ex. avec cas d’utilisation [use case] et récits d’utilisateurs [user story]), l’architecture ou le modèle des données, l’architecture de sécurité. Elle contient également la documentation informatique ou renvoie à la documentation du producteur. Les résultats du Concept du système sont résumés dans une annexe sur l’architecture de la solution. Celle-ci tient compte des instructions des organes de prescription et de contrôle de gestion.

Référence HERMES 2022: Architecture de la solution

Recommandation MPRO: facultatif, selon les dispositions prises lors de la libération de l'exécution du projet

Règle de nommage: CODE_ABVPR_ArchitectureSolution.docx

Lien de téléchargement: 2-MiseEnOeuvre

Concept de déploiement

Le concept de déploiement décrit les mesures pour le déploiement de la solution et l’organisation du déploiement. En font partie, entre autres, les mesures de gestion du changement organisationnel visant à soutenir la transition vers le nouvel état, le concept de formation, la planification des réceptions avec les critères de réception ainsi que les critères de libération de la mise en service.

Référence HERMES 2022: Concept de déploiement

Recommandation MPRO: facultatif, selon les dispositions prises lors de la libération de l'exécution du projet

Règle de nommage: CODE_ABVPR_ConceptDeploiement.docx

Lien de téléchargement: 2-MiseEnOeuvre

Concept d’exploitation

Le concept d’exploitation décrit l’organisation d’exploitation, avec l’organisation structurelle et les processus opérationnels de l’exploitant. Il constitue la base pour l’élaboration du manuel d’exploitation et de l’organisation de l’exploitant.

Référence HERMES 2022: Concept d'exploitation

Recommandation MPRO: facultatif, selon les dispositions prises lors de la libération de l'exécution du projet

Règle de nommage: CODE_ABVPR_ConceptExploitation.docx

Lien de téléchargement: 2-MiseEnOeuvre

Concept d’intégration

Le concept d’intégration décrit comment le système sera intégré dans l’environnement. Il décrit également comment le transport d’un environnement système à un autre est effectué et comment la gestion de la configuration et la qualité sont assurées. En cas de déploiement avec des unités de réalisation (classique) ou d’une intégration par étapes avec des releases (agile), la planification des unités de réalisation ou la planification des releases selon le plan de gestion du projet fait partie intégrante du concept d’intégration.

Référence HERMES 2022: Concept d'intégration

Recommandation MPRO: facultatif, selon les dispositions prises lors de la libération de l'exécution du projet

Règle de nommage: CODE_ABVPR_ConceptIntegration.docx

Lien de téléchargement: 2-MiseEnOeuvre

Concept de migration

Le concept de migration décrit les exigences techniques et organisationnelles et inclut le concept concernant les procédures de migration. Il atteste la faisabilité de la migration et en présente la planification. En plus des exigences techniques et organisationnelles, les exigences relatives à la révision ainsi qu’au SIPD sont aussi prises en compte.

Référence HERMES 2022: Concept de migration

Recommandation MPRO: facultatif, selon les dispositions prises lors de la libération de l'exécution du projet

Règle de nommage: CODE_ABVPR_ConceptMigration.docx

Lien de téléchargement: 2-MiseEnOeuvre

Concept d’organisation

Le concept d’organisation approfondit la variante de solution décrite et choisie dans l’étude du point de vue organisationnel. Il se base sur les exigences organisationnelles, complétées le cas échéant par les conclusions tirées des exigences envers la solution, et décrit les aspects pertinents du modèle d’affaires ainsi que l’organisation structurelle et l’organisation fonctionnelle (processus d’affaires) pour le traitement des affaires et l’assistance. Il montre quelle nouvelle organisation sera établie et quelles modifications seront apportées à ce qui existe déjà.

Référence HERMES 2022: Concept d'organisation

Recommandation MPRO: facultatif, selon les dispositions prises lors de la libération de l'exécution du projet

Règle de nommage: CODE_ABVPR_ConceptOrganisation.docx

Lien de téléchargement: 2-MiseEnOeuvre

Concept SIPD

Le concept SIPD sert de base pour la définition des mesures de sûreté de l’information et de protection des don-nées (SIPD). Il indique quels sont les risques résiduels liés à l’exploitation du système et à l’organisation.

Référence HERMES 2022: Concept SIPD

Recommandation MPRO: facultatif, selon les dispositions prises lors de la libération de l'exécution du projet

Règle de nommage: CODE_ABVPR_ConceptSIPD.docx

Lien de téléchargement: 2-MiseEnOeuvre

Concept du système

Le concept du système approfondit la variante de solution décrite et choisie dans l’étude. Il se base sur les exigences envers la solution et montre comment la solution y répond. Le concept du système peut décrire et évaluer plusieurs variantes de système. Il peut y avoir plusieurs concepts de système sur différents thèmes.

Ce livrable peut être remplacé par des spécifications fonctionnelles métiers rédigées sur un autre support (ex. wiki) mis à la disposition de l'équipe de développement pour l'implémentation de la solution.

Référence HERMES 2022: Concept du système

Recommandation MPRO: facultatif, selon les dispositions prises lors de la libération de l'exécution du projet

Règle de nommage: CODE_ABVPR_ConceptSysteme.docx

Lien de téléchargement: 2-MiseEnOeuvre

Concept de test

Le concept de test décrit les objectifs des tests, les objets à tester, les types de tests, l’infrastructure et l’organisation de test. Il englobe également la planification des tests et la description des cas de test. Une des-cription détaillée est établie pour chaque cas de test. Elle représente la spécification du test. La planification des tests détermine le déroulement logique et temporel des tests. Le concept de test constitue la base sur laquelle l’organisation et l’infrastructure de test sont mises à disposition et les tests sont exécutés. Il est régulièrement actualisé si de nouvelles constatations sont faites.

Référence HERMES 2022: Concept de test

Recommandation MPRO: facultatif, selon les dispositions prises lors de la libération de l'exécution du projet

Règle de nommage: CODE_ABVPR_ConceptTest.docx

Lien de téléchargement: 2-MiseEnOeuvre

Demande de modification

La demande de modification sert de base à tout changement. Elle englobe la description de la modification, avec la demande proprement dite, la procédure pour exécuter la modification et la solution proposée pour la mettre en œuvre. La demande de modification a le caractère d’une exigence et décrit en détail la modification à exécuter.

Référence HERMES 2022: Demande de modification

Recommandation MPRO: facultatif, selon les dispositions prises lors de la libération de l'exécution du projet

Règle de nommage: CODE_ABVPR_DemandeModification.docx

Lien de téléchargement: 2-MiseEnOeuvre

Description de l’organisation

La description de l’organisation décrit l’organisation structurelle avec l’organigramme détaillé, les descriptions des fonctions et les exigences en matière de personnel. Elle sert de base pour l’occupation des postes.

Référence HERMES 2022: Description de l'organisation

Recommandation MPRO: facultatif, selon les dispositions prises lors de la libération de l'exécution du projet

Règle de nommage: CODE_ABVPR_DescriptionOrganisation.docx

Lien de téléchargement: 2-MiseEnOeuvre

Description des processus

La description de processus est une organisation fonctionnelle détaillée jusqu’au niveau des processus, elle décrit les différents processus avec les moyens auxiliaires utilisés.

Référence HERMES 2022: Description de processus

Recommandation MPRO: facultatif, selon les dispositions prises lors de la libération de l'exécution du projet

Règle de nommage: CODE_ABVPR_DescriptionProcessus.docx

Lien de téléchargement: 2-MiseEnOeuvre

Exigences envers la solution

Les exigences envers la solution constituent un résultat HERMES déterminant. Elles contiennent les exigences métier et techniques, mais aussi d’autres éléments tels que les propriétés, les fonctions, les optimisations et les corrections de défauts, les directives juridiques ainsi que celles relatives à la solution et à la réglementation que le futur système ou produit doit remplir. Dans le cadre de la mise au point de la solution selon l’approche classique, les exigences envers la solution sont élaborées dans la phase Conception sur la base de l’Étude et de l’Analyse de la situation jusqu’au niveau de détail définitif et, si nécessaire, mises à jour au fur et à mesure pendant la mise au point de la solution via la gestion des changements. Dans le cadre de la mise au point de la solution selon l’approche agile, les exigences envers la solution sont élaborées pour la première fois sur la base de l’étude et de l’analyse de la situation lors de la phase de Mise en œuvre sous forme d'initial product backlogs déterminants établis en se fondant sur l’Étude et sur l’Analyse de la situation. Un product backlog est une liste d’exigences classées par ordre de priorité, divisées si nécessaire en releases, organisées en fonction d’aspects spécifiques à l’affaire ou d’autres aspects importants pour le projet et de dépendances logiques. Dans le cadre du développement agile autoorganisé, ils sont mis à jour en continu. En tant que résultat HERMES, ils sont mis à jour de manière itérative et incrémentale et n’ont par la suite plus qu’un caractère informatif et documentaire.

Référence HERMES 2022: Exigences envers la solution

Recommandation MPRO: facultatif, selon les dispositions prises lors de la libération de l'exécution du projet

Règle de nommage: CODE_ABVPR_ExigencesSolution.docx + CODE_ABVPR_ExigencesReferentiel.xlsx

Lien de téléchargement: 2-MiseEnOeuvre

Note: Ce livrable est accompagné en annexe d'un fichier Excel faisant office de référentiel des exigences.

Manuel d’exploitation

Le manuel d’exploitation fournit toutes les informations dont l’exploitant a besoin pour faire fonctionner le sys-tème de manière adéquate et réagir correctement en cas de problèmes. Il contient toutes les informations perti-nentes pour l’exploitant. Pendant la mise au point agile de la solution, le manuel d’exploitation est mis à jour à chaque itération ou release lorsqu’une partie complète de la solution est activée.

Référence HERMES 2022: Manuel d'exploitation

Recommandation MPRO: facultatif, selon les dispositions prises lors de la libération de l'exécution du projet

Règle de nommage: CODE_ABVPR_ManuelExploitation.docx

Lien de téléchargement: 2-MiseEnOeuvre

Manuel d’utilisation

Le manuel d’utilisation contient toutes les informations dont l’utilisateur d’un produit ou d’un système a besoin pour s’en servir et pouvoir réagir correctement en cas de problèmes.

Référence HERMES 2022: Manuel d'utilisation

Recommandation MPRO: facultatif, selon les dispositions prises lors de la libération de l'exécution du projet

Règle de nommage: CODE_ABVPR_ManuelUtilisation.docx

Lien de téléchargement: 2-MiseEnOeuvre

Phase: Clôture

Évaluation finale du projet

L'évaluation finale du projet constitue la base de la décision concernant la clôture du projet. Elle fournit au mandant une comparaison entre les objectifs visés et les objectifs atteints concernant les contenus, les délais, les coûts et la procédure. Les contenus des résultats des expériences acquises sont documentés sous forme de résumé. Le contenu et les délais pour le contrôle de la réussite du projet sont définis.

Référence HERMES 2022: Évaluation finale du projet

Recommandation MPRO: obligatoire pour valider la clôture du projet

Règle de nommage: CODE_ABVPR_EvalFinaleProjet.docx

Lien de téléchargement: 3-Cloture

Annexe 4c: Référentiel des livrables (Programme)

Ce document contient la liste des livrables documentaires prévus dans le cadre de la gestion des programmes. Ils sont basés et adaptés à partir des résultats selon HERMES 2022.

Merci de télécharger les documents et ne pas les éditer directement depuis le dépôt SharePoint online.

L'information [CODE ABVPG] présente dans l'en-tête des pages est à modifier dans la propriété "Objet" des documents.

Les documents marqués par un (*) sont des documents communs quelque-soit le type (mission, projet, programme).

Phase: Conduite

Conduite du programme (*)

Ce livrable générique est un regroupement de plusieurs livrables HERMES utiles, voire requis, pour la gestion et le suivi du programme. Chacun de ces livrables est présenté sous la forme d'un référentiel (tableau) avec des exemples de contenu.

Référence HERMES 2022: Expériences acquises dans le cadre du programme, Liste de l'état des modifications du programme, Liste des décisions relatives au programme, Liste des parties prenantes

Recommandation MPRO: obligatoire pour le suivi des activités et des décisions du programme

Règle de nommage: CODE_ABVPG_ConduiteProgramme.xlsx

Lien de téléchargement: 0-Commun

Rapport sur l'état du programme

Ce rapport permet de fournir périodiquement des informations sur l'état du programme, son avancement et les prévisions concernant la suite de son déroulement. Il y a lieu d'appliquer les directives de l'organisation permanente en ce qui concerne le contenu et la fréquence des rapports.

Référence HERMES 2022: Rapport sur l'état du programme

Recommandation MPRO: obligatoire.

Règle de nommage: N/A

Ce rapport d'état est à saisir directement dans l'outil Orchestra sous Reporting > Rapports Flash.

Présentation pour le COPIL (*)

Ce livrable est un modèle de présentation standard pour les comités de pilotage.

Référence HERMES 2022: N/A

Recommandation MPRO: obligatoire pour les séances de comité de pilotage, à adapter selon le contexte de la séance.

Règle de nommage: CODE_ABVPG_CoPil_aaaammjj_Presentation.pptx

Lien de téléchargement: 0-Commun

Présentation pour le COPIL extraordinaire (*)

Ce livrable est un modèle de présentation adapté pour les comités de pilotage extraordinaire.

Référence HERMES 2022: N/A

Recommandation MPRO: facultatif, à utiliser en remplacement si besoin de la présentation au format standard ci-dessus.

Règle de nommage: CODE_ABVPR_CoPil_aaaammjj_Extra_Presentation.pptx

Lien de téléchargement: 0-Commun

Procès-verbal (*)

Le procès-verbal documente d'une part les décisions prises et les mandats qui ont été donnés ou pris lors d'une réunion ou d'une discussion, et d'autre part les processus de conduite et d'exécution importants qui devront être retracés ultérieurement si nécessaire. Les points importants de discussion et d'action sont consignés. Les mandats définis dans le procès-verbal sont gérés dans une liste des points en suspens. De manière générale, le recueil de tous les procès-verbaux permet d'assurer la traçabilité des décisions, des procédures et des processus.

Référence HERMES 2022: Procès-verbal

Recommandation MPRO: obligatoire pour les séances de comité de pilotage, facultatif pour les autres (mais notes obligatoires)

Règle de nommage: CODE_ABVPG_[TypeSeance]_aaaammjj_PV.docx (remplacer [TypeSeance] par le type de séance, ex. CoPil)

Lien de téléchargement: 0-Commun

​​Mandat de travail du programme​

Le mandat de travail contient toutes les informations pertinentes pour l'exécution d'une tâche. Avec ce document, le chef de programme délègue des tâches aux collaborateurs du programme dans le cadre de la planification, de la conduite, de l'information et du contrôle. Les mandats de travail peuvent être octroyés à l'interne ou à l'externe. Les éventuels mandats spécifiques à la solution doivent être convenus au préalable avec le représentant des utilisateurs.

Référence HERMES 2022: Mandat de travail du programme

Recommandation MPRO: obligatoire pour lancer un projet ou une mission dans le cadre d'un programme

Règle de nommage: CODE_ABVPG_MandatTravailProgramme.docx

Lien de téléchargement: 0-Conduite

Phase: Initialisation

​Mandat d’initialisation du programme​

Le mandat d'initialisation du programme constitue la base formelle pour la libération de la phase d'initialisation. Il s'agit d'un accord entre le mandant et le chef de programme pour la phase d'initialisation.

Référence HERMES 2022: Mandat d'initialisation du programme

Recommandation MPRO: facultatif, selon les dispositions prises en amont du démarrage du programme

Règle de nommage: CODE_ABVPG_MandatInitProgramme.docx

Lien de téléchargement: 1-Initialisation

Analyse des bases légales du programme​

L'analyse des bases légales décrit les bases légales existantes pour le résultat du programme ainsi que l'éventuelle nécessité de les modifier. Une attention particulière est accordée aux exigences légales communales, cantonales, nationales et, le cas échéant, internationales ainsi qu'aux exigences relatives aux produits et à la réglementation que la solution envisagée doit respecter, y compris ses répercussions sur les systèmes environnants (conformité des produits) (Product Compliance).

Référence HERMES 2022: Analyse des bases légales du programme

Recommandation MPRO: facultatif, selon les dispositions prises en amont du démarrage du programme

Règle de nommage: CODE_ABVPG_BasesLegalesProgramme.docx

Lien de téléchargement: 1-Initialisation

​Mandat d’exécution du programme​

Le mandat d'exécution sert de cadre et de base contraignante pour l'élaboration de la solution ainsi que pour la clôture subséquente du programme et permet la poursuite de ce dernier. Il contient toutes les données essentielles spécifiques à la solution ainsi que des indications sur la manière de procéder dans les phases suivantes. Il s'agit d'un accord contraignant entre le mandant et le chef de programme.

Référence HERMES 2022: Mandat d'exécution du programme

Recommandation MPRO: obligatoire pour libérer la phase d'exécution du programme

Règle de nommage: CODE_ABVPG_MandatExecProgramme.docx

Lien de téléchargement: 1-Initialisation

Phase: Exécution

Aucun livrable référencé.

Phase: Clôture

​​Appréciation finale du programme​

​​Appréciation finale du programme​

L'appréciation finale du programme constitue la base de la décision concernant la clôture du programme. Elle résume les appréciations finales des projets et apporte des compléments concernant la conduite et le pilotage du programme. Elle fournit au mandant du programme une comparaison entre les objectifs visés et les objectifs du programme et des procédures en matière de contenus, délais et coûts. Les contenus des résultats des expériences acquises sont documentés sous forme résumée. L'évaluation définit aussi le contenu et les délais du contrôle de la réussite du programme.

Référence HERMES 2022: Appréciation finale du programme

Recommandation MPRO: obligatoire pour valider la clôture du programme

Règle de nommage: CODE_ABVPG_EvalFinaleProgramme.docx

Lien de téléchargement: 3-Cloture