Méthodologie Projets (MPRO)

La démarche Projets a été mise en place par le Centre informatique en 2016 sous la responsabilité du PMO (Project management office).

La Méthodologie Projets (MPRO) est appliquée dans le cadre des projets soumis au <COPRO>, développée par la Division des Solutions Métiers (DSM), basée sur HERMES, et en place depuis octobre 2018.

Bienvenue dans un projet du CI

Cette documentation est adressée à toute personne impliquée dans un projet IT du Centre Informatique (DSM) : membres du CI, métiers, externes, ... Elle a pour objectif de fournir les informations nécessaires et suffisantes en fonction de son implication au projet :

Bienvenue dans un projet du CI

Standards des projets du Ci

Afin d’assurer une bonne stratégie de communication, et l’alignement des parties prenantes à cette stratégie de communication, la réalisation d’une documentation autour des standards de communication dans les projets est nécessaire.

De plus, ces informations étant communes à tous les projets, il a été défini qu’une documentation générale serait plus optimale que d’autres solutions.

Cela permettra un alignement de tous les acteurs en présence sur les termes de gestion de projets et d’informatiques réusités ainsi que pour les séances types dans les projets.

 

Qu’est-ce qu’un projet ?

Wikipedia: « ensemble de tâches interdépendantes à exécuter sur une période déterminée et dans les limites d'un certain coût, qualité et d'autres limitations. »

La gestion de projet a pour objectif de réaliser le projet en respectant le principe « le triangle d’or » (Coûts, Qualité, Délais).

A l’UNIL, les projets sont définis comme :

Un « projet » est un ensemble unique d'activités menées sur une période temporaire qui fournissent un produit, un service ou un résultat unique qui soutiendra la stratégie de l'entreprise.

Un « projet » peut être un projet, un programme (un ensemble de projets interdépendants) ou un portefeuille de projet (un ensemble de projets ou programmes pouvant être interdépendants)

 

Un projet s’oppose à un processus par nature.

Wikipedia: « Un processus est une série ou un ensemble d’activités qui interagissent pour produire un résultat ; elle peut survenir une seule fois ou être récurrente ou périodique. »

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. Certaines méthodologies de gestion de projet essayent d’optimiser la gestion de projet par le biais de processus ou scénario de gestion comme le fait la méthodologie HERMES choisie à l’UNIL.

 

A quoi servent les projets ?

Les projets servent à accompagner et soutenir les changements effectués dans l’institution :


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

 

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

 

Afin d’assurer la bonne réalisation de ces changements ainsi que le bon usage de ces modifications, voici la nature organisationnelle mise en place :


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

 

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

 

 

Canaux & Moyens de communication

Les canaux et moyens de communication sont divisés en 3 types :

·         Push : ou « poussé » en français, les informations mises à disposition des utilisateurs comme un courrier.

·         Pull : ou « tiré » en français, les informations que les utilisateurs doivent aller consulter sans en avoir été notifiés, comme un site Web.

·         Interactif : les informations mises à disposition des utilisateurs lors d’un échange comme une réunion

La nature, l’impact et les besoins de récepteur de la communication définiront ensemble le type de communication approprié. Ces spécificités seront traitées, le cas échéant, dans le plan de communication du projet.

Note : Dans le cas des communications interactives, il est fortement conseillé de bien faire un accusé de réception du message discuté car nous avons tous des filtres propres à notre expérience de vie qui sont représentés sur ce diagramme par le « Noise » ou « bruit » dans la communication.

Ce quittancement peut être fait en rephrasant l’interlocuteur à l’instant T, ou en demandant un retour sur le PV de séance, ou d’autres méthodes afin d’assurer que nos filtres respectifs n’entrent pas en conflit créant 2 perceptions différentes.

 

De plus les communications se divisent aussi en 3 niveaux comme indiqué sur la pyramide.

La vision « simplifiée » de ces niveaux pour la gestion de projet est la suivante :

·         Stratégique : COPRO

·         Tactique : COPIL

·         Opérationnel : COMOP

 

 

 

 

 

Les Rapports

Les rapports sont communiqués en « push mode », « mode poussé », afin d’assurer que l’information a bien été transmise.

Note : Par défaut, ces rapports, avec les organisations décrites dans ce document, ne nécessitent pas cet effort. Le « pull mode », « mode tiré/consulté », devrait suffire.

Résultat

Type

Fréquence

Responsable

Destinataire

Délai

Rapport d’état du projet ou Newsletter (hors Flash report dans Orchestra)

Courriel avec du contenue ou une pièce jointe

Entre Hebdomadaire à Mensuelle

Chef de projet

Mandant

Premier jour ouvrable du mois

Rapport de phase (Conception)

Courriel ou COPIL

Fin de la phase conception

Chef de projet

Mandant

Voir planification

Procès-Verbal de Tests

Courriel avec la pièce jointe ou COPIL/COMOP

Fin des Tests

QA

Chef de projet & exploitation

Voir planification

Rapport de phase (Réalisation)

Courriel ou COPIL

Fin de la phase réalisation

Chef de projet

Mandant

Voir planification

Évaluation finale du projet

Courriel avec la pièce jointe

Fin du projet

Chef de projet

Mandant

Voir planification

 

Mesures de communication additionnelles

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

Afin de délivrer le meilleur service aux participants du projet, nous définissions ici des procédures de communication additionnelles afin d’assurer le meilleur engagement des participants tout au long du projet :

Déclencheur

Nom

Description

Participants

Besoin métier ou management pour une fréquence ou jalon projet

Newsletter

Une communication qui peut être soit un courriel soit une notification dans les canaux Teams. Cette information donne un statut du sujet qui permet de garder les acteurs engagés, par exemple lors de la publication d’un document projet.

CPR & COMOP en support

Besoin métier

Formation

Selon le cas, cela peut être une formation sur le produit ou le cas échéant sur l’organisation définie voir une méthodologie utilisée.

Métier & CPR ou BA en support

Besoin métier

Démo du produit

Dans une optique de formation légère ou d’engagement et de revue du produit en cours de construction/livraison.

Dev ou BA ou CPR selon le produit

Contraintes d’optimisations

Tests

Assurer la qualité du produit ou service livré, tout en engageant le métier ce qui permet d’inclure une formation et une habitude au nouveau produit.

QA & métier & CPR en support

Revue pour amélioration

Rétrospective

Assurer la qualité des prochains projets, sur la base des analyses des expériences du projet qui vient de se finir.

RETEX (REtour d'Expérience)

 

La documentation projet

La manière dont un projet doit être documenté est spécifié dans la méthodologie Hermès. A l’UNIL, notre variante d’HERMES est la DPRO (démarche projet). C’est la MPRO (méthodologie projet) qui définit la documentation projet qui doit être réalisé pendant le projet.

De plus, il existe des modèles de documents projets préremplis.

 

 

Le déroulement d’un projet (vue Hermès)

Méthodologie Hermès.png

 

Le déroulement d’un projet (vue PMI compatible avec Hermès et la MPRO UNIL)

 

Le résumé de cette vue « processus projet » est :

image.png

Note : Toutes les autres approches peuvent permettre de confirmer ou d’infirmer cette approche mais elles ne donnent en aucun cas un résultat aussi précis.

Bienvenue dans un projet du CI

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.

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

 

Abréviation

Titre complet

Commentaire

PMO

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

Hors Hermès

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

 

RSI

Répondant du Système d’Information

UNIL Selon la directive de Direction UNIL 6.10

RM

Responsable métier

UNIL Selon la directive de Direction UNIL 6.10

MAN

Mandant

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

MAND

Mandant Délégué

UNIL spécifique

CPR ou CdP

Chef de projet

Rôle Hermès et marché

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

RAP

Responsable applicatif

UNIL

CPO

Chef de Pôle

UNIL / marché

GQR

Gestionnaire de la qualité et des risques

Rôle Hermès

SCPR

Chef de sous-projet

Rôle Hermès et marché

AP

Assistance de projet

Rôle Hermès et marché

DEV

Développeur

Rôle Hermès et marché

PE

Prestataire externe

Rôle marché

QA

Analyste Qualité / Responsable de Test / Testeur

Rôle Hermès et marché

BA

Business Analyst ou Analyste métiers

Rôle Hermès et marché

TPO

Technical Product Owner

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

AQ

Analyste Qualité

Rôle marché

ARCHI-E

Architecte d’Entreprise assurant la cohérence du SI

Rôle marché

ARCHI-S

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

Rôle marché

MANG

Mandant du programme

Rôle Hermès et marché

CPG

Chef de programme

Rôle Hermès et marché

EP

Équipe de projet

Rôle marché

PAT

Personnel Administratif et Technique

UNIL

CISO

Chief Information Security Officer

UNIL et marché

CMO

Change management Office(r)

UNIL et marché

CM

Change Manager

UNIL et marché

EXP

Expert Métiers

UNIL et marché

BA

Business Analyst (

UNIL et marché

 

 

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

Note : 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

 

RACI

 

RACI 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

 

Bienvenue dans un projet du CI

Liste des meetings

COMINI & COPIL pour les libérations de phases

En clôture de la préparation du projet, un COMINI (Comité d'initialisation) est mis en place, en guise de « coordination interne CI », pour l’alignement des membres CI (CISO, chefs de pôles, etc.). Pour les autres phases du projet, c’est le COPIL (Comité de pilotage) qui sert à la validation des fins de phases et la libération des phases suivantes.

Le « Kick-off » est la séance d’engagement de l’équipe projet (tous horizons). Plusieurs formats de ce « kick-off » peuvent être définis selon les besoins ou la complexité.

COPIL intermédiaire

Un COPIL intermédiaire (Comité de pilotage intermédiaire) est une réunion ou un comité qui intervient à un stade spécifique d’un projet ou d’un programme. Il a pour objectif de faire le point sur l’avancement du projet ou du programme. Il permet de vérifier si les jalons et les étapes prévues sont respectés et d’ajuster la stratégie si nécessaire.

L’ordre du jour du COPIL intermédiaire comprend souvent des points tels que l’état d’avancement, les risques et les problèmes identifiés, les décisions à prendre et les actions à entreprendre.

Clôture du projet

Lors de la clôture du projet, la fiche de registre pour la LPD doit être livré avec les autres documents de type exploitation.

NOTE : Le registre va remplacer les FRAT sur le long terme

RETEX pour la clôture complète

Le RETEX est géré par la PMO afin d’obtenir les retours d’expériences sur le projet. C’est une activité « post-mortem » après la clôture du projet.

Le CPR à un rôle important de partage de ses expériences avec l’équipe défini par la PMO lors de cette séance.

Bienvenue dans un projet du CI

Membre COPIL

Bienvenue dans le COMité de PILotage du projet (COPIL)

Cette documentation est une introduction au rôle de membre du COPIL sous la forme de questions/réponses. Des liens sont proposés afin d'approfondir certains concepts de la méthode.

Pour toute information supplémentaire, contactez le Chef de Projet. Bon pilotage de projet !

Comment est structuré le COPIL ?

Le COPIL est composé généralement de 3 à 5 personnes dont :

Le mandant peut également faire appel à des spécialistes, dont le référent métier, de manière permanente ou ponctuelle.

+ sur l'organisation du projet

Quand intervient le COPIL ?

Le COPIL se réunit lors de séances :

+ sur le déroulement d'un projet

Au démarrage du projet, le COPIL se réunit une première fois pour déterminer les objectifs de la phase l'initialisation et libérer les ressources nécessaires.

Quelles sont les responsabilités du COPIL ?

Le COPIL prend les décisions de pilotage du projet sur la base :

+ sur le rôle de membre du COPIL tel que défini dans Hermes

Bienvenue dans un projet du CI

Membre de COMOP

Bienvenue dans le COMité OPérationnel du projet (COMOP)

Cette documentation est une introduction au rôle de membre de COMOP sous la forme de questions/réponses. Des liens sont proposés afin d'approfondir certains concepts de la méthode.

Pour toute information supplémentaire, contactez le Chef de Projet. Bon projet !

Comment est structuré le projet ?

Le projet est structuré en phases : initialisation, conception, réalisation, déploiement.

Lors de chaque phases, le COMOP produit et évalue les résultats prévus puis planifie les résultats de la phase suivante. En fin de phase, le Chef de Projet fait valider les résultats et la planification par le COPIL.

+ sur le déroulement d'un projet

+ sur l'organisation du projet

Le COMOP réalise périodiquement des séances d'avancement portant le même nom.

Quel est mon rôle ?

Le membre du COMOP est un expert d'un domaine technique ou métier et agit comme référent pour ce domaine.

Le COMOP est responsable de la production et de l'évaluation des résultats du projet.

+ sur les rôles principaux du COMOP et leur tâches

La composition du COMOP peut varier durant le projet. Par exemple il est fréquent que le COMOP soit constitué principalement de Référents Métiers durant la phase d'initialisation.

Quelles sont mes tâches ?

Les tâches du COMOP varient en fonction de l'avancement du projet et incluent :

+ sur les résultats d'un projet

Le COMOP peut faire appel à des intervenants pour réaliser des tâches spécifiques. Il en garde cependant la responsabilité en terme d'estimation, de coûts et de qualité.

Quelles sont mes responsabilités ?

Le COMOP est responsable de l'estimation et de la qualité des résultats. Que ces tâches soient réalisées directement ou déléguées.

+ sur l'estimation et planification du projet

Bienvenue dans un projet du CI

Intervenant au projet

Cette documentation est une introduction au rôle d'intervenant d'un projet IT sous la forme de questions/réponses. Des liens sont proposés afin d'approfondir certains concepts de la méthode.

Pour toute information supplémentaire, contactez le Chef de Projet.

Quel est le rôle de l'intervenant dans un projet ?

L'intervenant est un spécialiste qui réalise une tâche spécifique dans le cadre d'un projet.

La nature de son intervention varie selon la phase du projet :

+ sur le déroulement d'un projet

Comment se déroule une intervention ?

Une intervention se déroule de la manière suivante :

  1. Un accord est passé entre l'intervenant et l'équipe projet (le COMOP) qui spécifie notamment le périmètre et le délai de réalisation
  2. L'intervenant réalise la tâche définie sous la supervision d'un membre du COMOP
  3. Le résultat de l'intervention est validé par le COMOP puis l'accord prend fin

+ sur l'organisation du projet

L'intervenant peut-être externe à l'UNIL. Auquel cas une offre précède l'accord d'achat de la prestation. Le processus suivi est celui des marchés publiques de l'état de Vaud

Bienvenue dans un projet du CI

Technical Product Owner

Cette documentation est une introduction au rôle de Technical Product Owner (TPO). Des liens sont proposés afin d'approfondir certains concepts de la méthode.

Pour toute information supplémentaire, contactez le Chef de Projet.

Quel est le rôle du Technical Product Owner ?

Le Technical Product Owner est responsable de la mise en place de l'exploitation d'une solution du marché. Il assure l'intégration technique, la mise en oeuvre du support opérationnel et de l'exploitation pendant les différentes phases du projet et pour la future exploitation de la solution.

A ce titre, ses responsabilités sont :

Comment est impliqué le TPO dans le cadre des projets ?

Il y a 3 scénarios d'implication du TPO dans les projets. Chaque scénario présente le degré de responsabilité vis à vis des livrables d'exploitation du projet sous la forme d'une matrice RACI : Réalisation / Approbateur (valide) / Consulté / Informé.

Scénario 1 : implémentation d'une nouvelle solution
Initialisation Conception Réalisation Déploiement
Allocation et assignation du TPO (I)

Elaboration des offres (C)

Architecture du système* (C)

Concept d'exploitation (A, R)

Plan de formation (C)

Pré-réception (R)

Manuel d'exploitation (A, R)

Mise en service (R)

Réception (R)

* L'architecture du système est approuvée par le Comité de Pilotage (COPIL) en présence d'un représentant du Centre Informatique.

Le chef de projet doit s'assurer de l'allocation d'une ressource en tant que TPO avant la libération du projet (fin de phase d'initialisation). Puis d'accompagner le TPO dans l'élaboration des résultats et dans sa monté en compétence sur la solution.

Note : la charge théorique d'un TPO dans un projet est d'environ 20%. Cette charge peut être réévaluée à chaque fin de phase pour la suivante.

Scénario 2 : évolution d'une solution
Initialisation Conception Réalisation Déploiement
Etude – exigences d’exploitation (A, C)

Elaboration des offres (C)
Architecture du système (A)
Concept d’exploitation (A, R)
Plan de formation (C)

Pré-réception (R)

Manuel d'exploitation (A, R)

Mise en service (R)

Réception (R)

Scénario 3 : projet technique

Le TPO initie des projets techniques dans le cadre de l'évolution et la maintenance de la solution. Ces projets suivent la méthode simplifiée : mission. Le TPO prend alors le rôle de chef de mission. 

Initialisation Mise en oeuvre Clôture
Mandat de mission (A, R)
Demande d’achat (A, R)

Manuel d’exploitation (A, R)

Reporting (A, R)

Appréciation finale de la mission (A, R)

Comment sont partagés les responsabilités pour l'exploitation de la solution ?

Côté métier un Product Owner (PO), probablement le référent métier durant le projet, est responsable de l’utilisation de l’outil par les utilisateurs ainsi que de son évolution dans le but de répondre aux nouveaux besoins métier. Côté CI, le TPO est responsable du fonctionnement technique de la solution : disponibilité, sécurité/backups, mises à jour, facturation, licences.

Les détails de l'organisation et des processus de l'exploitation sont indiqués dans le concept et le manuel d'exploitation.

Bienvenue dans un projet du CI

Terminologie et Acronymes

Ce chapitre va rappeler les définitions du vocabulaire et des acronymes afin d’avoir un référentiel commun accessible à tous.

Cela permettra dans le temps de lisser des abus de langages éventuels, ainsi que d’aligner la terminologie sur les standards des marchés publiques.

Note : Dans le cas de nouvelles incompréhensions, il faudra mettre à jour ce contenu avec chaque terme dont l’utilisation n’est pas alignée avec la définition du marché afin d’avoir un référentiel UNIL adapté aux besoins internes et en accord les usages des fournisseurs externes.

La terminologie SAP standard est déjà documentée en ligne, pour des raisons d’efficacité, nous ne gardons ce lien comme référence : https://www.system-overload.org/sap/modules.html

Réf.

Acronyme

Signification

Définition

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 ? ».
Des livrables possibles sont un scénario Hermès, un diagramme BPMN des activités du projet ou un diagramme de PERT construit sur la base du WBS

·         Le « Schedule », ou Planning, répond aux questions « qui ? » et « quand ? »
Des livrables possibles sont un plan d’action ou un diagramme de GANTT construit sur la base du « Planning » avec les estimations des durées des tâches.


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.
La durée de rentabilité est le temps nécessaire pour que la mise de départ puisse être récupérée (retour sur investissement égal à zéro). »

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.

Note : 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.

Note d’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.

Note : 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 :


Note : 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

Must, Should, Could & Would 

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

Note : 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 :
consommée (Down) par l’équipe ou à consommer (Up) sur le Sprint

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

Note : 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.

Note : 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

Projet

 

Un projet est un « one-off » qui possède un début et une fin.

Il est unique.

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.

Note : 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.

Note : 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

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.

Note : 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.

Note : 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

Projet (simple)

 

Voir la définition d’un projet (Ref 41) 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 :

  • Fin-début
  • Début-début
  • Fin-Fin
  • Début-fin

63

Projet (Complexe)

 

Voir la définition d’un projet (Ref 41) pour le côté général et d’un projet simple (Ref 63) pour les cas simples.

 

Un projet complexe est un projet dont les liens entre les activités est de nature complexe :

  • Dépendances nécessaires entre les tâches en cours de réalisation

 

Note : dans le cas où ces liens fort n'existent que de manière sporadique, nous parlons d’un projet simple.

64

Programme (pour les projets)

 

Un programme est un projet constitué de plusieurs projets.

Voir la définition d’un projet (Ref 41) pour le côté général.

65

Programme (simple)

 

Voir la définition d’un programme (Ref 65) pour le côté général et d’un projet simple (Ref 63) 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

Programme (Complexe)

 

Voir la définition d’un programme (Ref 65) pour le côté général et d’un programme simple (Ref 64) 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

 

Note : 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.

Note : 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

 

82

nLPD

Nouvelle Loi sur la protection des données

 

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

 

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

DSM

Division des Solutions Metiers

 

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

FAQ

FAQ

Qu'est ce que la MPRO ?

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

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

+ sur le déroulement d'un projet

 

Une documentation plus détaillée de la méthode est à disposition des Chefs de Projets. Pour plus d'informations, merci de s'adresser à fabrice.douchant@unil.ch.

FAQ

Comment se déroule un projet ?

Cycle de vie du projet

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

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

image.png

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

Objectifs principaux

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

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

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

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

FAQ

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

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

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

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

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

FAQ

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

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

Référent Métier (RM)

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

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

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

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

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

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

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

Technical Product Owner (TPO)

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

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

Chef de projet / Business Analyste (BA)

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

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

FAQ

Comment est organisé un projet ?

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

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


FAQ

Quels sont les résultats du projet ?

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

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

FAQ

Comment est planifié un projet ?

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

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

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

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

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

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