Dans un projet, un product owner, ou un chef de projet, ont un rôle de leader, même si cela ne fait pas partie de leur fiche de poste. Dans les deux cas, leurs actions ont un impact important sur la performance des équipes. Pour s’assurer de leur réussite, ils disposent d’un certain nombre d’outils dont le PMI encourage l’utilisation. Parmi ces techniques et outils, je vais vous parler aujourd’hui du modèle de Tuckman.
Un des rôles du chef de projet, est de s’assurer que les livrables correspondent bien aux attentes des parties prenantes (stakeholders). Il doit veiller à ce que le domaine (scope) du projet évolue dans le bon sens, et que les nouvelles fonctionnalités demandées répondent aux attentes des utilisateurs. Il existe pour cela des méthodes. Nous avons déjà vu, par exemple, la méthode MoSCoW. Nous allons aborder cette fois-ci, le modèle de Kano.
Le déroulement d’un projet suit rarement le cours d’un long fleuve tranquille. De nombreux évènements demandent de prendre des décisions, pour ajuster la trajectoire du projet. A la fin, même si les livrables respectent les critères d’acceptation, ces nombreux changements peuvent impacter la qualité du travail réalisé. Ces écarts volontaires ou pas, visibles ou pas, sont regroupés sous le terme de « dette technique ». Nous allons dans cet article aborder cette notion, ainsi que ces causes, et ses conséquences.
L’une des difficultés rencontrées par le chef de projet, est de fixer les priorités, face à des parties prenantes, qui souhaitent disposer des toutes les fonctionalités demandées, le plus rapidement possible. La méthode MoSCoW permet d’aborder la priorisation des activités d’un projet de façon pragmatique. Elle peut également servir à prioriser les demandes ou les fonctionnalités elles-mêmes.
Parmi les outils du chef de projet, la matrice RACI fait partie des incontournables. Cette matrice permet au chef de projet, de définir le rôle et les responsabilités des parties prenantes de son projet. Parfois négligé, en raison de sa construction fastidieuse, cet outil permet pourtant de lever les ambiguïtés possibles entre les différentes équipes / organisations intervenant sur les tâches et délivrables d’un projet. Je vous propose un petit rappel sur cet outil indispensable.
Le Business Case (en français, Cas d’Affaire) d’un projet, est à la fois, la justification, et la raison d’être de ce projet (la réponse à la question pourquoi?). Un projet n’est valide que lorsqu’il s’appuie sur un business case « positif », c’est-à-dire qu’il apporte de la valeur à l’entreprise. Il n’est cependant pas toujours facile de démontrer la valeur apportée par un projet, encore plus lorsque l’on parle de valeur financière: L’argumentation s’appuie souvent des arguments techniques, qualitatifs, que l’on néglige souvent de transformer en informations financières. Des techniques existent cependant, et je vais en lister quelques unes dans cet article, en parlant notamment, d’un des outils abordé pendant ma formation PMP®: la Valeur Actuelle Net (VAN, en anglais : Net Present Value, NPV).
Les 24 et 25 avril dernier, l’équipe de PMI® France, organisait le forum national PMI France 2017. Ce forum annuel est l’occasion, pour les participants, d’échanger leurs pratiques sur la gestion de projet, et/ou de découvrir de nouvelles techniques. Il s’agissait de mon premier forum depuis l’obtention de ma certification PMP® en Décembre 2015.
