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

>>> Accéder au template

👉 Matrice RASCI

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.

>>> Accéder au template

👉 Bulletin de santé

Un bulletin de santé du projet doit être présenté par le Project Leader lors de chaque Comité de Pilotage (CoPil). Celui-ci fait état:

1. du 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?
2. du 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. 
3. du 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
4. de 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? 
5. de la qualité
   Les contrôles qualité requis sont-ils bien effectués (ex: données, système, procédure, documentation...)
6. des 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.

Un tableau récapitulant les 6 points susmentionnés vient clore la présentation du Project Leader au CoPil.

>>> Voir exemple

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