Votre projet est-il bien cadré ?

Les dix points vérifiés

Le diagnostic passe en revue ces dix dimensions. Ce sont celles qui, sur des missions bancaires, industrielles et dans le secteur public, expliquaient l'essentiel des dérives que j'ai eu à rattraper.

1. 01 · Objectif

   L'objectif du projet est-il formulé en termes de résultat mesurable ?

   Un projet dont l'objectif est une liste de fonctionnalités ne peut jamais être déclaré réussi ou raté : il n'a pas de critère. Reformulez en résultat attendu — réduire un délai, un coût, un taux d'erreur — et fixez la cible avant d'écrire la première story.

2. 02 · Décideur

   Une seule personne tranche en cas de désaccord sur le périmètre ?

   L'absence de décideur unique est la première cause de périmètre qui gonfle : chaque partie prenante ajoute son besoin et personne n'a mandat pour dire non. Nommez ce rôle explicitement, et faites-le valider par la personne concernée.

3. 03 · Périmètre

   Ce qui est HORS périmètre est-il écrit noir sur blanc ?

   Un périmètre ne se définit pas seulement par ce qu'il contient. Écrire les exclusions transforme une discussion pénible en fin de projet en un arbitrage tranché au début, quand il coûte encore peu.

4. 04 · Parties prenantes

   Les équipes impactées ont-elles été consultées avant le lancement ?

   Une équipe qui découvre un outil le jour de la bascule le rejette, même s'il est meilleur. Identifiez les impactés en amont — support, métier, conformité — et faites-les contribuer, même brièvement.

5. 05 · Expression du besoin

   Le besoin est-il découpé en éléments livrables indépendamment ?

   Un besoin monolithique ne peut être ni priorisé ni livré progressivement : tout arrive en même temps, ou rien. Découpez par valeur métier plutôt que par couche technique.

6. 06 · Priorisation

   La priorisation repose-t-elle sur une règle explicite ?

   Sans règle affichée, la priorisation devient un rapport de force. Une méthode même imparfaite, appliquée visiblement, désamorce l'essentiel des tensions parce qu'elle déplace le débat sur les critères.

7. 07 · Critères de recette

   Les critères d'acceptation sont-ils écrits AVANT le développement ?

   Écrire les critères après coup revient à valider ce qui a été construit plutôt que ce qui était attendu. Rédigés avant, ils servent de spécification autant que de test, et suppriment l'essentiel des allers-retours.

8. 08 · Risques et dépendances

   Les dépendances externes sont-elles identifiées et suivies ?

   Les dépendances externes — un prestataire, une API partenaire, une validation conformité — sont la cause de retard la plus fréquente et la moins anticipée, parce qu'elles échappent à votre équipe. Suivez-les comme des tâches, avec un nom et une date.

9. 09 · Gouvernance

   Existe-t-il un rythme de comité fixé à l'avance ?

   Un comité qui ne produit pas de décisions écrites n'est qu'une réunion d'information. Le relevé de décisions, diffusé après chaque point, est ce qui empêche de rejouer les mêmes arbitrages trois mois plus tard.

10. 10 · Mesure du succès

    Saurez-vous mesurer le résultat après la mise en production ?

    Sans mesure initiale relevée AVANT la bascule, vous ne pourrez jamais démontrer le gain : il n'y aura pas de point de comparaison. C'est le chiffre qui justifiera le budget du projet suivant.