null Quels documents faut-il produire dans le cadre de la gestion d'un projet IT?

👉 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

A noter: ce document n'est pas requis pour les micro-projets

👉 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, CIO, GGIT).

La responsabilitĂ© de la mise Ă  jour rĂ©gulière de la matrice RASCI incombe au Project Leader.

>>> AccĂ©der au template

R > Responsible/RĂ©alisateur
A > Accountable/Autorité
S > Support/Soutien
CConsulted/Conseiller
IInformed/A informer

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

>>> Visualiser un exemple

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

27 janv. 2023 - 18:26:32
1266 vues

Cet article ne rĂ©pond pas Ă  votre question ?  Contactez notre Support