Aaah…Le Chef de Projet…

Alors s'il y a bien un titre qui est très galvaudé de nos jours, c'est bien celui de « Chef de Projet » !

Ce titre est mis à toutes les sauces et pourtant...on rencontre souvent des « Chefs de Projets » qui ne font leur travail qu'à moitié en pensant que seul le respect du planning compte et que l'état de l'art consiste à presser (stresser) les différents acteurs afin que ce derniers respectent les délais qui ont été convenus. On jugera alors essentiellement les résultats par rapport aux objectifs du seul planning en mettant de côté les véritables « bonnes pratiques » que l'on est en droit d'attendre...

Nous parlerons ici de « projets » visant l'évolution du système d'information, bien entendu.

Je suis un D.S.I, je suis donc responsable d'un certain nombre de « projets », rôle qui consiste essentiellement à :

•  Analyser une demande émanant d'un « métier » de l'entreprise,
•  Proposer une solution pour répondre à cette demande,
•  Développer et/ou déployer cette solution,
•  Maintenir cette solution dans le temps.

Décrit comme cela, c'est tout bête...mais quand on commence à rentrer dans les détails, c'est là que cela se complique... Exemples :

•  La demande ne correspond t-elle à un réel besoin, validé par l'équipe dirigeante ?
•  La solution envisagée est-elle « acceptable » par l'entreprise, en terme de délais, en terme de coûts...etc... ?
•  Le développement (ou le déploiement) peut-il être effectué en interne ?
•  Le projet ne nécessite t-il pas la refonte ou la remise en question d'une autre application ?
•  La solution proposée est-elle pérenne ?
•  La solution n'est-elle pas trop chère à maintenir dans la durée ?

...etc...

Des questions comme celles ci-dessus, on peut s'en poser plus d'une centaine pour chaque projet que l'on adresse et ce, quelque soit sa taille...mais ce n'est peut-être pas comme cela qu'il faut procéder car ce serait alors un processus trop long, trop coûteux et pas vraiment « efficace » !

C'est là qu'entre en jeu le Chef de Projet qui, à partir de constats simples, doit rapidement fournir une réponse au « métier » (qui par définition demande des choses pour la veille...) car il serait illusoire de penser qu'ils vont attendre plusieurs semaines, voire plusieurs mois pour obtenir une réponse sur la faisabilité dudit « Projet ». Et si vraiment vous en arrivez-là alors ne vous étonnez pas de voir le « métier » se tourner vers un prestataire externe en vue d'acheter un produit sur étagère ou en mode SaaS, produit qui s’avérera au fil du temps cher à intégrer et cher à maintenir, le tout en apportant un « zéro » pointé au savoir-faire de votre entreprise...

Vous l'avez donc bien compris, le Chef de Projet se doit être un expert du système d'information et se doit connaître le métier (ou la partie du métier concernée) de son entreprise sur le bout des doigts.

Au sein de mon équipe, il y a plus de Chefs de Projets que de Développeurs, ce qui s'explique tout simplement par le fait que le développement d'une application (au sens codage du terme) n'est qu'une partie du projet et parfois, c'est la plus « petite »...

Dans notre entreprise (taille intermédiaire : 400 salariés), on pourrait résumer le rôle du Chef de Projet comme suit :

• Il analyse la demande en relation directe avec le « métier », il n'hésite pas à aller sur le terrain pour mieux comprendre,
• Il rédige cette analyse (une page maxi., au delà les gens ne lisent plus...) et il fait valider cette analyse par les demandeurs,
• Une fois l'analyse validée, il propose (rédige) une solution, là aussi une page maxi.,
• Il propose ensuite cette solution à ses pairs (autres Chefs de Projets) et au D.S.I (c'est moi!),
• Si acceptation du projet, il fait valider cette proposition par les demandeurs (le métier),
• Il assiste le (ou les Développeurs) dans la réalisation,
• Il teste les développements réalisés,
• Il fait tester la réalisation par les demandeurs,
• Il prononce la recette,
• Il définit les méthodes et moyens à mettre en place pour superviser cette nouvelle application ou cette évolution, si cela est nécessaire,
• Il écrit la documentation nécessaire au support,
• Il écrit la documentation technique nécessaire,
• Il met en « production » (déploiement la solution), en relation avec le « métier ».

Vous avez bien lu, il y a 13 étapes... Dans les plus grandes organisations, le chef de projets prend en charge beaucoup plus d'étapes encore, telles que : la conduite du changement, la formation, les manuels utilisateurs, la sécurité, la conformité, le respect des libertés, etc... Cela ne veut pas dire que ces sujets ne sont pas abordés chez nous mais ils sont souvent pris en charge par le « métier » ou directement par le D.S.I et non gérés par le Chef de Projet « Informatique ».

Ces 13 étapes constituent pour moi le « service minimum », quelque soit la taille de l'entreprise concernée. Faire une impasse sur une de ces étapes représenterait un maillon faible pour le projet concerné.

Attention toutefois à ne pas tomber dans l'excès, toute demande d'évolution du S.I n'est pas forcément à traiter en mode « projet » ! Et c'est là, peut-être, que l'on peut faire la différence entre une « bonne » D.S.I, à l'écoute du « métier », à l'écoute du marché (le fameux « Time to Market » qui signifie tout simplement : savoir réagir rapidement aux évolutions des marchés dans lesquels votre entreprise opère) et une D.S.I « Mamouth » où tout est compliqué et où rien ne peut se faire en moins de 6 mois et à moins de 100K€ (100.000€) voire plus !

Exemple : la modification d'une fonctionnalité, déjà existante et ,n'ayant aucun impact sur des données stockées dans une base, n'est pas à traiter en mode projet. A contrario, toute modification sur une donnée (longueur, type...etc...) ou tout ajout de données dans une base doivent forcément faire l'objet d'un « Projet », aussi petit soit-il, ne serait-ce que pour s'assurer que d'autres fonctionnalités ou d'autres applications ne seront pas affectées par cette modification.

En conclusion, l'objectif consiste à toujours répondre rapidement aux besoins du « métier » sans négliger la « consistance » de vos données et sans mettre en péril d'autres fonctionnalités de votre S.I. Facile à dire certes, mais pas toujours simple à faire ! Bon courage !