Comment établir le prix des projets et gérer le fluage de la portée

Je suis sûr que vous avez lu des articles irréalistes qui suggèrent qu'il existe une approche scientifique de la tarification qui vous permettra comme par magie de créer un devis précis. Vous avez peut-être également été amené à croire que la dérive de la portée doit être évitée à tout prix, mais dans le monde réel, cela se produira toujours.

Il est temps pour nous d'arrêter de jouer à ce jeu ridicule et de commencer à gérer des projets d'une manière qui ressemble moins à un pari et plus à la suite d'un processus robuste et fiable.

Est-ce que j'exagère ? Peut-être, mais regardons où les choses tournent si souvent mal avec les projets numériques.

Les problèmes avec notre processus de projet

D'après mon expérience, la plupart des organisations de tous les secteurs gèrent des projets à peu près de la même manière :

1. Quelqu'un dans la direction demande qu'un projet soit terminé. Malheureusement, cette demande manque souvent de détails en termes de livrables et tend à n'avoir que des objectifs vagues.
2. Un comité de parties prenantes est constitué pour définir le projet en détail et décider de son périmètre.
3. La portée détaillée est ensuite transmise à l'équipe qui la construira, et on lui demande d'estimer combien de temps cela prendra et combien cela coûtera.
4. Le projet est livré conformément aux spécifications, en mettant l'accent sur la livraison dans les délais et dans les limites du budget. En conséquence, le fluage de la portée devient l'ennemi.
5. Le projet est livré et tout le monde passe au projet suivant dans sa liste de tâches.

Cette approche est loin d'être idéale, en particulier pour les projets numériques. Le numérique nous fournit un retour d'information sans précédent sur le comportement des utilisateurs et facilite relativement la mise en œuvre des changements (par rapport aux produits physiques). Pourtant, une fois le périmètre défini et un devis fourni, le projet se verrouille, tout le monde hésitant à apporter des modifications au fur et à mesure de l'avancement du projet.

Pourtant, inévitablement, la portée finit par changer, principalement parce que les parties prenantes ont des interprétations différentes de ce qui sera construit ou parce qu'elles réalisent à mi-projet que des éléments critiques sont erronés.

En vérité, il n'y a rien de mal avec le fluage de la portée . Rester flexible et s'adapter au fur et à mesure que vous en apprenez est fondamental pour créer d'excellents services numériques. Le problème n'est pas la dérive de la portée, mais la façon dont nous gérons les projets.

Malheureusement, parce que les délais et les coûts ont été convenus, nous essayons d'apporter ces changements dans ces contraintes, ce qui entraîne des raccourcis.

Non pas que les délais et les coûts aient été exacts en premier lieu. Les projets numériques sont complexes, impliquant souvent des spécialistes et des parties prenantes travaillant ensemble. En conséquence, ils sont notoirement difficiles à estimer avec précision.

J'ai lu de nombreux articles qui proposent des méthodologies pour estimer avec précision. Cependant, ils ne sont pas pratiques dans le monde réel dans presque tous les cas, principalement parce qu'ils prennent trop de temps à appliquer. L'estimation d'un projet relève de l'intuition, de l'expérience et d'une supposition éclairée !

Comme vous le diront tous ceux qui ont travaillé dans le domaine, la plupart des estimations sont une fiction . Nous n'en savons généralement pas assez à l'avance, même pour déterminer quelle est la bonne solution ou comment les utilisateurs pourraient y répondre. Il est donc impossible d'estimer avec précision l'ensemble d'un projet à l'avance.

Malheureusement, cette ambiguïté conduit souvent à répartir injustement le blâme lorsque le projet rate inévitablement son échéance et dépasse son budget.

Heureusement, il existe un moyen de fournir des estimations précises et de gérer les glissements de périmètre qui impliquent de modifier les projets d'exécution. Le secret réside dans la division des projets en plus petits morceaux. Cette approche évite d'entreprendre des projets importants et complexes.

Diviser les projets en une série d'engagements plus petits

Je dois être clair à ce stade. Je ne dis pas que des programmes de travail ambitieux sont mauvais. Je travaille pour de gros clients sur des sites web conséquents et des programmes de travail tentaculaires. Cependant, je traite rarement ces engagements comme un seul grand projet. Au lieu de cela, je les décompose en projets plus gérables que je délimite un à la fois.

Lorsqu'un client m'approche pour entreprendre un projet numérique (qu'il soit grand ou petit), je le décompose généralement en quatre étapes qui se déroulent dans l'ordre suivant :

1. Découverte,
2. Alpha,
3. Produit minimum viable,
4. Itération et optimisation continues.

Chaque étape est un engagement distinct avec des livrables clairs. Je ne m'engage donc pas sur l'ensemble du projet mais uniquement sur la première phase. Cela facilite grandement l'estimation et la gestion de la dérive de la portée.

Par exemple, il vous suffit de définir le périmètre de l'étape suivante. Cela vous permet de mieux gérer le fluage de la portée, car vous pouvez l'adapter lorsque vous définissez l'étape suivante , une fois l'étape précédente terminée.

Au lieu d'estimer un programme de travail entier, vous estimez le prochain projet de ce programme. En outre, vous pouvez utiliser l'étape précédente pour vous aider à estimer plus précisément.

Chaque étape permet de définir et d'estimer l'étape suivante, en commençant par la découverte.

1. Découverte

Dans la phase de découverte, je travaille avec les parties prenantes pour valider le projet. Selon la taille globale du projet, cela pourrait être aussi simple que quelques réunions ou pourrait être un programme de travail complet.

Généralement, il comprend des éléments tels que :

• effectuer des recherches sur les utilisateurs ;
• analyser la concurrence;
• identifier les indicateurs de performance clés ;
• définir à quoi ressemble le succès ;
• comprendre les contraintes;
• recueillir les avis des parties prenantes.

L'idée est que la phase de découverte fournira une définition plus éclairée du projet, y compris les besoins des utilisateurs, les objectifs commerciaux et ce qui doit être créé.

Plus important encore, cela validera que le projet fournira la valeur requise.

Nous pouvons ensuite utiliser ce livrable pour définir et estimer le travail nécessaire dans une phase alpha. Cela rend nos estimations plus précises et ajuste également la portée en fonction de ce que nous avons appris.

2.Alpha

La phase alpha est l'endroit où nous définissons le fonctionnement du service numérique (qu'il s'agisse d'une application Web ou d'un site) et veillons à ce que les utilisateurs aient une expérience positive en l'utilisant.

Cela se fait généralement par la création d'un prototype. Sur des projets plus petits, cela pourrait n'être rien de plus que des maquettes de conception. Sur des projets plus importants, il peut s'agir d'un prototype fonctionnel que les gens peuvent essayer.

Quoi qu'il en soit, l'idée est de visualiser le service numérique que vous construisez.

Nous le faisons pour trois raisons.

• Tout d'abord, une visualisation garantira que toutes les parties prenantes ont une vision partagée de ce que vous créez. Un document peut être interprété de différentes manières, mais c'est beaucoup plus difficile à faire avec un prototype.
• Deuxièmement, un prototype permettra d'identifier beaucoup plus facilement tout ce qui aurait pu être négligé , afin d'éviter une dérive de la portée plus loin dans la ligne lorsqu'il est plus coûteux à résoudre.
• Enfin, si nous avons quelque chose de tangible, nous pouvons le tester avec les utilisateurs pour nous assurer qu'il sera adapté à l'usage avant de nous lancer dans la construction de la vraie chose.

Si cela teste mal, nous avons encore de la place avant la prochaine phase pour nous adapter sans casser le budget ou gâcher le calendrier.

Comme pour la phase de découverte, nous pouvons utiliser l'alpha pour estimer le travail requis à l'étape suivante. Avoir une visualisation de ce qui doit être construit facilite grandement l'estimation du travail requis pour toutes les parties prenantes impliquées. Ils peuvent voir ce qu'on leur demande de construire.

De plus, nous pouvons utiliser les leçons tirées des tests de l'alpha pour adapter ce que nous allons créer, créant une fois de plus un espace pour des changements de portée sans faire dérailler le projet.

Une fois que nous avons l'alpha, nous pouvons alors passer en toute confiance à la construction, sachant que nous allons créer la bonne chose et que les utilisateurs y répondront positivement.

3. Produit minimum viable

J'avais l'habitude d'appeler cette étape la « construction ». Cependant, j'ai constaté que les parties prenantes associaient la finition de la construction à l'achèvement du projet. En réalité, les services numériques ne sont jamais terminés, car ils doivent être constamment itérés pour s'assurer qu'ils sont aussi efficaces que possible.

Pour éviter ce problème, j'ai commencé à désigner cette étape comme le produit minimum viable (MVP). Au cours de cette étape, nous construisons et lançons la version initiale du service numérique.

En le qualifiant de produit minimal viable, nous soulignons qu'il y aura une itération post-lancement. Cela nous permet de gérer la dérive de la portée et la complexité imprévue en les repoussant jusqu'au post-lancement. Cela garantit que le projet reste sur la bonne voie et maintient son élan.

Inévitablement pendant la construction, nous mettrons certaines choses de côté jusqu'au post-lancement. Ces éléments deviennent ensuite la base de définition de notre étape finale, nous permettant de faire un premier devis d'optimisation post-lancement.

4. Itération et optimisation continues

La phase post-lancement traite de la fonctionnalité, de la complexité et d'autres problèmes que nous n'avons pas abordés dans le MVP. Cette liste d'améliorations est relativement facile à évaluer à ce stade et peut être estimée avec une précision raisonnable.

Cependant, en plus de ce travail, il devrait y avoir un processus continu de surveillance, d'itération et de test qui affine davantage l'efficacité des services numériques.

L'estimation de la part de ce travail que vous entreprenez doit être basée sur la taille et la complexité du service numérique. Votre estimation doit également être proportionnelle à l'investissement dans le reste du projet.

En décomposant vos projets en quatre phases et en complétant chacune séparément, vous éliminerez bon nombre des défis auxquels nous sommes confrontés lors de l'utilisation d'approches de gestion de projet traditionnelles.

Pourquoi la décomposition des projets fonctionne

Quatre avantages significatifs découlent de la décomposition des projets de cette manière :

• Chaque phase est mieux définie .
  Parce que les livrables de la phase précédente définissent chaque étape, cela signifie qu'il y a une vision claire de la direction. Cela aide les parties prenantes à comprendre où vont les choses et évite les mauvaises surprises plus tard.
• Les projets sont estimés avec plus de précision .
  Par exemple, au lieu d'avoir à deviner combien de temps il faudra pour livrer un projet important et nébuleux avec un nombre substantiel d'inconnues, vous ne faites qu'estimer la phase suivante et le faire sur la base des livrables de la phase précédente.
• Il en résulte de meilleurs services numériques .
  Parce que les idées de projet sont validées et testées avec les utilisateurs, vous pouvez être plus sûr que le produit final répondra à l'objectif. Cela permet également d'adapter la portée et les fonctionnalités entre les phases pour vous assurer d'obtenir le meilleur résultat possible.
• C'est une approche moins risquée .
  L'entreprise qui commande le service numérique n'a pas besoin de s'engager sur l'ensemble du projet en amont. Si la phase de découverte ne parvient pas à valider la viabilité du projet, il peut être abandonné avec une perte mineure. De même, si le prototype alpha ne se teste pas bien auprès des utilisateurs, il peut être adapté avant que les choses ne deviennent trop chères.

Ce dernier point est rassurant si un fournisseur extérieur est utilisé pour la première fois. Au lieu d'engager une agence pour un projet substantiel sans savoir si elle peut livrer, le client peut les engager pour une phase de découverte pour voir à quoi ils ressemblent. S'ils sont bons, ils peuvent continuer à travailler avec eux. Sinon, ils peuvent apporter les résultats à une autre agence sans rien perdre.

Si vous dirigez une agence ou êtes un indépendant, vous pourriez penser que cela semble être une mauvaise idée. Naturellement, vous préféreriez inscrire un client pour l'ensemble du projet. Cependant, j'ai évité de nombreux appels d'offres avec cette approche parce que le client n'avait pas l'impression de prendre un risque sur un si petit investissement initial. De plus, ils n'ont pas ressenti le besoin de parler à différents fournisseurs car s'ils ne m'aimaient pas, ils pouvaient facilement changer.

De plus, l'utilisation de cette approche progressive facilitera grandement la définition et la tarification de votre prochain projet à prix fixe. Bien sûr, cela ne fournira pas comme par magie une estimation ou empêchera le glissement de la portée. Cependant, cela rendra l'estimation plus facile à gérer, car vous ne délimitez qu'une partie à la fois. Cela vous permettra également de travailler avec le fluage de la portée, plutôt que d'essayer de le supprimer.

Alors mon conseil, que vous travailliez en interne ou en externe, sur de grands ou de petits chantiers, c'est d'arrêter d'essayer d'estimer et de dimensionner les projets sans les décomposer en phases. Au lieu de cela, abordez une phase à la fois et utilisez ce que vous apprenez pour informer la suivante . Si vous le faites, vous ferez une estimation plus précise, vous aurez la possibilité de vous adapter en fonction de ce que vous apprenez et vous constaterez que la gestion de projet est plus simple.