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.