Dans la tech, le produit, les startups avec le Lean Startup, le management.
On en parle comme d’une évidence, d’un standard, presque d’une vérité universelle.

Et pourtant, plus on creuse… plus une question apparaît :

Est-ce qu’on comprend vraiment ce qu’est le Lean ?

Le problème : un Lean réduit à des outils

Aujourd’hui, le Lean est souvent résumé à :

• réduire les gaspillages
• optimiser la Value Stream
• livrer plus vite
• améliorer en continu

Bref, une logique d’efficacité opérationnelle.

Le problème ?

Le Lean vient essentiellement du Toyota Production System (TPS).

C’est-à-dire : la production de voiture chez Toyota, et pas le développement de produit en lui-même.

Ce que l’on oublie : Toyota ne fait pas que du TPS

Toyota n’est pas performant uniquement parce qu’il optimise ses usines.

👉 Son vrai avantage est ailleurs : sa manière de concevoir ses produits

C’est ce qu’on appelle aujourd’hui le Toyota Product Development System (TPDS).

Et c’est là que tout change.

TPS vs TPDS : deux logiques « Lean » différentes

Le TPS (production) c’est :

• optimiser
• standardiser
• éliminer les variations
• améliorer l’existant

Ici, la logique est adaptée à la production de systèmes stables.

Le TPDS (développement produit), c’est :

• explorer
• apprendre
• expérimenter
• converger

Ici, la logique est adaptée à la création de systèmes complexes.

Ce qui veut dire que le TPS optimise ce qui est connu. Le TPDS explore/test ce qui ne l’est pas.

Le vrai problème : on applique le mauvais modèle !

Beaucoup d’organisations font aujourd’hui une erreur simple : elles appliquent une logique TPS… à des problèmes TPDS.

Exemples :

• planifier une roadmap produit comme une ligne de production
• figer une solution trop tôt
• optimiser un produit avant de savoir s’il a du sens

Résultat : rigidité, rework, et décisions fragiles à répétition…

De plus, dans un environnement produit, les besoins évoluent, les contraintes interagissent et les solutions ne sont pas connues à l’avance

Et on dépasse rapidement le cadre simple d’un produit, pour entrer dans un système complexe.

Et dans un système complexe :

❌ on ne peut pas tout prévoir
✔️ on doit apprendre en avançant

L’impact de l’ingénierie et de l’analyse de la valeur chez Toyota…

Le Lean, et plus largement les systèmes développés par Toyota (TPS pour la production, TPDS pour le développement produit), ne sortent pas de nulle part..

Toyota a intégré dès les années 50–70 :

• l’analyse fonctionnelle
• l’analyse de la valeur pour l’optimisation coût / valeur de la production
• l’ingénierie de la valeur pour la création de nouveau produit en éliminant, dès la conception, le superflu

Toutes ces techniques viennent des États-Unis (General Electric, Lawrence D. Miles, années 40)

Et dans les années 70, le choc pétrolier vient bouleverser l’industrie automobile mondiale.
Les constructeurs occidentaux, centrés sur des véhicules lourds et une production de masse rigide, se retrouvent en difficulté.

Toyota, de son côté, était déjà prêt. Grâce à cette intégration entre conception, coût et production, leurs véhicules sont plus économes, plus fiables, mieux adaptés aux contraintes du marché, et la production est standardisée, permettant une meilleure gestion des coûts.

Leur avantage ne vient donc pas uniquement de leur système de production, mais aussi de la cohérence entre ce qu’ils conçoivent et ce qu’ils produisent.

Et plutôt que d’appliquer les techniques comme des outils isolés, ils les ont progressivement intégrées dans un système complet de développement produit. Ce système évoluera ensuite vers un système d’apprentissage produit : le Set-Based Concurrent Engineering.

Aujourd’hui, le TPS applique une philosophie d’analyse de la valeur, et le TPDS applique l’ingénierie de la valeur.

Le cœur du système : le Set-Based Concurrent Engineering.

Toyota ne développe pas ses produits comme on l’imagine.

Ils ne font pas : définir → développer → tester

Ou en tout cas, pas de manière strictement séquentielle…

Ils font plutôt : explorer → apprendre → décider

L’application est simple… mais contre-intuitive :

Au lieu de choisir UNE solution très tôt :

• ils explorent plusieurs solutions en parallèle
• ils les testent progressivement
• ils éliminent celles qui ne tiennent pas

Jusqu’à converger vers une solution robuste.

Cette pratique définit le Set-Based Concurrent Engineering

Et en application ?

Concrètement, ça donne ça :

1. Identification des solutions possibles : toutes les options techniques sont envisagées.

2. Exploration parallèle : plusieurs équipes travaillent en même temps sur différentes pistes.

3. Convergence progressive : les contraintes (coût, production, qualité…) éliminent progressivement les options.

4. Décision tardive : on ne fige qu’une fois qu’on a suffisamment appris.

Et surtout :

On itère là où on apprend.
Quand on n’apprend plus, on fige. Puis on produit en série.

Le point clé : les équipes ne travaillent pas indépendamment…

Et c’est là que beaucoup se trompent sur Toyota ou le Lean en général.

Ce n’est pas juste des équipes en parallèle qui convergent tranquillement.

En réalité : les équipes se contraignent mutuellement.

Exemple :

• une décision sur un sous-système élimine des options ailleurs
• les contraintes circulent
• les solutions se réduisent puis se combinent

La convergence n’est donc pas un choix. C’est une élimination structurée et qui prend du temps.

Pourquoi ça marche ?

Parce que Toyota a compris une chose fondamentale…

Le développement produit est un processus de création de connaissance. Et pas juste un processus de production.

Et la recherche du zéro défaut structure fortement les décisions chez Toyota, car, ce qui compte le plus, c’est la satisfaction du besoin des utilisateurs, tout en gérant les coûts que cela engendre (la fameuse valeur dont tout le monde parle…)

Mais ce modèle crée un paradoxe : Toyota explore plus lentement… mais va plus vite.

Pourquoi ? Parce que moins de rework, des décisions plus robustes et moins d’erreurs tardives.

Aujourd’hui, beaucoup d’équipes produit :

• itèrent
• testent
• livrent

Mais sur une seule solution, et sans avoir réfléchi avant. Ce qui entraine des retouches à répétition, et à l’élaboration progressive de système lourd, que les infrastructures ou organisations environnantes ne peuvent pas supporter.

Et ça, ce n’est ni du TPDS, ni du Lean.

Conclusion.

Le problème n’est pas le Lean, ou les techniques que Toyoto a démocratisés. C’est le contexte dans lequel on les applique.

Dans les systèmes stables, le Lean optimise la production.
Dans les systèmes complexes, le Lean doit évoluer pour basculer sur le produit et devenir un système d’apprentissage.

Toyota, avec leur TPS/TPDS, ne cherche pas à avoir raison tôt. Ils cherchent à apprendre assez pour avoir raison tard.
Et c’est exactement l’inverse de ce que font la plupart des équipes aujourd’hui.

The post Lean et Toyota : pourquoi on se trompe (presque) tous appeared first on Yohan Pagnoux.

On a tendance à présenter la gestion de projet comme un ensemble de méthode.

Waterfall. Agile. Scrum. Prince2.

Comme s’il suffisait de choisir la bonne pour réussir.

C’est faux.

La gestion de projet ne repose pas sur une méthode.

Elle repose sur du bon sens, de la logique… et de la communication.

Le business de la méthode qui « marche », et de la méthode qui ne « marche pas »…

Beaucoup de contenus vendent des méthodes comme des solutions universelles.

« Applique Scrum et ton projet va fonctionner. »
« Structure ton projet en cycle en V et tout sera maîtrisé. »

Le problème, c’est que ces discours reposent souvent sur des cas particuliers.

Ce qui a fonctionné dans un contexte précis est présenté comme une vérité générale.

C’est un biais classique.

Mais un projet n’est jamais reproductible à l’identique.

Un projet ne commence pas par une méthode, mais par une question simple

Avant de parler d’outils, de planning ou d’organisation, il y a une question fondamentale :

👉 Est-ce qu’il y a réellement un problème à résoudre ?

Et surtout :

👉 Est-ce que ce problème justifie un projet ?

C’est ça, le vrai point de départ.

La gestion de projet n’est pas une exécution.

C’est un processus de questionnement.

Le cadrage : l’étape que tout le monde sous-estime

C’est dans la phase de cadrage que tout se joue.

C’est là que vous devez définir :

• le problème réel
• les résultats attendus
• les bénéfices pour l’organisation
• les ressources nécessaires

Mais surtout : c’est là que vous choisissez comment vous allez travailler.

Deux situations possibles :

• Soit la solution est claire, déjà connue, documentée.
• Soit elle ne l’est pas, et vous allez devoir explorer.

Et ces deux cas ne se gèrent pas de la même manière.

Adapter l’approche, au lieu de suivre une méthode…

C’est probablement l’erreur la plus fréquente : choisir une méthode… avant de comprendre le projet.

Dans la réalité :

• certains projets nécessitent une planification prédictive
• d’autres nécessitent une exploration progressive
• beaucoup nécessitent un mélange des deux

Ni Waterfall ni Agile ne garantissent quoi que ce soit.

Ce sont des cadres.

Rien de plus.

Le vrai travail consiste à construire une organisation adaptée à votre contexte.

L’itération est une nécessité, pas une option !

Un projet n’est jamais parfaitement défini dès le départ.

Il évolue. Votre compréhension évolue. Les contraintes évoluent.

C’est pour ça que la gestion de projet repose sur des cycles :

• collecter de l’information
• analyser
• tester
• ajuster

Encore et encore.

Ce processus est au cœur du pilotage. Pas la méthode.

Les outils ne sont que des supports…

Gantt, Trello, Jira…

Peu importe.

Un outil ne rend pas un projet meilleur.

Il rend simplement une organisation visible.

Le bon outil est celui qui correspond :

• au type de projet
• aux besoins de l’équipe
• au niveau de complexité

Certains projets nécessitent une planification détaillée.

D’autres fonctionnent mieux avec des cycles courts.

Et dans beaucoup de cas, il faut combiner plusieurs outils.

Un projet n’est jamais homogène !

Autre erreur fréquente : vouloir appliquer une seule méthode à tout le projet.

Dans la réalité, un projet est souvent composé de plusieurs phases très différentes.

Par exemple :

• une phase d’infrastructure
• une phase de développement
• une phase de déploiement

Chaque phase a ses propres contraintes. Et nécessite une organisation adaptée.

Une méthode unique ne permet pas de s’adapter à chaque situation.

La formation : le point souvent négligé !

Beaucoup rejettent la théorie.

« Ça ne correspond pas à la réalité. »

En réalité, le problème n’est pas la théorie.

C’est sa mauvaise compréhension.

Une bonne maîtrise des concepts permet :

• de comprendre les outils et les méthodes
• de choisir les bonnes approches
• d’adapter intelligemment les méthodes

Sans ça, on applique des choses… sans savoir pourquoi.

La communication : le vrai levier d’une méthode qui marche

Si vous devez retenir une seule chose, c’est celle-ci :

👉 un projet réussi est un projet où les gens se parlent

C’est par les échanges que vous :

• comprenez le besoin
• alignez les acteurs
• prenez les bonnes décisions
• ajustez votre trajectoire

Sans communication, tout le reste devient fragile. Et aucune méthode ne permet de corriger cela.

Conclusion

La gestion de projet n’est pas une méthode.

C’est une capacité à :

• comprendre une situation
• structurer une réponse
• s’adapter en permanence

Les méthodes, les outils, les frameworks…

Tout ça ne sert qu’à une chose : vous aider à réfléchir.

Mais ils ne remplaceront jamais le bon sens.

The post La gestion de projet n’est pas une histoire de méthode appeared first on Yohan Pagnoux.

Dans beaucoup de projets, quand il s’agit de faire une analyse de la valeur, on se pose toujours la mauvaise question.

« Qu’est-ce qu’on peut ajouter ? »

Alors qu’on devrait se demander :

« Qu’est-ce qui apporte réellement de la valeur ? »

C’est exactement là que l’analyse de la valeur intervient.

Et pourtant, elle est très peu utilisée.

Le problème : on produit sans réfléchir !

Un projet, c’est censé créer de la valeur.

Mais dans la pratique, on se focalise sur autre chose :

• les fonctionnalités
• les délais
• le budget
• la livraison

On mesure ce qu’on produit.

Mais rarement ce que ça apporte.

Résultat : on livre des produits complets… qui ne servent pas vraiment. Et qui coûtent cher à maintenir en bon état de fonctionnement.

La valeur, ce n’est pas ce que vous pensez…

Ce n’est pas une question de perception.

Ce n’est pas :

• « ça a l’air bien »
• « le client est content »
• « le produit est complet »

La valeur, c’est la capacité d’un produit à répondre à un besoin réel, de manière efficace.

Autrement dit : un produit crée de la valeur s’il permet d’obtenir un résultat concret.

Pas s’il est simplement « bien fait ».

L’analyse de la valeur : revenir à l’essentiel

L’analyse de la valeur repose sur une idée simple :

👉 un produit est défini par ce qu’il doit faire, pas par ce qu’il est !

On ne raisonne pas en fonctionnalités.

On raisonne en fonctions de service.

C’est-à-dire :

• les actions que le produit doit permettre
• les résultats qu’il doit produire
• les contraintes qu’il doit respecter

Cette approche permet de se concentrer sur le besoin réel, et non sur la solution.

Le piège : partir trop tôt sur la solution

Dans la majorité des projets, on fait l’inverse.

On parle directement :

• d’outils
• de technologies
• de fonctionnalités

Sans avoir clairement défini :

• le besoin
• les attentes
• les contraintes

Résultat : on optimise une solution… sans être sûr qu’elle soit pertinente.

Valeur = fonction / coût

L’analyse de la valeur s’appuie sur un principe fondamental :

👉 la valeur est un équilibre entre le service rendu et le coût engagé !

Un produit n’est pas « bon » parce qu’il est performant.

Il est bon s’il apporte le bon niveau de service… au bon coût.

Sinon :

• soit il est sous-dimensionné → il ne répond pas au besoin
• soit il est surdimensionné → il coûte trop cher pour ce qu’il apporte

Et dans les projets, la sur-qualité est beaucoup plus fréquente qu’on ne le pense.

La sur-qualité : le problème invisible

La sous-qualité est visible.

La sur-qualité ne l’est pas.

Et pourtant, c’est souvent là que se trouve le problème.

La sur-qualité, c’est :

• des fonctionnalités inutiles
• des performances excessives
• des exigences trop élevées

Tout ce qui dépasse le besoin réel.

Et ce surplus a un coût :

• développement
• maintenance
• complexité
• incompréhension

L’analyse de la valeur oblige à faire des choix

Faire de l’analyse de la valeur, ce n’est pas ajouter.

C’est arbitrer.

Cela oblige à :

• identifier les fonctions essentielles
• hiérarchiser leur importance
• éliminer ce qui n’apporte pas de valeur

Et surtout : accepter de ne pas tout faire.

Une démarche collective

L’analyse de la valeur ne se fait pas seul.

Elle repose sur une collaboration entre plusieurs acteurs :

• métier
• technique
• projet
• utilisateurs

Chacun apporte une vision différente.

C’est justement cette confrontation qui permet d’identifier ce qui est réellement utile.

Ce que ça change concrètement

Quand l’analyse de la valeur est bien faite :

• le périmètre est plus clair
• les priorités sont mieux définies
• les décisions sont plus simples
• les coûts sont maîtrisés

Et surtout : le produit est plus utile.

Pourquoi elle est si peu utilisée

Parce qu’elle demande du recul.

Et que le recul coûte du temps.

Dans beaucoup de projets, on veut aller vite.

Alors on saute cette étape.

Et on paie le prix plus tard.

Conclusion

L’analyse de la valeur n’est pas une méthode « en plus ».

C’est une façon de penser.

Elle oblige à se poser la seule question qui compte vraiment :

👉 est-ce que ce que je produis sert réellement à quelque chose ?

Et dans un projet, c’est probablement la question la plus importante.

The post L’analyse de la valeur, tout le monde en a besoin ! appeared first on Yohan Pagnoux.

Le document qui définit le besoin.

Le point de référence pour toutes les décisions.

Le socle de compréhension entre les parties prenantes.

Normalement, le document qui centralise tout cela, c’est le cahier des charges fonctionnel.

En théorie.

Dans la réalité, c’est souvent un document :

• mal compris
• mal rédigé
• mal utilisé

Et parfois… totalement inutile.

Le problème n’est pas le document, mais la logique derrière, et sa construction !

Beaucoup pensent que le cahier des charges sert à décrire une solution.

C’est faux.

Un cahier des charges fonctionnel sert à décrire le besoin et le service à rendre.

Pas la solution.

C’est une nuance fondamentale.

Parce que dès que vous décrivez une solution, vous limitez le champ des possibles.

Et vous prenez un risque : celui de résoudre le mauvais problème.

L’erreur classique : parler de « comment » au lieu de « quoi »…

Dans la majorité des projets, on voit apparaître très tôt :

• des choix techniques
• des fonctionnalités précises
• des outils imposés

Alors que le besoin n’est même pas stabilisé.

On saute directement à la solution.

Mais une bonne expression fonctionnelle des besoins consiste à répondre à une seule question :

👉 Qu’est-ce que le produit doit permettre de faire ?

Et pas :

👉 Comment il doit le faire ?

L’expression fonctionnelle : revenir au service rendu.

L’expression fonctionnelle des besoins consiste à définir le produit en termes de résultats attendus.

Autrement dit :

• ce que l’utilisateur doit pouvoir faire
• dans quelles conditions
• avec quelles contraintes

Une fonction de service est simplement une action attendue du produit pour répondre à un besoin

Exemple simple :

❌ “Créer une application mobile avec un système de notification”
✅ “Permettre à l’utilisateur d’être informé rapidement d’un événement important”

Dans le premier cas, vous imposez une solution.

Dans le second, vous ouvrez des possibilités.

Pourquoi c’est essentiel ?

Parce que le cahier des charges est utilisé par des personnes différentes :

• chefs de projet
• développeurs
• ingénieurs
• prestataires
• clients

S’il est mal formulé, chacun interprète à sa manière.

Et là, le projet part dans plusieurs directions.

Le rôle du cahier des charges fonctionnel est justement de créer un langage commun.

Le tableau fonctionnel : le cœur du sujet !

Un bon cahier des charges ne se limite pas à une description vague du besoin.

Il doit structurer les exigences.

C’est là qu’intervient le tableau fonctionnel.

Son rôle :

• définir les fonctions de service
• préciser les critères d’évaluation
• fixer des niveaux attendus
• indiquer les marges de flexibilité

Autrement dit, on ne se contente pas de dire ce qu’on veut.

On précise comment on saura que c’est atteint.

Cela permet de transformer une intention floue en exigence mesurable.

Le lien avec la valeur…

Un cahier des charges bien fait permet d’éviter un problème majeur : la surqualité.

Sans cadrage fonctionnel, les équipes ont tendance à :

• sur-développer
• ajouter des fonctionnalités inutiles
• complexifier le produit

Alors que l’objectif est simple : répondre au besoin, rien de plus.

Le cahier des charges permet justement de cadrer les résultats attendus et d’éviter de produire « trop ».

Et quoi de mieux, pour un prestataire, que de recevoir des exigences et des résultats à atteindre qui sont clairs, pour proposer la solution la plus adaptée ?

Une erreur fréquente : vouloir un cahier des charges exhaustif !

Beaucoup de cahiers des charges sont énormes.

Des dizaines, voire des centaines de pages.

Et pourtant… ils restent flous.

Pourquoi ?

Parce que la quantité ne remplace pas la clarté.

Un bon cahier des charges :

• va à l’essentiel
• structure l’information
• priorise les besoins

Tout le reste est du bruit.

Le rôle des priorités…

Tous les besoins ne se valent pas.

Et ne pas les hiérarchiser est une erreur majeure.

Des méthodes comme MoSCoW permettent de distinguer :

• ce qui est indispensable
• ce qui est important
• ce qui est optionnel
• ce qui est hors périmètre

Sans priorisation, tout devient critique.

Et un projet où tout est prioritaire… n’a plus de priorité.

Le cahier des charges n’est pas figé !

Autre erreur fréquente : considérer le cahier des charges comme un document définitif.

Un projet évolue.

Le besoin se précise.

Les contraintes changent.

Le cahier des charges doit donc évoluer aussi avant validation définitive.

Sinon, il devient rapidement obsolète.

Conclusion.

Le cahier des charges fonctionnel n’est pas un document administratif.

C’est un outil de réflexion.

Un bon cahier des charges fonctionnel :

• ne décrit pas une solution
• clarifie un besoin
• structure des exigences
• facilite les décisions

Et surtout : il évite de construire quelque chose… dont personne n’a réellement besoin.

The post Le cahier des charges : ce que tout le monde fait mal appeared first on Yohan Pagnoux.

C’est probablement la question la plus posée en gestion de projet.

Et aussi l’une des plus problématiques.

Parce que, dans la majorité des cas, la réponse est fausse.

Pas approximative.

Fausse.

Et pourtant, ce n’est pas un problème.

Les estimations ne sont pas des promesses !

La première erreur, c’est de confondre estimation et engagement.

Une estimation, c’est une approximation basée sur les informations disponibles à un instant donné.

Rien de plus.

Elle sert à réduire l’incertitude, pas à la supprimer.

D’ailleurs, une estimation ne garantit jamais un résultat exact. Elle permet simplement de s’en rapprocher

Mais dans beaucoup d’organisations, elle est traitée comme une vérité.

Et c’est là que les problèmes commencent.

On estime… sans comprendre…

Dans la pratique, les estimations sont souvent faites trop tôt.

Avant même que le besoin soit réellement clarifié.

On demande :

• un budget
• un délai
• un planning

Alors que :

• le périmètre est flou
• les contraintes sont mal identifiées
• les risques sont inconnus

Autrement dit, on estime… dans le vide.

Le biais de simplification !

Quand on estime, on simplifie.

On imagine un scénario « normal » :

• pas de blocage
• pas de dépendance critique
• pas de problème technique
• pas d’aléa organisationnel

Mais un projet réel ne se déroule jamais comme prévu.

Jamais.

Et pourtant, les estimations sont construites comme si c’était le cas.

Le problème, ce ne sont pas les estimations, mais leur interprétation !

Une estimation fausse n’est pas un échec.

C’est une conséquence normale de l’incertitude.

Le vrai problème, c’est ce qu’on en fait.

Dans beaucoup de projets :

• on fige l’estimation
• on construit tout dessus
• on refuse de la remettre en question

Résultat : le projet dérive, mais le cadre reste le même.

L’illusion du contrôle…

Plus un projet est incertain, plus on cherche à le contrôler.

Et donc à estimer précisément.

C’est paradoxal.

Parce que c’est justement dans ces situations que les estimations sont les moins fiables.

Certaines approches l’ont bien compris : quand l’incertitude est forte, on ne planifie pas la solution.

On planifie le chemin pour la découvrir.

Estimer, c’est collaborer

Une estimation faite seul est presque toujours mauvaise.

Pourquoi ?

Parce qu’elle repose sur une vision partielle.

Une estimation pertinente doit s’appuyer sur :

• l’expérience
• des projets similaires
• les compétences de l’équipe
• des échanges entre experts

C’est un travail collectif.

Pas un exercice isolé.

Ce qu’il faut vraiment faire avec les estimations…

Plutôt que chercher à faire « la bonne estimation », il vaut mieux :

• accepter qu’elle soit imparfaite
• la documenter (hypothèses, incertitudes)
• établir un planning de référence avec des estimations de références
• les réévaluer régulièrement (planification, exécution, contrôle)
• adapter le projet en fonction du réel

En résumé : traiter l’estimation comme un outil de pilotage, pas comme un engagement contractuel figé.

Le rôle des marges dans les estimations…

Un projet sans marge est un projet condamné.

Parce qu’il n’intègre aucune incertitude.

Les marges ne sont pas du confort.

Elles sont une nécessité.

Elles permettent d’absorber :

• les imprévus
• les erreurs
• les ajustements

Sans elles, le moindre écart devient critique.

Conclusion.

Les estimations ne sont pas faites pour être justes.

Elles sont faites pour aider à décider.

Le problème, ce n’est pas qu’elles soient fausses.

Le problème, c’est de croire qu’elles ne le sont pas.

Et tant que cette confusion existe, les projets continueront de dériver.

The post Les estimations projet sont fausses (et c’est normal) appeared first on Yohan Pagnoux.

« On va ajouter des fonctionnalités pour améliorer le produit ! »

C’est probablement l’une des erreurs les plus répandues en gestion de projet.

Sur le papier, ça paraît logique.

Plus de fonctionnalités = plus de possibilités = plus de valeur.

Sauf que dans la réalité… c’est souvent l’inverse.

Le piège de la « richesse fonctionnelle »

Quand un projet démarre, tout le monde a des idées.

Le client.
Les utilisateurs.
Les équipes.
La direction.

Chacun ajoute sa vision de ce que le produit devrait être.

Résultat : le périmètre grossit.

Et comme il est difficile de dire non, on empile.

Le produit devient plus complexe… sans être plus utile !

Chaque fonctionnalité ajoutée a un coût :

• développement
• maintenance
• compréhension
• utilisation

Mais surtout, elle crée de la complexité.

Et cette complexité a un impact direct :

• les utilisateurs comprennent moins bien le produit
• l’adoption diminue
• les erreurs augmentent
• la valeur perçue se dilue

Un produit trop riche devient difficile à utiliser. Et un produit difficile à utiliser… n’est pas utilisé.

La valeur ne vient pas du nombre de fonctionnalités !

Un produit crée de la valeur lorsqu’il résout un problème.

Pas lorsqu’il propose beaucoup de choses.

C’est une nuance importante.

Une fonctionnalité inutile, même parfaitement développée, n’apporte aucune valeur.

Pire : elle en détruit.

Parce qu’elle consomme des ressources qui auraient pu être utilisées ailleurs.

Le vrai problème : on confond besoin et fonctionnalités

Dans beaucoup de projets, les fonctionnalités sont définies trop tôt.

On demande : « Qu’est-ce qu’on doit développer ? »

Alors qu’on devrait demander : « Quel problème doit-on résoudre ?« 

C’est exactement le rôle du cadrage et du cahier des charges fonctionnel : définir le service à rendre, pas la manière de le rendre

Quand cette étape est mal faite, le projet dérive vers une accumulation de solutions.

L’incapacité à prioriser

Ajouter une fonctionnalité est facile.

Choisir de ne pas la faire est difficile.

Parce que prioriser, c’est renoncer.

Et dans beaucoup d’organisations, tout devient prioritaire.

Résultat :

• tout est « important »
• rien n’est vraiment critique
• les ressources sont dispersées

Et le produit perd en cohérence.

Le coût caché des fonctionnalités…

On parle souvent du coût de développement.

Mais on oublie le reste.

Chaque fonctionnalité entraîne :

• des tests supplémentaires
• plus de bugs potentiels
• plus de documentation
• plus de support utilisateur
• plus de dépendances techniques

Et ce coût continue… bien après la livraison.

La bonne approche : enlever plutôt qu’ajouter !

Les meilleurs produits ne sont pas ceux qui font le plus de choses.

Ce sont ceux qui font les bonnes choses.

Cela implique :

• identifier les fonctions réellement utiles
• pondérer et hiérarchiser leur importance
• accepter d’en éliminer certaines

Des méthodes comme MoSCoW existent justement pour ça : distinguer ce qui est indispensable de ce qui est accessoire

Mais encore faut-il accepter de les utiliser réellement.

Moins, mais mieux…

Un produit efficace est souvent un produit simple.

Pas simpliste.

Simple.

C’est-à-dire :

• compréhensible
• utilisable
• centré sur un besoin clair

Et cette simplicité est difficile à atteindre.

Parce qu’elle demande de faire des choix.

Conclusion

Ajouter des fonctionnalités ne rend pas un projet meilleur.

Ça le rend plus lourd.

Plus coûteux.

Plus difficile à piloter.

Et souvent… moins utile.

La vraie question n’est pas : « Qu’est-ce qu’on peut ajouter ? »

Mais : « Qu’est-ce qu’on peut enlever sans perdre de valeur ? »

C’est là que commence le vrai travail.

The post Plus de fonctionnalités ne crée pas plus de valeur appeared first on Yohan Pagnoux.

Le manque de temps, de budget, de ressources….

Parfois même… « les équipes ».

C’est rassurant.

Mais c’est rarement la vraie raison.

Le problème n’est presque jamais opérationnel !

Un projet qui dérape en exécution est souvent déjà condamné bien avant.

Simplement, personne ne s’en rend compte.

On pense que le problème vient :

• d’un retard
• d’un bug
• d’un manque d’organisation

Alors que ces éléments ne sont que des symptômes.

L’échec commence dès le cadrage !

Un projet mal cadré ne peut pas être bien exécuté.

C’est mécanique.

Si le besoin est flou, mal compris ou incomplet, alors tout le reste repose sur une base fragile :

• les décisions seront incohérentes
• les priorités instables
• les estimations biaisées
• les équipes désalignées

Et pourtant, le projet avance.

Parce qu’on produit.

Produire donne l’illusion d’avancer…

C’est l’un des pièges les plus dangereux.

Quand une équipe travaille, livre, développe, documente… on a l’impression que le projet progresse.

Mais produire n’est pas avancer.

Un projet avance uniquement lorsqu’il se rapproche de son objectif.

Sinon, il dérive.

Et cette dérive est souvent invisible au début.

Les décisions sont prises trop tôt (et mal)

Dans beaucoup de projets, on prend des décisions structurantes très tôt :

• choix techniques
• organisation
• roadmap
• périmètre

Le problème, c’est que ces décisions sont prises avec un niveau de compréhension encore faible.

On fige des choses… alors qu’on ne comprend pas encore le problème.

Résultat : on optimise une solution… qui n’est peut-être pas la bonne.

Le projet devient rigide… alors que le besoin ne l’est pas

Plus le projet avance, plus il devient difficile de changer :

• des dépendances apparaissent
• des coûts sont engagés
• des arbitrages ont été faits

Mais pendant ce temps, la compréhension du besoin évolue.

Et là, il y a un décalage.

Le projet est figé. Mais le besoin ne l’est pas.

Le vrai problème d’un projet raté : l’absence de remise en question !

Ce qui fait échouer un projet, ce n’est pas l’incertitude.

C’est l’incapacité à s’y adapter.

Un projet robuste n’est pas un projet parfaitement planifié.

C’est un projet qui :

• accepte de remettre en question ses hypothèses
• ajuste ses décisions en fonction du réel
• revoit son périmètre si nécessaire

Mais ça demande une chose que beaucoup d’organisations évitent : remettre en cause ce qui a déjà été décidé.

Pourquoi on ne le fait pas ?

Parce que ça coûte.

Pas seulement en argent.

Mais en ego, en crédibilité, en confort.

Revenir en arrière, admettre que le projet est raté, c’est reconnaître qu’on s’est trompé.

Et ça, peu d’organisations l’acceptent.

Alors on continue. Même quand on sait que ça ne va pas dans la bonne direction.

Ce qu’il faut vraiment surveiller…

Si vous voulez savoir si votre projet va échouer, ne regardez pas :

• le planning
• le budget
• l’avancement

Regardez plutôt :

• est-ce que le besoin est clair et partagé ?
• est-ce que les décisions peuvent être remises en question ?
• est-ce que l’équipe comprend pourquoi elle fait ce qu’elle fait ?
• est-ce que le projet s’adapte au réel ?

Si la réponse est non, le problème est déjà là.

Conclusion

Un projet n’échoue pas à cause de son exécution.

Il échoue parce qu’il a été mal compris dès le départ… et qu’on a refusé de l’admettre ensuite.

Et c’est pour ça que la gestion de projet n’est pas une question d’outils.

C’est une question de lucidité.

The post Un projet raté ne l’est pas pour les raisons que vous pensez appeared first on Yohan Pagnoux.

C’est vrai.

Mais ce qu’on ne vous dit presque jamais, c’est que la majorité des projets échouent… malgré une planification « correcte » sur le papier.

Pourquoi ?

Parce que la planification est souvent mal comprise.

La planification n’est pas un planning !

Dans beaucoup d’organisations, planifier un projet revient à produire un Gantt.

On liste des tâches, on met des dates, on affecte des ressources… et on considère que le projet est cadré.

Sauf que la planification, ce n’est pas ça.

La planification, c’est un processus systématique qui vise à définir comment le projet sera réellement exécuté, suivi et contrôlé

Autrement dit, ce n’est pas un document.

C’est une démarche. Un processus.

Le vrai rôle de la planification…

Planifier un projet, ce n’est pas prévoir l’avenir avec précision.

C’est réduire l’incertitude au maximum.

Concrètement, cela consiste à :

• comprendre ce que vous devez produire
• identifier les tâches nécessaires
• estimer les ressources et les délais
• anticiper les risques
• organiser le travail

Tout cela dans un objectif simple : utiliser efficacement les ressources pour atteindre un résultat dans un délai donné

Le piège : croire que tout est maîtrisable !

Beaucoup de chefs de projet pensent qu’une bonne planification permet de « sécuriser » le projet.

C’est faux.

Une planification ne sécurise rien.

Elle structure votre compréhension du projet à un instant T.

D’ailleurs, même dans les approches les plus prédictives, les estimations restent des… estimations.

Elles permettent de se rapprocher de la réalité, mais ne garantissent jamais son exactitude

Et c’est là que tout se joue.

Planifier dépend du niveau d’incertitude

Tous les projets ne se planifient pas de la même manière.

C’est une erreur classique de vouloir appliquer la même logique partout.

En réalité, votre façon de planifier dépend directement de votre niveau d’incertitude :

• Si tout est connu → vous pouvez planifier de manière détaillée dès le départ
• Si le besoin est partiel → vous planifiez progressivement
• Si le besoin est flou → vous planifiez en continu

Dans certains cas, la planification consiste même à organiser… l’apprentissage, ou la rédaction de la documentation.

Et pas uniquement la production.

Une planification efficace est forcément incomplète !

Une bonne planification n’est pas exhaustive.

Elle est suffisamment précise pour agir, mais suffisamment flexible pour évoluer.

C’est pour ça que la planification est un processus itératif.

Vous allez :

• affiner vos estimations
• ajuster vos ressources
• revoir vos priorités
• adapter votre organisation

Encore et encore.

La vraie compétence : naviguer dans l’incertitude !

La planification n’est pas une compétence technique.

C’est une compétence de pilotage.

Ce qui fait la différence, ce n’est pas votre capacité à produire un planning parfait.

C’est votre capacité à :

• comprendre ce que vous ne maîtrisez pas
• adapter votre plan en fonction du réel
• arbitrer entre coût, délai et qualité
• prendre des décisions avec de l’incertitude

Ce qu’il faut retenir…

Un projet bien planifié n’est pas un projet sans imprévus.

C’est un projet où l’équipe est capable de réagir aux imprévus sans perdre le contrôle.

Et ça, ça ne tient pas à Excel.

Ça tient à votre compréhension du projet.

Conclusion.

Arrêtez de voir la planification comme une formalité.

C’est l’un des rares moments où vous avez encore le pouvoir de réfléchir avant d’agir.

Et dans un projet, c’est souvent là que tout se joue.

The post La planification de projet, ce n’est pas un planning appeared first on Yohan Pagnoux.