Ils disent qu’ils souhaitent une résolution : livre blanc

Ce livre blanc fait partie de notre collection « Depuis les tranchées ». Il décrit certains défis courants que vous pouvez rencontrer dans le cadre de la planification des projets. Il décrit l’adoption de la meilleure approche lorsque vous essayez de déterminer la durée des tâches et le nombre de tâches nécessaires pour optimiser un planning de projet. Il décrit en quoi les différents secteurs d’activité nécessitent généralement différents types de plannings (par exemple, développement de logiciels, EPC (ingénierie, approvisionnement et construction) et arrêt d’installation). Il présente également plusieurs facteurs à prendre en considération pour le choix de la résolution du projet (par exemple, durée du projet, ressources impliquées, gestion ou répartition des ressources, vitesse et effort requis dans le cadre de la collecte des données et planification de la mise à jour des données).

Pour télécharger la version Word de ce livre blanc, voir Ils disent qu’ils souhaitent une résolution : livre blanc (Project Server 2010).

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

Ils disent qu’ils souhaitent une résolution

Avec toutes nos excuses aux Beatles pour le titre, le sujet d’aujourd’hui est la résolution de votre projet.

De nombreuses ressources sont disponibles sur la façon d’établir un planning. Toutefois, l’un des enseignements les plus critiques est extrêmement difficile à tirer : combien de tâches votre planning de projet doit-il comprendre et quelle doit être leur durée ?

Je suis régulièrement confronté à des plannings de projets incroyablement complexes ou à des gestionnaires de projets qui semblent incapables d’épingler d’éventuels problèmes dans leurs plannings parce que ceux-ci sont résumés à l’excès. Il m’est arrivé de voir un projet qui s’étalait sur plus de cent ans (vraiment), dont la longueur était parfaitement appropriée, et qui comprenait des tâches d’une durée de plusieurs décennies. J’ai également vu des plannings de projets d’une durée d’une heure ou moins, qui étaient parfaitement appropriés et dont certaines tâches ne duraient qu’une minute. J’ai vu des projets ne comprenant qu’une poignée de tâches, et d’autres en comptant plus de 100 000.

Les logiciels que nous utilisons aujourd’hui peuvent gérer des milliers de tâches et un vaste éventail de durées.

Dès lors, quelle est la bonne approche ?

Quelle doit être la longueur des tâches et combien en faut-il pour optimiser un planning de projet ? C’est ce que j’appelle la résolution du projet.

Caractéristiques différentes en fonction du public

Les besoins pouvant varier selon les secteurs d’activité, les types de projets et les situations, voyons comment déterminer le nombre et la durée des tâches à prévoir dans un planning.

Différents types de projets appellent naturellement différents types de plannings. Considérons trois exemples :

  1. Développement de logiciel   . De nombreux projets de logiciels présentent des caractéristiques communes. Chaque projet de logiciel est unique, mais comprend généralement une phase de conception, une phase de programmation, une phase d’assurance qualité, une phase de documentation et une phase de déploiement. Les projets de logiciels s’étalent généralement sur plusieurs semaines ou mois, et comprennent des tâches d’une durée d’un jour à quelques semaines. L’allocation des ressources s’effectue souvent au niveau individuel.

    Ceux qui adoptent un processus Agile pour le développement de logiciel envisagent des « sprints » brefs, d’une ou deux semaines, comprenant des tâches de courte durée, la durée globale du projet se mesurant en semaines. Nous en dirons plus sur le développement Agile un peu plus tard.

    Affichage Diagramme de Gantt de sprint Agile
  2. EPC – ingénierie, approvisionnement et construction   . Les projets EPC sont ceux dans le cadre desquels la méthodologie de planification de chemin critique a fait son apparition. Dans ce type de projet, le développement a trait à un objet de très grande ampleur. Il peut s’agir d’un ambitieux projet de défense tel que le projet de missiles Polaris qui a donné naissance aux diagrammes PERT, d’une plate-forme pétrolière en mer, d’un navire ou encore d’une centrale électrique. Ces types de projets comprennent une phase d’ingénierie consistant à concevoir le projet fini. Cette phase d’ingénierie comporte généralement un aspect qui n’a encore jamais été conçu. La phase d’approvisionnement porte sur la recherche, l’acquisition et la gestion des fournitures ou des contrats secondaires pour les divers éléments du projet. Durant la phase de construction, le produit final est construit, puis mis en service. Nous nous représentons généralement les plannings de projets EPC en termes de mois ou d’années, avec des périodes d’activité de quelques semaines à quelques mois. Il n’est pas rare que de tels projets comprennent entre 5 000 et 20 000 tâches. Dans ce cadre, la planification des ressources s’effectue presque toujours au niveau des compétences plutôt qu’au niveau individuel. Par ailleurs, pour pimenter le tout, un programme ou projet maître peut comprendre un grand nombre de sous-projets destinés à en faciliter la gestion.

    Affichage Diagramme de Gantt de plusieurs projets et sous-projets
  3. Arrêt d’installation   . Lorsque vous planifiez un projet d’arrêt d’installation pour maintenance, vous travaillez dans des conditions de planification parmi les plus difficiles qui soient. Un arrêt d’installation pour maintenance peut avoir lieu de façon planifiée ou d’urgence. Laissons pour l’instant de côté la situation d’urgence qui constitue un monde à part. La durée d’un arrêt d’installation planifié dépend largement du type d’installation. Par exemple, l’arrêt pour maintenance « rapide » d’une unité de centrale nucléaire peut prendre 12 mois. L’arrêt pour maintenance d’une raffinerie de pétrole peut durer entre 4 et 6 semaines. Toutefois, le type de planification d’arrêt d’installation qui me semble le plus intéressant est celui d’une usine de production d’acier, de papier ou d’autres matières. Il existe des milliers voire des dizaines de milliers d’installations de ce type dans le monde, qui doivent faire l’objet d’une maintenance régulière environ chaque année.

    Le coût de l’arrêt de telles installations se chiffre généralement en coût d’opportunité, c’est-à-dire la valeur de ce qui n’est pas produit lorsque l’installation est inactive pour cause de maintenance. Ce coût est exprimé en heures dont la valeur unitaire peut atteindre jusqu’à 250 000 dollars. Ainsi, chaque minute compte pour l’exécution de la tâche. Dans ce genre de situation, l’arrêt dure généralement de 5 à 8 jours, et un retard d’une seule journée se chiffre en millions. Si vous êtes habitué à des planifications plus longues, plus traditionnelles, vous vous interrogez peut-être sur le nombre de tâches qui seraient normalement effectuées en quelques jours. Toutefois, il n’est pas rare qu’un tel arrêt porte sur 2 000 à 4 000 tâches d’une durée de 15 minutes à quelques heures chacune. Dans ce cas, l’affectation des ressources se fait par compétence, mais leur ajustement est rarement répercuté sur le personnel. Avec un tel coût horaire, peu importe le nombre de personnes mobilisées pour le projet. Tout ce qui compte, c’est de faire au plus vite. Dans une telle situation, l’ajustement des ressources se fait souvent en fonction de goulets d’étranglement très contraignants. Par exemple, « le local électrique ne pouvant pas accueillir plus de deux personnes, il faut gérer cet aspect séparément ».

    Affichage Diagramme de Gantt des tâches séquentielles

Bien, nous avons donc trois types d’exemples. Il y en a bien sûr beaucoup plus, mais cela suffira amplement pour illustrer notre propos. Le type un (développement de logiciel) inclut des tâches d’une durée généralement comprise entre un jour et deux semaines. Le type deux (EPC) comporte des tâches pouvant s’étaler sur plusieurs semaines ou mois. Le type trois (arrêt d’installation) englobe des tâches dont la durée se mesure en tranches de 6 minutes (1/10ème d’heure), de 10 minutes, de 15 minutes (1/4 d’heure) ou de quelques heures. Il est évident que, dans certains cas, des tâches courtes ont un sens, alors que dans d’autres cas, des tâches longues sont plus appropriées. En suivant le même raisonnement, il est parfois logique d’avoir un très grand nombre de tâches, et parfois pas.

Facteurs déterminant le choix de la résolution de votre projet

Ces trois distinctions montrent clairement que la tâche de projet EPC de deux mois semblerait absurde dans le cadre d’une planification d’arrêt de six jours, et qu’une tâche de 15 minutes serait tout aussi incongrue dans le cadre d’un projet EPC ou de développement de logiciel. Toutefois, à part se référer à cet article et en déduire que, s’il s’agit d’un projet de développement de logiciel, 1 à 10 jours devraient suffire (surtout, ne faites pas ça), quelles caractéristiques d’un projet nous indiquent quel niveau de résolution choisir ? En voici quelques-unes évidentes :

Quelle est la durée du projet ?

Commençons par ce qui est le plus manifeste. Si votre projet est supposé durer quelques jours, comme dans notre exemple d’arrêt, prévoir des tâches de plusieurs jours n’a aucun sens. Une première approche descendante est souvent productive pour réfléchir au fractionnement d’un projet. Réfléchissez à une structure de répartition du travail. Commencez par les principaux composants. Songez à prévoir entre 4 et 20 éléments.

Est-ce une règle ? Non, bien sûr que non.

Il s’agit de bon sens. Avec moins de 4 éléments, vous vous demandez pourquoi avoir fractionné le travail, et avec plus de 20, il devient trop difficile de tout garder à l’esprit. Personnellement, je commence par me limiter à 8 éléments par élément de structure de répartition du travail. Ce choix résulte de la lecture d’un article publié il y a quelques années, selon lequel l’octogone serait la forme simple la plus complexe que l’esprit puisse appréhender instantanément.

Réfléchissez-y un instant. Vous pouvez identifier un cercle, un triangle, un carré, un pentagone, un hexagone avec ses 6 côtés, un heptagone avec ses 7 côtés (même s’il est plus difficile à visualiser) et un octogone.

Pouvez-vous identifier une forme comportant 9 côtés sans les compter ? Moi, je ne peux pas. Pour les puristes, c’est ce qu’appelle un « ennéagone ».

Donc, personnellement, j’essaie de m’en tenir à la limite de 8 éléments, le principe étant de ne pas en avoir moins de 4 ou plus de 20.

Pour chaque élément examiné, réfléchissez à la manière de répartir le travail. Une fois encore, songez à la règle des 4-20. Tout le secret est de savoir quand s’arrêter. Des gestionnaires de projets débutants auront tendance à subdiviser, puis subdiviser et subdiviser encore jusqu’à ce que chaque étape soit une tâche managée. Voici quelques questions décisives que vous pouvez vous poser sur la durée d’une tâche :

  • Quelle mesure prendrais-je si cette tâche était tardive ?    Si la réponse est « aucune », cela signifie probablement que la tâche en question est trop modeste pour nécessiter une gestion. Dans ce cas, vous vous égarez peut-être dans les détails. Remontez d’un niveau, à l’étape précédente, pour voir si cela suffit.

  • La collecte des données relatives à l’avancement de cette tâche prendra-t-elle plus de temps que la tâche elle-même ?    Nous ne songeons pas toujours aux efforts nécessaires pour gérer une tâche planifiée, mais il est judicieux d’y réfléchir ne serait-ce qu’un instant. S’il apparaît que la gestion de la tâche nécessitera plus d’efforts que son exécution, cela signifie probablement que la tâche est définie à un niveau de détail trop fin.

  • Quelle est la durée cette tâche ?     Lorsque nous subdivisons un travail, il arrive que nous perdions de vue à quel point une tâche devient minuscule. Les phases importantes de niveau supérieur s’étalent peut-être sur quelques semaines. En revanche, à mesure que nous descendons de quelques niveaux de granularité, nous pouvons facilement tomber dans le piège de définir une tâche à gérer, qui ne nécessite en réalité que quelques minutes. À propos des petites tâches, il faut s’interroger sur l’avantage qu’il y a à les gérer.

Confrontons à la réalité mes propos précédents. Dans un projet EPC de deux ans, un retard d’un jour sur une tâche d’une semaine ne nécessite probablement pas de mesure particulière. Dans un projet de développement de logiciel de six mois, un retard d’un jour sur une tâche d’une semaine ne nécessite probablement pas de mesure particulière. Dans un projet d’arrêt d’installation de six jours, un retard d’un jour sur une tâche d’une semaine constitue une situation d’extrême urgence. Autrement dit, une tâche d’une semaine dans le projet EPC peut correspondre à un niveau de détail trop fin, est probablement au niveau de détail approprié dans le projet de développement de logiciel, et nécessite presque certainement un niveau de détail plus important dans le projet d’arrêt d’installation.

Combien de ressources humaines sont impliquées ?

Je sais que nous nous intéressons en ce moment à l’étendue du projet. Toutefois, au moment d’examiner le type de résolution nécessaire, il faut réfléchir au nombre de personnes qui travailleront sur une tâche. Par exemple, dans un grand projet EPC, des dizaines de travailleurs de compétence égale peuvent être impliqués dans une même phase de travail. En revanche, si une même tâche requiert de nombreuses compétences différentes, sa gestion devient très compliquée, sinon impossible. Dans ce cas, les tâches qui nécessitent de nombreuses compétences différentes doivent probablement être divisées.

Dans un projet de développement de logiciel, nous avons tendance à considérer presque chaque personne comme une ressource éminemment technique disposant de capacités uniques. De plus, dans des projets de ce type, il est fréquent d’avoir de nombreuses tâches pouvant être ré-attribuées au sein d’un département, mais une seule tâche affectée à une personne déterminée. Ainsi, lorsque nous avons des tâches allouées au niveau d’un seul membre d’un groupe de ressources ou d’un département particuliers (par exemple, pour la programmation de l’interface), nous pouvons dire avec une quasi-certitude qu’il ne faut pas davantage de détails.

Comment les ressources sont-elles gérées ou subdivisées ?

La manière dont les ressources sont gérées détermine considérablement la manière de subdiviser les tâches. Par exemple, les grands projets EPC sont souvent subdivisés en sous-projets alloués à de gros sous-traitants. Dans ce cas, il y a plusieurs choses à faire :

  • Définir le travail de façon à ce qu’un gestionnaire de projet puisse superviser le sous-traitant, en sachant que la progression du projet est un facteur important.

  • Définir les tâches de manière à ce que le personnel d’ingénierie et de gestion de projet du sous-traitant en comprenne la signification sans aucune ambiguïté.

  • Assurez-vous que le niveau de résolution que vous avez adopté comme standard est compris et accepté par le sous-traitant.

En ce qui concerne les projets de nature intellectuelle, par exemple, en relation avec l’informatique, la recherche biologique ou l’ingénierie, il est fréquent de rencontrer une structure de gestion matricielle où les gestionnaires de projets ne disposent d’aucune ressource, entraînant la nécessité de travailler avec des responsables de département qui allouent les ressources nécessaires à différents projets. Dans ce cas, les questions clés doivent être les suivantes :

  • Sur combien de projets une ressource est-elle susceptible de travailler au cours d’une même journée ?

  • De combien de temps un employé a-t-il besoin pour passer d’un projet à l’autre ?

  • Le travail est-il défini de telle sorte que les employés et responsables de département comprennent comment y allouer les compétences adéquates ?

Lorsque nous considérons un projet d’arrêt d’installation ou de construction, nous avons tendance à réfléchir en termes d’équipes spécialisées. Dans ces situations, un responsable d’équipe de ressources pourrait gérer l’équipe d’électricité (même si elle comprend des menuisiers et tuyauteurs), une équipe de plomberie ou une équipe de rénovation d’unité de chauffe. Le travail doit être organisé de façon à pouvoir occuper l’équipe pendant toute sa période de travail, et à ce que l’équipe ne doive pas intervenir en même temps qu’une autre équipe dans une même zone. Compte tenu de la pression intense liée à la conduite d’un projet d’arrêt d’installation, il est fréquent que le travail soit d’abord organisé par tâche, puis planifié, puis regroupé et réparti entre les chefs d’équipe de façon à ce que chacun d’eux dispose d’un document reprenant uniquement l’ensemble des tâches qui lui sont attribuées, le projet entier étant décrit en contexte dans un document distinct. Les tâches doivent donc être définies d’une manière compréhensible par l’employé et le chef de l’équipe de ressources. Les tâches peuvent alors être définies avec une précision d’une heure, voire d’un quart ou d’un dixième d’heure.

À quelle vitesse pouvez-vous collecter les données et quel effort cela nécessite-t-il ?

Cette question peut sembler idiote si vous avez l’habitude de voir vos données de projet parfaitement organisées et prêtes à l’emploi en fin de semaine. En revanche, si vous tentez de déterminer le niveau de résolution de votre projet, ce peut être une question clé. Par exemple, si vous travaillez avec de nombreux sous-traitants, il est probable que vous receviez une sorte de mise à jour hebdomadaire ou mensuelle. En fait, il est essentiel que vous intégriez la clause de mise à jour de gestion de projet dans votre contrat. Dans ce cas, vous devez intégrer les données de ces différentes sources dans vos propres données, valider le sens des données de progression, puis effectuer vos propres tâches d’analyse et de rapport. Dans le cadre d’un projet EPC, vous pouvez probablement effectuer ces opérations une fois par mois.

Dans le cadre d’un projet d’arrêt d’installation, vous devez mettre à jour votre projet à chaque changement d’équipe, l’actualiser rapidement et faire parvenir les mises à jour aux chefs d’équipe au milieu de la période de travail de l’équipe suivante. Dans ce cas, le personnel du projet se disperse dans l’installation pendant toute la période de travail de l’équipe, collectant des données dans un délai aussi proche que possible du temps réel, tandis que les chefs d’équipe et contremaîtres consignent sur des feuilles de travail appropriées l’avancement des tâches qui leur sont attribuées. Dans le cadre d’un projet de développement de logiciel ou de recherche, vous travaillez probablement sur un planning hebdomadaire ou un système similaire, avec les intervenants rendant compte de leur propre progression et recueillant des approbations quotidiennement ou tous les deux jours.

Il est important de prendre cet aspect en considération lors de l’examen du nombre de tâches à prévoir dans votre projet, car la collecte des données a un coût.

Il est donc essentiel de réfléchir au temps nécessaire pour collecter, approuver, intégrer, analyser et rapporter les données à intervalles réguliers, ainsi qu’au coût de cette collecte et à la valeur de retour sur investissement des données collectées.

Quelle sera la fréquence de mise à jour ?

Voici deux clés pour déterminer la quantité de données que vous pouvez collecter et inclure :

  • Réfléchissez à la façon dont vous collecterez vos données.

  • Réfléchissez à la fréquence à laquelle vous pouvez raisonnablement mettre à jour votre projet et en assurer la gestion avec les outils de prise de décision requis pour conduire le projet et les ressources dans la bonne direction.

J’ai vu des responsables de projets insister sur leur volonté de passer à une gestion de projet et à une collecte de données en temps réel. Bien que cela soit théoriquement possible, il est extrêmement difficile d’y parvenir dans la pratique.

Lorsque nous considérons les données de gestion d’un projet, nous faisons des suppositions. Ces suppositions sont les suivantes :

  • Les données complètes   . Nous ne nous attendons pas à ce que certaines tâches soient à jour et d’autres non.

  • Les données ont toutes été mises à jour à peu près simultanément   . Nous ne nous attendons pas à ce que certaines tâches aient été mises à jour il y a quelques minutes, alors que les autres tâches ne l’ont plus été depuis deux semaines.

  • Toutes les données ont reçu un certain niveau d’approbation   . Nous nous attendons à ce que le responsable de projet puisse garantir que les données présentées constituent une représentation juste et précise du projet.

  • Les données constituent un ensemble cohérent   . Nous ne nous attendons pas au risque d’être trompé par certains coûts ou ressources imprécis, sauf si nous avons spécifiquement conçu nos rapports et analyses dans cette perspective.

Je demande souvent aux cadres que le concept de gestion de projet en temps réel enthousiasme ce qu’ils feraient si nous pouvions surmonter les problèmes que je viens d’évoquer. « Êtes-vous prêt à prendre des décisions de gestion à longueur de semaine ? » C’est toute la question. La réponse devrait dépendre du niveau de résolution. Dans un projet d’arrêt d’installation, devrait être positive. Dans un projet de développement de logiciel, la réponse serait probablement : « Non. Nous ferons ça une fois par semaine ». Et dans un projet EPC, la réponse serait : « Une fois par mois ».

À un moment donné, la loi des rendements décroissants amène à considérer qu’une fréquence plus rapide de remise de rapports de projet n’apportera pas de gain d’efficacité.

Révision de votre travail

Vous avez à présent matière à réflexion. Vous avez utilisé la méthode de répartition du travail pour subdiviser vos données, et vous avez observé certains signes d’avertissement indiquant que les données sont trop finement définies. Il est temps d’accrocher le planning au mur, de revenir en arrière, et d’examiner le projet dans une certaine perspective. Étonnamment, de nombreux responsables de projets ne font jamais cela. Ils se soucient tellement des détails infimes et de la subdivision des tâches à l’infini qu’ils se retrouvent à la date de mise en œuvre sans jamais avoir tenté de voir si ce qu’ils ont préparé sera gérable.

Parfois, la formation qu’ils ont reçue les pousse à penser que « plus il y a de détails, mieux ça vaut », et à définir des tâches de 5 ou 15 minutes pour des projets de six mois.

Il est toujours plus facile de modifier un projet avant son lancement qu’après. Par conséquent, prévoyez du temps dans votre activité de planification pour pouvoir remanier le planning si nécessaire.

Est-ce de trop ?

Les responsables de projets réalisent parfois, en considérant l’étendue de ce qu’ils ont créé, que le niveau de détail est trop fin. Dans ce cas, il est très facile de résoudre le problème. Cela peut nécessiter beaucoup de travail, mais vous vous féliciterez ensuite d’avoir simplifié le planning en remontant d’un niveau.

Il est parfois difficile d’avoir une vue d’ensemble. Dans certains cas, ce n’est qu’une fois le planning entièrement établi que le responsable de projet constate à quel point il est complexe. Les projets complexes sont, par nature, plus risqués. Dans la conjoncture actuelle, le risque est un facteur clé pour la sélection des projets. Certaines questions qui méritent votre attention avant le lancement d’un projet complexe peuvent être les suivantes :

  • Pouvons-nous faire cela en plusieurs parties ?    Certains projets risqués peuvent être fractionnés en projets de plus petite taille. Le risque associé à ces projets plus modestes est moindre. Toutefois, si vous optez pour cette stratégie, chaque projet doit avoir sa propre valeur une fois terminé.

  • Devons-nous repenser l’étendue du projet ?    La solution la plus simple est parfois de revenir aux concepteurs d’origine du travail, de mettre en évidence la complexité de la planification, et de voir s’il est possible de recommencer le travail. Cela aboutit souvent à des idées innovantes qui n’auraient jamais germé autrement.

Devons nous vraiment réaliser ce projet ?

Certains projets ne devraient jamais voir le jour. Le moment le plus économique pour les annuler est le jour précédant leur lancement. Si le risque lié à un projet n’apparaît que maintenant, il vaut mieux en prendre conscience maintenant que plus tard. En rapportant les conclusions tirées de votre planification au processus de gestion de portefeuille de projets (PPM), vous découvrirez peut-être que le risque lié au projet plus complexe présente un score de travail bien pire sur l’échelle de retour sur investissement.

Un projet Agile

J’ai promis de dire quelques mots sur de la gestion de projet Agile. Si vous êtes fan d’Agile et avez lu jusqu’ici, je vous remercie de votre patience. La gestion de projets de développement de logiciels selon la méthode Agile participe d’une certaine philosophie de plus en plus populaire auprès de ceux qui ont échoué dans le cadre de projets ambitieux de développement de logiciels.

Dans un environnement de développement de logiciel Agile, nous essayons de décomposer notre projet en « sprints » d’une à trois semaines, l’objectif de chaque mini-projet étant d’aboutir à un code utilisable. Dans ce cadre, nous travaillons dans le respect de contraintes bien connues, de sorte que notre niveau de résolution est parfaitement adapté.

Nous disposons d’une fenêtre d’une à trois semaines, les ressources sont à notre disposition et nous affectons un travail à chacune d’elles. Le nombre de tâches que nous pouvons définir dans cette structure est limité, et se prête au maintien d’un niveau approprié de résolution. Vous bien sûr rencontrer des problèmes dans Agile en définissant des tâches beaucoup trop courtes. « Define Field1: 10 minutes, Define Field2: 10 minutes, Define Field3: 10 minutes », etc., mais c’est beaucoup moins fréquent.

Agile a été conçu comme un environnement de développement d’entreprise où nous créons un logiciel pour un usage interne, mais son utilisation est souvent étendue au développement de logiciels commerciaux. (Chez HMS, nous utilisons la méthode pour le développement de notre système TimeControl.) La méthode Agile permet de disposer d’un département de développement plus maniable et souple, mais ne s’applique pas à tous les secteurs ou à toute société de développement de logiciels. Si vous effectuez la gestion de projets dans un environnement logiciel, je vous recommande de vous informer sur Agile, puis d’adopter les éléments (tous, certains ou aucun) susceptibles de renforcer votre efficacité.

En résumé

Comme pour la plupart des aspects de la gestion de projet, il n’existe pas de réponse toute faite aux questions apparemment évidentes. Le choix du nombre de tâches que comporte votre projet et de leur durée vous appartient… Mais vous devez décider.

Le choix du niveau de résolution de votre projet est une responsabilité qui peut être déterminante pour le succès de la gestion de la planification du projet.

À 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.

×