Project Decisions

http://www.pmhut.com/project-decisions

Par Dave Nielsen

Pendant la vie de tout projet, beaucoup de décisions doivent être prises. Le nombre et l’importance de ces décisions dépendront de la taille et de la complexité du projet, mais il est sûr de dire que chaque projet prendra quelques décisions et manager celles-ci est une partie critique du travail du chef de projet. Comment vous managez ces décisions dépendra de plusieurs facteurs : si la décision est la vôtre, si c’est une décision de passage de jalon/porte, ou si la décision changera la portée, le calendrier, ou le budget du projet.

Jetons tout d’abord un coup d’œil aux décisions de plus haut profil.

Peut-être la plus en vue des décisions dont vous êtes responsables est la décision de passage de jalon/porte. Cette décision détermine l’aptitude de votre projet à passer à la phase suivante et en cas de décision de passer de la phase de planification à celle de mise en œuvre; il peut avoir beaucoup d’argent en jeu. Votre travail n’est pas de prendre la décision, bien que vous soyez en position de l’influencer.

Votre travail est d’identifier le bon ensemble de critères que votre projet doit réunir pour passer à la phase suivante. Les critères que votre projet doit respecter dépendront de la phase complétée, mais peuvent généralement prendre en compte le travail complété dans la phase précédente et les ressources et plans nécessaires pour commencer la suivante. Que le travail de la phase précédente soit complet est vérifié par la présence et la qualité de ses livrables. Les livrables que vous prenez comme vos critères devraient être ceux qui sont visibles des décideurs. Pour une décision de passage de jalon entre planification et construction, vos livrables seront des plans de projet, des déclarations de portée, les Déclarations de Travail, les documentations des besoins, des contrats signés et autres choses de ce genre. Pour une porte de passage de la phase de construction à celle de clôture, ces livrables correspondront aux objets, applications et systèmes qui supportent le cas d’affaires du projet. Cet article n’est pas destiné à instruire le lecteur sur les rencontres de revue de jalon/porte.

Une fois que vous avez identifié les critères nécessaires à la décision, identifiez les décideurs. Si vous avez assez de chance pour avoir un Comité de pilotage fournissant une surveillance du projet, vous n’avez pas besoin de regarder plus loin. A défaut, votre sponsor de projet devrait pouvoir aider les décideurs. Donnez à ces gens beaucoup de préavis pour votre réunion et préparez vos critères de déclenchement dans un format qui les rendra facilement digestibles. N’oubliez pas que ces personnes ne sont pas prêtes à se concentrer sur la minutie de votre travail.

Votre objectif pour la rencontre de passage de jalon/porte est de parvenir à une décision “passe, ne passe pas” à la phase suivante. Ne restez cependant pas scotché à la nature Booléenne de la décision. Il est parfaitement acceptable de prendre une décision « passe » qui dépende le la livraison d’un livrable oublié ou incomplet à la phase suivante, si c’est nécessaire. La première diapositive de votre présentation devrait parler de cette décision. Vous pouvez ou pas trouver nécessaire de définir le processus de prise de décision. Gardez à l’esprit que les personnes dans la pièce seront probablement seniors; Attachez-vous à ne pas attirer une attention indésirable sur les différences d’ancienneté.

Gardez votre revue de passage de jalon/porte brève et précise.

Les questions litigieuses devraient déjà être adressées avant que vous n’atteigniez votre réunion. Dans les cas où vous savez, ou suspectez, que vous pourriez avoir des problèmes, vous pouvez vouloir tenir une pré-réunion avec votre équipe et les parties prenantes non décisionnaires pour dégager ces questions avant votre réunion de passage de jalon/porte. Vous devriez aussi être préparés à répondre à n’importe quelles questions que vos décideurs vont probablement avoir sur les livrables ou les ressources dont vous discutez. Par exemple, pourquoi votre projet a-t-il besoin de 10 programmeurs (ou plombiers) quand Jane n’en demande que 8 ? Vous pouvez vouloir avoir un expert technique qui vous accompagne à la revue pour répondre aux questions techniques qui dépassent votre capacité à répondre. Une incapacité de répondre à une question technique ne devrait pas empêcher une décision; c’est là que le passage avec contingence ou conditionnel entre en jeu. Un livrable pas tout à fait complété à la satisfaction des décideurs, ou une question sans réponse peut être adressé par une action de votre part qui complétera le livrable ou répondra à la question. Vous devrez enregistrer ces items dans un registre d’action pour la réunion et revenir vers les décideurs quand les items sont complétés.

Un autre enseignement important nécessaire pour la décision, auquel je ne me suis pas encore attaqué, est le cas d’affaires. Le projet est entrepris pour produire un résultat positif pour l’organisation qui l’entreprend. Ce résultat sera exposé clairement dans le cas d’affaires comme un accroissement accru, une augmentation des bénéfices, des réductions de dépenses, la correction d’un problème opérationnel, la mise à jour d’un système pour répondre à de nouvelles demandes techniques ou législatives, ou un bénéfice intangible. La réunion devrait vérifier que les bénéfices sont toujours tels que décrits dans le cas d’affaires et que le coût est toujours conforme à celui prévu dans le cas d’affaires. Le cas d’affaires devrait être mis à jour pour refléter les prévisions les plus récentes. Si le projet n’a pas de cas d’affaires, trouvez ces bénéfices et coûts d’une autre source comme la charte de projet.

Les changements de contenu, d’échéancier, ou de budget du projet sont un autre secteur de décision important.

Ces décisions devraient être dirigées par votre processus de management de changement de projet. Le processus devrait définir qui prendra la décision, comment des informations nécessaires pour prendre la décision doivent être rassemblées, comment ces informations doivent être suivies et qui est responsable de chaque étape du processus. Faire tout cela devrait assurer que votre projet tire bénéfices de bonnes prises de décisions. Ce que cela ne fera pas est garantir que les décisions seront prises à l’heure et sans cet élément, vos décisions de qualité peuvent être sans valeur.

Chaque décision y aura une temporalité unique.

La contrainte de temps peut être explicitement exposée dans le changement demandé. Par exemple, une requête pour changer un produit utilisé par le projet en faveur d’un autre qui serait moins cher devrait indiquer la date de commercialisation dans la requête pour que chacun connaisse le délai pour donner la décision. D’autres chronologies seront moins clairement définies. Elles peuvent être implicites dans la requête comme une requête pour changer une fonction ou une fonctionnalité logicielle. Cette décision devrait être prise avant que l’application ne soit construite. C’est votre travail que d’analyser la requête et déterminer le délai pour la décision. Si cette analyse exige une connaissance plus technique que celle que vous possédez, vous devez obtenir les informations d’un expert qui peut déterminer la contrainte de temps.

Connaître “la date de péremption” de la requête de changement est tout ce qui est exigé si vous êtes le décideur.

Quand un conseil de contrôle de changement (Change Control Board : CCB) est exigé pour prendre que la décision, adhérer à la chronologie peut être un peu plus difficile. Votre CCB devrait se réunir régulièrement et votre première étape devrait être de mettre la décision sur votre changement demandé à l’ordre de l’une de ces réunions. Choisissez la date au plus tôt disponible quand les décisions sont nécessaires rapidement. Si la date disponible suivante est trop tard pour votre décision, essayez d’arranger une réunion spéciale qui respectera votre délai. Vous devrez expliquer l’urgence de la décision pour attirer les membres du CCB à la réunion spéciale. Si vous constatez qu’il est impossible de le faire, allez chez votre sponsor et demandez une décision. Dans un scénario catastrophe, où vous vous trouvez dans l’impossibilité d’obtenir une décision de votre CCB ou de votre sponsor de projet, prenez le taureau par les cornes et décidez vous-même. Cela peut sembler risqué, mais tant que vous vous êtes munis de toutes les informations nécessaires pour prendre une décision sensée et avez consulté toutes les bons experts, vous constaterez probablement que votre initiative sera récompensée. Dans le pire des cas, vous découvrirez que vous êtes sur le mauvais projet.

Beaucoup de décisions de projet, au moins sur des projets logiciels, sont celles prises par un groupe d’experts qui sont responsables de passer en revue les plans, documents et design du projet et fournir leurs avis. Le document ou le design sont approuvés une fois que le retour d’information a été atteint. Les décisions sont souvent retardées parce que ces personnes sont très occupées, ou ne comprennent pas l’urgence de finir dans les délais. Votre travail est de vous assurer que la valeur que ces personnes fournissent à la revue de la qualité du document ou de la conception dont ils sont responsables respecte les délais. Soyez clair avec vos délais. N’envoyez pas le document pour revue sans fournir le délai et la raison du délai et tenez ensuite les experts responsables de respecter ce délai, de la même façon dont vous les tiendriez responsables de respecter tout autre délai de projet. L’assurance que vos experts comprennent la raison de la date imposée devrait assurer la réponse. Dans le cas où leur réponse n’est pas reçue à l’heure, vous avez une décision à prendre : allez de l’avant et approuvez le document sans le retour d’experts, ou retardez le projet jusqu’à ce que vous obteniez le retour d’information. Assurez-vous que vous rendez votre décision à l’heure.

Le remplacement de la revue individuelle et des sessions de retour d’information avec un groupe “de revue de détail” (« Walkthrough ») est une alternative qui a 2 avantages : elle ajoute la valeur du groupe au processus, elle peut d’habitude être complétée en une heure ou moins et vous en contrôlez le timing. Les « Walkthrough » sont un excellent outil pour valider le code, mais peut aussi être utilisé pour la revue de n’importe quel document de projet par un groupe d’experts.

Chaque décision prise sur votre projet vient avec “une date de péremption”. Quelques “dates de péremption” sont explicites et facilement identifiables, d’autres sont implicites et exigent des investigations pour les déterminer. Votre travail est d’identifier la date, identifier les décideurs et mettre ensuite les informations nécessaires entre leurs mains pou qu’ils puissent respecter la date. Garder vos yeux sur ces points clés de la prise de décisions aidera votre projet à livrer dans les temps.