Partager!

Certaines des questions les plus populaires dans l'environnement du projet et, bien sûr, dans les processus d'évolution agiles montrent une rivalité entre le WBS et le Backlog. Bien qu'un tel combat soit quelque peu stupide à mon humble avis, voici quelques-unes des questions auxquelles je répondrai ci-dessous :

  1. Est-il préférable d'élaborer un WBS ou un Backlog ?
  2. Pourquoi les projets agiles - menés avec Scrum ou XP - n'ont-ils pas de SRT ?
  3. Comment puis-je planifier un projet s'il n'y a pas de portée définie dans un OTP ?

Je vais répondre ici à toutes ces questions - et à bien d'autres - pour vous aider à comprendre la structure de répartition du travail (SRT) et le système de gestion des ressources humaines. Backlog.

Qu'est-ce qu'un WBS ?

Dans le contexte des projets, une structure de répartition du travail (SRT). Par définition, le WBS est un décomposition hiérarchique de l'étendue totale des travaux à réaliser[1]Basé sur la définition la plus récente fournie par le Project Management Body of Knowledge ou PMBOK version 7.

L'OTP est un outil puissant et utile dans les contextes où il est possible de souscrire à la totalité de l'étendue des travaux, mais que faire s'il n'est pas possible ou pratique de souscrire à l'étendue du projet ?

L'OTP : un outil clé dans les environnements prédictifs

De nombreux chefs de projet pensent que l'incapacité à souscrire à l'ensemble de la portée du projet est un problème d'analyse ou de planification. Et si une mauvaise planification est souvent à l'origine de nombreux problèmes, l'OTP n'est pas un outil infaillible.

L'OTP est très utile - et seulement là - lorsque la le contexte de planification est prévisible. C'est-à-dire lorsque nos estimations et nos "prédictions" de ce qui va se passer ont une forte probabilité de se produire.

Une photographie d'une pomme dans la main d'une personne - comme si elle était prête à la lancer en l'air.

Prenons un exemple. Si vous lancez une pomme en l'air, vous pouvez être sûr qu'elle retombera à un moment ou à un autre. Bien sûr, nous pourrions imaginer que quelqu'un l'attrape en plein vol ou que des extraterrestres arrivent et attrapent la pomme avec un rayon gravitationnel, mais la vérité est que nous savons avec une certitude de presque 100% que la pomme va tomber. Même si vous vous souvenez du mouvement parabolique que vous avez appris à l'école, vous pouvez calculer où il va tomber. Nous lançons donc des fusées dans l'espace et récupérons les astronautes à leur retour. Nous pouvons prédire, avec un haut degré de certitude, ce qui va se passer.

C'est là que le WBS - la décomposition de la portée totale - est très utile. Mais qu'en est-il d'un environnement différent où il n'est pas possible ou pratique d'anticiper le résultat ?

EDT : Plus de problèmes que d'avantages dans les environnements complexes et adaptatifs

Imaginez un projet dont le périmètre n'est pas fermé. Certains maniaques du contrôle diront qu'il n'est pas possible qu'un projet existe sans une portée fermée. Pour illustrer mon propos, je vais utiliser une anecdote.

Défis dans les environnements adaptatifs

Il y a plusieurs années, dans l'un de mes cours pour un groupe de maîtrise, nous avons examiné le concept de projets adaptatifs et la nécessité d'établir des modèles de gestion de projet lorsque la portée n'est pas définie, pas du tout claire, ou lorsque, même si elle est définie, nous nous attendons à ce qu'elle change.

L'une des personnes du cours est venue me voir et m'a dit quelque chose comme ceci : "C'est le premier cours de ce master qui a un sens dans mon travail", et a poursuivi en expliquant que pour elle, le WBS, le calendrier détaillé des activités et le budget - résultat d'une telle ventilation et construction du calendrier, approche TOP-DOWN - était un véritable non-sens.

La raison de cette affirmation ? Elle travaillait dans la recherche scientifique et a expliqué que le problème le plus grave était que ces concepts "prédictifs" étaient également exigés par les entités qui allouaient les ressources de recherche. Pour elle et son équipe, l'accès aux ressources de recherche nécessitait la soumission d'un calendrier détaillé des activités et d'un budget.

Comment faire des projets à portée variable sans avoir de WBS ?

La nécessité de réaliser des projets sans portée fermée ou définie existe, et le problème méthodologique n'est pas mineur. On le voit dans la recherche scientifique, mais aussi dans les domaines d'innovation : pourrait-on demander à un domaine d'innovation de présenter un calendrier détaillé de ses activités en début d'année ? Ou encore, dans les domaines du marketing et de la publicité, ou de la gestion de l'image, pourrions-nous anticiper la réaction du public à une question particulière ? Et si nous n'avons pas le temps de faire des études de marché ?

Par conséquent, dans ce type de scénario, nous utilisons des structures plus flexibles et moins prédictives. C'est là que le Backlog comme l'une des alternatives.

Pourquoi le WBS ne fonctionne-t-il pas comme un Backlog ?

Revenons à la définition de l'OTP : décomposition hiérarchique de l'étendue totale des travaux. On y parle de portée totale et de décomposition hiérarchique.

Quatre différences entre le Backlog et le WBS

  1. Le champ d'application. Tout ce qui est inclus dans la SRT doit être réalisé pour achever le projet. Le backlog, quant à lui, peut contenir des éléments - de faible priorité - qui ne sont jamais livrés.
  2. Priorités. La WBS ne fixe pas de priorités, le travail est donc optimisé en fonction de la logique de résolution ou de construction du livrable (optimisation du processus de production). Le backlog est optimisé en fonction de la valeur pour l'entreprise, ce qui signifie qu'il est parfois possible de faire quelque chose puis de le "refaire différemment" ou de le "modifier" pour augmenter la valeur perçue.
  3. Structure. L'OTP est hiérarchique et, bien qu'il ne s'agisse pas d'une règle empirique, beaucoup utilisent une telle hiérarchie pour établir des phases ou des niveaux comparables - c'est-à-dire le niveau 0, le produit final à livrer, le niveau 1, les composants ou les phases du projet, le niveau 2, les comptes de contrôle, et ainsi de suite. Le backlog, malgré ce que beaucoup voudraient dire, peut comporter des éléments de nature différente tels que des user stories, des epics, des corrections, des améliorations, des cas d'utilisation, des exigences ponctuelles.
  4. Valeur commerciale. De nombreuses personnes incluent dans l'OTP - plus précisément dans le dictionnaire de l'OTP - le coût de réalisation d'un composant ou d'un élément particulier de la ventilation. L'arriéré peut inclure ce coût - rien ne l'interdit - mais il est classé par ordre de priorité en fonction de la valeur - l'avantage qu'il représente. Le coût et la valeur ne sont pas toujours synonymes, quelque chose de peu coûteux à réaliser peut être très bénéfique pour l'entreprise, et vice versa.

Nous pourrions probablement parler d'autres différences, mais celles-ci, à mon avis, sont les principales.

Mieux vaut un WBS ou un backlog ?

Ni l'un ni l'autre. Le WBS est essentiel et très utile si votre projet exige que vous ayez le contrôle de la portée - ce qui est fait, ce qui n'est pas fait et quand nous discutons si nous changeons l'une de ces deux réponses.

Le backlog, quant à lui, favorise l'adaptabilité. Ainsi, si votre projet est appelé à changer de portée ou à s'appuyer sur des cycles de retour d'information pour ajuster la portée, vous avez besoin d'un backlog et la tenue d'un WBS peut devenir un véritable casse-tête.

Est-il possible d'utiliser l'OTP et le Backlog en même temps dans un projet ?

Bien qu'à première vue, on pourrait dire... QUEL SANS-SENS. La vérité est que c'est possible, et parfois nécessaire. Imaginez un grand projet dont l'une des composantes est le développement d'une application mobile. Bien que le projet soit plus vaste et qu'il implique, par exemple, la formation de la force de vente, le lancement de produits et d'événements promotionnels, ainsi que d'autres activités prévisibles, le développement lui-même - qui pourrait être considéré comme un lot de travaux ou un compte de contrôle - et géré de manière dynamique en fixant la durée et le coût dans le plan.

Cela peut vous sembler un peu "alambiqué", mais les projets sont-ils tous simples ? Nous n'avons pas toujours le scénario du livre qui parle de 100% projets prédictifs ou 100% projets agiles. D'ailleurs, à l'avenir, j'espère que cette "différenciation" disparaîtra car elle ne fait que favoriser davantage la division.

Comment estimer le coût d'un projet sans WBS ou périmètre fermé ?

Alors, revenons aux questions difficiles. Bien qu'il y ait plus d'une bonne réponse, choisissons l'option la plus probable.

Si un projet doit démarrer sans une portée fermée ou entièrement définie, il est préférable de fixer une limite de temps et de budget pour valider un résultat - commercial ou social. Par exemple, lorsque nous avons découvert que nous devions, en tant que société, travailler à la mise au point d'un vaccin contre une nouvelle maladie, de nombreux gouvernements et entreprises privées ont mis de côté une somme d'argent fixe - une ligne budgétaire - et ont donné aux laboratoires des délais ou des créneaux horaires pour soumettre leurs résultats.

Ces projets à coûts et délais "fixes" sont gérés dans l'intention de "maximiser" le profit. En d'autres termes, je ne sais pas ce qui en sortira, mais ce sera le meilleur résultat que nous pourrons obtenir dans le temps et avec les ressources allouées.

Cela signifie que certains laboratoires ont réussi à trouver un vaccin et que d'autres n'y sont tout simplement pas parvenus et que les projets ont été annulés.

Si certains peuvent trouver ces approches "chanceuses", dans de nombreux contextes, tels que l'entrepreneuriat et l'innovation, elles constituent le seul modèle logique et cohérent.

Ici, l'important est d'être strict avec l'une des variables sous contrainte, le budget ou la portée. Sinon, nous nous retrouverons dans un projet sans fin qui ne prend pas d'engagements et ne donne pas de résultats.

Partager!

Commentaires et notes de l'auteur[+]

Image par défaut
Alberto Dominguez
Diriger des équipes de la théorie à la réalisation réelle et durable de produits et services informatiques innovants.
Publications: 33

2 commentaires

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

fr_FR