10 défis pour les chefs de projet informatique en 2020

La gestion de projet informatique : défis et retours d’expériences !

Bienvenue dans notre article dédié à la gestion de projet informatique en 2020, celle qui rime principalement avec méthode agile ! Pour bien comprendre la gestion de projet et les problématiques actuelles, vous pouvez faire un saut dans le passé en découvrant les principales évolutions entre la gestion de projet informatique d’hier et celle d’aujourd’hui.

Ici, nous nous concentrerons davantage sur les principaux défis que rencontrent les chefs de projet informatiques dans les ESN et autres sociétés informatiques, qui sont en charge de développer des projets en mode agile pour le compte de leurs clients. Gestion des risques, spécifications, gestion des développeurs, implication du client... Plongez dans le quotidien de nos chefs de projets informatiques !

Pour écouter notre podcast, c’est ici :

La gestion de projet informatique, c’est quoi ?

La gestion de projet informatique, définition

Avoir un projet, c’est chercher à répondre à un besoin, et obtenir des résultats à l’issue d’une phase de réalisation (le projet).

La gestion de projet informatique, c’est mettre en place toute l’organisation et toutes les méthodes qui vont bien pour amener chacune des phases du projet à bien.

Et en informatique, nous n’avons rien inventé ! On réutilise des grands principes qui existaient dans l’historique du bâtiment ou d’autres corps de métiers.

Dans la gestion de projet, notre objectif est de délivrer un projet, tel qu’il soit, on time et on budget. Autrement dit, dans le temps imparti (ce qu’on a imaginé en termes de planning) et dans le budget qu’on s’était fixé.

Pour y arriver, il est nécessaire de faire concourir toutes les tâches à effectuer pour réussir à délivrer le projet tel qu’on l’avait imaginé, dans le bon tempo.

Quelque soit la technologie, la solution choisie, ou la taille du projet, nous devons réfléchir à la meilleure gestion de projet possible.

Les grandes étapes de la gestion de projet informatique

Aujourd’hui, tous les projets informatiques sont grossièrement faits de la même manière, avec les phases suivantes :

• Conception : imagination de la solution qui va être développée.
• Architecture : imagination du design complet de la solution.
• Phase de réalisation : développement de la solution, via des sprints en méthodologie agile. Durant cette phase de réalisation, les utilisateurs finaux (clients) réalisent parallèlement des phases de test (recettes).
• Mise en production
• Maintenance et évolutions

Gérer un projet, c’est gérer des risques

Gérer un projet, c’est correctement gérer les risques du projet.

Pour un chef de projet informatique, la problématique principale est d’identifier les risques potentiels et de voir comment il peut réussir à couvrir ces risques.

Quand on parle de gestion de projet, quelque soit la méthodologie qu’on va mettre en face, l’essentiel à nos yeux est de faire une bonne analyse des risques. Parce que, quelque part, piloter un projet, c’est analyser les risques.

Cela se traduit dans le quotidien par beaucoup d’anticipation, du prévisionnel (imaginer ce qui va se produire) et mettre en place les actions préventives qui vont permettre de faire en sorte que le projet arrive au bout tel qu’on l’a imaginé.

Concrètement, c’est :

• construire un planning pour ne pas avoir de dérapage sur des chemins critiques
• mettre en place une méthodologie pour faire en sorte d’avoir les meilleurs résultats possibles
• organiser la gestion des ressources autour du projet : savoir quel profil métier je vais avoir besoin, à quel moment, et quelles compétences…
• etc.

Les différents acteurs

Au sein d’un même projet, il y a plusieurs acteurs que ce soit chez le client, ou chez le prestataire qui développe la solution informatique. Nous avons : les experts fonctionnels, les architectes, les experts techniques, les développeurs, les utilisateurs finaux, les testeurs, etc.

Tout l’enjeu de la gestion de projet et du chef de projet en l’occurence, c’est de faire fonctionner ensemble tous les acteurs du projet pour réussir à délivrer le projet attendu.

Défi #1 : Réussir le cadrage du projet !

C’est durant la phase de cadrage projet (et ça démarre même en amont durant les phases d’avant-vente) que nous nous mettons d’accord avec le client sur la manière de répondre à son besoin.

Conception : se mettre d’accord sur les grandes lignes du projet

A l’origine de tout projet, il y a une idée, un besoin auquel il faut répondre dans l’optique d’obtenir des résultats. Avant de démarrer le projet, il est donc essentiel de se mettre d’accord sur le comment on va répondre à ce besoin. L’idée n’est pas de rentrer dans les moindres détails, mais surtout de se donner les grandes lignes du projet pour savoir où on va (grandes fonctionnalités, type de solution mise en place, etc. )

Etre clairement d’accord sur tous ces aspects, c’est important ! En effet, si on n’ouvre pas cette discussion, le chef de projet informatique côté prestataire imagine une version, le chef de projet côté client imagine une autre version, et lorsqu’on confronte les deux à la fin, ce n’est pas fabuleux... C’est pourquoi, il faut être le plus clair possible quand on se lance sur un projet : qu’est-ce qu’on va faire, comment on va le faire, où est-ce qu’on va… Puis on va lister les éléments et les mesurer : nombre de pages, de règles de gestion, interfaces…

L’organisation : keep it simple !

Dès le démarrage, le chef de projet informatique doit fixer les rôles des uns et des autres. Il faut savoir qui va faire quoi, quels vont être les attributions et les fonctions de chacun pour pouvoir avancer et communiquer efficacement.

Le rôle du chef de projet informatique va être de faire interagir tout le monde avec des règles de gouvernance qui soient les plus simples et les plus claires possibles. Dans les méthodes agiles, il existe beaucoup de littérature autour du rôle des uns et des autres. On pourrait très bien être "jusqu’au-boutiste" et adopter une méthode très stricte. Cependant, nous pensons qu’il faut revenir aux bons vieux fondamentaux :

• Qui fait quoi ?
• Quand est-ce qu’on se réunit ?
• Comment on se réunit ?
• A quel moment ?
• A quelle fréquence ?
• Qu’est-ce qu’on a comme relevé de décision ?
• Quelles sont les futures actions à faire ?
• Y’a-t’il des risques imminents ? Comment on les gère ?

Concernant la taille de l’équipe, on est partisans des petites équipes compactes et pilotables. Parce que, quand vous avez des plateaux de 20 développeurs qu’il faut faire travailler de manière commune sur un projet, c’est compliqué... et il y a de fortes chances qu’il y ait un pourcentage de l’équipe qui ne soit pas d’une grande efficacité !

De manière générale, on incite à faire des projets de taille humaine, où le pragmatisme a une place essentielle ! Pour arriver aux meilleurs résultats et gagner en efficacité, restons concentrés sur un petit nombre de personnes et un petit nombre de tâches.

Défi #2 : Choisir ses outils de gestion de projet informatique

Avant de rentrer dans le dur du projet, on se pose souvent la question suivante : quel est le meilleur outil de gestion de projet à utiliser ?

J’espère qu’on ne vous décevra pas, mais nous n’avons pas LA bonne réponse à vous apporter. Il existe plein d’outils de gestion de projet : des outils collaboratifs, de planification, de suivi de tâches, de management visuel, etc. On peut bien sûr citer quelques outils qu’on apprécie comme Gitlab, Jira ou encore Trello. Mais ça reste une appréciation personnelle à chacun, car, dans le fond, les principaux outils connus se valent et sont très bons. C’est l’utilisation qu’on fait des outils qui va faire la différence !

On part sur le principe que, dès lors qu’on sait correctement utiliser un outil, et mettre en place une organisation autour pour obtenir des résultats, c’est l’outil adapté ! Alors, on vous conseillera plutôt de tester les outils et de voir par vous-même avec lequel vous vous sentez le plus à l’aise ! Rien ne sert d’avoir un outil si on ne l’utilise pas ou si on l’utilise mal.

Aussi, si l’on choisit un outil en pensant qu’il va résoudre toutes les problématiques d’un projet, on va droit dans le mur. Il faut avoir la méthode et l’organisation qui vont avec l’outil, et inversement... Les outils n’ont rien de magique !

Quelque soit l’outil choisit, le chef de projet informatique doit monter en compétences dessus pour en tirer pleinement les avantages et surtout, s’y tenir dans le temps ! Oui, la gestion de projet ce n’est pas seulement un super planning en début de projet. Tout se joue dans le suivi des activités et de l’atteinte des objectifs.

Défi #3 : Les spécifications, ne pas confondre vitesse et précipitation !

Logiquement, les projets devraient commencer bien avant les développements, avec la réalisation de spécifications. Dans la réalité, on fait souvent les choses à l’envers ! Aujourd’hui, sous couvert de méthode agile, les porteurs de projets ont tendance à vouloir commencer les développements très rapidement pour tout un tas de raisons : contraintes clients final, démonstration en interne de la capacité à délivrer des applications pour les métiers... Et l’étape de réflexion en amont du projet est souvent trop écourtée.

Même si les grandes spécifications telles qu’on les faisait 20 ans en arrière ne sont plus d’actualité, il faut trouver un compromis entre un document de 300 pages et quelques idées sur un post-it :)

Rassurez-vous, il y a tout de même des spécifications qui sont faites dans les méthodes agiles. Généralement, on se met d’accord sur des grands concepts, des grandes fonctionnalités de l’application et après, on va plus vite dans la logique de développement. On ne cherche pas à avoir les moindres détails de la part des clients au sujet des fonctionnalités souhaitées pour la simple et bonne raison, que c’est difficile pour le chef de projet côté client d’imaginer une solution et de penser à tout du premier coup !

Pour pallier aux manques de spécifications, on fonctionne différemment ! On réalise des POC, des applications V0 et on fait réagir rapidement le client face à ce premier livrable. Finalement, c’est beaucoup plus rapide et efficace comme méthode ! Quelque part, ça simplifie la tâche de l’utilisateur testeur.

La durée d’un projet se compte généralement en mois. Aussi, on préfère avoir une première version qui nous donne une première étape tout de suite, plutôt que d’attendre des mois pour avoir une solution complète.

Défi #4 : Adapter la composition des sprints

En mode agile, on fonctionne via des sprints de durée et de composition variable. Le schéma est toujours le même : spécifications, développements, recette, traitements des retours, et on boucle sur le sprint suivant !

Cette mécanique en itération permet de faire de bons choix, de s’ajuster (avec des tests réguliers) et de créer la valeur.

La force de bons sprints, est de pouvoir les adapter en fonction de la phase du projet et donc, d’être flexible. Par exemple, on peut faire un premier sprint de 3 semaines avec un profil architecte, un profil expert technique et un profil développeur. On peut faire un deuxième sprint d’une durée de 4 semaines avec 2 développeurs backend et un frontend.

C’est là que se trouve la grande richesse des méthodes agiles, la FLEXIBILITE. Cela permet d’avoir une organisation très polymorphe, très malléable qui puisse s’adapter en permanence aux besoins, à la phase du projet. Ensuite, il suffit de bien composer ses sprints et de les dérouler tout en gardant en tête l’objectif majeur du projet.

Défi #5 : Impliquer le client dans les phases de test

On ne le dira jamais assez, la réussite d’un projet dépend en partie de l’implication du client !

L’organisation agile demande une implication importante du client durant chaque sprint pour tester les fonctionnalités réalisées. C’est en partie en fonction de la qualité de ces tests, que se font les retours et les développements suivants.

Créer et insister sur la notion d’équipe étendue. Chez AXOPEN, on met un point d’honneur à bien intégrer les clients et leurs compétences au sein de l’équipe ! En dehors des phases de recette, on le sollicite pour des besoins de précision de fonctionnalités, des validations immédiates de certains comportements de l’application, des avis, etc.

Cette organisation permet d’éviter beaucoup de surprises et aussi de mettre en stand by des parties structurantes pour la suite du projet. Avec des tests réguliers et beaucoup de communication, on sécurise l’atterrissage du projet !

Défi #6 : Gérer les changements de route des clients

Finalement et logiquement, depuis qu’on a laissé la possibilité aux clients finaux de pouvoir faire des demandes de changement au cours du projet de façon simple et rapide , ils l’utilisent ! Ne l’oublions pas, nous sommes dans des méthodes agiles, méthodes qui permettent le droit à l’erreur. Donc, si le client se trompe et qu’il change d’avis sur une fonctionnalité par exemple, on va pouvoir le prendre en compte dans le sprint suivant très rapidement.

Pour bien traiter ces retours, on utilise les backlogs ! C’est la liste de toutes les fonctionnalités, toutes les tâches qui vont être réalisées. Cette backlog est priorisée. Charge ensuite au client de pouvoir revenir sur cette priorité au besoin en fonction des urgences du moment.

Gérer les changements de route de clients en faisant des ajustements, c’est génial ! En revanche, attention tout de même aux dérives... Si l’on change tout le temps d’avis à propos de tout, le projet n’avance pas. Il faut s’accorder à garder une ligne directrice et à apporter de la stabilité, c’est aussi important dans un projet !

Défi #7 : Le suivi du projet : s’assurer qu’on est dans le plan de marche !

Quand on parle de gestion de projet, on parle aussi de gestion de contraintes. Il faut prendre en compte tout au long du projet les aspects technologiques, les aspects de méthodologie, la partie planning, les attentes du client, etc.

Mais, que se passe-t-il vraiment dans le quotidien de la gestion de projet ?

Lorsqu’on démarre le projet, on a essayé d’envisager tout ce qui pouvait se passer, comment on pouvait arriver au résultat attendu pour le client, et, une sorte de référentiel méthodologique et technologique s’est construit. Le but du jeu pour le chef de projet est de vérifier très régulièrement (toutes les semaines) que nous sommes toujours alignés sur ce référentiel. En d’autres termes, il faut vérifier que ce qui a été fait, est bien ce qu’on avait prévu de faire.

Si jamais il y a des écarts (ce qu’on appelle plus communément des dérives projets), le chef de projet doit identifier les actions correctives à mettre en œuvre pour rectifier le tir, ou adapter la cible (car les méthodologies agiles permettent justement d’adapter les actions au fil de l’eau, en concertation avec le client).

Défi #8 : S’assurer que tout le monde travaille main dans la main !

On l’a dit, on est dans une mécanique d’équipe étendue entre le prestataire informatique et le client. Equipe dans laquelle se trouvent des architectes, des utilisateurs, des chefs de projets, la MOA, etc.

Toute l’alchimie d’un bon directeur de projet, c’est de réussir à faire travailler tout ce monde en parfaite autonomie et harmonie ( alors qu’ils n’ont pas forcément les mêmes codes, les mêmes attentes ou les mêmes enjeux).

La réussite de la méthode agile repose en grande partie sur cette cohésion globale. Il faut réussir à bien travailler ensemble, bien s’entendre en permanence, communiquer au jour le jour, etc. Un véritable défi !

Défi #9 : Gérer les équipes de développement

La gestion des développeurs au quotidien

Qui dit équipe, dit gestion RH et management ! C’est essentiel de réussir à fédérer notre équipe. Il faut gérer toutes les énergies, les faire aller dans le même sens et faire en sorte que tout le monde adhère au projet, soit motivé, compétent, formé !

Pour ce faire, il faut beaucoup de communication et d’attention au quotidien ! Dans les méthodes agiles, c’est ce que nous appelons le delimiting : vérifier tous les jours que tout le monde sait ce qu’il a à faire, qu’il n’y a pas de points de blocage, que chaque collaborateur sait ce que font ses collègues.

De plus, nous faisons des entretiens régulièrement avec les uns et les autres, pour voir si on est toujours sur le même alignement et que tout va bien !

Ces nombreux points de contact permettent d’être, encore une fois, plus efficace et d’assurer une bonne coordination de l’équipe !

Composition d’équipe et turnover

Comme on vous le disait un peu plus haut, on est partisans des petites équipes, qui peuvent être adaptées aux besoins des sprints. Seulement, si pour des raisons X ou Y, il arrive que nous devions changer un développeur sur un projet, ça se complique !

Par le passé, remplacer un développeur par un autre ne posait pas trop de soucis. Il y avait moins de technologies différentes à maitriser et on pouvait se permettre d’allouer 15 jours pour intégrer un développeur sur un projet. Aujourd’hui, l’expressivité du code complique notre affaire ! En effet, la stack technique est plus large et plus complexe à maitriser sur un projet, on peut maintenant développer beaucoup de choses, très rapidement ! Et trouver un développeur qui soit pleinement motivé, qui ait exactement la capacité technique, les connaissances qu’il faut, et qui puisse rentrer rapidement et efficacement dans le projet, c’est un sacré défi !

Défi #10 : Gérer la (ou les) mise(s) en production, et l’après...

En fonction de l’organisation choisie, les mises en production se passent soit au fil de l’eau, soit en toute fin de projet.

Le fait de livrer plusieurs fois en plus petits blocs, ça limite les risques ! Il y a moins de fonctionnalités à tester, c’est plus rapide et les sujets sont mieux maitrisés par les équipes et par le client. Pour autant, faire plein de petites mises en production peut s’avérer compliqué en fonction de l’organisation du client... Encore une fois, il faut qu’il soit impliqué pour que ça marche ! A discuter donc avec les clients pour trouver le dispositif optimum !

Un projet informatique, ce n’est jamais terminé ! Après la MEP, il faut également mettre en place des dispositifs de maintenance pour assurer les évolutions de l’outil. On passe donc dans une dynamique de gestion de projet de maintenance, et c’est encore différent de la gestion de projet informatique telle que nous l’avons décrite ici car on s’organise plutôt autour d’un service, que sur une réalisation. Cependant, les questions qu’on se pose peuvent êtres assez similaires par moment !

Retours d’expériences : bonus !

Soyons honnêtes, chaque chef de projet informatique a déjà loupé la gestion d’un projet au moins une fois dans sa vie... et nous n’échappons pas à cette règle ! Mais l’important est d’en tirer les leçons... on vous partage les nôtre !

Changer d’avis oui, mais pas trop !

L’intérêt des méthodes agiles, c’est qu’on peut toujours tout bouger ! Mais, attention à ne pas trop changer d’avis, et pas pendant toutes les phases du projet. Il y a des moments où il faut stabiliser les choses, c’est important, ça fait du bien !. Plein de projets sont morts nés à force d’avoir voulu trop bouger la trajectoire, la cible et finalement, n’ont jamais rien livré...

Ne pas se dire qu’on fait du jetable.

Les SI d’aujourd’hui sont remplis d’applications qu’on avait considéré comme jetables lors du développement et qui, finalement, marchent bien et sont en dur dans le SI !

Ce n’est pas parce qu’on fait du rapide, de l’itératif, de l’agile qu’il faut minimiser le côté durabilité qu’on peut avoir sur ce qu’on produit, en termes de code et surtout, en terme de documentation. Un des gros travers c’est d’aller vite, de livrer puis de partir et de passer à autre chose. Les développeurs et utilisateurs passent à autre chose, et on se retrouve avec des pans de code dont plus personne ne sait comment ça fonctionne...

On a besoin de se remettre dans une logique où on se dit : "je dois faire un développement durable, qui va s’installer pour longtemps dans notre système d’informations.

A partir du moment où nous livrons du code, et n’importe quel code, il doit être de qualité et documenté. Cela permet à des patrimoines entiers de perdurer ! Car finalement le SI d’une entreprise, c’est une suite ininterrompue de projets de toute taille. Et c’est la concaténation de toutes ces briques de projets qui doivent continuer à pouvoir opérer ensemble. C’est ça le vrai sujet : se dire que, même si on fait les projets de manière agile et rapide, il faut qu’on les conçoive de manière durable et qu’on puisse compter dessus dans les années à venir.

Bien gérer un projet, c’est le maitriser.

Prenons pour exemple l’architecture d’une maison. Le chef du chantier vous a dit que votre maison serait livrée avec telle fenêtre à tel endroit, la porte de telle taille, à tel moment et dans tel budget. S’il n’y a pas de dérapages et que la maison arrive comme prévu, vous êtes content et vous vous dites que le chef de chantier est un super bonhomme ! Dans l’informatique, c’est la même chose.

Une fois qu’on a défini les contours du projet, les coûts que ca allait représenter, et à quel moment on va livrer, on a plus qu’à maitriser la suite ! Alors oui, au milieu, il y a des aléas, des pondérables, des choses qu’on avait pas prévues... Mais l’intérêt d’une bonne gestion de projet, c’est justement de gérer ces aléas pour amener à l’objectif final qui est la réalisation du projet.

Conclusion : nos conseils pour les futurs chefs de projet informatique

• Posez-vous les bonnes questions dès le début ! Plus on avance dans le projet, moins on peut agir sur le résultat final. Ne mâchez pas la préparation du projet et anticipez !
• Soyez pragmatique ! C’est vraiment le maitre mot pour réussir dans les méthodos agiles actuelles.
• Gérez le projet. Vous êtes le chef de projet, c’est vous le patron, alors quoi qu’il se passe, gérez, c’est votre job !
• Ayez l’esprit d’équipe ! On ne réussit pas un projet seul. Le vrai talent d’un chef de projet, c’est de savoir emmener tout le monde et d’animer l’ensemble du dispositif dans l’objectif !

Puis, sachez vous adapter ! La gestion de projet d’aujourd’hui ne sera probablement pas celle de demain, ce n’est pas figé, surtout pas ! Cela va encore bouger car les technologies évoluent, les attentes des entreprises aussi, les outillages seront différents... Ca évolue avec les usages, l’air du temps, et on a pas fini d’apprendre ! Les projets de demain et les modes de gouvernance ne sont pas encore définis. Donc c’est forcément un sujet qu’on remet en permanence en réflexion !

A notre sens, c’est d’ailleurs ce qui en fait un job passionnant : la gestion de projet n’est pas une science exacte, c’est empirique !

Et vous, comment vous pensez que la gestion de projet va évoluer ? Comment gérez-vous vos projets ? Partagez-nous vos retours d’expérience !