Du haut vers le bas ou du bas vers le haut : livre blanc

Ce livre blanc fait partie de notre collection « Depuis les tranchées ». Il traite de la gestion de projets, de la gestion de portefeuille et de la gestion des tâches, en comparant les pratiques de gestion de haut en bas et de bas en haut qui y sont associées.

Pour télécharger la version Word de ce livre blanc, voir Du haut vers le bas ou du bas vers le haut : livre blanc (Project Server 2010).

Pour consulter d’autres livres blancs, voir les livres blancs « Depuis les tranchées ».

Du haut vers le bas ou du bas vers le haut ?

« Nous avons besoin d’une solution de gestion de projets... Je veux dire, de gestion de portefeuille... Enfin, surtout de gestion des tâches... Oh, et puis zut ! On a besoin de tout ça. » Je ne compte plus le nombre de fois où j’ai entendu ce genre de propos. Cette confusion ne naît pas d’un manque de définition de ces trois concepts, mais de leur similarité.

Ceux d’entre nous qui travaillent dans le secteur de l’informatique depuis de nombreuses années finissent par considérer les choses d’un point de vue trop technique. Parfois, cela nous joue des tours. Des données de gestion de portefeuille, de gestion de projets et de gestion des tâches peuvent sembler très similaires. Dans les trois cas, j’ai un champ d’identifiant, un champ de description et des champs de date de début et de fin. La liaison de ces trois systèmes de gestion entre eux devrait être naturelle.

Et bien, peut-être pas.

Examinons ces trois concepts un par un. Il est facile de voir leurs similitudes, mais il existe des différences fondamentales entre les trois perspectives.

Gestion de portefeuille : une approche de haut en bas

Le concept de « gestion de portefeuille » peut signifier bien des choses différentes selon les personnes mais, le plus souvent, il a trait à la sélection et à la hiérarchisation de projets. Les principes affectent en définitive tous les membres de l’organisation, mais le processus est très utile pour les cadres supérieurs. La gestion commence par certaines contraintes comme un budget total disponible et la nécessité de répondre à la question : « Que pouvons-nous et devrions-nous faire de cet argent » ? Si le processus de gestion de portefeuille est suffisamment mûr, cette analyse devrait inclure, outre des idées nouvelles, des projets existants.

Tableau de bord affichant l’état de plusieurs projets

Pour créer un processus de sélection et de hiérarchisation de portefeuilles, la gestion doit considérer les critères qui déterminent l’orientation de l’entreprise et convenir à l’avance des indicateurs qui seront pris en compte lorsque de l’examen de projets nouveaux ou existants. Le retour sur investissement doit-il être un indicateur clé ? Peut-être devrions-nous prendre en compte les effets sur la satisfaction des clients, la rétention du personnel ou l’alignement avec les objectifs stratégiques. Quels que soient les indicateurs clés, la gestion doit permettre de pondérer chaque initiative de projet afin de déterminer comment ce projet s’inscrit dans la poursuite des objectifs et comment il se compare à d’autres initiatives auxquelles l’argent pourrait être consacré.

Ce processus est éminemment analytique, même s’il est exécuté mentalement. Et il est définitivement très analytique si vous utilisez un logiciel de gestion de portefeuille de projets. Même lorsque l’analyse du logiciel arrive sous la forme d’un rapport ou d’un affichage, l’encadrement effectue presque toujours une supervision pour prendre une décision finale concernant les priorités. Lorsque cette opération terminée, les résultats finaux doivent être transmis à ceux qui assureront la gestion de chacun des projets. Les effets de ces décisions seront de financer certains projets et non d’autres, de rendre des ressources disponibles en priorité pour certains projets plutôt que d’autres, et d’avancer dans l’échéancier de certains projets en en retardant d’autres.

Gestion de projet : de haut en bas et de bas en haut

Une fois qu’un projet est approuvé, il passe dans un domaine complètement différent. Désormais, l’attention se concentre sur l’affichage plus classique de la planification de projet. À présent, nous devons réellement créer ce que nous avons décrit dans notre justification d’entreprise avant son approbation.

Un responsable de projet commence à réfléchir à l’étendue du projet et aux éléments à livrer. Le responsable de projet sait quel est le produit fini à créer, qu’il s’agisse d’un composant logiciel ou d’un bâtiment prêt pour occupation. Il peut envisager les phases principales du projet et créer une structure de répartition du travail.

Phases principales d’un projet illustrées dans un graphique

Un chemin critique comprenant les étapes logiques requises pour l’accomplissement du projet est conçu. Le responsable de projet, sachant qu’il devra justifier l’échéancier produit, consulte une série d’experts techniques en relation avec le projet. Le responsable de projet crée un affichage de bas en haut du projet, en examinant chaque tâche, puis en récapitulant ces tâches pour définir des phases du projet, voire le projet lui-même. À ce stade, le responsable de projet peut également commencer à allouer des ressources par compétence, par département ou même par nom. Des coûts peuvent être associés à ces ressources. Le résultat du calcul de la durée des tâches, des ressources nécessaires et de leurs coûts constitue une estimation de bas en haut du projet.

Jusque là, tout va bien.

Affichage Diagramme de Gantt d’un projet

Pourtant, si nous considérons l’approche de haut en bas de la procédure de sélection de portefeuille de projet, il y avait également un coût. En fait, le coût estimé du projet faisait partie de la justification d’entreprise que l’encadrement a prise en compte lors de l’approbation du projet. À présent, si nous prenons seulement l’estimation de bas en haut du projet résultant de l’expertise combinée des experts techniques, quelle part l’encadrement a-t-il prise dans la sélection du projet ?

C’est une bonne question. Dans certaines organisations, le projet fera l’objet dune estimation approximative du service du projet afin de créer une justification d’entreprise. Dans d’autres organisations, une estimation complète de bas en haut est créée avant que le projet soit pris en considération dans le processus de portefeuille. Le problème de ces deux approches est qu’elles nécessitent des efforts. Une estimation complète peut nécessiter bien des efforts alors que le projet doit recevoir une approbation préalable au financement de tout effort. Ainsi, dans de nombreuses organisations, un membre de l’encadrement effectue simplement une estimation des coûts futurs du projet.

Le processus semble totalement intégré, mais on peut y voir un cercle vicieux. Qu’est-ce qui se produit en premier, le travail consacré à l’estimation du projet, ou la sélection du projet afin de pouvoir y consacrer du temps ?

En outre, que se passe-t-il si l’estimation de bas en haut ne correspond pas à l’estimation du processus de sélection de portefeuille ? Si l’estimation est inférieure, il n’y a probablement aucun problème mais, si le travail accompli dépasse le temps ou le budget estimé par les responsables de la sélection de portefeuille, il y a conflit.

Vous pourriez penser que la solution naturelle serait de reconvoquer l’encadrement supérieur pour discuter simplement du problème, mais il existe de nombreuses situations où ce n’est pas aussi simple qu’il y paraît.

Tout d’abord, le comité de sélection de portefeuille est rarement l’équipe de gestion de projet. Les membres supérieurs du personnel de gestion de projet font presque toujours partie du comité de sélection de portefeuille, mais le groupe est généralement composé de cadres de très haut niveau qui trouvent difficile d’organiser leur temps pour se réunir tous ensemble. Ensuite, le comité de sélection se réunit parfois de façon sporadique, de sorte que rassembler tout le monde pour discuter de tous les aspects du coût d’un seul projet qui s’écarte de l’estimation peut s’avérer très compliqué. Enfin, selon la culture de certaines entreprises, il est peu opportun pour le plan de carrière d’avoir à informer un cadre supérieur que l’estimation qu’il a faite de l’échéancier et du budget d’un projet était totalement erronée.

Gestion des tâches : une approche de bas en haut

Quand nous songeons à la gestion des tâches, nous avons tendance à considérer les choses sous un angle opérationnel, ce qui nous ramène le plus souvent à notre agenda et à un produit comme Outlook.

Affichage d’une liste des tâches

À présent, nous travaillons au niveau d’un individu ou d’un membre de petite équipe. Nous ne voyons pas les tâches dans leur contexte. Nous voyons les choses auxquelles nous nous sommes engagés, ou peut-être celles auxquelles nous avons demandé à un membre de l’équipe de s’engager. Ce n’est pas du tout une vue analytique. Il existe les tâches à accomplir et les personnes qui ont promis de s’en charger.

Au fond, la gestion des tâches est très simple. Vous accomplissez la tâche puis, quand c’est fait, vous informez la personne qui vous l’a confiée que vous en avez terminé. Toutes les fonctionnalités nécessaires pour cela sont intégrées dans Outlook.

Inconvénient des données similaires

Chacun connaît le dicton : « L’habit ne fait pas le moine. » Ce qui vaut pour les moines vaut également 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, éventuellement, des phases composant ce projet. Les informations de phase peuvent comporter 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 composant le projet. Les informations de tâche peuvent comporter un numéro de code, une description, une durée, une date de début et une date de fin.

  • Au niveau de la gestion des tâches, nous avons une tâche, et les informations de tâche peuvent comporter un numéro de code, une description, une durée, une date de début et une date de fin.

Toutes ces informations se ressemblent mais, en fait, la perspective des données a pour effet que ces enregistrements assez courants servent un objectif très différent.

On me demande souvent : « Puis-je déplacer des données à partir de l’affichage de portefeuille vers l’affichage de projet pour Outlook et inversement ? »

La réponse courte à cette question est « Oui ».

Cependant, dans notre entreprise, nous avons un mantra que nous ressassons avant de donner un conseil technique : « Ne pas dire comment faire, mais pourquoi le faire. »

  1. Pour bien comprendre, imaginez l’exemple suivant. Nous créons un environnement entièrement intégré. Au sommet 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 davantage, en les suivant après leur activation à partir du système EPM. Pour ce faire, nous utilisons des fonctionnalités disponibles pour déplacer les définitions de projet et de phase, du côté du portefeuille de notre système intégré vers le côté projet du système. Les données semblent identiques.

  2. Dans notre système de gestion de projet d’entreprise, nous créons à présent une définition plus détaillée, en utilisant les phases d’origine de la définition du portefeuille qui a été répercutée du haut vers le bas. Par conséquent, lorsque nous mettons à jour nos projets, le récapitulatif dans le système de portefeuille est également mis à jour. Nous créons de nombreuses tâches et affectons de nombreuses ressources. Nous effectuons à présent une analyse de nivellement des ressources afin de déterminer notre capacité pour un grand nombre projets.

  3. Nous utilisons nos affectations de ressources pour envoyer des données de tâche et d’affectation à chaque utilisateur sous la forme de tâches ou d’événements de calendrier Outlook. Les utilisateurs n’ont plus besoin d’accéder à un système de gestion de projet. Ils peuvent désormais voir leurs données dans leur agenda quotidien. Les données présentent le même aspect que dans la liste des projets, et son liées en amont à l’affichage du portefeuille.

  4. Les données Outlook relatives à l’avancement de ces tâches et à la disponibilité sont renvoyées, de la personne au système de gestion de projets, avec des estimations concernant le moment où ce travail sera achevé. Les données se présentant exactement comme dans les deux autres systèmes, leur déplacement est relativement aisé.

La création d’un tel système est techniquement très simple à l’aide des outils dont nous disposons aujourd’hui, moyennant un peu de configuration et de développement. Et sa démonstration serait magnifique.

On nous demande régulièrement ce type précis de structure. Toutefois, bien que nous puissions le faire, le devons-nous ?

Imaginez qu’au niveau de la tâche, une personne prenne sa matinée pour une visite d’urgence chez le dentiste, et mette à jour son Outlook pour indiquer qu’elle sera indisponible pendant cette période. Ce n’est certes pas une bonne nouvelle pour cette personne, mais les répercussions sur l’ensemble du projet pourraient être considérables. À présent, le système de projet calcule que la tâche qui était planifiée pour ce matin ne sera pas accomplie aujourd’hui, mais seulement demain à midi. Il examine consciencieusement le chemin critique et toutes les tâches en aval pour les repousser de quatre heures. Cela peut affecter des centaines de tâches. Le résultat pourrait être un report de la date de fin du projet d’une demi-journée. D’autres projets sont également affectés, car les tâches d’autres personnes travaillant sur ce projet doivent à présent être réorganisées, de sorte que l’affichage du portefeuille lui-même avance de quelques pixels.

Si nous imaginons cela en temps réel, le problème prend une proportion considérable. Des centaines, voire des milliers de personnes modifient leur agenda à longueur de journée, tandis que l’affichage EPM, l’affichage de nivellement des ressources et l’affichage du portefeuille répercutent constamment les effets de ces changements.

En réalité, cela ne se produit pas. Tout d’abord, l’infortuné patient dentaire reprendra son poste à midi et fera peut-être quelques heures supplémentaires en soirée pour éviter de perturber ce chemin critique, de sorte que tout rentrera dans l’ordre le lendemain matin.

De plus, bien que les données semblent identiques, elles ne sont jamais intégrées de cette façon, précisément pour éviter cet effet.

Contexte des données : importance de la perspective

Lorsque nous consultons des données, leur contexte est essentiel. Des données qui peuvent sembler identiques dans un schéma d’enregistrement à enregistrement sont utilisées à des fins très différentes selon la perspective de l’application.

Dans une perspective de portefeuille de haut en bas, nous prenons des décisions stratégiques relatives à l’allocation de nos ressources afin de maximiser notre retour sur investissement. Cela nous permet de prendre des décisions qu’un responsable de projet ne prendrait pas. Par exemple, dans ma propre organisation, nous avons parfois choisi des projets totalement étrangers à nos compétences existantes, en sachant pertinemment que nous serions très inefficaces pour les accomplir. Nous l’avons fait pour la simple raison que nous étions désireux d’acquérir ces compétences précises. Le retour sur investissement ne résultait pas de l’efficacité de l’installation, mais de la disponibilité d’installateurs formés. Il s’agit là d’une vue analytique.

Dans une perspective de projet tactique, nous prenons des décisions opérationnelles concernant l’optimisation du rendement du personnel et la conduite des projets avec un maximum de rapidité et d’efficacité. Le regard d’un responsable de projet est toujours tourné vers l’avenir. Ce qui a pu se produire dans le passé n’a d’intérêt pour un responsable de projet que dans la mesure où cela lui permet d’améliorer sa vision de l’avenir. Il s’agit également d’une vue éminemment analytique.

Dans une perspective de gestion des tâches, comme un agenda, nous ne sommes pas analytiques. Un agenda est un système de gestion des engagements. Nous promettons, à nous-mêmes ou à d’autres personnes, d’exécuter une tâche particulière à un moment donné. Cela peut être compatible avec la vue analytique, mais pas nécessairement.

Une combinaison de ces perspectives et contextes sans compréhension de l’impact éventuel peut créer le chaos.

Du haut vers le bas ou du bas vers le haut ?

Comme d’habitude, la bonne réponse n’existe pas. Certains aspects de votre système de gestion de projets nécessitent réellement une approche de bas en haut. En définitive, ce sont des personnes qui vont créer l’objet de votre projet. Par contre, certaines décisions sont et doivent être prises au sommet, et font nécessairement l’objet d’une approche de haut en bas.

Si vous distinguez clairement la raison d’être de chaque niveau du paradigme de gestion de projets, il devient beaucoup plus facile de déterminer la nécessité ou non d’intégrer ces systèmes. Si l’intégration complète du processus et de la réflexion d’un niveau à partir d’un autre niveau ne produit pas d’avantage direct, cela signifie que l’intégration n’est pas le meilleur scénario. Il est important de se représenter comment une telle intégration fonctionnerait dans un contexte réel, et si la fréquence et les détails d’un niveau apporteraient à l’autre une valeur ajoutée.

Diagramme illustrant un flux de travail

Par exemple, si un comité directeur ne se réunit qu’une fois par trimestre pour prendre les grandes décisions sur les projets à faire avancer ou non, quelle est l’utilité d’actualiser son point de vue chaque jour, chaque semaine ou chaque mois ?

L’algorithme de nivellement des ressources de la gestion de projet d’entreprise doit-il vraiment tenir compte d’un rendez-vous d’une personne chez le dentiste ou suffit-il de connaître la disponibilité approximative de cette personne ?

Et encore, si nous pouvions afficher directement une affectation sur l’agenda ou la feuille de temps d’une personne, cela lui permettrait-il de gagner quotidiennement quelques minutes en lui évitant de devoir accéder à une interface et un système différents pour consulter les mêmes données ?

Ainsi, l’approche de haut en bas est appropriée dans certains cas, et l’approche de bas en haut dans d’autres. Avant de relier ces outils et concepts, vous devez examiner votre propre situation afin de déterminer où leur intégration pourrait être rentable.

À propos de l’auteur

Chris Vandersluis est le président et le fondateur de HMS Software. Basée à Montréal (Canada), l’entreprise est un partenaire Microsoft Certified Partner. Diplômé en sciences économiques de l’université McGill, Chris a plus de 30 ans d’expérience dans l’automatisation des systèmes de gestion de projets. Il est membre du Project Management Institute (PMI) depuis de nombreuses années et a participé à la création des chapitres du Microsoft Project Users Group (MPUG) pour Montréal, Toronto et Québec. Il a publié des articles dans Fortune, Heavy Construction News, Computing Canada et PMNetwork. Il tient également une chronique régulière pour Project Times. Il enseigne la gestion de projets avancée à l’université McGill et intervient souvent lors d’événements organisés par des associations de gestion de projets en Amérique du Nord et dans le monde entier. HMS Software est l’éditeur du système d’horloge pour les projets TimeControl et est un partenaire Microsoft Project Solution Partner depuis 1995.

Vous pouvez contacter Chris Vandersluis à cette adresse : chris.vandersluis@hms.ca.

Pour consulter d’autres articles en lien avec la gestion des projets d’entreprise rédigés par Chris Vandersluis, rendez-vous sur le site EPM Guidance de HMS Software (http://www.epmguidance.com/?page_id=39).

Développez vos compétences
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoignez le programme Office Insider

Ces informations vous ont-elles été utiles ?

Nous vous remercions pour vos commentaires.

Merci pour vos commentaires. Il serait vraisemblablement utile pour vous de contacter l’un de nos agents du support Office.

×