J’ai été chef de projet pour la ré-informatisation de mon SCD pendant 2 ans, et vu que j’ai un peu galéré pour trouver des infos sur ce type de mission, je me dis que mon expérience pourra être utile à d’autres (je ne dis pas que j’ai tout fait correctement, hein, j’en suis souvent bien loin, même).
Se renseigner
Autant le dire tout net : les livres sur « le rôle du chef de projet dans la cadre d’une réinformatisation », ça n’existe pas 🙂 – il n’existe pas non plus grand chose sur l’administration des SIGB en général, entre parenthèses (juste ça et ça). Côté articles ou blogs, la pêche n’est pas terrible non plus, même à l’étranger – il y a une niche à prendre, là, c’est sûr 😉
Finalement, les avis les plus judicieux m’ont été prodigués par des chefs de projet dans d’autres domaines que le mien.
Bien s’entourer
Il faut le savoir : dans la fonction publique, vraiment n’importe qui peut être nommé chef de projet, pas forcément quelqu’un qui connaît à fond techniquement tous les aspects du projet. Pas de panique : ce que l’on attend de vous, c’est que vous coordonniez les différentes actions et étapes du projet. Personne ne vous demande de tout savoir, mais à vous de constituer votre équipe avec des gens qui, eux, sont hyper-compétents techniquement et/ou ont une bonne connaissance des pratiques professionnelles locales. Et une fois qu’ils font partie de l’équipe, leur faire confiance, et ne pas hésiter à déléguer.
Organiser le bal
Pas question de se laisser porter par le mouvement : en réunion, le chef de projet est là pour mener la danse ; il arrive avec un ordre du jour, prend note des demandes et suggestions, et se charge généralement de la rédaction des compte-rendus. Pour les tests, il explique aux testeurs ce qui est attendu d’eux, dans quel délai, sous quelle forme. Il prend également en charge la logistique des formations.
Elle fait rien qu’à rapporter
A toutes les étapes du projet, il faut prévoir un récapitulatif régulier pour sa hiérarchie bien sûr, mais aussi pour les collègues : le projet existe, il y a des agents qui travaillent dessus, il faut que ça se sache, que ça fasse partie du paysage commun, du contexte global du service. Ca permet aussi de rassurer à propos des éventuels retards, et de motiver les équipes, de les impliquer dans la mise en place de ce nouveau système qui, après tout est quand même leur futur outil de travail…
Autre tâche du chef de projet : recueillir les retours des testeurs, et rapporter les bugs au prestataire… Nous utilisons un outil libre pour le suivi des problèmes rencontrés lors de l’utilisation du système (les bugs, quoi) : on ouvre un ticket à chaque fois que l’on veut signaler un bug, un manque ou suggérer une nouvelle fonctionnalité.
Documentez, documentez, il en restera toujours quelque chose
Parce que chef de projet, c’est une mission temporaire, il faut documenter le plus possible les choix qui sont faits, en terme de paramétrages particulièrement, mais pas seulement : avoir un historique du projet, avec les compte-rendus des réunions, mais aussi les notes et autres synthèses intermédiaires qui auront été produites, sera précieux à la personne qui prendra en charge l’administration quotidienne une fois le système passé en production – qui peut être une personne différente du chef de projet.
Facile à dire, mais pas à faire
Je vois plusieurs écueils pouvant guetter le chef de projet en herbe – à ce que j’ai entendu dire, hein 😉 :
– trop s’investir dans le projet : on en rêve la nuit, quand on arrive à dormir ; on prend les remarques des collègues pour des critiques personnelles – et on finit déprimé et fatigué
– travailler en solo : on ne délègue rien, on communique au minimum – et tout le monde vous tombe dessus lors du passage en production.
– être chef de projet sur le papier, mais chef de rien en réalité : les décisions sont prises ailleurs, la communication vous échappe, vous passez pour un(e) imbécile.
Du suivi
Une ré-informatisation c’est un peu comme la construction d’une maison : il faut suivre tout les corps de métier sous peine d’accumuler erreurs et retards. Et comme en général « votre » projet n’est qu’un projet parmi d’autres pour vos « partenaires » (DSI, scolarités, prestataires), il vous faut relancer les uns et les autres pour que le chantier avance correctement.
Des outils qui aident
- Freemind (ou tout autre outil pour faire des cartes heuristiques) pour y voir clair dans ce qui est fait / ce qu’il reste à faire.
- Un outil de reporting comme Mantis, pour alimenter le workflow de tous les bugs et autre problèmes techniques.
- Des wikis pour mettre en ligne toute la documentation, les tables de correspondance, les supports de formation etc – pour être sûr d’avoir toujours la version la plus à jour (je suis toujours contente de PBworks, mais on travaille aussi avec Dokuwiki).
Est-ce que ces remarques s’appliquent aussi au rôle d’administrateur du SIGB ? Est-ce que c’est plus simple, ou plus compliqué ? Il est trop tôt pour vous le dire, on verra à la fin de l’année universitaire…
[photo : fotemas]
Pas toujours évident de s’y retrouver dans les bases qui proposent des archives de revues, notamment pour les revues de droit anglophone. On a toujours l’impression d’acheter plusieurs fois les mêmes revues, et bien sûr quand on cherche une revue qu’on croyait comprise dans tel bouquet, on s’aperçoit qu’elle n’y est pas… Avec l’aide d’un doctorant*, nous avons donc établi ce comparatif entre les ressources JSTOR, Westlaw et HeinOnline. Nous sommes partis de la liste des titres du domaine « Droit » sur JSTOR (73 titres), et nous avons cherché s’ils étaient présents sur HeinOnline et Westlaw. Si c’était le cas, nous avons ajouté la période de couverture disponible pour chaque base. Nous avons également mentionné dans quelle(s) collection(s) les titres étaient disponibles sur JSTOR.
Ca n’a échappé à personne, c’est la rentrée… Et avec elle le nouveau tirage de l’incontournable brochure 
Marlène's corner 