Interrogé dernièrement dans le cadre de la mise à jour d’un schéma directeur informatique, il nous a été demandé d’arbitrer entre différents projets informatique pour décider de les lancer ou non. Le « Go ? No go ? » est peut-être la question la plus fréquente et la plus importante qu’un responsable de projet (avec l’aide de ses collègues) va se poser avant de prendre en charge un projet, qu’il soit en approche projet « prédictive » ou agile. Est-ce la bonne formulation pour décider ou non de lancer un projet et quelles sont les autres variantes.

De nombreuses approches de gestion de portefeuille de projets estiment que le « Go ? No go ? » est un processus de prise de décision trop binaire, ce que l’on peut donc considérer comme une erreur. Quelques exemples de décision d’y aller pour un projet :

  • Nous avons réalisé une bonne année, nous avons le budget, c’est le moment de nous lancer dans ce nouveau projet.
  • Parmi la concurrence, il va y avoir une nouvelle offre plus performante que la notre. Et si on avançait notre lancement de projet de quelques mois ? Cela nous permettrait d’aborder cette concurrence dans de bonnes conditions.
  • Avec de la marge supplémentaire ajoutée au planning, j’accepte d’embarquer dans mon projet les futures demandes du marketing non exprimées à ce jour, et je lance mon projet en l’état.
  • Et si on découpait le projet en s’arrêtant à mi-parcours pour faire un petit état des lieux sur les nouveaux besoins, avant d’entamer la deuxième phase et limiter les risques ? On lance de suite le projet et on laisse ainsi les idées se mettre en place et se préciser et on continue après avec de bonnes visibilités sur les fonctionnalités à offrir et à ajouter à notre projet.
  • Les conditions du projet sont proches de mes limites en gestion de projet et des connaissances techniques de l’équipe. Je décide de partir avec un consultant plus expérimenté, qui en plus connaît bien cette nouvelle technologie. Je l’engage contractuellement jusqu’à la fin estimée de mon projet.

Du point de vue gestion de projet, le « Go ? No go ? » est souvent une erreur, voire un danger. En effet, si au vue des conditions internes et externes au projet, un décideur ou un chef de projet choisit la réponse « Go », il part et lance son projet avec le sentiment que le déroulement pourra se réaliser dans son intégralité suivant le plan initial. En clair, il se met des œillères, et aura du mal à changer de plan de projet si les conditions sont différentes des prévisions.

Les nouvelles approches de gestion de projet, et en particulier l’agilité, proposent donc une variante : « Start / Continue ». L’expérience sur les nombreux projets nous a fait comprendre à quel point il est important de toujours rester méfiant vis-à-vis des prévisions initiales d’un projet et d’avoir un plan B, voir C, D…

Avant le lancement, le chef de projet doit analyser tous ses paramètres projet et conclue que le lancement du projet est possible. La prochaine réflexion se fera une fois le projet lancé, à savoir si celui-ci peut se poursuivre jusqu’à destination suivant le plan projet initial, ou s’il y a nécessité de se dérouter, c’est à dire, modifier le périmètre, les délais, le budget, l’équipe… Ainsi, le chef de projet n’arrête pas le processus de prise de décision une fois le projet lancé. Il sait que les conditions lui permettent dans un premier temps de démarrer son projet, et il affinera l’analyse une fois lancé afin de répondre à la seconde interrogation : « Continue ? ».

Conclusion

Ces stratégies de conduite de projet, basées ou non sur les approches agiles, demandent un peu d’expérience (avant de se lancer dans des prises de décisions complexes), de jugement et bien sûr nécessite de la préparation en amont. Elles n’excusent en rien les mauvaises prises de décisions ou les comportements du genre « On va voir ce que ça donne une fois le projet lancé ou les premières livraisons effectuées ». Un projet ce n’est pas binaire, il faut savoir ajuster son pilotage et ses décisions tout le long de son déroulement, et jusqu’à la fin, pour bien le finaliser.

Vous avez aimé cet article ? Alors partagez-le avec vos relations en cliquant sur les boutons ci-dessous :

 

Méthode Agile, agilité en entreprise, agilité en gouvernance… ce mode de management de projets est à la mode depuis maintenant quelques années. Ce management « agile » est inspiré d’une approche dans le développement d’applications informatiques. Cette approche a été conçue pour remédier aux écarts constatés entre les attentes des utilisateurs et les outils informatiques livrés suite aux développements. Pour cela, on applique un manifeste qui conseille l’adaptation aux changements, plutôt que le suivi d’un plan, on livre fréquemment le logiciel informatique fonctionnalité par fonctionnalité, on privilégie le dialogue en face à face via des points quotidiens.

Cette approche projet et de management d’équipe a eu un tel succès dans l’informatique qu’elle a rapidement été appliquée au niveau des autres entités de l’entreprise, RH, marketing, production.

Le succès a été tel que l’approche agile est arrivée à l’Elysée et le terme est fréquemment employé par le président français lui-même, Emmanuel Macron.

Mais désormais, Emmanuel Macron doit rire jaune avec l’approche agile et les gilets (il fallait bien que je place quelque part ce jeu de mots un peu tordu … bon, ça c’est fait 😉 ).

En effet, avec la crise des « gilets jaunes », on constate une nouvelle fois, l’importance de la bonne prise en compte des parties prenantes, de la conduite du changement, de la gestion des risques… dans tout projet, qu’il soit agile ou non. On ne peut que constater en France, que l’approche agile du nouveau gouvernement et la rapidité de la mise en place des nouvelles réformes n’ont pas obtenu l’adhésion de toutes les parties prenantes, c’est à dire, de tous les Français.

Moralité, au 21e siècle, et malgré l’approche agile, on peut aller droit à l’échec d’un projet, qu’il soit informatique, d’un autre secteur de l’entreprise ou politique.

Donc, un conseil à notre président et aux managers, oui à l’agilité, mais pas au détriment des parties prenantes de vos projets, sinon, vous allez vous prendre une veste, qu’elle soit jaune ou pas ! Avant de vous lancer un peu trop vite dans vos « sprints » projets, analysez bien les impacts sur les parties prenantes, essayer de répondre à leurs attentes et prenez en compte l’ensemble des acteurs impliqués ou pouvant influencer votre projet. Ce n’est pas simple, mais c’est tout le charme du management et des facteurs humains !

Vous avez aimé cet article ? Alors partagez-le avec vos relations en cliquant sur les boutons ci-dessous :