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.
- 1. Introduction à la MPRO
- 2. Organisation et rôles
- 3. Déroulement d'un projet
- 4. Après-projet (exploitation)
- 5. Implication du métier
- 6. Business Analyse
- 7. Quality et testing
- 8. Gestion du changement
- Annexe 1: Terminologie et acronymes
- Annexe 2: Intervenants UNIL dans les projets
- 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. 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.
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 :
-
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.
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
Le début du projet comprend toujours la phase d'initialisation (HERMES).
Le début du projet est 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.
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
Prendre en main les outils projet
- Marche à suivre Orchestra : https://wiki.unil.ch/ci/books/methodologie-projets-mpro/chapter/guide-orchestra
- Marche à suivre Teams : https://wiki.unil.ch/ci/books/methodologie-projets-mpro/chapter/guide-teams
-
Marche à suivre Zenhub : https://wiki.unil.ch/ci/books/methodologie-projets-mpro/chapter/guide-zenhub
É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 :
-
Les spécifications détaillées de la solution sont rédigées. Ces spécifications transcrivent dans un langage technico-fonctionnel les exigences métiers à l’aide de registres d’exigences, de maquettes graphiques, de modèles de données ou de modélisations de processus ;
-
La solution est implémentée sur la base des spécifications détaillées fournies aux développeurs. Différentes technologies sont utilisées à l’UNIL pour ces développements, dépendant principalement de l’écosystème et du domaine métier concerné ;
-
Des tests sont exécutés pour valider que la solution soit conforme aux spécifications, et par extension, qu’elle réponde aux exigences métiers. Il existe différents types de tests :
-
Les tests unitaires, généralement réalisés par les développeurs sur les fonctions spécifiques qu’ils ont implémentées ;
-
Les tests fonctionnels, réalisés par l’équipe projet (Test Manager, référent métier, pour valider le fonctionnement général de la solution ;
-
Les tests utilisateurs, réalisés par les utilisatrices et utilisateurs clés (lien à mettre à jour), voire par les utilisatrices et utilisateurs finaux, pour la prise en main et les dernières vérifications de l’utilisabilité de la solution.
-
-
Dans certains projets, une migration de données est aussi requise. Elle doit être documentée, planifiée, exécutée et testée au même titre que les développements de la solution ;
-
La solution est enfin mise en production (i.e. déploiement sur l’infrastructure de production), puis mise en service après sa réception par les représentant·es des métiers. L’accompagnement au changement et la formation des utilisatrices et utilisateurs finaux se déroulent généralement durant la période juste avant la mise en service.
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 :
- Les expériences acquises, systématiquement collectées et documentées en permanence sous forme de rétrospective du projet
- Le document « Évaluation finale du projet »
- La séance de COPIL de clôture du projet
- Le traitement du reste à faire
- La clôture administrative du projet
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 :
-
Planifier et suivre les délais, le budget, les risques, …. ;
-
Coordonner les travaux des parties prenantes du projet ;
-
Organiser et réaliser les séances des différents comités ;
-
Rédiger et faire valider les livrables ad hoc.
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
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 :
- 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
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.
6. Business Analyse
Cette page est en cours de préparation. Merci pour votre patience.
7. Quality et testing
Cette page est en cours de préparation. Merci pour votre patience.
8. Gestion du changement
Cette page est en cours de préparation. Merci pour votre patience.
Annexe 1: Terminologie et acronymes
Ce chapitre va rappeler les définitions du vocabulaire et des acronymes spécifiques à la gestion de projet et aux techniques informatiques (à partir de 0) mais aussi à certains termes spécifiques (-X) afin d’avoir un référentiel commun accessible à tous.
Dans le contexte de l'UNIL et du CI, ce référentiel supplante tout autre référentiel lexical.
Par exemple: la définition du terme "projet" ci-dessous supplante la définition d'un dictionnaire, pour ce terme, la définition doit être en accord avec la définition de la méthode HERMES.
Ce référentiel doit vivre et être mis à jour pour les besoins contextuels UNIL et marché.
La référence lexicale générale est le dictionnaire de la langue française, C'est le dictionnaire qui fait fois pour les définitions et les significations des termes,. Par exemple https://www.larousse.fr/ ou https://www.dictionnaire-academie.fr/
Note: En sociologie, la sémantique contextuelle est acceptée et étudiée selon son contexte. En français, les sémantiques officielles et contextuelles sont référencées dans le dictionnaire, par exemple le terme "char" ou le terme suisse "panosse", L'utilisation contextuelle d'une "définition sociale" hors du dictionnaire n'est pas conseillée.
La terminologie SAP standard est déjà documentée en ligne, pour des raisons d’efficacité, nous gardons ce lien comme référence : https://www.system-overload.org/sap/modules.html
Les acronymes des titres et rôles sont disponibles dans la page associée: Intervenants UNIL dans les projets
Réf. |
Acronyme |
Signification |
Définition |
-1 |
RESPECT |
Respect dans les comportements |
Le Larousse défini le respect comme suit : « Sentiment de considération envers quelqu'un, et qui porte à le traiter avec des égards particuliers ; manifestations de ces égards »
Nos sentiments sont basés sur notre système de croyance propre, nos valeurs, nos expériences, notre culture et bien d’autres parties cachées de notre personne. Ces parties sont toutes liées entre elles avec de grosses influences les unes sur les autres. La conséquence de ces paramètres est que le terme « respect » se retrouve galvaudé par tout un chacun.
Afin de pouvoir adresser cette problématique, nous allons nous pencher sur une définition plus sociologique du terme « respect » qui présentera cette définition : « Fondamentalement, il existe deux types de respect : le respect sans évaluation et le respect avec évaluation (Darwall, S. L. (1977). Deux sortes de respect. Éthique, 88 : 36–49). "L'idée que toutes les personnes devraient être traitées avec respect simplement parce qu'elles sont des personnes" est un respect sans évaluation. C'est du respect avec évaluation quand on respecte quelqu'un parce qu'il a une compétence particulière. »
Déjà cette définition posera une difficulté, car dans nos croyances, la notion de respect ne comprend pas cette acceptation d’une évaluation tierce. Pourtant, cette évaluation est naturelle.
Du coup, l’auteur de cette étude défini le respect comme un comportement :
Dans le cadre de l’UNIL, il signifiera pour chacun de savoir :
La notion « d’honnêteté » bloquera tout fonctionnement décris de manière « floue » comme « politique ».
|
0 |
HERMES |
Méthode HERMES |
Méthode de gestion de projet suisse. Cette méthode est une copie partielle de la méthode anglaise Prince2. Hermès est principalement utilisé dans les organisations étatiques Suisse. |
1 |
SDP, OTP ou WBS |
organigramme des tâches du projet ou Work Breakdown Structure |
En français, un WBS est la « Structure de répartition du travail ». C’est un organigramme des activités du projet trié par thèmes et/ou départements. La méthode Hermès définis plusieurs scénarios standards qui sont des WBS séquencés. |
2 |
Planning VS Schedule (EN) |
Plan(nification) VS Planning (FR) |
En Français, le « Planning » (organisation/emploi du temps) et le « Schedule » (calendrier/planning) sont le même mot : « planning ». Définitions françaises du mot Planning : · Organisation d'un plan de travail, emploi du temps, programme de travail. · Dans une entreprise, une administration, service chargé d'ordonnancer et de lancer un travail. · Tableau représentant la prévision d'emploi d'un ensemble de personnels ou de machines.
Les différences de signification : · Le « Planning », ou Plan(ning), répond aux questions « quoi ? » et « comment ? ». · Le « Schedule », ou Plan(nification), répond aux questions « qui ? » et « quand ? » |
3 |
KPI |
Key Process Indicator |
Un KPI, ou indicateur de processus clef, est une valeur définie permettant de mesurer une performance et de suivre son évolution dans le temps. Par exemple, l’agilité SCRUM utilisera les points poker assignés aux sujets du Sprint pour mesurer la performance d’une période de réalisation. |
4 |
ROI |
Return on Investment |
Le ROI, retour sur investissement en français, est la valeur attendue des résultats d’un projet. C’est une notion financière qui se veut être calculable. Définition de ROI d’une source Web : « La formule générale du retour sur investissement est : (gains – coûts de l’investissement) / coûts de l’investissement. Dans les faits, le ROI n’est pas toujours calculable directement car certains gains ne sont pas facilement mesurables. Certaines données détaillées ne sont pas (encore) récoltées voir non récoltables. Par exemple : · - Un gain de qualité du logiciel amenant moins de demandes de modification des utilisateurs ; · - Un gain de qualité avec du monitoring assurant une proactivité à maintenir les sites en ligne ; · - Une nouvelle interface graphique plus intuitive réduisant le nombre de demandes de support ; · - Une meilleur communication grâce à un alignement faisant gagner du temps lors des diverses séances ; · - Une page web qui charge plus vite ou une structure des données plus intuitive afin de conserver l’attention des utilisateurs ; - Ou simplement que la perception de différentes personnes permet de ne pas percevoir de ROI sur certains sujets comme la qualité. Ce ROI est défini par le demandeur dans la fiche DESI décrivant la demande de projet sous l’appellation « Valeur ajoutée ». Pour les cas non mesurables, il faut trouver un autre KPI afin de mesurer le gain ou la différence avant la livraison. |
5 |
CSF |
Critical Success Factors |
Les CSF, facteurs critiques de succès, sont les besoins « minimaux » attendu par le demandeur. Ils constituent le cahier des charges minimum. |
6 |
MVS |
Minimum Viable Solution |
Une solution minimale viable est la solution la plus simple (et la moins coûteuse) qui contient néanmoins tous les composants de base identifiés comme nécessaires et peut donc être pilotée efficacement. C’est l’appellation logicielle d’un MVP. |
7 |
MVP |
Minimum Viable Product |
Le MVP est le produit viable minimum. En termes de réalisation, cela signifie que les fonctions minimums à rendre le produit viable sont livrées. Cette notion est clef car elle permet une organisation itérative dans les projets et les maintenances. L’organisation itérative permet de livrer le plus rapidement possible une valeur ajoutée aux utilisateurs. Le MVP est très rarement un « produit final ». Le plus souvent, c’est le produit remplissant uniquement les CSF de la demande initiale ainsi que les contraintes annexes comme la sécurité. Pour donner un exemple plus concret et visuel, le MVP d’une voiture correspond à l’intégrations des pièces du châssis, des roues et du moteurs permettant aux véhicules de fonctionner techniquement selon la demande initiale. Pour autant, ce produit ne peut pas être commercialisé car il ne répond pas aux contraintes additionnelles comme les législations en place par exemple. Pour un logiciel informatique, le MVP serait le site et les fonctions métiers du site. Certaines fonctions de sécurité et d’intégration dans le Système d’information sont à ce stade encore manquant. Le MVP se différencie d’un PoC étant donné que sa réponse est pleine et entières vis-à-vis des critères minimaux de bon fonctionnement. |
8 |
DoR |
Definition of Ready |
Le DoR, définition de prêt (à réaliser), est une liste de vérification des besoins nécessaires à commencer une tâche. Cela assure de ne pas démarrer sans les conditions nécessaires à la réalisation d’une tâche ou activité. |
9 |
DoD |
Definition of Done |
Le DoD, définition de fait (ou réalisé), est une liste de vérification des CSF ou résultats attendus de l’activité. Cela permet d’assurer que l’activité a été réalisée sans oublier de détails importants à la qualité de la livraison. |
10 |
BDD |
Business Driven Development |
Le BDD, développement orienté métier, est un concept de développement informatique ou la réalisation se tourne vers la satisfaction des besoins du métier. L’approche Hermès assigne le métier au rôle de mandant afin d’assurer la satisfaction du métier ; Hermès est donc aligné avec le BDD. |
11 |
TDD |
Test Driven Development |
Le TDD, développement orienté tests, est un concept de développement informatique ou la réalisation se tourne vers la satisfaction des besoins de qualité du livrable en définissant non pas des spécifications métiers mais directement les cas de tests des résultats attendus. Le TDD est totalement compatible avec le BDD. Le TDD permet d’optimiser la charge administrative de la gestion de projet en orientant les spécifications vers la validation des livrables par des tests. Optimisation : Des spécifications métiers de grande qualité vont définir les attentes en incluant les informations de vérifications de ces attentes avec des cas de tests ou des DoD. |
12 |
DDD |
Domain-Driven Design |
Le DDD, conception pilotée ou orientée par le domaine en français, est une technique de conception de logiciel que l’on peut résumer à architecturer la solution afin de représenter le métier et ses processus plutôt que de coder les fonctions du métier dans un bloc. C’est une forme de modularité qui nécessite une architecture technique. |
13 |
QA |
Quality Assurance |
Le QA, assurance qualité, est une notion pour englober l’ensemble des efforts à faire pour assurer la qualité d’un produit ou d’un service : tests, DoD, monitoring ou tout autre mesure. Dans un projet Hermès, le QA se limite aux vérifications de qualité (QC) définis dans le projet, par exemple sur la base des CSF ou des attentes définies par des contraintes extérieures ou internes au projet, du point du vue d’un chef de projet. Un rôle de Gestionnaire de la qualité et des risques a la charge de la qualité transverse du projet. Pour avoir plus de détails, voir le concept de plan de qualité. |
14 |
Sprint |
|
Un Sprint est une unité de temps de réalisation qui se situe entre 1 et 4 semaines. Cette unité soutient la notion de réalisation itérative tout en permettant un contrôle régulier des niveaux d’avancement dans les tâches à faire. Les équipes de développement en interne utilisent des Sprints d’une valeur de 2 semaines. Le pôle projet en interne utilise des Sprints d’une valeur de 1 semaine. |
15 |
RAM (RASCI et RACI ou DACI) |
Responsibility Assignment Matrix |
Le RAM (Responsibility Assignment Matrix) est une matrice d’assignation des rôles et responsabilité de chacun Le RAM est le nom général. Les nom, RASCI et RACI, sont les noms issus des rôles assignés : Il est envisageable d’enrichir cette matrice avec d’autres rôles à préciser. La matrice DACI propose une autre organisation comparable mais moins « populaire/usité » : Pour la comparaison : · Driver = Responsible · Approver = Accountable · Contributor = Support & Consulted · Informed = Informed |
16 |
SPOC |
Single Point of Contact |
Le SPOC est le point d’entrée des communications et demandes selon le contexte. C’est l’entité à charge de trier, filtrer et rediriger les sujets aux bonnes personnes. Le PMO est le SPOC pour les demandes de nouveaux projets. |
17 |
PLM |
Product Lifecycle Management |
La gestion du cycle de vie d’un produit est un cycle en boucle fermé pour la gestion d’un produit. Il part de l’idée en passant par sa conception, sa réalisation, sa mise en service, son support et sa retraite (ou remplacement) qui retombe ensuite sur l’idée. Cette approche intègre la maintenance et le support nécessaire à l’exploitation de la solution à l’inverse du projet qui lui livre des informations à cette phase de maintenance sans être une partie prenante active au bon fonctionnement de cette phase cruciale qui correspond au début de la vérification du ROI du produit réalisé pendant le projet. |
18 |
UaT |
User at Test |
La notion d’UAT signifie qu’aucun produit ne peut être considéré comme validé tant que les utilisateurs finaux n’ont pas fait eux-mêmes les tests d’acceptation du produit et validé par eux même. Le rôle des testeurs est donc d’assurer la qualité du produit avant le passage du métier afin de garder des coûts de qualité maitrisés par l’entité. |
19 |
PBS |
Product Breakdown Structure |
En français un PBS est la « Structure de répartition (des fonctions) du produit ». C’est un organigramme des fonctions du produit trié par thèmes et/ou modules. C’est comparable à un WBS mais sur une vue du produit ou service. |
20 |
ITSM |
Information Technology Service Management |
L’ITSM, la gestion du service IT, représente les bonnes pratiques de gestion d’un département IT. La méthodologie ITIL décrit ces bonnes pratiques en s’orientant sur la maintenance, la qualité du service et l’intégration des projets. ISO-9001 :2015 propose une vue compatible incluant les projets. |
21 |
ITIL |
Information Technology Infrastructure Library |
ITIL est un ensemble de bonnes pratiques conçues pour aider une organisation à tirer une valeur optimale de l'informatique (projets, maintenances et opérations) en alignant les services informatiques sur la stratégie métier. |
22 |
DRP |
Disaster Recovery Plan |
Le DRP, ou plan de secours en français, est le plan de gestion mis en place en cas désastre. Ce plan peut posséder plusieurs scénarii comme la méthodologie HERMES. |
23 |
BCP |
Business Continuity Plan |
Le BCP, ou plan de continuité métier ou des opérations, est le plan de secours utilisé en cas d’évènements non planifiés impactant les services aux utilisateurs finaux. |
24 |
SWOT |
Strength, Weakness, Opportunity & Threat |
Le SWOT est une matrice d’analyse des risques classant les risques selon leurs impacts comme le nom de la méthode le donne : force, faiblesse, opportunités, menaces. |
25 |
MoSCoW |
La méthode de MoSCoW est une méthode de priorisation selon l’importance : · Must : doit être · Should: devrait être · Could: pourrait être · Would: ne sera pas |
|
26 |
KISS |
Keep, Improve, Start & Stop |
La méthode KISS permet de prioriser les sujets selon les critères : garder, améliorer, démarrer ou arrêter. La matrice KISS est très proche d’une matrice MoSCoW. |
27 |
KISS! |
Keep It Simple, Stupid! |
Le principe de KISS! Est de garder les choses assez simples pour : · Que tout le monde ait accès à l’information (documentation) · Que les sujets soient facilement maintenables (développement) o Eviter de produire de gros blocs logiciels ayant une sur-inflation de fonctionnalités qui pourraient être plusieurs solutions o Eviter de produire des solutions dont seul quelques élus pourront faire la maintenance |
28 |
CRUDE |
Create, Update & Delete |
Un CRUDE est un terme technique signifiant que des opérations sont faites sur les données en base de données. C’est un terme le plus souvent utilisé en BA ou en QA pour définir l’action à développer ou à tester. |
29 |
BDD ou DB |
Base de données ou Data Base en anglais |
Lieu de stockage des données dans un format technique utilisé par les applications. |
30 |
CMS |
Content Management System |
Un gestionnaire de contenu permet de pouvoir facilement créer, éditer, collaborer et publier du contenu digital. |
31 |
ERP |
Enterprise Resources Planning |
Un ERP est un applicatif qui permet de suivre et automatiser les processus de l’entreprise. Pour la gestion de projet, Orchestra est qualifiable d’ERP. |
32 |
Baseline |
Ligne de base |
Cette ligne est une représentation des contraintes initiales du projet (plan et planning) servant de référence afin de pouvoir adapter le pilotage du projet et de rester dans les plans tels que définis, tout en vérifiant que le projet reste dans les marges définies selon son avancement. |
33 |
RT(F)M |
Read The (Fucking) Manuel |
Initialement c’est une boutade de développeur, mais le terme se généralise facilement dans des équipes CI quand les sujets sont bien documentés. |
34 |
Kanban |
Tableau de suivi |
C’est une manière de suivre les activités d’un WBS ainsi que leur statut. Ces activités sont découpées selon leur niveau : · Epic : c’est le niveau le plus haut. Il peut contenir tous les types de cartes. Il est conseiller de ne pas y imbriquer trop d’autres Epics selon le principe KISS ! · User Story : C’est le niveau qui décrit les cas d’utilisations, cela correspond au diagramme UML « Use-Case ». Une user Story ne devrait contenir que des Features et des Tasks · Feature: C’est la fonction à réaliser, elle peut contenir des Tasks. · Task: C’est une action simple à réaliser comme par exemple préparer une base de données. |
35 |
Backlog |
Liste des tâches |
Une liste ordonnée et hiérarchisée des caractéristiques du produit souhaitées par le client et les missions à réaliser par l’équipe. |
36 |
Burn Up/Down chart(s) |
Diagrammes de consommation |
Ce sont 2 représentations de la charge de travail : |
37 |
Release |
Version |
Une Release est une nouvelle version du logiciel apportant ses corrections, modifications ou améliorations. |
38 |
SIPD |
Sûreté de l'information et protection des données |
Ce concept vient de la méthodologie Hermès. Il reprend les notions de DRP voir BCP (CISO UNIL) tout en y intégrant les notions de sécurité. Cette approche groupée reste difficile à appréhendez pour les novices en matières d’ITSM. |
39 |
Agile |
Méthode agile
|
L’agilité est une approche d’organisation d’une équipe de développement centrée sur l'humain et la communication. Ce qui signifie que cette méthodologie possède une dépendance clef à l’application de ses valeurs. Beaucoup des pères fondateurs ont renié le manifeste agile du fait des travers liés aux manques d’applications des valeurs dans les entités. |
40 |
Pjt |
Projet |
Un projet est une entreprise temporaire initiée dans le but de fournir un produit, un service ou un résultat unique, selon PMI. Sur deux projets similaires en tout, le 2e est un processus. Dans le cas de différences, le 2e est une variante donc un projet. Les scénario Hermès sont des tentatives de conversion de projet « similaires » en processus. Or selon les caractérisations Hermès actuelles, ou les définitions internes, ces scénarios sont au mieux des optimisations pour la gestion de projet. Une optimisation efficace marché est de transformer l’ITSM afin d’avoir les processus nécessaires pour la partie « Run », et de la compléter des cas d’usages de « Build ». Le traitement de la demande suit un processus, la réalisation de la demande elle suit un mode de gestion de projet adapté (Scénario Mission par exemple). |
41 |
Pcs |
Processus |
Un processus est une activité répétitive qui est documentée et facile à reproduite et enseigner. Un processus doit pouvoir faire référence au terme « RTFM ». |
42 |
QC |
Quality Control |
Le contrôle qualité est la partie réalisation du QA. Il est donc théoriquement impossible de faire un QC « de qualité » sans avoir fait un QA. Le concept de test générique est un QA pour un scénario du type « de développement IT » dans Hermès. |
43 |
MTBF |
Mean Time Between Failure |
« MTBF est le temps écoulé prévu entre les pannes inhérentes d'un système mécanique ou électronique pendant le fonctionnement normal du système. Le MTBF peut être calculé comme la moyenne arithmétique (moyenne) du temps entre les pannes d'un système. Le terme est utilisé pour les systèmes réparables, tandis que le temps moyen jusqu'à panne (MTTF) désigne le temps prévu jusqu'à panne pour un système non réparable. » (Source Wiki) |
44 |
MTTR (1) |
Mean Time To Recovery Repair |
« Le temps moyen de réparation (MTTR (1)) est une mesure de base de la maintenabilité des éléments réparables. Il représente le temps moyen nécessaire pour réparer un composant ou un appareil défaillant. » (Source Wiki) |
45 |
MTTR (2) |
Mean Time To Recovery |
« Le temps moyen de récupération (MTTR (2)) est le temps moyen qu'il faudra à un appareil » ou service « pour se remettre d'une panne. Les exemples de tels dispositifs vont des fusibles à réarmement automatique (dont le MTTR serait très court, probablement quelques secondes), à des systèmes entiers qui doivent être réparés ou remplacés. » comme des applications informatiques (Source Wiki) |
46 |
6 s |
Six Sigma |
« 6 Sigma est une marque déposée de Motorola désignant une méthode structurée de management visant à une amélioration de la qualité et de l'efficacité des processus » (Source Wiki) |
47 |
DPRO |
Directive Projet |
La DPRO est pilotée par la PMO et formalisée à l’aide des directives CI-UNIL. La DPRO formalise l’utilisation d’Hermès comme méthode de projet. |
48 |
MPRO |
Méthode projet |
La MPRO est pilotée par l’équipe DSM-PRO, dans le respect de la DPRO, avec comme objectifs principaux d’augmenter la qualité dans la gestion de projet et de réduire les investissements temporels des chefs de projets dans des tâches répétitives par la mise en place et utilisation de standards de gestion communs. Hermès utilise la notion de scénarii pour trier ces standardisations pour les projets. La MPRO peut aussi être améliorer par le biais de standards plus orientés pour les besoins de l’organisation permanente ; par exemple la manière de mettre en place ou de communiquer avec les outils des projets. |
49 |
PoC ou POC |
Proof of Concept |
Le PoC, « preuve de concept » traduit, ou en français un « prototype », est la maquette permettant de vérifier la viabilité d’une demande. Cette notion permet de découvrir les difficultés, possibilités ou limitations techniques liées à une idée. En informatique, la maquette réalisée sera peu fonctionnelle mais permettra aux équipes de valider la capacité de réalisation et le rendu final à moindre coût que le projet partiel voir entier. |
50 |
EPT, ETP ou FTE |
Equivalent Temps Plein ou Full Time Equivalent |
Cette notion correspond à une charge de travail à 100% selon les normes contractuelles du Fort défini. Pour l’UNIL c’est le Canton de Vaud avec 42h par semaine comme ETP. |
51 |
BPM(N) |
Business Process Model (and Notation) |
C'est-à-dire « modèle de procédé d'affaire et notation », est une méthode de modélisation de processus d'affaires pour décrire les chaînes de valeur et les activités métier d'une organisation sous forme d'une représentation graphique |
52 |
PM |
Project Management |
Management de Projet |
53 |
PV |
Procès-Verbal |
Le compte rendu officiel de la séance est appelé PV. |
54 |
SI ou IS |
Système d’information ou Information System |
Cette notion défini l’ensemble des produits et services nécessaires à la gestion des informations. De nos jours, cela représente la liste des biens et services gérer et fourni par le CI à ses utilisateurs. |
55 |
URL |
Uniform Resource Locator |
Adresse Web (ex. https://www.unil.ch) |
56 |
N/A |
Not Applicable |
Cette notion est utilisée dans la documentation pour qualifier l’inutilité d’un sujet. |
57 |
O(S)FA |
One (Size) Fits All |
C’est une notion d’industrialisation disant qu’un seul produit ou service peut répondre aux besoins de tous. |
58 |
DMS ou GED |
Document Management System ou Gestion Electronique de Document |
Un DMS, ou une GED, est un système informatique proposant un ensemble de fonctions liées à la gestion des documents. De manières non exhaustive, les principales fonctions sont : · Gestion des versions · Processus de validation d’un document · Processus de publication d’un document |
59 |
IHM |
Interface Homme (ou Humain) Machine |
L’IHM est l’ensemble des composant visuels ou autre qui permettent l’interaction entre l’utilisateur et la machine (PC) |
60 |
PC |
Personal computer |
En français, c’est un ordinateur. |
61 |
OS |
Operating System |
L’OS est l’ensemble des composants logiciels permettant l’interaction avec l’ordinateur. Les OS connus sont : Windows, MacOS, Android |
62 |
PjtS |
Projet (simple) |
Voir la définition d’un projet (Ref 40) pour le côté général.
Un projet simple est un projet dont les liens entre les activités / tâches est de nature simple :
|
63 |
PjtC |
Projet (Complexe) |
Voir la définition d’un projet (Ref 40) pour le côté général et d’un projet simple (Ref 62) pour les cas simples.
Un projet complexe est un projet dont les liens entre les activités est de nature complexe :
Dans le cas où ces liens fort n'existent que de manière sporadique, nous parlons d’un projet simple. |
64 |
Pg |
Programme (pour les projets) |
Un programme est un groupe de projets connexes gérés de manière coordonnée pour obtenir des bénéfices que leur gestion individuelle n'apporterait pas, selon PMI. Voir la définition d’un projet (Ref 40) pour le côté général. |
65 |
PgS |
Programme (simple) |
Voir la définition d’un programme (Ref 64) pour le côté général et d’un projet simple (Ref 62) pour les cas simples. La définition du programme simple est celle d’un projet simple où le mot « activités / tâches » pour le projet devient « sous-projet » pour le programme.
Un programme simple est un projet dont les liens entre les sous-projets est de nature simple : · Fin-début · Début-début · Fin-Fin · Début-fin |
66 |
PgC |
Programme (Complexe) |
Voir la définition d’un programme (Ref 64) pour le côté général et d’un programme simple (Ref 63) pour les cas simples. La définition du programme complexe est celle d’un projet complexe où le mot « activités / tâches » pour le projet devient « sous-projet » pour le programme.
Un programme complexe est un projet dont les liens entre les sous-projets est de nature complexe : · Dépendances nécessaires entre les sous-projets en cours de réalisation · Ces dépendances peuvent être entre des de nature simple entre les activités / tâches des sous-projets Ces dépendances peuvent être matérialisées avec des dépendances entre des releases des sous-projets par exemple. |
67 |
PDS |
Point De Situation |
C’est une séance pour faire l’état de l’art, entre plusieurs acteurs, de l’évolution d’une situation |
68 |
SAP ACTIVATE |
|
C’est la méthodologie de projet de SAP |
69 |
BP (SAP) |
Business Partner |
C’est une notion de base de SAP. Toutes les actions SAP sont liées à des BP qui endossent un rôle dans les processus financiers. |
69 bis |
BP (générique) |
Best Practice |
L’ensemble des expériences faites et documentées au format d’un processus. Dans SAP, c’est implémenté au travers d’un scope item. |
70 |
HANA |
High performance ANalytic Applicance |
Une « Appliance » de SAP, une combinaison hardware et software, optimisée pour tirer parti des technologies les plus récentes en matière de processeurs multicœurs et de mémoire vive. |
71 |
ECC |
ERP Central Component |
Version de SAP actuelle basée sur le système SAP R/3. |
72 |
PSM-FM |
Public Sector Management - Funds Management |
Module SAP de gestion des processus budgétaires et de l’exécution budgétaire dans S/4HANA faisant partie de l’industrie secteur public. |
73 |
PS |
Project System |
Module SAP concernant la gestion des projets dans SAP ; il permet d'effectuer les actions fonctionnelles suivantes : Structuration des projets. Suivi de coûts et budgets. Planning et calendrier. |
74 |
EC-PCA |
Entreprise Controlling - Profit Center Accounting |
Module SAP de la Comptabilité des Centres de Profits. |
75 |
HCM |
Human Capital Management |
Module et ensemble de solution SAP couvrant les processus HR dans les solutions ECC et S/4 comme l’administration HR, le traitement des salaires, la gestion des temps et absences, etc.
|
76 |
LoB |
Line of Business |
Regroupement de fonctionnalités proposé par SAP dans S/4HANA afin de couvrir une famille de processus ou un domaine d’entreprise.
|
77 |
SAC |
SAP Analytics Cloud |
Solution cloud proposée par SAP pour gérer les processus de planification budgétaire et le reporting
|
78 |
WRICEF |
Workflow Reporting Interface Conversion Enhancement Form |
Correspond à la typologie du développement envisagé dans un domaine : - Workflow (processus et étapes d’acceptation, validation) - Reporting (tous éléments de restitution) - Interface (scénario d’intégration avec d’autres applicatifs comme SYLVIA p.ex.) - Conversion (tout programme effectuer dans le cadre des reprises de données) - Enhancement (programme couvrant une fonctionnalité particulière non standard) - Form (formulaire, ou tout document/correspondance devant être généré et imprimé depuis SAP
|
79 |
SCI |
Système de Contrôle Interne |
|
80 |
SAP |
Systems, Applications and Products |
Par abus de langage le nom utilisé pour désigner un progiciel de gestion intégré développé et commercialisé par l'éditeur de ce produit (SAP AG) |
81 |
LPD |
Loi sur la protection des données |
Loi Suisse |
82 |
nLPD |
Nouvelle Loi sur la protection des données |
Mise à jour de la Loi Suisse |
83 |
CCP |
Comité de coordination des projets |
Organisation de projet |
84 |
Ci |
Centre Informatique UNIL |
Organisation Permanente |
85 |
DESI |
Demande d’Evolution du Système d’Information |
Document initial pour la demande de création du projet |
86 |
DEV-INT |
Pôle Développement et Intégration |
|
87 |
DSM |
Division des développements des Solutions Métiers |
|
88 |
FRAT |
Fiche de Registre des Activités de Traitement |
|
89 |
MPRO |
Méthodologie Projets |
Organisation de projet |
90 |
OJ |
Ordre du Jour |
|
91 |
PAT |
Personnel Administratif & Technique |
Le personnel UNIL qui ne fait pas parti du corps enseignant |
92 |
PPRO |
Pôle Projets |
|
93 |
RGPD |
Règlement Général sur la Protection des Données |
|
94 |
SI ACAD |
Système d’Information Académique |
|
95 |
SI UNIL |
Système d’information de l’UNIL |
|
96 |
TransNum |
Initiative Transition numérique |
|
97 |
UNIL |
Université de Lausanne |
|
98 |
DCSR |
Division calcul et soutien à la recherche |
|
99 |
RDP |
Revue de projets |
|
100 |
PDI |
Plan directeur informatique |
|
101 |
SDM |
Schéma directeur métier |
|
102 |
RGE |
Règlement Général des études |
|
103 |
SLCM |
Student Life Cycle Management |
|
104 |
BaS ou SBX |
Bac à Sable ou SandBoX |
C'est un environnement technique de notre plateforme SAP qui tient principalement un rôle d'un environnement de post-production pour des raisons de sécurité, mais au besoin, il peut tenir un rôle de pré-production pour tester les paquets de release à déployer ou de test de dev pour régler des conflits de version des composants SAP |
105 |
SPO |
|
C'est une procédure de gestion des versions de SAP qui inclus une analyse d'impacts et d'autres standards de qualité. |
106 |
Grooming |
|
|
107 |
Sprint Planning |
|
Séance de planning pour les activités qui seront réalisées pendant la durée du Sprint |
108 |
Sprint Review |
|
Séance de revue des activités réellement réalisées pendant la durée du Sprint |
109 |
(Daily) SuM |
(Daily) Stand-up Meeting |
Séance de suivi (quotidienne), de la méthode Agile SCRUM, qui selon la méthodologie se passe debout afin de forcer les participants à aller à l'essentiel. le plus vite possible |
110 |
Sprint Retrospective |
|
Séance d'analyse afin de pouvoir tirer les expériences sur la période de temps écoulée, cette séance liste le bon, le moins bon et les actions d'amélioration à mettre en place |
111 |
Backlog Review / Refinement |
|
C'est une activité, qui peut se faire dans une séance, de revue et priorisation des sujets ouverts du Backlog. |
112 |
DoS |
Definition of Small |
La définition de petit est une notion qui adapte le périmètre de l'activité à la période de temps allouée pour sa réalisation, ou Sprint. |
113 |
Agile SCRUM |
|
C'est l'une des méthodologies Lean, elle est adaptée à la gestion d'une équipe de développement pour un backlog |
114 |
Agile SAFe |
Scaled Agile Framework |
C'est l'une des méthodologies Lean, elle est adaptée à la gestion d'un portefeuille de projet |
115 |
Lean |
|
Lean est l'une des méthodologies de gestion, notamment pour les projets. C'est la méthodologie mère des différentes méthodologie Agiles. |
116 |
IceBox |
|
"la boite à glaçon", c'est un terme anglais américain signifiant "en attente". C'est la seule exception de traduction qui sera traité dans cette liste. |
117 |
HPC |
High Performance Computing |
Le calcul haute performance (HPC) permet de traiter les données et d'effectuer des calculs complexes à des vitesses élevées. |
118 |
Dev Full-stack |
|
"Un développeur Full Stack est quelqu'un de familier avec toute la stack technique et qui a les compétences pour faciliter le travail de ses collaborateurs". Cela signifie réellement que le développeur connait les technologies avec lesquels il travaille et ne représente pas une surcharge pour ses collaborateurs techniques. |
119 |
SRE |
Site Reliability Engineering |
La SRE est la mise en œuvre pratique de DevOps |
120 |
DevOps |
Development & Operations |
"DevOps repose sur une culture de la collaboration entre développeurs et équipes opérationnelles, qui partagent les responsabilités et combinent le travail. Il améliore l'efficacité des équipes et permet d'accélérer les transferts de tâches et la création de code conçu pour un environnement d'exécution spécifique." |
121 |
|
Cette matrice est similaire aux méthodes MoSCoW & KISS, elle sert à la priorisation des activités selon des critères d'urgence et d'importance:
Ce qui nous donne la matrice de 2 par 2 suivante:
|
|
122 |
ABCDE |
Cette méthode est similaire aux méthodes MoSCoW, KISS et à la matrice d’Eisenhower, les tâches sont triées sur la base de paramètre d'importance, optionnalités, délégation et élimination:
La délégation est un art comme d'autres sujet, il ne sera pas aborder dans cette liste.
Pour bien appliquer cette méthode, veillez à avoir relativement peu de tâches dans les catégories A et B en comparaison des catégories C, D et E. |
|
123 |
RICE |
Cette méthode est similaire aux autres mais sur la base des paramètres Reach, Impact, Confidence et Effort.
Le Score est alors calculé: (Reach x Impact x Confidence) / Effort |
|
124 |
Kano |
Kano Model |
Ce modèle porte le nom de son créateur Noriaki Kano. Ce modèle va permettre de trier les qualités des fonctionnalités (attractivité, proportionnalité et nécessité) sur 2 axes (satisfaction et présence de la fonction). Afin de comprendre le modèle, il faut clarifier les définitions:
Un tel modèle se comprends mieux dans sa représentation graphique: Et se prépare sur la base d'une liste de fonctions trié dans une matrice: Les autres méthodes sont plus faciles à l'utilisation. |
125 |
Priorisation |
Priorisation (des tâches) |
L'action "d'Accorder une importance préférentielle à quelque chose ou à quelqu'un". Il existe plusieurs moyen d'effectuer cette action. Cette liste référence des méthodes préférées de par leur aspects tangibles. Ce référencement est non exhaustif, une recherche google vous permettra d'en trouver d'autres.
Les méthodes peuvent être adaptée ou combinée selon le besoin. Dans le cas d'un projet nécessitant une priorisation spécifique ou retravaillé depuis les méthodes, merci de vous référer au chef de projet qui lui même se réfèrera au PMO en cas de besoin.
|
126 |
BaU |
"Business as Usual" |
Signifie que l'activité est vue comme régulière et une tâche quotidienne qui ne nécessite plus de suivie spécifique comme au travers d'une gestion de projet par exemple. |
127 |
SLA |
Service Level Agreement |
Le SLA est le niveau de service offert au client pour la gestion des incidents pouvant impacter le fonctionnement du service. Il fournit une partie des réponses contenues dans les plans BCP et DRP. |
128 |
GTI |
Garantie de Temps d’Intervention |
C'est le temps de prise en compte de l'incident |
129 |
GTR |
Garantie de Temps de Rétablissement |
C'est le temps nécessaire à la résolution de l'incident pour un retour au service normal |
130 |
PDMA |
Perte de Données Maximale Admissible |
C'est en générale l'ensemble des données perdu depuis le dernier back-up. |
131 |
RPO |
Recovery Point Objective |
C'est un point de mesure calculé du nombre de données perdu sur la période précédent l'incident |
132 |
RTO |
Recovery time objective |
C'est le terme anglais pour le GTR. |
133 |
PMI |
Project Management Institute |
c'est une entité spécialisé dans la gestion de projet qui propose divers certification et le PMBoK |
134 |
PMP |
Project Management Professional |
c'est l'une des certification de PMI |
135 |
PMBoK |
Project Management Body of Knowledge |
c'est le livre des connaissances de gestion de projet proposé par PMI |
136 |
BABoK |
Business Analysis Body of Knowledge |
c'est le livre des connaissances d'analyse métier proposé par IIBA |
137 |
IIBA |
International Institue of Business Analysis |
c'est une entité spécialisé dans la gestion de projet qui propose divers certification et le BABoK |
138 |
WIP |
Work in Progress |
Travail en cours dans une colonne d'un board Kanban |
139 |
SMART |
Specific, Measurable, Achievable, Realistic, Time-bound |
La méthode SMART consiste à identifier des objectifs quantitatifs et/ou qualitatifs sur une période définie.
|
140 |
CAPM |
Certified Associate in Project Management |
c'est l'une des certification de PMI |
141 |
FYI |
For Your Information |
Pour votre information |
142 |
FA |
For Action |
Pour action |
143 |
Esprit d'équipe |
cohésion de groupe |
C'est ce qui permet le proverbe "Teamwork is Dreamwork" signifiant "le travail en équipe est un travail de rêve". Avant tout, c'est un ensemble de savoir-être et de savoir-faire qui permettent d'instaurer la confiance, incluant le savoir gérer les différences et les crises. Par exemple, voici les 10 conseils pour instaurer un bon esprit d'équipe. |
144 |
DESC |
Décrire, Exprimer ses émotions, Spécifier des solutions, conséquences et Conclusion |
La méthode DESC est un outil pour la réalisation des rétrospectives dans un esprit d'équipe, mais aussi pour la gestion des conflits. La page peut référencer d'autres méthodes pour les gestions de conflits. |
145 |
|
Portefeuille (de projets) |
Un portefeuille est défini comme un ensemble de projets, programmes, portefeuilles subsidiaires et opérations gérés en tant que groupe dans le but d’atteindre des objectifs stratégiques, selon PMI. Voici une figure qui schématise ces liens: |
146 |
CVE |
Common Vulnerabilities and Exposures |
Accompagné d’un chiffre et d’une année, il permet aux chercheurs et entreprises de retrouver cette vulnérabilité partout. C’est une référence unique, heureusement internationale. Il est collecté et documenté par le DHS/CISA/MITRE (américain). Ex. CVE-2024-12797, vulnérabilité sur OpenSSL déclarée en 2024. |
147 |
CVSS |
Common Vulnerability Scoring System |
Est un système de notation d’un(e) CVE de 0 à 10. Il est évalué en fonction de plusieurs critères (voir ci-dessous). Attention, il existe plusieurs versions de cette métrique (v2, v3.1 …). Il se base sur plusieurs critères : exemple pour une CVE OpenSSL de ci-dessus : AV (Attack Vector) => Où se trouve la faille ? (N = Réseau, L = Local, etc.). AC (Attack Complexity) => Est-ce facile à exploiter ? (L = Facile, H = Difficile). PR (Privileges Required) => Faut-il être authentifié ? (N = Non, L = Oui, etc.). UI (User Interaction) => L'utilisateur doit-il faire une action ? (N = Non, R = Oui). S (Scope) => Impact limité au système ou propagation possible ? (U ou C). C, I, A => Impact sur Confidentialité, Intégrité, Disponibilité (None, Low, High). Vous avez donc la liste des vulnérabilités, et vous pouvez connaître l’impact est Low/Medium/High Les trois derniers points C I A : évaluent l’impact sur la Confidentialité, l’Intégrité et la Disponibilité. Avec tout cela vous obtenez une note. Cependant, après avoir cette information, nous devons évaluer dans quelle mesure nous sommes impactés ! Nous pouvons également déterminer les efforts à mettre en place pour patcher ou mitiguer la vulnérabilité. |
148 |
VPR |
Vulnerabilty Priority Rating |
Certaines de sociétés de sécurité proposent une « pondération » de la note CVSS en fonction du risque réel, de 0 à 10. Il est possible que la vulnérabilité soit très importante, mais qu’elle soit très difficile à exploiter. Ou qu’elle est inexploitable chez nous, dans notre contexte ! Avec le service payant de Tenable-Nessus, nous pouvons éviter de patcher systématiquement tout, ce qui présente une vulnérabilité n’est peut-être pas si « grave » que cela ! Actuellement le SOC se base plutôt sur cette note, que la CVSS, pour demander aux administrateurs de patcher leurs serveurs. |
149 |
Scoring (sécurité IT) |
Scoring (non standard…) de 0 à100 |
Il existe de nombreuses évaluations plus globales (Microsoft, SecuritscoreCard, Saporo…) qui indiquent une valeur en %. Ces valeurs sont propre à chacun de ces fournisseurs et ne sont pas comparable au standard CVE/CVSS. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 |
|
RM |
Responsable ou Référent métier |
|
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 |
|
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 |
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 :
Les règles de ces fonctions sont décrites ci-après :
|
|
Microsoft Outlook |
Deux fonctions principales :
|
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 :
|
|
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 |
|
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. |
|
Wiki de l’UNIL | Contient les différentes documentations internes de l’UNIL comme des procédures RH, maintenance informatique, contacts, et autres. |
|
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. |
|
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.
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.
Phase: Initialisation
Mandat d’exécution de la mission
Le mandat d’exécution de la mission constitue la base formelle pour la libération de la mission. Il représente la convention 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. Elle présente un résumé des expériences liées à la mission. Elle définit également le contenu et les délais pour le contrôle de la réussite de la mission.
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
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.
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
Plan de gestion du projet
L’élaboration initiale du plan de gestion du projet est marquée le choix de la variante et de la procédure fait dans la phase d’initialisation. En particulier le choix de la procédure, qu’elle soit classique ou agile, influence 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 règles concernant les méthodes, les techniques, les rôles et les utilitaires qui doivent être définies de manière spécifique pour le projet. Il sert de base d’action unique pour tous les participants au projet. Dans le cadre de l’organisation du projet, il fait en sorte 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 assez 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 mise au point 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 en vue de l’exécution 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 sommaires sur la base de l’état des lieux, en énumérant les variantes de solution 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 y choisit le scénario approprié, 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 des opérations peut être prise. La procédure rigoureuse s’applique en particulier à l’état des lieux, afin de ne pas prolonger inutilement la phase d’initialisation. La décision relative à la suite des opérations 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
Mandat d’exécution
Le mandat d’exécution sert de cadre et de base contraignante pour la mise au point 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’appréciation 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
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.
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 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 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
Mandat de travail du programme
Le mandat de travail du programme contient toutes les informations pertinentes pour l’exécution d’une tâche. Avec ce document, le chef de programme confie les travaux aux collaborateurs du programme. L’avancement du programme est contrôlé sur la base des mandats de travail et du degré de mise au point des résultats. Les mandats de travail peuvent être confiés à l’interne ou à l’externe. Un mandat de travail du programme est attribué pour chaque tâche ou pour un ensemble de tâches.
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 cette phase.
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 du programme décrit les bases légales en vigueur pour le résultat du programme ainsi que l’éventuelle nécessité de les modifier.
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 du programme sert de cadre et de base contraignante pour la mise au point 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 regroupe les évaluations finales des projets et les complète avec les thèmes de la conduite et du pilotage du programme. Elle fournit au mandant une comparaison entre les valeurs planifiées et les valeurs effectives concernant les objectifs en termes de contenus, de délais et de coûts du programme et de la procédure. Elle résume les expériences liées au programme. Elle détermine le contenu et les délais concernant le 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