1. Présentation générale Présentation générale de la méthodologie, et de ses principes de gouvernance. 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 : Une modification d’une solution informatique existante ; La mise en place d’une nouvelle solution informatique ; La réalisation d’une nouvelle offre 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 :  Figure 2 : extraite du PMBOK Figure 1-4. Organizational Project Management 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 Ci (PDCi) ; Le portfolio des demandes d’évolution du système d’information institutionnel de l’UNIL (SI UNIL) est piloté par le Ci 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 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 :   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. 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 : De la mandante ou du mandant, qui préside le comité ; De la cheffe ou du chef de projet, qui organise et anime la réunion ; De la référente ou du référent métier, qui représente la voix des utilisatrices et utilisateurs ; D’une référente ou d’un référent IT (ou architecte IT), qui représente la voix du Ci (note : et pas des développeurs, conflit d’intérêt entre besoin/exigence du métier et faisabilité/maîtrise technique). 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 : De la cheffe ou du chef de projet, qui préside le comité ; De la référente ou du référent métier ; D’une ou d’un responsable des développements ; D’une représentante ou d’un représentant 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 . 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. 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 : 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. 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 : 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. 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.