Vous avez l'idée d'un projet ? Voici les différents documents à produire avant, pendant et après:
Avant le démarrage du projet
Compléter le formulaire centralisé de demande IT -> Demande IT
Pendant le projet
Des documents formalisés sont à compléter à chacune des phases du cycle de vie d'un projet.
Phase de Conception
- Mandat (à fournir au PMO)
- Comptes rendus de réunion
Phase d'Organisation
- Cahier des charges (le cas échéant)
- Charte projet (à fournir au PMO)
- Bulletin de santé mensuel (à fournir au PMO et au COPIL)
- Comptes rendus de réunion
Phase d'Exécution
- Bulletin de santé mensuel (à fournir au PMO et au COPIL)
- Analyse fonctionnelle (récolte besoins, design de la solution (flux BPMN)) -> créer article Analyse fonctionnelle + supprimer Design solution
- Analyse technique
- Spécifications -> ébauche à supprimer
- Fichier des tâches (Matrice RASCI) -> créer article Fichier des tâches + supprimer Matrice RASCI
- Plan de tests -> ébauche à supprimer
- Plan de communication -> ébauche à supprimer
Hand-over
- Bulletin de santé (à fournir au PMO et au COPIL)
- Documentation fonctionnelle -> ébauche à supprimer
- Documentation technique -> ébauche à supprimer
- Documentation support
- Comptes rendus de réunion
- Compte rendu de réception -> à créer
Après le projet
Phase de Clôture
- Lessons learned -> à créer
👉 Demande IT
Le besoin informatique est à formaliser dès la conception du projet au moyen du formulaire de Demande IT. Cette formalité incombe au Sponsor ou au Project Leader.
Réceptionnée par l'IT Project Management Office (PMO), la demande est ensuite examinée par l'IT Demand Mgmt Committee auquel il revient de la caractériser.
>>> Accéder au formulaire de Demande IT (connexion à votre compte M365 requise)
👉 Mandat
Le Mandat est à compléter après réception de la part du PMO du Project_id et après présentation du projet à l'IT Project Framing Committee. Cette tâche revient au Sponsor ou au Project Leader.
Il incombe au PMO de valider le Mandat et de le consigner.
>>> Accéder au formulaire d'enregistrement de Mandat (connexion à votre compte M365 requise)
👉 Charte projet
La rédaction de la Charte Projet revient au Project Leader. Il est généralement aidé dans cette tâche par le Sponsor, le Technical Leader et/ou le Functional Leader.
La version finale de la Charte est vérifiée par l'IT Project Framing Committee et consignée par le PMO.
Les projets dits "institutionnels" ou "transversaux" sont priorisés sur base de leur alignement stratégique et des informations fournies dans la charte.
👉 Matrice RASCI (fichier des tâches)
La matrice RASCI permet de lister les tâches projets, de les assigner et d'en assurer le suivi lors des réunions hebdomadaires du Comité de projet. Il s'agit d'un document vivant qui permet de conserver du rythme dans la réalisation des tâches et de répartir les responsabilités de manière équilibrée au sein de l'équipe projet.
Cette matrice permet par ailleurs au PMO d'extraire les données nécessaires au reporting vers les organes de gouvernance des projets (CBA, C2I, GGIT).
La responsabilité de la mise à jour régulière de la matrice RASCI incombe au Project Leader.
A > Accountable/Autorité
S > Support/Soutien
C > Consulted/Conseiller
I > Informed/A informer
👉 Bulletin de santé
Le bulletin de santé du projet est un document produit par le Project Leader et dont l'ojectif est d'offrir aux instances de gouvernance des projets IT une vue simplifiée et graphique de l'état d'avancement et de santé du projet. Son format est identique pour tous les projets IT
Six points à décrire/justifier:
- le scope
Le périmètre du projet validé à son démarrage (via le mandat pour les micro-projets ou la charte pour les projets) est-il bien respecté? En cas d'extension ou de réduction du scope initial, la modification a-t-elle bien été validée par le CoPil du projet et rapportée au PMO? - le planning
Le planning établi au démarrage du projet est-il respecté? En cas de retard par rapport aux prévisions initiales, il convient de justifier celui-ci (ex: extension du scope, ressources indisponibles, résistance au changement, problème technique...). Toute modification du planning doit être validée par le CoPil et rapportée au PMO. - le budget
Le budget alloué au projet est-il sous contrôle? Les risques de dépassements budgétaires sont à rapporter au CoPil qui, selon la situation, peut décider:- d'une extension du budget
- d'une réduction du scope
- du report (d'une partie) du projet à une date ultérieure
- de l'abandon du projet
- la gouvernance
Le projet a-t-il bien été enregistré au portefeuille institutionnel des projets? A-t-il été présenté au CBA/C2I pour avis? A-t-il reçu le feu vert des instances décisionnelles (PMO, GGIT...)? A-t-il été soumis à la procédure de priorisation des projets? Est-il suivi par un CoPil dédié/global? - la qualité
Les contrôles qualité requis sont-ils bien effectués (ex: données, système, procédure, documentation...) - les risques
Les risques inhérents au projet (ex: manque de ressources, de collaboration, mésestimation du planning, du budget...) doivent être identifiés et rapportés au CoPil le plus tôt possible. Les risques liés aux éventuelles modifications des paramètres du projet, voire à l'abandon de celui-ci sont également à exposer.
👉 Compte rendu de réunion
Dans le cadre de la gestion de projet, les comptes rendus de réunion constituent un outil indispensable pour:
- asseoir la compréhension des différents interlocuteurs (plus particulièrement dans le cadre de la récolte des besoins);
- formaliser et documenter les décisions.
Il revient au Project Leader de s'assurer de la rédaction des comptes rendus de réunion et de leur bonne diffusion.
>>> Voir exemple
👉 Flux BPMN
La modélisation BPMN des processus impactés par le projet se révèle un outil efficace d'aide à la réflexion tout au long du projet. L’outil utilisé à l’ULB pour cette modélisation est Visio.
Avant la phase de hand-over, les BPMN sont mis à jour et publiés en version .pdf sur la plateforme Support ULB. Ils servent de documentation tant aux équipes métier qu'aux équipes informatiques en charge de l'opérationnel.
Il appartient au Functional Leader de veiller au formalisme et à la publication des BPMN.
>>> Voir exemple
👉 Documentation fonctionnelle
La documentation à destination des utilisateurs se doit d'être concise et dépourvue de jargon. Elle prend la forme de FAQs qui sont publiées sur la plateforme Support ULB.
Il revient au Project Leader de s'assurer de la publication de la documentation fonctionnelle avant la phase de hand-over.
Après cette phase, la mise à jour des FAQs sur base des retours d'expérience des utilisateurs revient aux équipes opérationnelles.
>>> Pour solliciter une formation à l'édition d'articles de support, contactez communication-it@ulb.be
👉 Documentation technique
Il incombe au Technical Leader de s'assurer avant le départ de tout membre de l'équipe technique et avant la phase de hand-over que le code est correctement documenté.
Le Project Leader veillera par ailleurs à la publication des schémas d'architecture technique.
👉 Documentation Support ULB
Les équipes en charge du support ont besoin de documentation pour 1) pouvoir répondre aux questions simples qui leur sont adressées et 2) pouvoir orienter correctement les questions relevant du support de niveau 2 (ou +). Cette documentation est stockée dans la Knowledge Base (KB) Support ULB.
Il appartient au Project Leader de s'assurer, pendant la phase de hand-over, du transfert de connaissances vers l'équipe Support. La rédaction des articles de la KB, quant à elle, est confiée à l'équipe Support elle-même, avec le soutien de l'équipe projet.