15/11/2024

DSI Experience

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 !

author avatar
LeCastillan
D.S.I autodidacte d'une E.T.I (Entreprise de Taille Intermédiaire) de 400 personnes ayant une activité internationale 24/7 - Passionné - Aime écrire - Aime les choses "simples" - Aime la Liberté - Aime l'Open Source - Curieux - Pragmatique...
Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Envoyer par mail

2 commentaires sur “Aaah…Le Chef de Projet…

  • Article sympa…
    « 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 ». »

    Il existe aussi les directeurs de projet pour les projets importants.

    « toute demande d’évolution du S.I n’est pas forcément à traiter en mode « projet » !  »
    Évolution, fonctionnement et Projet : 3 types de changement pour lesquels le code budgétaire n’est pas le même :):)

    Je t’invite à lire 2 anciens articles :
    http://www.geekandmore.fr/projet-informatique/
    et
    http://www.geekandmore.fr/la-gestion-de-projet-cest/

    En espérant du coup lire un prochain article sur AGILE 🙂
    http://www.geekandmore.fr/faire-face-au-changement-scrum-agile-2/

    Au plaisir de te relire

    Répondre
  • Bonsoir idem2lyon,

    Oui oui et oui un Directeur de projet cela existe aussi…et quant au budget, j’ai connu un patron qui me disait toujours : « les dépenses sont toujours certaines et le retour sur investissement toujours incertain… » ! Tout cela pour en venir au sujet qui nous intéresse : la taille du projet doit être « compatible » avec la taille de l’investissement et des retombées éventuelles… Exemple : cela me rapporte quoi de migrer de WinXP vers Windows Seven ? Bon allez pas simple tout cela… J’ai pris connaissance des deux articles, c’est toujours intéressant de relire les règles de l’art… Quant à AGILE, c’est une méthode qui, comme son nom l’indique signifie « souple » et « rapide » et je pense qu’effectivement une D.S.I se doit être souple et rapide pour réussir aujourd’hui. Néanmoins l’agilité amène parfois quelques tensions, surtout quand cela ne peut pas s’appliquer à un projet, exemple : un projet visant la sécurité du S.I où là, « souplesse » pourrait rimer avec « faiblesse »… Ce sera peut-être l’objet d’un article à venir… A bientôt !

    Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.