Méthodologie Projets (MPRO)

La Méthodologie de Projets (MPRO) est la méthode choisie par le Centre Informatique (Ci) pour conduire les projets métiers et techniques. Cette méthode est basée sur la méthodologie de la Confédération Suisse HERMES (version 2022) et a été adaptée aux besoins et aux pratiques de l'Université de Lausanne (UNIL).

Cette démarche a été mise en place par le Ci en 2016 sous la responsabilité du Project Management Office (PMO), puis a été développée sur HERMES à partir de 2018. Aujourd'hui, notre méthodologie MPRO a déjà été utilisée pour la conduite et l'exécution de plusieurs dizaines de projet IT de toute envergure et complexité, et constitue à ce jour une référence sûre au niveau institutionnel.

Présentation générale

Cette documentation est adressée à toute personne impliquée dans un projet IT du Centre Informatique. Elle a pour objectif de transmettre les informations utiles et/ou nécessaires en fonction de l'implication de ces personnes, qu'elles soient membres du Ci, collaboratrices d'une faculté ou d'un service, ou prestataires externes.

Note: cette documentation étant en cours d'actualisation et de révision, il se peut que certains contenus soient encore manquants ou incomplets. Merci de votre compréhension, et désolé pour les désagréments occasionnés.

Présentation générale

1. Introduction à la MPRO

Ce chapitre présente les notions de base des projets, distingue les différents types de projets et introduit la MPRO.

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. Il peut s’agir aussi d’un programme (un ensemble de projets interdépendants) ou un portefeuille de projets (un ensemble de projets ou programmes pouvant être interdépendants).

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 :


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

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

Les projets s’inscrivent dans un cadre bien défini : 

Figure 2 : extraite du PMBOK Figure 1-4. Organizational Project Management

A l’UNIL, cette structure se retrouve de la manière suivante :

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 Ci 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 (Méthodologie de Projets).

A qui s’adresse la MPRO

La MPRO s’adresse avant tout aux chefs 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 (Business Analyst), la gestion de la qualité (Quality Assurance) et la gestion du changement (Change Management).


Figure 3 : Périmètre d'application de la Méthodologie de Projets de l'UNIL (MPRO)

Différents types de projet

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

Présentation générale

2. Organisation et rôles

Ce chapitre décrit les rôles obligatoires ou importants dans la gestion de projet.

Notions de base

Comme décrit dans la page Introduction à la MPRO, un projet est une activité temporaire qui se démarque des activités courantes de l’organisation permanente. De la même manière, 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.

Rôles des parties prenantes

Les rôles présentés ci-dessous 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. La ou le mandant 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. Elle ou il est généralement secondé·e par un Comité de pilotage qu’elle ou 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 la ou le 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. La cheffe ou le chef de projet est ainsi la personne qui 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. Elle ou 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 une ou un professionnel de la gestion de projet (collaborateur du pôle Projets du Ci), s’il s’agit d’un projet métier, ou par une ou un Chef de pôle du Ci, s’il s’agit d’une mission (projet technique ou maintenance évolutive).

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 la ou le spécialiste métier concerné 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 une ou un 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)

La ou le 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)

La ou le quality analyst soutient la mandante ou le mandant 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)

La ou le test manager conçoit, planifie et coordonne les tests. Elle ou 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)

La ou le change manager est responsable d’accompagner le changement au sein des unités impactées par le projet.

Utilisateur clé (Key User, KU)*

L’utilisatrice ou l’utilisateur clé est une utilisatrice ou un utilisateur final qui reçoit une formation spécifique à l’utilisation de la solution déployée par le projet, afin qu’elle ou il puisse à son tour former et aider ses homologues.

Utilisateur final (End User, EU)*

L’utilisatrice ou l’utilisateur final est la personne à qui bénéficie principalement la solution déployée par le projet.

Responsabilités des parties prenantes

Le RASCI (Responsible, Accountable, Support, Consulted, Informed) présente les diverses responsabilités que peuvent prendre les parties prenantes selon leur rôle dans un projet.

 

Rôles du projet Pre-Initialisation Phases du projet PLM / Maintenance
Initialisation Conception Réalisation Déploiement Clôture
RM   R C I I I  
MAN I A A A A A R
CPR S R (Sauf COMINI) R R R R C (RETEX)
QA   S C R C C C
BA I S R C I I I
TM   I R R R C C
CM     A A A C A
KU R R R R R C I
EU C C C R/C R/C C I

Organisation d’un projet

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


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 de la mandante ou du mandant, ou à la demande de la cheffe ou du chef de projet, et se compose à minima des membres suivants :

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 de la cheffe ou chef de projet, et se compose à minima des membres suivants :

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.

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 utilisatrices et utilisateurs finaux afin d’être consultés sur certains choix métiers à prendre par le projet.
La mandante ou le mandant et/ou la ou le CPR peuvent demander la mise en place de comités complémentaires.

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

Présentation générale

3. Déroulement d'un projet

Ce chapitre décrit le 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.


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

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

Classique vs. Agile


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.

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.

Phase d’initialisation

Ledébut du projetcomprend toujours laphase d'initialisation (HERMES). 

Ledébut du projetest consacré à l'orientation du projet selon les visions, les besoins et les objectifs. Elle constitue une base pour la planification et le pilotage du projet. 

Ici nous nous concentrons uniquement sur le minimum nécessaire à l’élaboration de la phase d’initialisation. 

Les exceptions sont traitées au cas par cas et ne font pas partie d’une démarche standard MPRO. 

image.png

DESI validée  

La validation d’une Demande d’évolution du système d’information (DESI) par le Comité de direction (CODIR) en fonction d’un préavis positif et d’une priorisation du Comité de coordination des projets (COPRO) est l’élément déclencheur à la création d’un projet. 

 La Directive 6.10 est garante du processus et de la définition de la stratégie numérique de l’UNIL.

Désignation de la Cheffe ou du Chef de projet  

Une fois que la décision est prise d’initier un projet, le Responsable du Pôle Projet désigne une Cheffe ou un Chef de projet et lui transmet tous les éléments en sa possession concernant le projet (Mandant [lien wiki], objectifs, périmètre, contraintes, etc.). 

Séance d’initialisation

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

Prendre en main les outils projet 

Élaborer le mandat d’initialisation  

Le Mandat d’initialisation décrit la situation de départ, les objectifs et les ressources nécessaires. Le PV de la séance d’initialisation en est la base. 

Kick-Off d’initialisation 

Une fois le Mandat d’initialisation validé, un Kick-Off d’initialisation est organisé par la Cheffe ou le Chef de projet avec les membres de l’équipe d’initialisation (Mandant·e, RM, BA).  

 Le but étant d’aligner toute l’équipe qui sera à l’œuvre durant la phase d’initialisation sur les objectifs, le périmètre et les contraintes du projet, ainsi que sur la méthode de projet du CI (MPRO). 

É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 documentée dans l'étude. 

Référence HERMES : https://www.hermes.admin.ch/fr/pjm-2022/comprendre/taches/elaborer-l-etude.html 

Élaborer le plan de gestion de projet  

L'élaboration du plan de gestion du projet permet non seulement de définir, sur la base de la planification et des délais définis dans l'étude, la planification globale du projet ainsi que les dispositions et règles essentielles, mais aussi de créer les conditions nécessaires à l'élaboration du mandat d'exécution.  

Référence HERMES : https://www.hermes.admin.ch/fr/pjm-2022/comprendre/taches/elaborer-le-plan-de-gestion-du-projet.html 

COMINI : Choix de variante CI 

Le COMINI (Comité d’initialisation) est une séance organisée en interne au CI par la Cheffe ou le Chef de projet à l’issue de l’Étude. 

Le but de la séance est de présenter les conclusions de l’Étude aux Responsables de Pôles du CI 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 la Mandante ou le Mandant, sur la base des préconisations du COMINI. 

Document modèle : CODE_ABVPR_ChoixVariante_aaaammjj_Présentation.pptx

É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. 

Référence HERMES : https://www.hermes.admin.ch/fr/pjm-2022/comprendre/taches/elaborer-le-mandat-d-execution.html 

COPIL de fin de phase 

Le COPIL de fin de phase est organisé par la Cheffe ou le Chef de projet et réunit tous les membres du COPIL (Comité de Pilotage). 

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 la phase d’exécution du projet (Phase de Conception en méthode classique ou Phase de Mise en Œuvre en méthode agile). 

Phase de mise en œuvre

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 principales activités entreprises durant cette phase, qu’il s’agisse d’un mode agile ou non, sont les suivantes :

Une solution développée à l’UNIL est généralement découpée en plusieurs lots de fonctionnalités réalisées lors de sprints de 2 semaines, permettant ainsi d’avoir régulièrement des feedbacks des utilisateurs sur les résultats partiels obtenus, mais aussi permettre d’exécuter des tests fonctionnels de manière plus régulière afin de gagner en qualité.

Dans le cas de l’implémentation d’une solution du marché, les activités ci-dessus sont réalisées généralement par ou avec un prestataire externe. Les spécifications détaillées servent à rédiger un cahier des charges qui servira de référence pour réaliser un appel d’offres et évaluer les offres reçues.

Phase de clôture

La fin d’un projet se manifeste par la phase dite de clôture du projet. La MPRO offre une structure de tâches, séances et livrables pour terminer systématiquement un projet. Nous retrouvons au minimum :

Rétrospective du projet

Il s’agit d’une collecte et documentation systématique des expériences du CPR et de l’équipe de projet. Son objectif principal est de capitaliser sur l’apprentissage et les expériences afin d’améliorer les processus futurs.

Selon les besoins il peut aussi y avoir des rencontres bilatérales entre la cheffe ou le chef de projet et la ou le mandant, de la ou du RM ou autres membres du COPIL suivant les niveaux hiérarchiques ou des rencontres plénières avec toute l’équipe rassemblée

Le résultat de ces revues est transcrit dans le document « Expériences acquises ».

É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. Elle présente un résumé des expériences liées au projet.

Les éléments du document « Expériences acquises » sont utilisés dans la production du livrable « Évaluation finale du projet ».

Il est recommandé de faire valider au préalable l’Évaluation finale du projet avant de la transmettre au COPIL pour relecture.

Séance de COPIL de clôture

Il s’agit de la séance de décision pour décharger officiellement les participantes et participants au projet de leurs responsabilités et clôturer le projet.

L’Évaluation finale du projet est le fil conducteur du COPIL de clôture. Les membres du COPIL ont préalablement pris connaissance de ses éléments et les valident durant la séance. Elles et ils valident également les actions à entreprendre quant au « reste à faire » (Ex : activités de type hypercare ; tickets ouverts chez le prestataire ; quand traiter les demandes ouvertes hors-périmètre etc.).

Traitement du reste à faire

Il s’agit d’une planification post-projet d’actions et d’améliorations qui encadre le cycle d’exploitation(cf. PLM – Product Life Cycle Management).

Clôture administrative

Il s’agit d’une liste de tâches à effectuer tant au niveau du classement des documents, que de la fermeture des espaces de collaborations, des outils de suivi du projet et des développements afin d’assurer la qualité de la clôture [RM5] du projet.

RETEX

Pilotage et Conduite du projet

Le pilotage (décisions stratégiques, par le mandant) et la conduite (décisions opérationnelles, par le chef de projet) 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. Plusieurs tâches sont attendues de la part  de la ou du mandant, de la ou du chef de projet ou de l’équipe du projet, notamment :

Chaque projet fait l’objet d’un reporting régulier de la part du chef de projet, qui mentionne :
·         Le pourcentage d’avancement général du projet
·        
La météo du projet et sa tendance, selon trois niveaux :
      o   Soleil : le projet se déroule selon la planification en cours. Si certains problèmes peuvent être identifiés, ils n’ont pas
          d’impact sur le déroulement du projet.
      o  
Nuage : une dérive est constatée dans la planification du projet, impactant plus ou moins fortement les délais, les coûts                ou les ressources du projet. Des mesures correctives sont attendues pour mitiger les problèmes identifiés.
      o  
Pluie : le projet est à risque car la planification ne peut plus être respectée en l’état. Les travaux sont en général stoppés                dans l’attente d’une révision de la planification et/ou de la mise en place d’un plan d’action pour résoudre les problèmes              impactants.
·         Une description des faits marquants, des éventuels problèmes rencontrés et des prochaines étapes

Présentation générale

4. 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 [LCHA1] 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 :

Présentation générale

5. Implication du métier

Ce chapitre décrit les 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 « métier » 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 ou une « référent·e » dans le cadre d’un projet, qui agit en tant qu’agent du changement mais aussi comme porte-parole des utilisatrices et utilisateurs de l’organisation qu’il représente.

Tâches attendues du métier

Dans le cadre d’un projet, plusieurs tâches incombent au ou à la référent·e métier et 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.

De par leur importance pour la réussite du projet, il est essentiel que les représentant·es du métier impliqués dans le projet puisse 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.

Phase d’initialisation

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 :

Phase de mise en œuvre

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

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 :

Clôture

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.

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.

 

Présentation générale

6. Business Analyse

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

Présentation générale

7. Quality et testing

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

Présentation générale

8. Gestion du changement

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

Présentation générale

Annexe 1: Terminologie et acronymes

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

Présentation générale

Annexe 2: Intervenants UNIL dans les projets

L’objectif est de faciliter la compréhension de chacun des responsabilités pour son ou ses rôles dans les projets.

Ces informations complètent celles présentées à la page de bienvenue.

 

Titres des rôles dans un projet

Cette section donne les acronymes et les titres usités à l’UNIL et sur le marché.

Les rôles projet des intervenants sont définis par Hermès 5.1 et Hermès 2022.

Les rôles programmes des intervenants sont définis par Hermès 5.1 et Hermès 2022.

Ces descriptions des rôles contiennent également les organigrammes standards.

Ce tableau ne fait donc que grouper les acronymes et les titres complet, sans dupliquer les informations déjà disponibles dans la méthodologie Hermès ou d’autres standards disponibles en ligne.

 

Abréviation

Titre complet

Commentaire

PMO

Project Management Office(r) ou Portfolio (of project) Management Office(r)

Hors Hermès

Responsable d’assurer le suivi du portfolio via des KPI (résultat) sur la base des bonnes pratiques mises en place (cœur du métier).

 

RSI

Répondant du Système d’Information

UNIL Selon la directive de Direction UNIL 6.10

RM

Responsable ou Référent métier

UNIL Selon la directive de Direction UNIL 6.10

MAN

Mandant

Rôle Hermès et projet sous d’autres noms type Sponsor

MAND

Mandant Délégué

UNIL spécifique

CPR ou CdP

Chef de projet

Rôle Hermès et marché

L’UNIL utilise l’abréviation CPR et le marché CdP.

RAP

Responsable applicatif

UNIL

CPO

Chef de Pôle

UNIL / marché

GQR

Gestionnaire de la qualité et des risques

Rôle Hermès

SCPR

Chef de sous-projet

Rôle Hermès et marché

AP

Assistance de projet

Rôle Hermès et marché

DEV

Développeur

Rôle Hermès et marché

PE

Prestataire externe

Rôle marché

QA

Analyste Qualité / Responsable de Test / Testeur

Rôle Hermès et marché

BA

Business Analyst ou Analyste métiers

Rôle Hermès et marché

TPO

Technical Product Owner

UNIL. Responsable technique pour les divers produits et/ou applications du Ci (Exploitant)

AQ

Analyste Qualité

Rôle marché

ARCHI-E

Architecte d’Entreprise assurant la cohérence du SI

Rôle marché

ARCHI-S

Architecte de solution assurant la cohérence de l’application

Rôle marché

MANG

Mandant du programme

Rôle Hermès et marché

CPG

Chef de programme

Rôle Hermès et marché

EP

Équipe de projet

Rôle marché

PAT

Personnel Administratif et Technique

UNIL

CISO

Chief Information Security Officer

UNIL et marché

CMO

Change management Office(r)

UNIL et marché

CM

Change Manager

UNIL et marché

EXP

Expert Métiers

UNIL et marché

DPO Data Protection Office(r) UNIL et marché
CTO  Chief Technical Officer Sur le marché, c'est le directeur informatique (technique), connaissant donc les besoins techniques informatiques (software et hardware)

 

 

RASCI Projet

Ce RASCI (Responsible, Accountable, Support, Consulted, Informed) se base sur les responsabilités des rôles décris par Hermès et les rôles internes de l’UNIL et sur le processus projet UNIL. Un RASCI est un RACI avec le rôle S en plus.

Cette matrice ci-dessous est une vue plus haut niveau complète, donc moins exhaustive et moins exacte, que la vue détaillée mise en place dans la MPRO UNIL. Les colonnes de pré-initialisation et de maintenances (en vert) ne sont pas dans le cycle de vie d’un projet Hermès.

Rôles du projet

Pre-Initialisation

Phases du projet

PLM / Maintenance

Initialisation

Conception

Réalisation

Déploiement

PMO

R

R (COMINI) & I (Reste)

I

I

I

R (RETEX), R (Missions) & I (Reste)

RSI

C

I

I

I

I

I

RM

 

R

C

I

I

 

MAN

I

A

A

A

A

R

CPR

S

R (Sauf COMINI)

R

R

R

C (RETEX)

RAP

C

C

C

I

I

C

CPO

A

I

I

I

I

I

GQR

I

A

A

A

A

 

SCPR

I

R

R

R

R

 

AP

 

S

S

S

S

 

DEV

 

I

I

R

R

 

PE

 

I

I

R

R

A

QA

 

S

C

R

C

 

BA

I

S

R

C

I

 

TPO

 

I

I

 

I

C/A

AQ

 

C

C

C

C

 

ARCHI-E

C

R

R

S

S

C

ARCHI-S

C

R

R

S

S

C

MANG

I

A

A

A

A

 

CPG

S

R

R

R

R

 

EP

I

R

C

R

R

 

PAT

S

S

S

S

S

I/C

CISO

I

C

C

I

C

 

CMO

I

C

C

I

I

 

CM

 

C

C

R

R

 

 

RASCI Programme

Ce RASCI (Responsible, Accountable, Support, Consulted, Informed) se base sur les responsabilités des rôles décris par Hermès et les rôles internes de l’UNIL et sur le processus programme UNIL.

 

Phases du programme

Rôles du projet

Pre-Initialisation

Initialisation

Exécution

Clôture

PMO

C

I

I

I

RSI

R

I

I

I

RM

 

R

I

I

MAN

I

A

A

A

CPR

S

R

R

R

RAP

C

C

I

I

CPO

A

I

I

I

GQR

I

A

A

A

SCPR

I

R

R

R

AP

 

S

S

S

DEV

 

I

R

R

PE

 

I

R

R

QA

 

S

R

C

BA

I

S

C

I

TPO

 

I

 

I

AQ

 

C

C

C

ARCHI-E

C

R

S

S

ARCHI-S

C

R

S

S

MANG

I

A

A

A

CPG

S

R

R

R

EP

I

R

R

R

PAT

S

S

S

S

CISO

I

C

I

C

CMO

 

C

I

I

CM

 

C

R

R

 

Présentation générale

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 :

 

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.

 

Présentation générale

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.

Liens de téléchargement

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.

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

Phase: Mise en oeuvre

 

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

Présentation générale

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.

Liens de téléchargement

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.

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

Présentation pour le COPIL

Ce livrable est un modèle de présentation de base 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

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)

​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

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

É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

Présentation pour le choix des variantes

Ce livrable est un modèle de présentation pour présenter le choix des variantes de l'étude conseillée par le Ci au comité de pilotage.

Référence HERMES 2022: N/A

Recommandation MPRO: facultatif mais fortement recommandé en cas de décision à prendre pour choisir une variante.

Règle de nommage: CODE_ABVPR_ChoixVariante_aaaammjj_Presentation.pptx

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

​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

Phase: Mise en oeuvre

 

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

Présentation générale

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.

Liens de téléchargement

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.

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 programmeListe de l'état des modifications du programmeListe des décisions relatives au programmeListe 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

Présentation pour le COPIL

Ce livrable est un modèle de présentation de base 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

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)

​​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

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

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

​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

Phase: Exécution

 

Phase: Clôture

​​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

FAQ

FAQ

Qu'est ce que la MPRO ?

La Méthodologie de Projets (MPRO) est la méthode choisie par le Centre Informatique (Division Solutions Métiers - DSM) pour conduire les projets métiers et techniques.

Cette méthode est basée sur la méthodologie de la Confédération Suisse : Hermes et a été adaptée aux besoins et pratiques de l'UNIL.

+ sur le déroulement d'un projet

Une documentation plus détaillée de la méthode est à disposition des Chefs de Projets.

FAQ

Comment se déroule un projet ?

Cycle de vie du projet

La méthode de gestion de projet HERMES utilise un modèle de phases qui permet une approche classique ou agile. Le modèle de phases proprement dit repose sur le cycle de vie du projet. Il crée les conditions requises pour que toutes les parties prenantes comprennent le déroulement du projet de la même manière. Les phases déterminent la structure du projet.

La figure ci-dessous montre le cycle de vie d'un projet HERMES.

image.png

Source : HERMES>Gestion du projet 2022>Comprendre>Phases

Objectifs principaux

Les projets se composent de 4 phases dont voici les objectifs principaux :

A chaque fin de phase, le COPIL se réunit pour valider :

  1. La clôture de la phase actuelle : l'ensemble des résultats développés durant la phase.
  2. La planification de la phase suivante : les résultats proposés et estimés par le COMOP.

Une phase peut contenir d'autres jalons décisionnels, par exemple pour la validation d'un POC, de l'achat d'une solution, ...

FAQ

Comment est défini le contenu (périmètre) du projet ?

Le périmètre du projet délimite ce qui est attendu de la solution et ce qui ne l'est pas.

La définition du périmètre est une activité primordiale qui s'affine tout au long du projet. Voici les grandes étapes :

Le périmètre du projet doit aborder toutes les "thématiques" (modules) ci-dessous :

Le périmètre peut amener à évoluer suite à une opportunité, une contrainte technique ou métier, un changement de stratégie, ... Les changements sont alors analysés par le COMOP (pertinence, faisabilité métier/technique, impacts coûts/délais). Selon l'impact, le changement est escaladé au COPIL pour être validé.

FAQ

Quels sont les principaux rôles associés à l'exécution d'un projet ?

Parmi les rôles qui participent à l'exécution du projet, voici les 4 principaux :

Référent Métier (RM)

C'est l'expert d'un domaine métier/service (RH, communication, ...). Il est également le représentant des autres membres de son domaine au niveau des connaissances, des besoins et des décisions.

A noter que le projet peut être transverse sur plusieurs domaines métiers avec chacun son RM.

Ci-dessous les principales tâches et le niveau d'implication attendu (faible, moyenne et forte) durant le déroulement du projet :

Spécialiste IT (développeur, intégrateur)

C'est l'expert d'un domaine ou système IT. Il est responsable du développement et de l'intégration de ce système. Il peut être interne ou externe (prestataire) à l'UNIL selon si le système est développé ou acheté.

A noter que la solution du projet peut-être constituée de plusieurs systèmes avec chacun son Spécialiste.

Ci-dessous les principales tâches et le niveau d'implication attendu (faible, moyenne et forte) durant le déroulement du projet :

Technical Product Owner (TPO)

C'est l'exploitant technique de la future solution. Il est le référent technique une fois la solution déployée. Il peut être également le Spécialiste IT si la solution est développée à l'UNIL.

Ci-dessous les principales tâches et le niveau d'implication attendu (faible, moyenne et forte) durant le déroulement du projet :

Chef de projet / Business Analyste (BA)

C'est le responsable de la conduite du projet et de l'atteinte des résultats et objectifs du projet. Il coordonne le COMOP et le représente aux séances de COPIL. En tant que business analyste, il fait le lien entre la partie métier et technique et participe au recueil et à l'analyse des besoins du projet.

Ci-dessous les principales tâches et le niveau d'implication attendu (faible, moyenne et forte) durant le déroulement du projet :

FAQ

Comment est organisé un projet ?

Il y a 3 types d'acteurs au sein d'un projet :

Le COPIL et le COMOP forment les organes décisionnels pour le pilotage et respectivement l'execution d'un projet :


FAQ

Quels sont les résultats du projet ?

Les résultats qu'un projet produit dépendent de son périmètre. Il existe 2 catégories de résultats :

Bien que le but d'un projet informatique soit la mise en oeuvre et le déploiement d'un système (produit) informatique, le projet couvre également d'autres aspects : migration, exploitation, organisations, ...

FAQ

Comment est planifié un projet ?

La planification du projet permet de coordonner les tâches, d'assurer la disponibilité des ressources et de prendre des décisions.

La planification repose sur l'estimation des tâches à réaliser et s'articule autour de 3 concepts :

  1. L'effort : le temps de réalisation d'une tâche (jour / personne)
  2. L'allocation : la disponibilité de la personne qui réalise la tâche (%)
  3. Le délai : l'échéance de la tâche

Une marge est souvent ajoutée à l'estimation. Elle dépend notamment de l'expérience de la personne et du degré d'inconnu de la tâche.

Le Chef de Projet suit et fait évoluer la planification régulièrement sur la base des informations fournies par le COMOP.

Le responsable d'une tâche (technique ou métier) doit communiquer au COMOP tous les risques ou problèmes identifiés afin de de limiter leurs impacts sur le planning.