Standards des projets du Ci

Note de version: Un chapitre sur le change management a été ajouté, et un peu d'humour pour aborder les approches à éviter.

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

• Une modification d’une solution informatique existante ;
• La mise en place d’une nouvelle solution informatique ;
• La réalisation d’un produit à commercialiser (Un nouvel enseignement) ;
• La modification d’organisation d’une sous-entité du groupe ;
• Et beaucoup d’autres changements de nature unique.

 

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 :

• ·         La stratégie est gérée  par la directive 6.10 (en cours de rédaction)
• ·         Le Portfolio est géré avant le projet, dans la phase de Pré-initialisation.
• ·         Les projets et programmes sont les phases du projet dictées par Hermès.
• ·         Les opérations correspondent à la maintenance pouvant amener de petites corrections sans suivi ou de grosses corrections se faisant par le biais de projets ou missions.

 

 

Le Change Management dans un projet?

Selon la nature et la complexité du projet, les résultats et bénéfices du projet peuvent induire des changements plus ou moins importants pour les métiers.

Pour des projets de nature applicative, la manière dont la gestion de projet est organisé, cela suffit pour faciliter l'acceptation des changements lors des phases de communication avec les utilisateurs.

Pour des projets ayant des impacts organisationnels voir sur les procédures métiers, il est important de traiter la gestion de changement comme une partie du périmètre du projet.

On conseillera toujours d'utiliser la stratégie des projets de nature applicative:

• C'est l'approche la plus simple d'accompagnement tout au long du projet.
• De par sa nature, elle permet d'adresser certaines "résistances naturelle au changement" notamment lors des phases projets de spécifications et de retours des tests
• Et comme cela se fait durant le projet, sur la quasi totalité du projet, cela laisse le temps à chacun de pouvoir aller à son rythme dans nos processus humains.

Pour les cas plus complexe, on conseille de bien séparer la gestion du changement avec plusieurs facteurs de succès:

• Une personne qui comprennent bien les émotions liées aux changements et qui se sent à l'aise avec cette partie de l'humain
• Une personne distincte pour la gestion du changement, qui est non impliqué dans les délais du projet en temps que tel, afin que cette personne soit toujours l'observateur neutre capable d'absorber les différentes réactions qu'un changement peut entrainer
• Une séparation claire des communications (contenu, stratégie d'engagement, canaux de communication, autre) liés aux changement 
• Une boucle de "feedback" ou retour afin que les divers plans répondent aussi aux vitesses de fonctionnement de chacun
• Un plan projet du changement qui ne s'aligne pas exactement sur le projet mais sur les besoins des utilisateurs
  • Point d'attention: Il est probable d'avoir une avance ou un retard de phase de la gestion du changement en comparaison du projet.
• Une approche qui corresponds aux besoins de l'entité (hiérarchique, collaborative, et autres) voir dans certain cas, qui correspond aux changement lui même (p.e. changer un fonctionnement hiérarchique en fonctionnement collaboratif)

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.

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.

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)

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 :

1. en 1^er lieux définir le périmètre d’objectifs de manière claire
2. pour obtenir les activités à réaliser
3. séquencer ces activités
4. estimer la charge de chacune des actions
5. ce qui donnera un planning avec les dates possibles de livraison

 

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.

Des modèles de gestions de projet à ne pas appliquer

 

Ce chapitre est de l'humour de gestion de projet, mais malheureusement, l'humour se base toujours sur des fonds de vérités dans les faits.

La gestions sous pressions: que l'on peut aussi traduire par un manque de préparation et des dates définies sans avoir fait un travail d'analyse préalable.

La méthodologie de La RACHE (en Français sur le jeux de mot "à l'arache"): possédant son propre site web a consonance sarcastique

Ce qui peut se traduire par une gestion du projet et des spécifications absente avec des dates buttoirs définies sur une idée que l'on se fait du sujet et non un travail d'analyse fin de la réalisation à mettre en place: