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]
« Le marché des revues scientifiques se caractérise par une délégation des achats, des indicateurs de demande pas fiables, et des produits complexes et difficiles à évaluer. La demande de revues est par conséquent très peu élastique en ce qui concerne les prix. De grands éditeurs commerciaux ont capitalisé sur cette demande non-élastique, en réduisant la concurrence à travers des fusions et des regroupements, en proposant des contrats couplés (les « big deals »), et en augmentant leurs prix bien au delà des coûts moyens. Selon nous, la demande pour de l’accès à des articles de revues serait bien plus élastique, et le coût global pour la communauté universitaire plus faible, si les universités cessaient d’acheter des licences de site pour des bouquets à des prix excédent largement le coût moyen. Tant que d’autres bibliothèques continueront d’acheter des licences à des prix gonflés, une université à elle seule ne peut espérer un changement de la structuration des prix en supprimant elle-même ses licences de type « big deal ». Quelques bibliothèques sont pourtant parvenues à faire des économies substantielles en négociant férocement. D’autres, comme Stanford et le California Institute of Technology, ont économisé encore plus en rejetant les contrats couplés et en ne s’abonnant plus qu’aux revues individuelles les plus rentables. »
Marlène's corner 