# NUPP Les Principes Quasi Universels de Projets [image] NUPP fait partie d’OMIMO (https://omimo.org/fr/), une famille de modules ouverts et minimalistes. Ce manuel peut être utilisé et distribué librement conformément à la licence Creative Commons Attribution 4.0 International. OMIMO est cofinancé par l’Union européenne. Les points de vue et opinions exprimés n’engagent toutefois que l’OMIMO et ne reflètent pas nécessairement ceux de l’Union européenne ou d’EPOS VZW. Ni l’Union européenne ni l’autorité chargée de l’octroi de la subvention ne peuvent en être tenues responsables. Traduit par : Gerard Olushola ODJE ## Introduction Les Principes Quasi Universels de Projets (NUPP - Nearly Universal Principles of Projects) sont ceux que nous avons intérêt à suivre pour tout projet, quelles que soient les méthodologies et les approches que nous utilisons, pour maximiser nos probabilités de succès. Chaque livre et méthode de gestion de projets prend en compte certains de ces principes quasi universels (NUP - Nearly Universal Principles), cependant : - Ils ne sont pas traités dans leur ensemble, or ce serait utile que les praticiens considèrent tous les principes quasi universels (NUP - Nearly Universal Principles) au lieu de quelques-uns, - les principes sous-jacents la gestion de projet ne sont généralement pas assez clairs dans les livres et la plupart des professionnels en gestion de projets sont tellement focalisés sur les aspects pratiques qu’ils oublient les principes et adoptent des pratiques qui ne leur sont pas compatibles. Les Principes Quasi Universels de Projets (NUPP - Nearly Universal Principles of Projects) sont compatibles avec les systèmes, ressources et méthodologies majeures tels que PRINCE2^(®), le guide PMBOK^(®), P3.express, PM², DSDM^(®), XP et Scrum. Bien qu’ils ne soient pas compatibles avec certaines interprétations de ces systèmes, les NUPP tentent d’encourager les praticiens à reconsidérer leurs interprétations. Les principes quasi universels (NUP - Nearly Universal Principles) sont : - NUP1 — Préférer les résultats et la vérité aux affiliations - NUP2 — Préserver et optimiser énergie et ressources - NUP3 — Soyer toujours proactif - NUP4 — Rappelez-vous qu'une chaîne est aussi forte que son maillon le plus faible - NUP5 — Ne rien faire sans un objectif clair - NUP6 — Utiliser des éléments reproductibles ## NUP1 Préférer les résultats et la vérité aux affiliations [image] Nous avons naturellement un besoin d’appartenance à des groupes. Il arrive que cette appartenance prenne des formes qui dépassent son cadre de base. Ainsi de fortes affiliations peuvent naître de ce fait et causer des problèmes. En effet, nous pourrions étouffer l’éclosion de notre potentiel à cause des affiliations, alors qu’en évitant de limiter notre identité et nos préférences à certains groupes nous pouvons devenir des experts plus professionnels et plus efficaces. ### Exemple : La methodologie Agile vs Predictive Des personnes très motivées ont eu le courage d’essayer des approches de développement adaptatif en développement informatique lorsque la norme consistait à utiliser des approches prédictives. Le groupe décida d’appeler leur méthodologie Agile. C’était une excellente initiative qui prouva qu’il ne fallait pas limiter ses choix à ce qui semblait être nécessaire. Il existe toujours de nombreuses personnes enthousiastes et orientées résultats dans la communauté Agile, mais malheureusement, certains membres de cette communauté transforment Agile en culte et prennent en adversité toute autre approche. Cela pose problèmes pour plusieurs raisons, notamment : - Cette attitude les empêche d’apprendre de qui que ce soit en dehors de leur groupe - les autres professionnels en gestion de projets sont retissant à apprendre d’eux - l’appartenance au groupe devient plus importante que le réel objectif, ce qui empêche plusieurs de leurs membres d’apprendre le véritable sens de l’Agilité. Ce problème peut être maitrisé, voire supprimé : en utilisant «Agile» uniquement comme un label faisant référence à une approche de développement plutôt qu’à une communauté avec des membres, en ayant des personnes qui se considèrent comme des créateurs, des porteurs de solutions et des leaders qui considèrent Agile comme l’une des méthodologies efficaces qui ont amélioré la gestion de projet de développement informatique, pas comme leur identité. Il n’existe pas de guerre de méthodologies Agile-Prédictive pour un vrai professionnel. ### Exemple : PRINCE2^(®) vs. Guide PMBOK^(®) De nombreux professionnels de la communauté s’associent à PRINCE2^(®) ou à PMBOK^(®) (généralement en raison de leur situation géographique) et ne connaissent pas l’autre. Nous avons tous le droit d’avoir des préférences vis à vis de certaines bases de connaissances. Ceci ne fait pas d’elles notre identité. Mieux, nous devons nous familiariser avec toutes les bases de connaissances pour élargir notre perspective et nos choix. Le vrai professionnel est ouvert à la connaissance sans discrimination, il la recherche, l’acquiert, en fait usage partout où cela est requis, sans pour autant s’affilier. ### Exemple : La Formation continue Les affiliations satisfont l’individu à travers le sentiment d’appartenance et ne le poussent pas acquérir de nouvelles connaissances. Dans certains cas, les affiliations le découragent même d’apprendre de peur de les perdre. Quand vous êtes libre, un expert sans affiliations, vous avez besoin de vous étoffer avec la formation : avec la formation continue. Nos certitudes d’aujourd’hui sont simplement notre meilleure compréhension du moment, qui doit être améliorée au fur et à mesure que nous evoluons. Elles ne sont pas la vérité. Si nos idées sont exactement les mêmes que ce qu’elles étaient il y a quelques années alors nous avons quelques raisons de nous inquiéter. C’est même le cas pour les Principes Quasi Universels de Projets (NUPP - Nearly Universal Principles of Projects) : si vous revenez après quelques années et que vous voyez exactement la même chose, vous devriez devenir suspicieux. ### Exemple : L’ouverture d’esprit Lorsque vous vous opposez à une personne, assurez-vous que l’objection vise l’idée, pas la personne. Cela aide à prévenir beaucoup de tensions. D’autre part, quand quelqu’un vous oppose, essayez de ne pas interpréter cela comme une guerre contre vous, mais comme un débat d’idée, et restez ouvert à cela. N’écoutez pas pour répondre, écoutez pour comprendre, et travaillez avec l’autre personne pour améliorer l’idée. Bien que certaines personnes puissent vous cibler intentionnellement au lieu de l’idée, aidez-les à se concentrer sur l’idée plutôt que sur vous avant de poursuivre et essayez de préservez cet esprit tout au long de la conversation. ## NUP2 Préserver et optimiser énergie et ressources [image] Les ressources disponibles pour le projet sont limitées, de même que l’énergie mentale nécessaire pour prendre de bonnes décisions. Vous devez préserver et optimiser cette ressource (l’énergie mentale) pour vous-même et le projet et aider les autres membres de l’équipe à faire de même. ### Exemple : La loi des 80/20 Une portion importante des bénéfices possibles en matière de gestion de projet est obtenue avec un minimum d’effort. Dans la plupart des cas, cibler 100% des bénéfices possibles est très coûteux et injustifiable. Vous devez tenir compte de cette règle dans tout ce que vous faites et encourager les autres à faire de même. ### Exemple : La fatigue décisionnelle Nous utilisons une source d’énergie mentale unique pour prendre toutes sortes de décisions et exprimer notre volonté. Si vous utilisez une portion importante de cette source pour des décisions non strictement nécessaire ou inutiles, vous aurez moins d’énergie pour les décisions importantes, ce qui peut entraîner des contreperformances. C’est l’une des raisons pour lesquelles vous devriez éviter la micro-gestion (le principe de « délégation » de PRINCE2^(®)). Les désaccords sur les idées peuvent être utiles, mais les conflits de personnes nuisent généralement au projet, ce qui aboutit à l’épuisement de l’énergie mentale des membres de l’équipe. Si vous voyez un tel conflit, vous devez faire de votre mieux pour en comprendre la cause et la résoudre. ### Exemple : prenez soin de vous ! Les décisions que vous prenez et la volonté que vous exprimez utilisent votre source d’énergie mentale. D’autre part, cette source est remplie d’énergie lorsque vous dormez et mangez correctement. Alors, prenez bien soin de vous : assurez-vous de dormir suffisamment, de vous reposer et de bien manger. Si vous avez des problèmes à dormir, vous n’avez pas à vous en occuper seul ; de nombreux spécialistes peuvent vous aider à résoudre ce problème plus facilement. L’activité physique peut également aider avec cette source d’énergie, mais les études ne sont pas encore concluantes à ce sujet. Essayez d’encourager les membres de l’équipe à faire de même. Tout d’abord, assurez-vous qu’ils travaillent à un rythme soutenable et sans trop d’heures supplémentaires. Ensuite, dans la mesure du possible, essayez de proposer des aliments sains, des collations et des boissons énergiques pendant les heures de travail. ### Exemple : l’équilibre vie professionnelle-vie privée En général nous aimons notre travail, mais le travail à lui tout seul n’offre pas une vie équilibrée et heureuse. Autant vous êtes performant au travail, autant vous devriez planifier et mettre en œuvre des idées dans votre vie personnelle pour rester joyeux et heureux. Etant heureux, vous pouvez avoir plus de succès au travail. Essayez d’encourager les membres de votre équipe à faire de même dans la mesure du possible. ### Exemple : la motivation La motivation est un concept complexe. Il existe des livres intéressants et utiles sur le sujet, mais aussi de nombreuses approches non scientifiques. Néanmoins, vous devriez comprendre ce concept et l’utiliser en permanence, car cela augmente l’énergie mentale de l’équipe et la possibilité d’obtenir de bons résultats dans le projet. La motivation peut être aussi simple que de faire savoir aux gens que vous remarquez leurs bonnes performances par un gentil sourire ou un simple « merci ». Cependant, soyez prudent, car bon nombre des méthodes de motivation courantes ont un effet négatif ; par exemple, une petite récompense financière. ### Exemple : la collaboration et le travail d’équipe Les personnes qui collaborent ont généralement la force d’obtenir de bons résultats, mais plus important encore, notez que les humains sont êtres sociaux et aiment faire partie d’un groupe. Si vous pouvez supprimer les aspects négatifs du travail d’équipe et créer un environnement agréable, les membres de l’équipe seront plus heureux dans le projet. Soyez prudent, cependant, car les gens sont différents et certains ont besoin de plus de temps de détente, de concentration et de solitude que d’autres. Il s’agit généralement de trouver le bon équilibre. ### Exemple : la culture de l’esprit d’équipe Les différents acteurs du projet ont tendance à créer ou considérer des sous-groupes et ceci génère des tensions avec d’autres groupes ; par exemple, les personnes responsables des aspects financiers et de gestion du projet contre les personnes qui le réalisent techniquement. Ces tensions font perdre beaucoup d’énergie dans les deux camps, et c’est l’une des raisons pour lesquelles nous devrions essayer de créer une culture reposant sur l’esprit d’équipe, une seule équipe dans laquelle tout le monde travaille pour le même objectif. ### Exemple : la sagesse de la foule Lorsqu’un groupe de personnes de cultures diverses se réunit et travaille dans un environnement adéquat, il est possible d’obtenir de très bons résultats, de très bonnes idées et des solutions parfois meilleures à celles émanant d’un seul expert. Si cette option est à votre portée, vous pouvez l’utiliser régulièrement en demandant aux membres de l’équipe de vous aider à résoudre des problèmes difficiles liés au projet. A delà de l’obtention de bons résultats, cette approche permet également aux membres de l’équipe de savoir que leurs opinions sont prises en compte et qu’ils jouent un rôle important dans le projet, ce qui booste leur énergie. L’activité E02 de P3.express est un exemple d’application de la sagesse du groupe dans les projets. ### Exemple : animateur en chef du projet Si vous êtes chef de projet, la plupart de vos activités ont un caractère de facilitation (ou du moins devraient l’avoir). D’autre part, vous constaterez peut-être que les membres de l’équipe ont eu de mauvaises expériences avec des chefs de projets dans le passé, et que ces expériences ont une incidence sur leur relation avec vous : une partie de leur énergie est consacrée à l’analyse de votre comportement pour détecter les menaces potentielles au lieu de vous faire confiance. Dans ce cas, vous pouvez changer votre titre de chef de projet en animateur en chef du projet. Après tout, c’est ce que vous faites en réalité dans le projet. ## NUP3 Soyer toujours proactif [image] Nous avons une tendance naturelle à être réactifs. Cela peut nous aider à préserver notre énergie dans des domaines sans importance, ou à obtenir de bons résultats lorsque nous opérons dans un domaine où nous n’avons aucun savoir-faire. Ces situations sont différentes de nos projets et pour obtenir de bons résultats ici il faudra être proactif. ### Exemple : planification Si vous souhaitez vous rendre à un endroit pour la première fois et que vous êtes en retard, vous pouvez commencer à conduire immédiatement pour « gagner du temps » et gérer les problèmes éventuels au fur et à mesure qu’ils surviennent. L’approche proactive consiste à prendre un peu de temps et à configurer votre « GPS » pour vous donner l’itinéraire le plus rapide en fonction du trafic, des accidents et blocages possibles, puis démarrer ; c’est cela se donner le temps de préparation avant l’exécution, pour éviter des problèmes plus tard et gagner du temps à la fin. Contrairement à ce que certains pensent des projets Agile, la planification est toujours nécessaire ; seuls le type et le niveau de détail des plans diffèrent d’une méthodologie à une autre. Planifier avant l’exécution est une approche proactive. Rappelez-vous la citation : « donnez-moi six heures pour abattre un arbre et je passerai les quatre premières à affûter la hache. » S’il s’agit d’un projet prédictif, vous pouvez passer 4 heures à affûter votre hache, car vous êtes sûr de vouloir abattre un arbre. Dans un projet Agile, vous ne savez pas si vous allez abattre un arbre, récupérer des branches cassées, récolter du gazon, extraire du charbon ou autre chose. Néanmoins, vous devez toujours vous y préparer de façon générale (savoir où se trouve la quincaillerie la plus proche) et de façon plus spécifique (affûter votre hache) lorsque vous allez vous concentrer sur une solution donnée. c’est cela la planification. ### Exemple : planifier la planification Planifier la manière dont nous allons exécuter le projet est une approche proactive. Cette proactivité peut même être étendue en planifiant la manière dont nous allons planifier l’exécution ; c’est le concept de plan de gestion du Guide PMBOK^(®), les stratégies de gestion de PRINCE2^(®) et les approches de DSDM^(®). ### Exemple : planification continue La réalité correspond rarement à ce que nous avons prévu, et il faut s’y attendre. Cependant, nous devons continuellement adapter nos plans pour nous assurer qu’ils restent réalistes et pratiques. Nous devrions le faire dès que l’adaptation est requise, non pas lorsque surviennent des problèmes ; ceci est une approche proactive. ### Exemple : gestion du risque Toute la notion de gestion du risque repose sur une approche proactive : face à des événements incertains, au lieu d’attendre de voir ce qui se passe et d’y réagir, nous réfléchissons aux possibilités et aux impacts, examinons les réponses et, si possible agissons par anticipation avant que l’événement ne se produise. Notez que ce que nous faisons dans les projets est très sérieux ; c’est parfois la vie des humains qui est en jeu. ### Exemple : définir les rôles et les responsabilités Vous pouvez choisir de laisser les membres de l’équipe de projet travailler sans clairement définir leurs rôles et responsabilités. Plus tard, une certaine forme de rôle et de responsabilité se formera, mais c’est trop cher payer et peut ne pas fonctionner. L’approche proactive consiste à les définir tôt à la toute première phase du projet et à les adapter si nécessaire. Cela facilite le travail de tous, et chacun peut se concentrer sur la réalisation de l’idée, du service ou produit, au lieu de décider qui fait quoi. Le nombre et la variété des rôles dépendent du type et de la taille du projet. il peut s’agir d’une définition simple telle que celle de Scrum, quelque chose de modéré tel que celui de P3.express ou complète, comme celles de DSDM^(®) et PRINCE2^(®). Cependant, n’oubliez pas que les descriptions de rôle dans ces méthodes ne concernent que les activités de gestion, et vous devez toujours ajouter des descriptions de rôle pour les aspects techniques. ### Exemple : clôturer prématurément ou poursuivre le projet Devez-vous clôturer le projet prématurément ou le poursuivre ? Il n’y a rarement que deux possibilités, même si c’est ce que sous-entend la question. Vous devez adopter une approche proactive et analyser toutes vos options avant de prendre une décision. Peut-être que vous pouvez modifier le cahier de charges du projet ; Peut-être que vous pouvez faire une pause jusqu’à ce que quelque chose devienne clair pour évoluer ; vous pouvez peut-être changer l’approche du projet (par exemple, choisir une tierce partie pour continuer le projet), etc. ### Exemple : La Pensée critique Nous avons tous beaucoup de préjugés qui nous aident à survivre d’une part, et à prendre de mauvaises décisions d’autre part. Lorsqu’il s’agit de prendre des décisions importantes dans le cadre du projet, il est préférable de se donner le temps de prendre en compte tous les préjugés qui peuvent avoir une incidence sur notre décision avant qu’ils ne posent problème. À titre de référence, vous pouvez utiliser la liste des Biais cognitifs de Wikipedia. Il existe même des cadres décisionnels que vous pouvez utiliser pour améliorer votre processus de prise de décisions. Au début, ils peuvent être déroutant et même agaçant de les utiliser, mais vous vous habituerez vite à eux et les appliquerez sans effort avec le temps. ### Exemple : La transparence Nous aimons éviter d’être en retard ou d’avoir quelque problème que ce soit dans le projet, mais cela ne signifie pas que nous devrions cacher ces cas s’ils surviennent. Soyez transparent et informez les parties prenantes, car certaines d’entre elles pourront peut-être vous aider. De toutes les façons, elles finiront par découvrir les problèmes et leurs conséquences tôt ou tard, et certaines d’entre elles devront agir vite (par exemple, accepter la conséquence négative). ### Exemple : communiquer efficacement Il arrive souvent que vous envoyez des rapports aux parties prenantes sans que celles-ci ne vous fassent part de leurs commentaires. Vous pensez peut-être que tout va bien juste parce qu’il n’y a pas de retour négatif. Vous devez être proactif et vérifier s’ils ont vraiment fait usage du rapport et si celui-ci a été utile, puis recueillir les remarques pour ajuster votre méthode de communication. Si vous sous estimez la nécessité de vous assurer que les parties prenantes utilisent vos rapports, cela risque de poser de graves problèmes de communication qu’il sera trop difficile de les résoudre plus tard. ### Exemple : assumer ses responsabilités Il est facile de faire porter aux autres la responsabilité des mauvais résultats. Par exemple, vous voudriez que votre organisation vous donne les pleins pouvoirs de changer tout le projet et de le faire parfaitement, mais ce n’est pas le cas ; par conséquent le projet échoue. Ceci n’est pas une approche proactive. L’approche proactive consiste à assumer ses responsabilités et à faire tout ce qui est en son pouvoir dans les limites imposées. Vous ne pouvez pas vous attendre à ce que l’organisation vous fasse pleinement confiance et vous donne tout dans l’espoir d’obtenir de bons résultats, surtout lorsque la tendance générale d’échec de projets est à la hausse. Ce que vous devez faire est d’apporter une petite amélioration aux contraintes définies, l’utiliser pour gagner un peu de confiance de la part des parties prenantes, un peu plus de ressources et un peu plus de tolérance pour les contraintes, l’utiliser ensuite pour un impact positif plus visible, ainsi de suite jusqu’à ce que vous atteigniez l’objectif ultime. ## NUP4 Rappelez-vous qu'une chaîne est aussi forte que son maillon le plus faible [image] Il existe différents domaines dans les projets et ils nécessitent tous une attention particulière. Nous devons avoir une perspective holistique du projet. Faire attention à un domaine apparemment important (par exemple, le temps) ne suffit pas, car tous les domaines interagissent et ne fonctionnent correctement que s’ils reçoivent tous suffisamment d’attention. ### Exemple : tout dépend de la date limite ! Disons que vous construisez quelque chose pour les Jeux Olympiques. Les délais sont très critiques, ce qui rend la gestion du temps très importante. N’est-ce pas ? Que se passe-t-il si la qualité du rendu est si mauvaise que cela entraîne un travail supplémentaire pour les corrections ? cela aurait un impact sur le temps. Donc la qualité est tout aussi importante que le temps. Vous avez prévu un jardin très élaboré dans la définition originale du projet, mais vous savez que s’il n’y a pas assez de temps, vous pouvez le simplifier en recouvrant la surface de gazon, tant que vous avez envisagé cette possibilité à temps et que vous vous y êtes préparé. La gestion du cahier des charges est donc également importante. Nous avons ainsi les domaines du cahier des charges, du temps et de la qualité au centre de toutes les attentions. Avez-vous entendu parler de cette célèbre anecdote dans laquelle le président Kennedy a rencontré un concierge de la NASA et lui a demandé ce qu’il faisait, et il a répondu : « J’aide à faire poser un homme sur la lune » ? La participation de ce type de personnes au projet ne permet-elle pas de respecter les délais ? Au fur et à mesure, vous constaterez que chaque domaine du projet contribue à la gestion du temps, et vous ne pouvez pas respecter l’échéance avec une certitude acceptable si vous ne prêtez pas attention à tous les domaines. ### Exemple : Le picorage Lorsqu’exposés à diverses méthodologies, parfois nous commençons à sélectionner les éléments de part et d’autre et créons un mélange de tout ce qui semble intéressant à partir de systèmes différents. Cela ne marche généralement pas, car les éléments ne fonctionnent pas de manière isolée et doivent être compatibles les uns avec les autres. Tout ajout ou changement à un système doit être effectué avec une vue holistique. C’est pourquoi nous constatons parfois des éléments contradictoires dans des méthodologies différentes ; quelque chose fonctionne bien dans un système, et son contraire fonctionne bien dans l’autre système. Pris isolément, cet élément n’est ni vrai ni faux en soi. L’approche la plus sûre consiste à sélectionner une méthodologie pour le projet, à l’adapter, puis à y ajouter prudemment de nouveaux éléments en tenant compte de la cohérence de l’ensemble du système. ### Exemple : l’approche anti-processus L’une des choses les plus importantes que les méthodologies agiles ont réalisées est d’avoir attiré l’attention sur les aspects humains. Le manifeste Agile semble donner plus de valeur a l’humain qu’aux processus et aux outils. Notons que cette affirmation n’est pas exacte car toutes les méthodologies disent que les aspects humains sont importants, et la vraie différence avec les méthodologies Agiles est que les aspects humains sont une partie intégrante de leurs processus, plutôt qu’une simple suggestion. Donc ce n’est pas une compétition entre les aspects humains et les processus, mais un accent particulier sur la façon dont les aspects humains sont traités dans le système. Il ne fait aucun doute que certaines personnes essaient de remplacer les aspects humains par des processus plus sophistiqués, mais ce n’est qu’une mauvaise pratique. Même le contraire existe également : des personnes essayant de remplacer des processus par des aspects humains, ce qui ne fonctionne pas bien non plus. ### Exemple : voici tous les domaines requis Lorsque vous réfléchissez aux domaines, veillez à ne rien omettre. Mais que sont les domaines ? Si vous vérifiez les bases de connaissance fondamentales, vous obtiendrez des réponses différentes et pourtant, aucune d’elles n’est toute la vérité. Les thèmes de PRINCE2^(®) sont des domaines, mais ce ne sont que des domaines qui jouent un rôle clé dans la méthodologie. Tous les autres domaines importants n’y sont qu’implicites. Le Guide PMBOK^(®) n’est pas une méthodologie et peut donc traiter le sujet en profondeur avec les dix domaines de connaissances. Cependant, il s’agit d’interprétations (de tous les domaines) fondées sur la perspective du projet par le Guide PMBOK^(®), et non de manière neutre (ce n’est pas qu’une perspective neutre existe nécessairement). Par exemple, les aspects humains ne retiennent pas beaucoup l’attention dans le Guide PMBOK^(®). ICB est une bonne source d’informations sur les domaines. Cependant, il ne s’agit pas de domaines, mais des compétences requises dans le projet. Il n’est pas comparable trait pour trait aux domaines, mais aide beaucoup à les identifier. Il n’ya pas de liste de domaines dans Les Principes Quasi Universels de Projets (NUPP - Nearly Universal Principles of Projects), principalement parce qu’il s’agit d’un méta-système plutôt que d’un système, et aussi parce que la catégorisation des domaines dépend du type de projet et de son environnement ; Par exemple, un projet de construction de routine peut nécessiter une perspective différente de celle d’un projet de recherche créatif. ## NUP5 Ne rien faire sans un objectif clair [image] Vous ne devriez rien faire à moins que cela soit motivé par un objectif clair. Imaginez deux mondes parallèles où tout est identique, sauf ce que vous envisagez : jusqu’à quel point seraient-ils différents ? La différence vaut-elle l’effort que vous investirez ? Si vous n’avez pas d’objectif précis et ne faites que parce que tout le monde le fait ou que tout le monde dit que c’est important, alors : - Votre cas n’aura peut-être pas un bénéfice réel, et vous ne pourrez donc rien en retirer, Ou - Il peut toujours avoir des bénéfices potentiels dans votre cas, mais comme vous n’avez pas l’objectif en tête, votre façon de le faire ne vous aidera peut-être pas à en tirer des bénéfices. ### Exemple : portefeuilles et programmes Si vous êtes impliqué dans la sélection et le lancement de projets, vous devez vous concentrer sur les bénéfices et les problèmes qui sont censés être résolus avant le produit qui va concrétiser ces choses. L’exemple classique est celui du fabricant d’ascenseurs qui recevait autrefois des plaintes concernant la vitesse de leurs ascenseurs et qui lançait plusieurs projets pour augmenter la vitesse de ses ascenseurs sans succès. Cela a continué jusqu’à ce qu’ils décident de se concentrer sur le problème (ennui ou inconfort des gens) au lieu de la solution « naturelle » (ascenseurs plus rapides). Résultat : ils ont ajouté des miroirs aux ascenseurs, ce qui a tout simplement résolu le problème. Rappelez-vous que la gestion de projet consiste principalement à bien faire les choses, alors que la gestion de portefeuille consiste à faire les bons choix. Peu importe la qualité de la gestion de vos projets, cela ne fonctionnera pas si vous choisissez les mauvais projets. Il s’agit d’avoir un objectif. ### Exemple : le projet dans son ensemble La flexibilité du produit varie selon les projets. Dans certains projets de développement informatique, le produit est totalement flexible et sa forme finale dépend du retour d’informations généré par les incréments du produit au cours du projet, ce qui nécessite une approche adaptative (Agile). Il s’agit pratiquement d’une combinaison des couches portefeuille, programme et projet, et doit faire l’objet d’une attention maximale à l’ultime objectif. C’est une bonne idée de documenter l’objectif et de le rendre accessible ; c’est l’un des buts visés par la « vision produit » utilisée dans certains types de projets tels que les projets Scrum. L’attention portée à la valeur commerciale dans les projets Agiles est leur moyen d’assurer l’alignement sur leur objectif. Dans d’autres types de projets, où le produit est relativement fixe et qu’il existe d’autres mécanismes pour garantir que le produit identifié satisfera à l’objectif recherché, il est possible pour les membres de l’équipe de projet de déplacer une grande partie de leur attention du but vers le produit ( d’où le principe de «focus sur les produits» de PRINCE2^(®)), mais un minimum d’attention est nécessaire pour que le produit satisfasse à ce but, ce qui peut être fait en comparant les avantages prévus aux avantages escomptés (d’où le principe de «justification commerciale continue» et le thème «étude de rentabilité» dans PRINCE2^(®)). Lorsque le projet est à réaliser pour des clients externes, le client a son propre objectif et votre entreprise a un objectif différent. Vous devez comprendre et utiliser les deux pour vraiment réussir. ### Exemple : le suivi de projet Garder l’objectif ultime en vue est nécessaire, mais il peut s’avérer trop abstrait pour la plupart des tâches quotidiennes. C’est pourquoi une hiérarchie d’indicateurs est nécessaire pour le rendre plus pratique. Tout d’abord, la justification et les bénéfices du projet sont définis en fonction de l’objectif ultime, puis vous aurez des objectifs explicites et implicites pour les variables du projet (par exemple, le temps, le coût et la qualité) afin de satisfaire la justification, ce qui à son tour satisfera le l’objectif ultime. Ce sont des objectifs de niveau inférieur qui sont utiles pour beaucoup de nos tâches quotidiennes. En ce qui concerne le suivi, le contrôle de bas niveau du projet sera effectué en utilisant le plus bas niveau de variables, car il ne sera peut-être pas possible de suivre l’objectif ultime. Dans ce cas, vous devriez toujours avoir les objectifs en tête : quel est l’objectif du suivi ? Une réponse normale et acceptable consiste à voir si nous sommes sur la bonne voie et, sinon, à déclencher une réaction qui nous ramènera sur la bonne voie ou ajustera les variables pour voir si ces ajustements peuvent toujours nous permettre d’atteindre l’objectif ultime. Par conséquent, nos mesures devraient vous permettre de traiter cet objectif de bas niveau, et les mesures appropriées sont des prévisions pour les variables à la fin ; c’est-à-dire, quand serions-nous en mesure de terminer le projet ? De quel budget aurions-nous besoin pour terminer le projet ? Etc. Toutes les autres mesures, telles que les valeurs planifiées et réelles à ce jour, ne sont que des valeurs intermédiaires dont vous avez besoin pour calculer les prévisions, et non les valeurs finales que vous utilisez à des fins de gestion. ### Exemple : les documents Quelle que soit l’approche de développement que vous utilisez dans le projet, la planification est toujours nécessaire. La question importante est le niveau de détail de chaque type de plan. Si le plan n’est pas suffisamment détaillé, sa contribution sera négligeable et l’exécution du projet reposera davantage sur des décisions ad hoc que sur des décisions holistiques et intégrées. Par ailleurs, de nombreuses personnes essaient d’être prudentes et d’ajouter trop de détails à au plan, ce qui rend sa préparation et sa maintenance trop difficiles, et trop rigide pour les incertitudes du projet. Par conséquent, le plan devient irréaliste et inutile. La meilleure façon de décider du niveau de détail du plan est d’avoir un objectif en tête ou de considérer tous les éléments déterminants du plan. Par exemple, si vous envisagez d’ajouter une ressource au plan, vous devez avoir un objectif : comment allez-vous l’utiliser ? Comment cela aiderait-il le projet ? Quel effort sera nécessaire pour l’intégrer, cela en vaut-il la peine ? Il s’agit parfois de décider si vous souhaitez inclure un élément dans vos plans, et parfois de choisir votre façon de planifier ou de préparer quelque chose. Prenez une étude de rentabilité, une charte de projet ou un rapport : vous devez toujours vous demander pourquoi vous préparez ce document et en quoi il peut aider le projet. La recherche d’un «exemplaire» est le contraire de faire quelque chose basé sur un objectif. ### Exemple : le rapport sur l’état du projet Il est courant d’avoir des rapports d’état très longs dans de nombreux projets. Sur la base de ces Principes Quasi Universels (NUP - Nearly Universal Principles), nous devrions nous demander quel est l’objectif du rapport et comment nous pouvons atteindre cet objectif, indépendamment de ce que la plupart des gens peuvent faire. Cela peut, dans de nombreux cas, nous amener à préparer des rapports très simples d’une page que les parties prenantes lisent et comprennent vraiment au lieu de longs rapports. C’est aussi cela faire attention à l’objectif. Cependant, si vous préparez des rapports d’une page, certaines personnes peuvent vous objecter et penser que vous ne disposez pas d’un système de suivi « approprié ». Cela crée pratiquement un second objectif pour vous (outre le premier objectif, qui consiste à aider les parties prenantes à comprendre le statut du projet), et pour le satisfaire, vous pouvez simplement créer un second type de rapport très long. Cependant, vous ne combinerez pas cela avec le premier rapport, car ces deux objectifs ne sont pas les mêmes. ### Exemple : les études de rentabilité et la charte de projet Préparer des documents tels qu’une étude de rentabilité et une charte de projet est généralement une nécessité fastidieuse, infructueuse et bureaucratique pour la plupart des gens, alors que ces documents ont tous des objectifs valables qui s’appliquent à la plupart des projets. Si vous essayez de trouver un “modèle” et remplissez le modèle, le travail est simplement inutile, alors que vous pouvez plutôt vérifier le but réel de ces documents, voir comment et s’ils peuvent être utiles dans votre projet, puis préparer le document comme vous le souhaitez, rien que pour satisfaire ces objectifs : c’est le bon document. Pendant que vous réfléchissez à la manière dont vous pouvez préparer les documents pour répondre à leurs objectifs, vous pouvez ne pas penser à tous les scénarios et rater quelque chose. Pour éviter cela, vous pouvez vérifier ce que suggèrent PRINCE2^(®), Guide PMBOK^(®), P3.express et DSDM^(®), puis évaluer ces suggestions en fonction des objectifs visés. ### Exemple : le suivi post-projet Bien que le projet ait un objectif précis et que nous puissions en tenir compte tout au long du projet, sa réalisation est principalement évaluée sur la base de prévisions établies au cours du projet, et nous ne devons pas l’oublier une fois le projet terminé. Il est important de vérifier la réalisation des objectifs une fois le projet terminé, car : - nous pouvons voir comment les objectifs ultimes sont atteints et en tirer des enseignements pour les projets futurs, et - Parfois, les objectifs ne sont atteints que si nous réalisons quelques tâches supplémentaires après l’achèvement du projet, et comprendre la nécessité de ces tâches supplémentaires requiert un suivi. Le suivi post-projet est une étape nécessaire si vous êtes axé sur les objectifs. C’est principalement la responsabilité des systèmes de gestion de programme et de portefeuille, et comme la plupart des entreprises n’ont pas de tels niveaux de gestion, cette étape est généralement négligée. C’est pourquoi P3.express et DSDM^(®) ajoutent cette étape à leurs méthodologies de gestion de projet. ### Exemple : la simplicité Le monde est complexe et chaotique, mais nos modèles sont des approximations abstraites reflétant partiellement le monde. Par conséquent, ils peuvent être simples. D’un autre côté, les systèmes simples fonctionnent généralement mieux, car nous pouvons nous concentrer sur l’usage principale. Nombre d’entre nous essaient d’obtenir de bons résultats en rajoutant de la complexité à nos systèmes, espérant que cela corresponde à la complexité du monde, même si cela rend le système difficile à utiliser et nous empêche généralement d’atteindre l’objectif recherché. ### Exemple : L’adaptation Les projets ne sont pas les mêmes. Un logiciel de diffusion de musique en ligne impose des conditions très différentes de celles qui seront utilisées pour l’équipement d’un hôpital ou pour un avion dont la vie peut dépendre, ou d’un logiciel qui sera utilisé dans un satellite où il est supposé fonctionner pendant de nombreuses années sans se planter, et ces logiciels sont tous différents de la construction d’une maison de vacances, d’une centrale anti-incendie et d’une usine de traitement. Une fois que vous avez les objectifs en tête, vous comprendrez mieux comment adapter les systèmes et la documentation à différents projets. ## NUP6 Utiliser des éléments reproductibles [image] Une approche improvisée du projet épuise en termes d’énergie, de ressources et risque toujours de passer à côté d’éléments nécessaires. La meilleure façon de simplifier ce qui doit être fait est d’utiliser des éléments reproductibles, et de préférence les prendre en cycles reproductibles. ### Exemple : les listes de contrôle de la qualité Une liste est un exemple simple d’un élément potentiellement reproductible que de nombreuses personnes utilisent dans leur vie personnelle et professionnelle. Prenez par exemple les critères de qualité d’un livrable : - Tout d’abord, vous pouvez créer une liste de tous les critères, qui est une forme de planification. - Le sixième Principe Quasi Universel (NUP6 - Nearly Universal Principle number 6) recommande de standardiser la liste : existe-t-il des livrables similaires dans le projet ? Dans ce cas, préparez une liste générique de contrôle la qualité pour cette catégorie de livrables et utilisez-la pour chacun d’eux. S’il existe des variantes, conservez cette liste et ajoutez-y quelques éléments supplémentaires pour les livrables individuels. Maintenant, vous avez des listes de contrôle reproductibles. - Lorsque vous préparez des listes de contrôle génériques pour divers types de livrables, vous pouvez trouver des éléments qui se répètent, ce qui suggère la possibilité de créer une catégorie mère virtuelle pour eux. Dans ce cas, au lieu de répéter les éléments de toutes ces listes génériques, extrayez-les et mettez-les dans une liste mère. Enfin, vous aurez probablement une seule liste générique pour l’ensemble du projet. Les critères d’acceptation de Scrum (Scrum’s Definition of Done) sont un exemple de liste de contrôle de la qualité (entre autres) au niveau du projet. Ce faisant, chaque livrable appartiendra à une hiérarchie de catégories et devra satisfaire les éléments qui apparaissent dans les listes de toutes les catégories de leur chaîne. Ainsi, un élément de la liste mère devient reproductible pour toutes ses sous-tâches, ce qui permet de gagner du temps et de l’énergie dans la planification et l’exécution. Plus encore, une fois que vous l’avez exploitée pour un projet, vous pouvez l’adapter et l’utiliser pour tous les projets similaires à l’avenir, ce qui constitue une forme reproductible de planification pour plusieurs projets. ### Exemple : les processus et flux de travail Certains livrables ou objectifs qu’ils contiennent nécessitent certaines étapes qui peuvent devenir normalisées et reproductibles. Par exemple, si les produits livrables doivent être conçus individuellement et approuvés, vous pouvez préparer un flux de travail simple qui clarifie toutes les étapes, les personnes impliquées et les durées approximatives, tout en évitant de nombreuses difficultés. Veillez toutefois à ne pas rendre les processus et les processus trop compliqués ou trop exigeants en documentation, car cela aurait des conséquences négatives. Toutes les personnes impliquées dans le projet doivent trouver les flux de travail et les processus comme un support pour leur travail et leur simplifier la tâche, et non comme une documentation bureaucratique qui bloque leur vrai travail. Les projets agiles ont pratiquement des éléments reproductibles dans leur approche de développement itérative, où certains types d’activités de développement sont répétés pour chaque fonction ; par exemple. la routine quotidienne commune sous XP (eXtreme Programming) : associer, choisir un élément, le concevoir sur un tableau blanc, construire les scripts de test et le code, intégrer le code, etc. Outre les flux de travail reproductibles pouvant être utilisés pour des activités techniques, peut également avoir des éléments reproductibles pour les activités de gestion de projet. Les processus décrits dans les guides PMBOK^(®), PRINCE2^(®) et DSDM^(®), les activités dans P3.express et les événements dans Scrum sont des exemples de ce concept. ### Exemple : les cycles Avoir des éléments reproductibles pour gérer le projet est utile. Cela peut être rendu encore plus facile en les mettant dans des cycles reproductibles. Ces cycles simplifient considérablement les activités quotidiennes des personnes impliquées dans la gestion et la direction du projet. Les cycles de groupes de processus dans PMBOK^(®) Guide utilisés dans un projet comportant plusieurs phases, des étapes dans PRINCE2^(®), des cycles quotidiens, hebdomadaires et mensuels dans P3.express, des itérations et des boîtes de temps dans DSDM^(®) et des sprints dans Scrum sont des exemples de ce concept. Les cycles plus courts sont plus faciles à comprendre et à utiliser que les plus longs ; Par exemple, Sprints dans Scrum contrairement aux phases selon le Guide PMBOK^(®). Toutefois, les cycles trop courts peuvent ne pas suffire pour prendre en charge certains types de projet. La solution peut être l’utilisation de plusieurs cycles, tels que l’utilisation par DSDM^(®) de cycles courts de type timebox avec des cycles d’itération plus longs, ou l’utilisation de P3.express par cycles quotidiens, hebdomadaires et mensuels. ### Exemple : les méthodologies L’usage d’une méthodologie ou d’un cadre pour l’exécution d’un projet est un autre exemple d’exploitation d’éléments reproductibles. Il peut s’agir d’une methodologie existante tel que PRINCE2^(®), P3.express, DSDM^(®) ou Scrum, ou d’un système que vous avez personnalisé ou construit vous-même. Cependant, il est généralement préférable de commencer par l’une des méthodologies existantes et de l’adapter à vos besoins plutôt que d’en construire une nouvelle. Tout élément reproductible est abstrait et doit être personnalisé pour s’adapter à la réalité du terrain. Il existe cependant un éventail d’abstraction et de besoins de personnalisation : des listes de contrôle de qualité courtes et relativement précises se situent à une extrémité de l’éventail avec le minimum d’abstractions et de besoins d’adaptation, tandis que les méthodologies sont à l’autre bout, avec le besoin le plus élevé d’adaptation. Vous devez toujours noter le besoin d’adaptation, sinon l’élément reproductible ne correspondra pas à vos besoins.