Comment évaluer les projets et gérer le screep de 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 le fluage de portée devrait être évité à tout prix, mais dans le monde réel, cela arrivera toujours.

Il est temps pour nous d'arrêter de jouer à ce jeu ridicule et de commencer à exécuter des projets d'une certaine manière. cela s'apparente moins au jeu qu'au suivi d'un processus robuste et fiable.

Est-ce que j'exagère ? C'est possible, 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 mènent des projets à peu près de la même manière :

1. Quelqu'un dans la direction demande qu'un projet soit achevé. Malheureusement, cette demande manque souvent de détails en termes de livrables et a tendance à n'avoir que des objectifs vagues.
2. Un comité de parties prenantes est réuni pour définir le projet en détail et décider de la portée. l'équipe qui le construira, et il leur est demandé d'estimer combien de temps cela prendra et combien cela coûtera. En conséquence, le fluage de la portée devient l'ennemi.
3. 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 digital nous apporte un retour d'expérience sans précédent sur le comportement des utilisateurs et permet de mettre en œuvre des changements relativement facilement (par rapport aux produits physiques). Pourtant, une fois la portée définie et un devis fourni, le projet est verrouillé, tout le monde hésite à 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'ils réalisent à mi-projet que des éléments critiques sont faux. Rester flexible et s'adapter à mesure que vous en apprenez plus est fondamental pour créer d'excellents services numériques. Le problème ne vient pas de la dérive de la portée, mais de 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 le cadre de ces contraintes, ce qui conduit à des raccourcissements.

Ce n'est pas que le les délais et les coûts étaient exacts en premier lieu. Les projets numériques sont compliqués, 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 sont peu pratiques dans le monde réel dans presque tous les cas, principalement parce qu'ils prennent trop de temps à appliquer. Estimer un projet se résume à l'intuition, à l'expérience et à une supposition éclairée !

Comme vous le dira quiconque a travaillé dans le domaine pendant un certain temps, la plupart des estimations sont une œuvre de 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 la faute lorsque le projet manque inévitablement son échéance et dépasse le budget.

Heureusement, il existe un moyen de fournir des informations précises. estimations et la gestion des dérives de portée qui impliquent de modifier les projets en cours. Le secret réside dans la division des projets en plus petits morceaux. Cette approche évite d'entreprendre des projets importants et complexes.

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

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

Lorsqu'un client me propose d'entreprendre un projet numérique (qu'il soit grand ou petit), je le divise généralement en quatre étapes qui se produisent. dans l'ordre suivant :

1. Discovery,
2. Alpha,
3. Minimum viable product,
4. Itération et optimisation en cours .

Chaque étape est un engagement distinct avec des livrables clairs. Par conséquent, je ne m'engage 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 la portée 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 suivanteune fois l'étape précédente terminée.

Au lieu d'estimer un programme de travail complet, 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écouverteje travaille avec les parties prenantes pour valider le projet. Selon la taille globale du projet, cela peut être aussi simple que quelques réunions ou un programme de travail complet.

Cela comprend généralement 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 ;
• rassembler les opinions des parties prenantes.

L'idée est que la phase de découverte fournira un 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 requis 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 celle où nous définissons comment le service numérique (qu'il s'agisse d'une application Web ou d'un site) fonctionnera et veillons à ce que les utilisateurs aient une expérience positive en l'utilisant.

Cela se fait généralement via le création d'un prototype. Sur des projets plus petits, cela peut 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.

• Premièrement, 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. se glisser plus loin quand il est plus coûteux à traiter.
• Enfin, si nous avons quelque chose de tangible, nous pouvons le tester avec les utilisateurs pour s'assurer qu'il sera adapté à l'usage avant d'aller au coût de la construction de la vraie chose.

S'il 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 nécessaire à l'étape suivante. Avoir une visualisation de ce qui doit être construit rend l'estimation du travail requis beaucoup plus facile pour toutes les parties prenantes impliquées. Ils peuvent voir ce qu'on leur demande de construire.

De plus, nous pouvons utiliser les enseignements tirés des tests de l'alpha pour adapter ce que nous allons créer, créant à nouveau de l'espace pour des changements de portée sans faire dérailler le projet. [19659003] Une fois que nous avons l'alpha, nous pouvons alors passer en toute confiance à la construction, sachant que nous créerons 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 réitérés pour s'assurer qu'ils sont aussi efficaces que possible.

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

En l'appelant le produit viable minimal, nous soulignons qu'il y aura une itération post-lancement. Cela nous fournit un moyen de gérer le fluage de la portée et la complexité imprévue en le 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 suspendrons certaines choses jusqu'au post-lancement. Ces éléments deviennent alors la base pour définir notre étape finale, nous permettant de faire une première estimation pour l'optimisation post-lancement.

4. Itération et optimisation continues

La phase de 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 les services numériques. ' efficacité.

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 les complétant séparément, vous éliminerez bon nombre des défis auxquels nous sommes confrontés lors de l'utilisation des approches traditionnelles de gestion de projet.[19659068]Pourquoi la décomposition des projets fonctionne

Quatre avantages importants découlent de cette décomposition des projets :

• Chaque phase est mieux définie.
  Parce que les livrables de la phase précédente définissent chacune é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 plus précisément.
  Par exemple, au lieu d'avoir à deviner combien de temps il faudra pour livrer un important, projet nébuleux avec un nombre substantiel d'inconnues, vous estimez seulement la phase suivante et le faites sur la base des livrables de la phase précédente.
• Il en résulte de meilleurs services numériques.
  Parce que des idées de projet sont validés et testés avec les utilisateurs, vous pouvez être plus sûr que le produit final correspondra à l'objectif. Cela permet également d'adapter la portée et les fonctionnalités entre les phases pour vous assurer de fournir le meilleur résultat possible.
• C'est une approche moins risquée.
  L'entreprise qui met en service le service numérique n'a pas besoin de s'engager dans l'ensemble du projet dès le départ. 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 n'est pas bien testé 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 l'engager pour une phase de découverte afin de voir à quoi elle ressemble. S'ils sont bons, ils peuvent continuer à travailler avec eux. Sinon, ils peuvent transmettre 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 car le client ne sentait pas qu'il prenait un risque sur un si petit investissement initial. De plus, ils n'ont pas ressenti le besoin de parler à divers fournisseurs car s'ils ne m'aimaient pas, ils pourraient facilement changer. Plus facile. Bien sûr, cela ne fournira pas comme par magie une estimation ou n'empêchera pas le fluage de la portée. Cependant, cela rendra l'estimation plus gérable, car vous ne définissez qu'une partie à la fois. Cela vous permettra également de travailler avec le fluage de portée, plutôt que d'essayer de le supprimer.

Donc, mon conseil, que vous travailliez en interne ou en externe, sur des sites grands ou petits, est d'arrêter d'essayer d'estimer et de définir la portée des 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 aurez 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.

(vf, yk, il)