Nous avons vu dans la première partie les grands principes d’un planning projet. Regardons un exemple de planning projet de plus près.
Contexte projet et mise en pratique
L’exercice de chiffrage projet fait l’objet d’un autre article, nous considèrerons ici qu’il est bien fait (dans la mesure du possible). Le voici de manière macro :
- Spécifications : 11 jours
- Reprise de données : 7 jours
- Intégration : 3 jours
- Recette : 5 jours
- Réalisation – partie admin : 15 jours
- Réalisation – partie utilisateur : 45 jours
- Documentation : 8 jours
et un calendrier du projet que l’on peut trouver dans une proposition commerciale sur la base du chiffrage ci-dessus :
Une hypothèse a été prise de répartir la charge de réalisation (15+45) sur 3 personnes soient 20 jours de délai. Le projet démarre au 1er septembre (T0). Au delà de ça, ce n’est qu’une représentation de la charge dans le temps, rien de plus.
Nous allons voir comment améliorer ce planning projet aussi bien sur le fond que sur la forme et faire prendre un bon départ au projet.
La phase de spécification du projet
Le projet démarre par la phase de spécification, si on déroule le projet dans sa tête, comment cela va-t-il se passer ?
– Démarrage T0 : généralement une réunion de lancement a lieu, avec une présentation des interlocuteurs, une relecture de la proposition commerciale, etc. Cela prend une demi-journée entre les transports, la réunion en elle-même et la rédaction du compte rendu et c’est sans compter la préparation pour peu que vous n’ayez pas participé à la rédaction de la proposition. Donc autant dire que les spécifications ne peuvent démarrer idéalement qu’à T0 +1 donc le 2 septembre.
– Travail de spécification : il consiste généralement en plusieurs ateliers avec le client, de la rédaction, de la réflexion et de l’analyse. L’expérience montre que le besoin n’est pas toujours très clairement exprimé, que les interlocuteurs métier ont encore besoin de réflexion ou tout simplement que la disponibilité des interlocuteurs est très réduite. Donc prévoir plus de délai que de charges, sans doubler non plus ! Dans notre cas, passons à 14 jours de délai pour 11 jours de charges.
– Validation des spécifications : contractuellement, les spécifications doivent être validées avant de commencer les développements donc la phase de validation doit apparaître dans le planning et est à mettre en évidence (en rouge par exemple) pour en montrer l’importance au client. En pratique, rien ne nous empêche de commencer plus tôt sur les parties du périmètre où l’on est sûr que c’est bon, le risque est tout de même à mesurer. On se créera ainsi de la marge en délai.
A moduler en fonction de la charge du collaborateur affecté au projet : si vous rédigez les spécifications et que vous faites la gestion de projet sur 2 autres projets, il vous faut prévoir un peu de marge en délai sans quoi vous allez travailler de longues journées ..
La phase de réalisation du projet
Continuons avec le planning de la réalisation du projet. 60 jours de réalisation en 20 jours soient 3 personnes à plein temps. Ca peut paraître bien mais en pratique ?
– Aurez-vous 3 personnes le jour J pour commencer la réalisation ? très souvent, vous en avez une sûre, la deuxième vous est confirmée 3 jours avant et la troisième va malheureusement arriver 3 jours après mais ne connaît pas le langage. Il faut donc anticiper les problèmes d’affectation car si vous ne pouvez commencer qu’avec une personne, peut-être devrez-vous monter en charge jusqu’à 5-6 personnes pour tenir le délai … à vous de bien coordonner ensuite !
– 3 personnes qui commencent le même jour, ça suppose un lancement collectif de la réalisation : expliquer le contexte, le livrable final, la méthodologie de la même manière aussi bien au développeur senior avec qui vous avez l’habitude de travailler qu’au jeune débutant qui a beaucoup à apprendre. Je préfère accueillir dans la mesure du possible chaque personne individuellement et donner des directives adaptées. Restons sur 3 personnes mais séparons les ressources de manière visible sur le planning.
– Peut-on paralléliser la réalisation de cette manière ? Idéalement, il faut descendre au niveau tâches pour être précis, connaître le chemin critique et détecter quelques contraintes supplémentaires (fourniture de pré-requis, ordonnancement particulier des tâches, etc.). De la même manière, il faut se projeter dans la réalisation : c’est mieux de définir une charte graphique dès le départ et créer des modèles pour éviter de repasser sur tous les écrans de l’application ensuite. Ce n’est souvent que du bon sens et un peu d’expérience. Mais il y a toujours un minimum incompressible, le fameux chemin critique : 9 femmes ne font pas un bébé en un mois !
– Idéalement, la reprise de données est à faire le plus tôt possible, d’une part parce que c’est une tâche qui peut être très chronophage pour des questions de qualité de données d’origine et de disponibilité client pour les traiter, d’autre part cela permet d’avoir des jeux de test concrêts et réalistes de la future application (les « toto », « 123 » et « coucou » ont leur limite …) et détecter des anomalies rapidement. Donc à positionner dès la fin des spécifications.
– Attention au calendrier : jours fériés et vacances peuvent vous mettre en retard .. ! Pour les jours fériés, dans notre exemple, les 1er et 11 novembre sont des jours de la semaine fériés. Imaginez que vous êtes en pic de charge à ce moment-là avec 6 personnes, vous perdez 12 jours-hommes de réalisation, 20% de la charge de développement, gloups ! Par ailleurs, dès que vous connaissez l’affectation sur le projet, demandez les congés pris par les personnes de l’équipe. Si vous devez vous engager sur un planning avant de connaître l’équipe, provisionnez des congés selon la période (Noël, juillet/août) et la durée du projet.
– Adapter les tâches aux profils : faire commencer quelqu’un d’expérimenté permet d’initialiser le projet avec de bonnes bases (écran d’exemple, arborescence des fichiers, …) que le reste de l’équipe pourra suivre. Penser éventuellement à garder un peu de marge sur la personne expérimentée pour qu’elle fasse de la relecture de code des autres personnes sans avoir le couteau sous la gorge en terme de délai à tenir pour ses propres développements. La faire terminer plus tôt pour démarrer les tests d’intégration (ou mieux les découper au fur et à mesure de la réalisation pour éviter les mauvaises surprises de fin de projet) et débloquer les problèmes de dernière minute.
– La documentation projet peut apporter un peu de mou sur la fin du projet pour occuper la personne en charge des corrections en recette en cas d’attente ou absorber de l’ultime retard. Vous pouvez négocier de ne livrer que la documentation d’installation dans un premier temps et livrer la documentation d’utilisation et d’exploitation avec un délai supplémentaire. A voir selon le contexte.
Autres remarques pour piloter le planning dès la phase d’avant-vente
– La recette : une semaine c’est trop court … Une demi-journée pour récupérer votre livraison, une journée pour l’installer car l’environnement n’est pas prêt, une journée pour débugger l’environnement, une journée off car le client a pris un congé (sans vous prévenir) .. La recette commence effectivement le 5ème jour ..
– Les pré-requis : ne pas hésiter à ajouter les pré-requis au planning, le client doit respecter les jalons sur la fourniture des éléments nécessaires à la réalisation, les deux parties sont ainsi engagées dans le planning.
– Bien mettre en évidence les phases où la disponibilité du client doit être forte. Comment faire les spécifications si l’interlocuteur clé n’est pas là pendant 3 semaines ? à vous de prévenir et d’anticiper le problème pour fournir un planning adapté.
Un peu de mise en forme du planning projet
A partir de là ça devient subjectif .. mais voici quelques unes de mes manies pour « embellir » le planning :
– J’intègre les informations au planning directement, ça me fait gagner de l’espace en supprimant les colonnes de gauche et je gagne en lisibilité. Je positionne les dates de début de tâches à gauche car elles ont une largeur fixe et le libellé de la tâche à droite.
– J’ajoute une tâche Gestion de projet qui fait la longueur du projet pour montrer la présence continue du chef de projet, cela rassure le client. Je la colore en jaune pour la rendre plus discrète car non primordiale.
– J’utilise des couleurs pour mettre en évidence certaines tâches-clés, attention à ce que ça reste lisible en impression noir&blanc …
Résultat : un planning projet plus solide et plus clair
Au final on obtient ce planning :
La recette démarre presque 10 jours plus tard, ça aurait pu être difficile de tenir l’engagement sur le premier planning. Maintenant, on a un peu de marge en délai qui compense la prise de risque (3 personnes en parallèle), on a une vision de la montée en charge et des disponibilités des personnes de l’équipe à la fin du projet. Le client voit également rapidement quand il doit s’impliquer.
Si vous avez régulièrement des problèmes de qualité de développement et constatez de nombreuses anomalies, vous pouvez enlever 10% de la charge de développement et créer une tâche pré-recette à la fin (ou en plusieurs fois) pour faire votre propre recette interne. Vous challengez ainsi votre équipe et pouvez augmenter significativement la qualité de la livraison.
Suivi du planning projet et pilotage
Le suivi tient ensuite plus du pilotage projet que du planning en lui-même, voilà ce qu’on peut dire :
– Un retard se détecte rapidement : le chef de projet de l’A380 ne s’est pas réveillé un matin en constatant qu’il avait 2 ans de retard sur son projet ..
– Suivre le planning revient à effectuer cet exercice encore et encore puisque plus le projet avance plus vous avez d’information et plus vous pouvez ajuster votre planning.
– Sortez la tête du planning, ajustez la fréquence de mise à jour en fonction du contexte, de la criticité, de l’expérience de l’équipe. Pour notre exemple, une fois par semaine est suffisant.
– Restez honnête avec vous-même, si vous constatez du retard, n’espérez pas trop longtemps le rattraper … Préparez rapidement les conséquences du retard, notamment la négociation de la date de livraison. Mieux vaut prévenir un mois à l’avance qu’on va avoir 3 jours de retard plutôt que la veille, vous permettez à votre client de se préparer, vous resterez crédibles et donnerez l’image d’un chef de projet qui maîtrise son projet.
Conclusions
– Un planning projet ne doit pas être généré automatiquement, c’est un instrument, pas seulement un reporting, un manche à balai pas un altimètre !
– La qualité d’un planning dépend de la capacité du chef de projet à se projeter, à être le plus proche de ce qui va réellement se passer, il faut rester pragmatique et anticiper les problèmes (jours fériés différents pour une équipe au Maroc, retard de validation, congés prévus de longue date, …).
– Faites confiance à votre feeling ! l’expérience doit vous servir à construire un planning, à sentir qu’un dispositif est meilleur qu’un autre …
Je vous invite d’ailleur à jouer au Jeu du chef de projet pour vous familiariser avec les indicateurs clés d’un projet et apprendre à prendre les bonnes décisions !
Et vous quels sont vos bonnes pratiques pour un planning projet ?
Voir également la série d’articles sur le chiffrage projet.
Les sources des plannings au format Microsoft Project : projets_mpp.zip
On sent qu’il y a eu des erreurs pour pouvoir diffuser ces conseils …
Ces conseils sont effectivement le résultat de coups de stress, de peurs, de soulagements, de soupirs, …
Merci pour cet article intéressant.
Ceci dit, dans la pratique, faute aux ressources, on a souvent besoin d’optimiser nos planning projet voire même de les compresser. Je trouve que cet article aborde très bien ce sujet: https://blog-gestion-de-projet.com/management-des-delais-du-projet/