Du haut vers le bas ou de bas en haut
Cet article fait partie de notre collection « From the Trenches ». Il traite de la gestion de projet, de la gestion de portefeuille et de la gestion des tâches, et compare les pratiques de gestion descendantes et ascendantes associées.
Pour télécharger la version Word de cet article, consultez le livre blanc de haut en bas ou de bas en haut (Project Server 2010) .
Pour plus d’articles, consultez les livres blancs « From the Trenches ».
De haut en bas ou de bas en haut ?
« Nous avons besoin d’une gestion de projet... Je voulais dire gestion de portefeuille... um, je veux vraiment dire la gestion des tâches... Oh heck, nous avons besoin de tous », est un cri de bataille que j’entends souvent. Ce n’est pas le manque de définitions de ces trois concepts qui provoque la confusion, c’est leur similarité.
Ceux d’entre nous qui travaillent dans l’informatique depuis de nombreuses années ont tendance à voir les choses d’un point de vue technique et parfois cela ne nous sert pas bien. Si nous examinons les données de la gestion de portefeuille, de la gestion de projets et de la gestion des tâches, elles peuvent sembler très similaires. J’ai un champ ID, un champ de description et une date de début et de fin dans les trois. La liaison de ces trois devrait donc être naturelle.
Peut-être pas.
Prenons ces trois concepts un par un. Il est facile de voir leurs similitudes, mais il existe des différences fondamentales dans les trois perspectives.
Gestion de portefeuille : une approche descendante
Personnes peut signifier beaucoup de choses différentes par « gestion de portefeuille », mais la signification la plus courante est probablement la sélection et la hiérarchisation des projets. En fin de compte, les principes affectent tous les membres de l’organisation, mais le processus présente un grand intérêt pour les cadres supérieurs. La direction commence par certaines contraintes, comme le budget total disponible et la nécessité de répondre à la question suivante : « Que pouvons-nous et devons-nous accomplir avec cette somme d’argent ? » Si le processus de gestion de portefeuille est suffisamment mature, cette analyse peut inclure non seulement de nouvelles idées, mais également des projets existants.
Pour créer un processus de sélection et de hiérarchisation du portefeuille, la direction doit confronter les critères métier qui guident l’entreprise et s’entendre à l’avance sur les métriques qui seront prises en compte lors de l’examen des projets nouveaux et existants. Le retour sur investissement doit-il être une métrique clé ? Peut-être devrions-nous envisager les effets sur la satisfaction des clients, la rétention du personnel ou l’alignement sur les objectifs stratégiques. Quelles que soient les métriques clés, la direction doit évaluer chaque initiative de projet afin de déterminer comment ce projet peut atteindre ces objectifs et comment chaque projet se compare à d’autres initiatives pour lesquelles l’argent pourrait être dépensé.
Il s’agit d’un processus hautement analytique, même s’il est effectué dans sa tête. Il est certainement très analytique lorsque vous utilisez un logiciel de gestion de portefeuille de projets. Même une fois que l’analyse du logiciel arrive dans un rapport ou une vue, il y a pratiquement toujours une surveillance au niveau de la gestion où une décision finale sur les priorités est prise. Une fois cette opération terminée, les résultats finaux doivent être transmis à ceux qui feront la gestion de projet de chacun des projets. Ces décisions auront pour effet de financer certains projets et non d’en financer d’autres, d’affecter des ressources plus prioritaires à certains projets et non à d’autres, de faire avancer le calendrier de certains projets et d’en retarder d’autres.
Gestion de projet : de haut en bas et de bas en haut
Une fois qu’un projet est approuvé, il passe à un domaine complètement différent. Maintenant, la vue plus classique de la planification de projet est mise en avant. Maintenant, nous devons réellement construire la chose que nous avons décrite dans notre justification commerciale avant qu’elle ne soit approuvée.
Un responsable de projet commence à réfléchir en termes d’étendue du projet et de livrables. Le chef de projet connaît le produit final qui doit être créé, qu’il s’agisse d’un logiciel ou d’un bâtiment prêt à être occupé. Ils peuvent penser aux grandes phases de ce projet et créer une structure de répartition du travail.
Un chemin critique d’étapes logiques requises pour terminer le projet est conçu. Le responsable de projet sait également qu’il sera tenu de rendre compte de l’échéancier qui est produit, donc il ou elle consulte un éventail d’experts en la matière dans le projet. Le responsable de projet crée une vue ascendante du projet en examinant tâche par tâche et en résumant ces tâches jusqu’aux phases du projet et finalement au projet lui-même. À ce stade, le responsable de projet peut également commencer à allouer des ressources par compétence, par service ou même par nom. Ces ressources peuvent avoir des coûts associés. Le résultat du calcul de la durée des tâches, des ressources nécessaires et de leurs taux nous donne une estimation ascendante du projet.
Pour l'instant ça va.
Toutefois, lorsque nous examinons l’approche descendante du processus de sélection du portefeuille de projets, il y avait également un coût. En fait, le coût estimé du projet faisait partie de la justification opérationnelle que la direction a prise en compte lorsqu’elle a approuvé le projet. Si nous obtenons simplement l’estimation de bas en haut du projet à partir de l’expertise combinée des experts en la matière maintenant, qu’ont-ils utilisé dans la sélection du projet dans la suite exécutive?
C’est une bonne question. Dans certaines organisations, le projet reçoit une estimation approximative du service du projet afin de créer une justification métier pour le projet. Dans d’autres organisations, une estimation ascendante complète est créée avant d’envisager le projet dans le processus de portefeuille. Le problème de ces deux approches est qu’elles font des efforts. Une estimation complète peut nécessiter beaucoup d’efforts et pourtant, le projet n’a pas encore reçu d’approbation pour le financement de tout effort. Ainsi, dans de nombreuses organisations, un membre de la direction fait simplement une estimation des coûts de ce projet.
Donc le processus semble tout intégré, mais il peut y avoir un peu de catch-22 ici. Qui vient en premier, le travail consacré à l’estimation ou à la sélection du projet afin de pouvoir passer du temps sur le projet ?
De plus, que se passe-t-il si l’estimation ascendante ne correspond pas à l’estimation du processus de sélection de portefeuille ? Si l’estimation est inférieure, il n’y a probablement pas de problème, mais si le travail ne peut pas être effectué dans le temps ou le budget estimé par les personnes qui sélectionnent le portefeuille, il y a un conflit.
Vous pourriez penser que la chose naturelle à faire serait de réunir de nouveau la haute direction et de discuter du problème, mais il y a beaucoup de situations où ce n’est pas aussi facile que cela semble.
Tout d’abord, le comité de sélection du portefeuille est rarement le personnel de gestion de projet. Les membres supérieurs du personnel de gestion de projet sont presque toujours inclus dans le comité de sélection de portefeuille, mais le groupe lui-même est généralement des cadres très supérieurs qui trouvent difficile d’organiser le temps d’être tous ensemble. Deuxièmement, le comité de sélection peut se réunir de façon irrégulière, de sorte que le fait de les réunir pour discuter de toutes les conséquences d’un coût incompatible pour un projet par rapport à l’estimation pourrait être un grand défi. Enfin, il y a certaines cultures d’entreprise où il ne sera pas une mesure d’avancement de carrière d’avoir à annoncer aux cadres supérieurs que leur estimation est complètement erronée sur le calendrier et le budget appropriés pour ce projet.
Gestion des tâches : approche ascendante
Lorsque nous pensons à la gestion des tâches, nous avons tendance à penser de manière très opérationnelle, ce qui nous amène le plus souvent à notre agenda quotidien et à un produit comme Outlook.
Maintenant, nous travaillons au niveau d’un membre individuel ou d’une petite équipe. Nous ne voyons pas les tâches en contexte. Nous voyons les éléments que nous nous sommes engagés ou peut-être ceux que nous avons demandé à un membre de l’équipe de s’engager. Il ne s’agit pas du tout d’une vue analytique. Il y a des tâches à faire et l’individu a promis de les faire.
À la base, la gestion des tâches est très simple. Vous effectuez la tâche et lorsque vous avez terminé, vous dites à la personne qui vous a donné la tâche qu’elle est terminée. Toutes les fonctionnalités de cette fonctionnalité se trouvent déjà dans Outlook.
Les méfaits de données similaires
Il y a un dicton: « S’il ressemble à un canard et quacks comme un canard, il doit être un canard. » C’est vrai pour les canards, mais ce n’est pas toujours le cas pour les données basées sur les tâches.
Examinons ces trois niveaux de données orientées projet :
Au niveau du portefeuille, nous avons un projet et peut-être des phases en dessous de ce projet. Les informations de phase peuvent avoir un numéro de code, une description, une durée, une date de début et une date de fin.
Au niveau du projet, nous avons un projet et des tâches sous le projet. Les informations de tâche peuvent avoir un numéro de code, une description, une durée, une date de début et une date de fin.
À ce niveau de gestion des tâches, nous avons une tâche et les informations de tâche peuvent avoir un numéro de code, une description, une durée, une date de début et une date de fin.
Ils se ressemblent certes, mais en fait, la perspective des données fait que chacun de ces enregistrements plutôt communs a un objectif très différent.
On me demande souvent : « Puis-je déplacer des données de l’affichage portefeuille vers l’affichage projet vers Outlook et revenir en arrière ».
La réponse courte à cette question est « Oui ».
Mais dans notre cabinet, nous avons un mantra que nous nous disons quand nous donnons des conseils techniques : « Ne me dites pas comment faire, dites-moi pourquoi vous devriez le faire. »
Pour faire le point, imaginez cet exemple. Nous créons un environnement entièrement intégré. À l’extrémité supérieure de l’échelle, nous avons une liste de projets organisés par portefeuille. Non seulement nous sélectionnons ces projets, mais nous les intégrons encore davantage, en les suivant une fois qu’ils ont été activés dans des projets en direct à partir du système EPM. Pour ce faire, nous utilisons les fonctionnalités déjà disponibles pour déplacer les définitions de projet et de phase du côté Portefeuille de notre système intégré vers le côté projet du système. Les données sont identiques.
Dans notre système de gestion de projet d’entreprise, nous faisons maintenant une définition plus détaillée, en utilisant les phases d’origine de la définition de portefeuille qui a été poussée de haut en bas. Cela permet de mettre à jour ce résumé dans le système de portefeuille lorsque nous mettons à jour nos projets. Nous effectuons de nombreuses tâches et affectons de nombreuses ressources. Nous effectuons maintenant une analyse de nivellement des ressources pour déterminer notre capacité sur de nombreux projets.
Nous utilisons nos affectations de ressources pour envoyer (push) des données de tâche et d’affectation à chaque utilisateur en tant qu’événement de calendrier ou de tâche Outlook. Les utilisateurs n’ont plus besoin d’accéder à un « système de gestion de projet ». Ils sont désormais en mesure de voir leurs données dans leur agenda quotidien. Les données ressemblent à celles de la liste des projets et sont liées plus en amont à la vue de portefeuille.
La progression de ces tâches et la disponibilité à partir d’Outlook sont déplacées de l’individu vers le système de gestion de projet, avec des estimations sur le moment où ce travail sera terminé. Les données ressemblent aux deux autres systèmes, de sorte que le déplacement des données est relativement facile.
La création d’un tel système est techniquement très simple à l’aide des outils disponibles aujourd’hui, ainsi que d’un peu de configuration et de développement. Et il se montrerait magnifiquement.
On nous demande exactement ce type de structure sur une base régulière. Mais, même si nous pouvons le faire, devrions-nous?
Imaginez qu’au niveau de la tâche, une personne prend la matinée pour une visite dentaire d’urgence et met à jour outlook qu’elle ne sera pas disponible ce matin. C’est une mauvaise nouvelle pour lui, mais les effets d’entraînement sur le projet pourraient être énormes. Maintenant, le système de projet calcule que la tâche qui devait être effectuée ce matin ne sera pas terminée aujourd’hui; il ne sera terminé qu’à la mi-journée demain. Il examine conscieusement le chemin critique et toutes les tâches en aval de celui-ci et les pousse vers l’avant de quatre heures. Des centaines de tâches ont peut-être été affectées. Le résultat peut être l’envoi de la date de fin du projet une demi-journée plus tard. D’autres projets sont également affectés, car les autres personnes travaillant sur ce projet doivent maintenant avoir leurs tâches réorganisées et l’affichage du portefeuille lui-même glisse vers l’avant de quelques pixels.
Si nous imaginons cela en temps réel, le problème est amplifié. Des centaines ou des milliers de personnes effectuent des modifications tout au long de la journée, et la vue EPM, la vue de nivellement des ressources et la vue portefeuille s’animent d’avant en arrière avec les effets.
En réalité, cela ne se produit pas. Tout d’abord, la patiente indécise sera de retour à son poste à midi et pourrait juste travailler quelques heures plus tard ce soir pour s’assurer que ce chemin critique est rattrapé et que tous seront de nouveau sur les rails le matin.
De plus, même si les données se ressemblent, elles ne sont jamais intégrées de cette façon en raison exactement de cet effet.
Contexte des données : la perspective est importante
Lorsque nous examinons les données, le contexte des données est critique. Les données qui peuvent ressembler à un schéma d’enregistrement à enregistrement sont utilisées à des fins très différentes en fonction de la perspective de l’application.
Dans une vue de portefeuille de haut en bas, nous prenons des décisions stratégiques sur l’emplacement où placer nos ressources afin d’optimiser notre retour sur investissement. Nous pouvons faire des choix qu’un responsable de projet ne ferait pas. Dans ma propre organisation, nous avons parfois choisi des projets qui sont complètement en dehors de nos compétences existantes, sachant que nous serions terriblement inefficaces pour les accomplir, mais parce que nous voulions améliorer ces compétences. Le retour sur investissement n’était pas une installation efficace, c’était des installateurs formés. Il s’agit d’une vue analytique.
Dans une vue de projet tactique, nous prenons des décisions opérationnelles sur l’endroit où obtenir le meilleur débit de notre personnel et pour faire en sorte que nos projets soient terminés aussi rapidement et efficacement que possible. Le regard d’un chef de projet est toujours vers l’avenir. Ce qui s’est passé dans le passé n’est intéressant que pour le chef de projet dans la mesure où il améliore sa vision de l’avenir. Il s’agit également d’une vue hautement analytique.
Dans une vue de gestion des tâches telle qu’un ordre du jour, nous ne sommes pas analytiques. Un ordre du jour est un système d’engagement. Nous promettons à nous-mêmes ou aux autres que nous ferons une chose particulière à un moment donné. Cela peut correspondre à la vue analytique. Et ce n’est peut-être pas le cas.
La combinaison de ces perspectives et contextes sans comprendre l’impact peut provoquer un chaos.
De haut en bas ou de bas en haut ?
Comme d’habitude, il n’y a pas de réponse juste. Certains aspects de votre système de gestion de projet doivent vraiment venir de bas en haut. Après tout, en fin de compte, ce sont les individus qui vont construire tout ce que votre projet a pour objet. Mais certaines décisions sont et doivent être prises de haut en haut et sont, par nécessité, de haut en bas.
Lorsque vous conservez les distinctions entre chaque niveau du paradigme de gestion de projet, il devient plus clair de voir si certains de ces systèmes doivent vraiment être intégrés ou non. Si le processus et la réflexion d’un niveau n’ont pas d’avantage direct en étant entièrement intégré à partir d’un autre niveau, l’intégration n’est pas la meilleure solution. Il est important de découvrir comment une telle intégration fonctionne dans un contexte réel et si la fréquence et les détails d’un niveau apportent une valeur à l’autre.
Si, par exemple, un comité directeur ne se réunit qu’une fois par trimestre pour prendre des décisions importantes sur les projets à mettre en avant ou non, alors quel est l’avantage de mettre à jour son point de vue tous les jours, chaque semaine, voire tous les mois?
L’algorithme de nivellement des ressources de gestion de projet d’entreprise a-t-il vraiment besoin de voir le rendez-vous dentaire d’une personne ou est-il suffisant pour connaître la disponibilité approximative de cette personne ?
Et pourtant, si nous pouvions envoyer un devoir directement à l’ordre du jour ou à l’écran de feuille de temps d’un individu, est-ce que cela lui éviterait quelques minutes chaque jour d’avoir à passer dans un système et une interface différents pour voir les mêmes données ?
Ainsi, de haut en bas est juste dans certaines circonstances et de bas en haut dans d’autres. Vous devez examiner votre propre situation pour voir où l’intégration de ces outils et concepts peut rembourser les dividendes appropriés avant de les lier.
À propos de l’auteur
Chris Vandersluis est le président et fondateur de HMS Software, basé à Montréal, au Canada, un partenaire certifié Microsoft. Il a un diplôme en économie de l’Université McGill et plus de 30 ans d’expérience dans l’automatisation des systèmes de contrôle de projet. Il est un membre de longue date du Project Management Institute (PMI) et a participé à la création des sections de Montréal, Toronto et Québec du Microsoft Project Users Group (MPUG). Les publications pour lesquelles Chris a écrit incluent Fortune, Heavy Construction News, le magazine Computing Canada et PMNetwork de PMI, et il est un chroniqueur régulier pour Project Times. Il enseigne la gestion avancée de projets à l’Université McGill et intervient souvent à des fonctions d’association de gestion de projets dans Amérique du Nord et partout dans le monde. HMS Software est l’éditeur du système de gestion du temps timecontrol orienté projet et est partenaire de solution Microsoft Project depuis 1995.
Chris Vandersluis peut être contacté par e-mail à l’adresse : chris.vandersluis@hms.ca
Si vous souhaitez lire d’autres articles relatifs à L’EPM de Chris Vandersluis, consultez le site d’aide sur l’EPM de HMS (https://www.epmguidance.com/?page_id=39).