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.

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.