Ils disent qu’ils souhaitent une résolution
Cet article fait partie de notre collection « From the Trenches ». Il décrit certains défis courants que vous pouvez rencontrer lors de la planification de projets. Il décrit la meilleure approche lorsque vous essayez de déterminer la durée des tâches et le nombre de tâches qu’il doit y avoir pour optimiser une planification de projet. Il explique comment différents secteurs d’activité nécessitent généralement différents types de planifications (par exemple, développement de logiciels, EPM (ingénierie, approvisionnement et construction) et arrêt de l’usine). Il traite également de plusieurs facteurs dans le choix de la résolution du projet (par exemple, la longueur du projet, les ressources impliquées, la gestion ou la division des ressources, la vitesse et les efforts nécessaires à la collecte des données et la planification de la mise à jour des données).
Pour télécharger la version Word de cet article, voir Ils disent qu’ils veulent une résolution : livre blanc (Project Server 2010).
Pour plus d’articles, consultez les livres blancs « From the Trenches ».
Ils disent qu’ils souhaitent une résolution
Avec des excuses aux Beatles pour le titre, le sujet d’aujourd’hui est la résolution de votre projet.
De nombreux documents sont disponibles sur la façon d’établir une planification, mais l’une des leçons les plus critiques est terriblement difficile à obtenir : combien de tâches vous devez avoir dans votre planification de projet et combien de temps chaque tâche doit être ?
Régulièrement, je suis confronté à des plannings de projet qui semblent incroyablement complexes ou à des gestionnaires de projet qui semblent impuissants à identifier les problèmes dans leur planning parce que le planning est à un tel niveau de synthèse. J’ai vu un projet qui a été plus d’une centaine d’années (oui, vraiment) qui était parfaitement approprié en longueur et dans lequel il y avait des tâches qui ont duré des décennies. J’ai également vu des planifications de projet qui n’ont duré qu’une heure ou moins qui étaient parfaitement appropriées et dans lesquelles certaines tâches n’ont duré qu’une minute. J’ai vu des projets avec seulement quelques tâches et d’autres avec plus de 100 000 tâches.
Les logiciels que nous utilisons aujourd’hui peuvent gérer des milliers de tâches et un large éventail de durées.
Alors, quelle est la bonne approche ?
Quelle doit être la durée des tâches, et combien devriez-nous avoir pour optimiser notre planification de projet ? Je vais appeler cela la résolution du projet.
Différents traits pour différentes personnes
Étant donné que la configuration requise peut être différente selon les secteurs d’activité, les différents types de projets et les différentes situations, voyons comment déterminer le nombre de tâches à placer dans votre planification et la durée des tâches.
Les différents types de projets appellent naturellement des planifications différentes. Examinons trois exemples différents :
Développement de logiciels. De nombreux projets logiciels ont des caractéristiques communes. Bien que chaque projet logiciel soit unique, il existe généralement une phase de conception, une phase de programmation, une phase d’assurance qualité, une phase de document et une phase de déploiement. Les projets logiciels sont généralement mesurés en semaines ou en mois, et qui se prêtent à des tâches d’une journée à quelques semaines. Ici, l’allocation des ressources est souvent affectée au niveau individuel.
Ceux qui ont adopté le processus Agile pour le développement de logiciels recherchent des « sprints » courts d’une ou deux semaines et, dans ce sprint, mettent des tâches de courte durée, mais la durée globale du projet est toujours mesurée en semaines. Nous parlerons plus en détail du développement Agile un peu plus tard.
EPC - Ingénierie, approvisionnement et construction. Les projets EPC sont les débuts de la méthodologie de planification des chemins critiques. Dans ce genre de projet, quelque chose de très important est en cours de développement. Il pourrait s’agir d’un grand projet de défense comme le projet de missile Polaris qui a donné leur début aux diagrammes PERT, ou il pourrait s’agir d’une plate-forme pétrolière offshore, d’un nouveau navire ou d’une centrale électrique. Dans ce genre de projets, il y a une phase d’ingénierie où le projet fini est conçu. La phase d’ingénierie présente généralement un aspect qui n’a jamais été conçu auparavant. La phase d’approvisionnement porte sur la localisation, la passation de marchés et la gestion de la livraison de fournitures ou de sous-contrats pour des éléments du projet. Dans la phase de construction, le produit final est construit, puis mis en service pour utilisation. Nous pensons généralement à des calendriers de projets EPC en plusieurs mois ou plusieurs années avec des durées d’activité allant de quelques semaines à quelques mois. Il n’est pas du tout inhabituel d’avoir 5 000 à 20 000 tâches sur un tel projet. La planification des ressources ici est presque toujours attribuée au niveau de compétence plutôt qu’à l’individu, et (juste pour ajouter à l’amusement) il peut y avoir de nombreux sous-projets faits dans un programme ou un projet maître pour faciliter la gestion.
Arrêt de l’usine. Lorsque vous planifiez un projet pour l’arrêt et le redressement d’une usine pour la maintenance, vous travaillez dans l’un des environnements de planification les plus difficiles possibles. Un arrêt de l’usine pour faire de la maintenance se présente sous deux types : planifié et d’urgence. Laissez le type d’urgence de côté un instant; c’est un monde en soi. La durée d’un arrêt d’usine planifié dépend fortement du type d’usine. Une unité de centrale nucléaire, par exemple, peut effectuer un arrêt et un redressement « rapide » de la centrale en 12 mois. Une raffinerie de pétrole peut durer 4 à 6 semaines. Mais le type de projet d’usine que je trouve le plus intéressant est une usine de fabrication comme une aciérie, une papeterie, ou quelque chose de similaire. Il y a des milliers ou des dizaines de milliers de plantes de ce type dans le monde, et elles doivent faire l’objet d’un entretien régulier chaque année environ.
Le coût de l’arrêt pour ces situations est généralement mesuré en coût d’opportunité; le coût du produit qui ne sera pas produit pendant que l’usine est inactive et en cours d’entretien. Ce coût est mesuré en heures, et le coût peut atteindre plus de 150 000 $ à 250 000 $ l’heure! Donc la pression est sur minute par minute pour faire le travail. Dans ce genre de situation, l’arrêt dure généralement de 5 à 8 jours et le délai d’une journée est calculé en millions. Si vous n’êtes habitué à des planifications plus longues et plus traditionnelles, vous pensez peut-être qu’en quelques jours, « combien de tâches peut-il y en avoir généralement ? », mais il n’est pas du tout inhabituel qu’un tel arrêt ait 2 000 à 4 000 tâches, chacune d’une durée de 15 minutes à quelques heures. Ici, les affectations de ressources sont effectuées par compétence, mais le nivellement des ressources est rarement effectué sur le personnel. Avec le coût par heure étant si intense, peu importe si vous mettez plus de personnes sur le projet, il suffit de le faire à la hâte. Dans cette situation, le nivellement des ressources est souvent effectué pour les goulots d’étranglement fortement limités. Par exemple, « nous ne pouvons accueillir que deux personnes dans la salle électrique, donc cela doit être géré discrètement ».
Ok, nous avons maintenant trois types d’exemples, et il y en a beaucoup d’autres, mais ces trois-là serviront parfaitement les objectifs de la discussion. Dans le type 1 (Développement logiciel), nous obtenons des tâches qui sont généralement d’une durée d’un jour ou de deux jours à deux semaines. Dans le type 2 (EPC), nous obtenons des tâches d’une durée de semaines ou de mois. Dans le type 3 (arrêt de l’usine), nous obtenons des tâches qui sont mesurées en unités de 6 minutes (1/10e d’heure), 10 minutes, 15 minutes (1/4 d’heure), jusqu’à quelques heures. Il est évident que dans certains cas, les tâches courtes ont un sens et, dans d’autres, les tâches longues sont plus appropriées. Selon la même logique, il est parfois judicieux d’avoir un grand nombre de tâches et parfois ce n’est pas le cas.
Facteurs dans le choix de la résolution de votre projet
Avec ces trois distinctions, il est facile de voir que la tâche de projet EPC de deux mois semble ridicule dans un calendrier d’arrêt de six jours et qu’une tâche de 15 minutes serait hors de place dans le projet EPC ou Software. Mais en plus de se référer à cet article et de dire, « Vandersluis dit qu’il s’agit d’un projet logiciel afin que les tâches ne peuvent être longues que 1 à 10 jours », (et s’il vous plaît, ne faites pas cela) quelles caractéristiques du projet nous indiquent quel niveau de résolution choisir ? Examinons quelques-uns des éléments évidents :
Combien de temps dure le projet ?
Commençons par le plus évident. Si votre projet devrait prendre quelques jours, comme dans notre exemple d’arrêt, avoir des tâches de plusieurs jours n’a aucun sens. Commencer par une approche descendante est souvent productif lorsque nous pensons à la sous-division de l’étendue. Utilisez la pensée de structure de répartition du travail. Commencez par les principaux composants. Pensez à avoir pas moins de 4 et pas plus de 20 articles.
C’est une règle ? Non, bien sûr que non.
C’est du bon sens. Moins de 4 vous fait vous demander pourquoi vous avez divisé le travail du tout et plus de 20 est trop difficile à tenir dans l’esprit à la fois. Personnellement, je vais avec pas plus de 8 éléments par élément WBS et c’est à cause d’un article que j’ai lu il ya des années qui a suggéré qu’un octogone était la forme simple la plus complexe que l’esprit puisse reconnaître immédiatement.
Pensez-y un instant. Vous pouvez identifier un cercle, un triangle, un carré, un pentagone, un hexagone qui a 6 côtés, un heptagon qui a 7 côtés (ok, celui-là est difficile à visualiser) et un octogone.
Pouvez-vous identifier une forme à 9 côtés sans compter ? Je ne peux pas. C’est ce que l’on appelle un « nonagon » pour vous les mordants de trivia.
Donc, personnellement, je m’efforce de la limite de 8 éléments, mais ma règle de base est 4-20.
Pour chaque élément que vous avez examiné, réfléchissez à la façon dont vous devez diviser le travail. Encore une fois, pensez à la règle des 4-20. Mais savoir quand arrêter est le secret. Les nouveaux gestionnaires de projets subdiviseront, subdiviseront et subdiviront jusqu’à ce que chaque étape dans le couloir soit une tâche gérée. Voici quelques questions intéressantes que vous pouvez vous poser sur la durée d’une tâche :
Quelle action dois-je entreprendre si cette tâche était en retard ? Si la réponse est « rien », c’est une bonne indication que la tâche que vous envisagez est trop petite pour être utile à gérer. Si c’est le cas, vous regardez trop en détail. Remontez un niveau, faites un pas en arrière et voyez si vous avez terminé.
La collecte des données sur la mise à jour de cette tâche prendra-t-elle plus de temps que la tâche elle-même ? Nous ne pensons pas toujours au type d’effort qu’il faudra pour gérer une tâche planifiée, mais il est utile de réfléchir à ce même si pour un moment. Si la gestion de la tâche nécessite plus d’efforts que d’exécution, cela indique que la tâche est définie à un niveau de détail trop précis.
Quelle est la durée de cette tâche ? Lorsque nous subdivisant le travail, nous perdons parfois de vue à quel point une tâche devient minuscule. Les grandes phases au niveau supérieur durent peut-être des semaines, mais à mesure que nous descendons de quelques niveaux de granularité, nous pouvons facilement tomber dans le piège de la définition d’une tâche à gérer qui ne dure que quelques minutes. Lorsque nous obtenons des tâches minuscules, nous devons nous demander quel serait l’avantage de les gérer.
Appliquons une vérification de la réalité à ce dont je viens de parler. Dans un projet EPC de deux ans, si une tâche d’une semaine est un jour en retard, il n’est presque certainement pas utile de prendre des mesures. Dans un projet logiciel de six mois, une tâche d’une semaine qui est un jour en retard ne vaut probablement pas la peine de prendre des mesures. Dans un projet d’arrêt de six jours, une tâche d’une semaine qui est un jour en retard est une urgence massive. En d’autres termes, une tâche d’une semaine dans le projet EPC peut être un niveau de détail trop élevé; dans le projet de logiciel, c’est probablement à peu près correct; et dans le projet Shutdown, il est presque certainement nécessaire de le décomposer plus en détail.
Combien de ressources sont impliquées ?
Je sais que nous travaillons seulement sur la portée, mais quand nous examinons le type de résolution dont nous avons besoin, il est utile de réfléchir au nombre de personnes qui travailleront sur une tâche. Dans un grand projet EPC, par exemple, nous pouvons avoir des dizaines de travailleurs d’une compétence impliquée dans une phase de travail. Mais quand nous nous trouvons avec de nombreuses compétences différentes dans la même tâche, la gestion de cette tâche devient très difficile, voire impossible. Donc, dans cette situation, les tâches qui nécessitent de nombreuses compétences différentes doivent probablement être réparties.
Dans un projet logiciel, nous avons tendance à considérer presque chaque individu comme une ressource hautement technique avec des capacités uniques. De plus, dans les projets logiciels, il est courant d’avoir de nombreuses tâches qui peuvent être réaffectées au sein d’un service, mais une seule tâche affectée à une seule personne. Par conséquent, lorsque nous avons des tâches qui sont allouées à un niveau d’une personne d’un groupe de ressources ou d’un service particulier (par exemple la programmation d’interface), nous sommes assez proches pour dire que nous n’avons pas besoin de plus de détails.
Comment les ressources sont-elles gérées ou subdivisée ?
La façon dont les ressources sont gérées est un facteur déterminant dans la façon de subdiviser vos tâches. Dans les grands projets EPC, par exemple, les projets sont souvent divisés en sous-projets qui sont regroupés à d’énormes sous-traitants. Dans cette situation, nous devons faire deux choses :
Définissez le travail d’une manière qui permet à un chef de projet de superviser le sous-traitant avec l’assurance que les progrès réalisés sont un facteur important.
Définissez les tâches de manière à ce que le personnel de gestion de projet et d’ingénierie du sous-traitant comprenne ce qu’ils signifient sans ambiguïté.
Assurez-vous que le niveau de résolution que vous avez adopté comme norme est compris et accepté par le sous-traitant.
Lorsque nous examinons des projets en col blanc tels que les logiciels, la recherche biologique ou l’ingénierie, nous sommes plus susceptibles de rencontrer une structure de gestion matricielle où les gestionnaires de projet ne possèdent aucune des ressources et nous devons travailler entre les gestionnaires de service qui allouent ces ressources dans de nombreux projets différents. Dans ce cas, les questions clés sont les suivantes :
Combien de projets une ressource est-elle susceptible de fonctionner sur une seule journée ?
Combien de temps faut-il à un employé pour passer d’un projet à un autre ?
Le travail est-il défini de telle sorte que les employés et les responsables du service des ressources comprennent comment y affecter les compétences appropriées ?
Lorsque nous examinons un projet d’arrêt ou de construction, nous avons tendance à travailler entre des équipes spécialement conçues. Dans ces situations, un responsable d’équipe de ressources peut gérer l’équipe électrique (même si cette équipe comprend des menuisiers et des monteurs de tuyaux), une équipe de plomberie ou une équipe de rénovation d’unité de chaudière. Le travail doit être organisé de telle sorte que l’équipage puisse être occupé tout au long de l’équipe et qu’il n’arrive pas sur une autre équipe qui travaille déjà dans quelque chose dans cette région. Étant donné l’intense pression liée à l’exécution d’un projet d’arrêt, le travail est souvent organisé par travail d’abord, planifié, puis regroupé et subdivisée par un responsable d’équipe de ressources afin que chaque responsable d’équipe puisse se déplacer avec ses tâches uniquement dans un document et avec l’ensemble du projet dans un autre contexte. Les tâches doivent donc être définies d’une manière compréhensible par l’employé et par le responsable de l’équipe de ressources. Les tâches ici sont probablement définies jusqu’à l’heure ou avec encore plus de granularité jusqu’au dixième ou quart d’heure.
À quelle vitesse pouvez-vous collecter des données et combien d’efforts cela nécessite-t-il ?
Cela semble être une question idiote lorsque vous êtes habitué à voir les données de votre projet bien alignées à la fin de la semaine pour être examinées, mais lorsque vous essayez de déterminer le niveau de résolution de votre projet, cette question peut être essentielle. Par exemple, lorsque vous travaillez avec de nombreux sous-traitants, il est probable que vous receviez une mise à jour hebdomadaire ou mensuelle. En fait, il est essentiel d’intégrer 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 sociétés dans vos propres données, vérifier que les données de progression sont pertinentes, puis effectuer vos propres analyses et rapports. Dans un mode EPC, il s’agit probablement d’une occurrence mensuelle.
Dans un projet d’arrêt, vous devez mettre à jour votre projet à chaque équipe, le mettre à jour rapidement et obtenir les mises à jour des responsables de l’équipe de ressources au milieu de la prochaine équipe. Dans cette situation, le personnel du projet se déploie partout dans l’usine tout au long du quart de travail, en recueillant des données aussi près que possible en temps réel et en faisant en sorte que les chefs d’équipe de ressources et les contremen utilisent des feuilles « take-down » pour « réduire » la progression de leurs affectations. Dans le cadre d’un logiciel ou d’un projet de recherche, vous travaillez probablement sur un calendrier hebdomadaire ou quelque chose comme celui-ci avec des personnes qui signalent leurs propres progrès et passent par des approbations sur une ou deux journées.
Il s’agit d’un point important à prendre en compte lorsque vous examinez le nombre de tâches à effectuer dans votre projet, car la collecte des données est coûteuse.
Il est donc essentiel de réfléchir à la rapidité avec laquelle vous pouvez collecter, approuver, intégrer, analyser et rapporter les données sur une base cyclique régulière, tout comme la prise en compte du coût de la collecte des données et du retour sur investissement de ces données collectées.
À quelle fréquence procéderons-nous à la 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 allez collecter vos données.
Réfléchissez à la fréquence à laquelle vous pouvez mettre à jour raisonnablement votre projet et fournir à la direction les outils décisionnels nécessaires pour guider le projet et les ressources dans la bonne direction.
J’ai vu certains chefs de projet insister sur le fait qu’ils veulent passer à la gestion de projet en temps réel et la collection de projets et bien que cela puisse être possible en théorie, il est terriblement difficile à réaliser dans la pratique.
Lorsque nous examinons les données de gestion de projet, nous faisons quelques hypothèses. Nous partons du principe que :
Les données sont toutes là. Nous ne nous attendons pas à examiner certaines tâches qui sont mises à jour et d’autres qui ne le sont pas.
Les données ont toutes été mises à jour à un moment similaire. Nous ne pensons pas que la moitié des tâches ont été mises à jour il y a quelques minutes, mais l’autre moitié n’a pas été mise à jour depuis deux semaines.
Toutes les données ont reçu un certain niveau d’approbation. Nous nous attendons à ce que le chef de projet se défende des données présentées et qu’il soit en mesure de dire « Il s’agit d’une représentation juste et précise du projet ».
Les données appartiennent ensemble. Nous ne nous attendons pas à ce que les risques soient brouillés avec les coûts et les ressources, sauf si nous avons conçu spécifiquement nos rapports et notre analyse de cette façon.
Je demande souvent aux cadres qui sont enthousiasmés par le concept de gestion de projet en temps réel ce qu’ils feront si nous pouvions surmonter les points que je viens de soulever plus haut. « Êtes-vous prêt à prendre des décisions de gestion tout au long de la semaine ? » Je vais demander. La réponse doit dépendre du niveau de résolution. Dans un projet d’arrêt, il vaut mieux répondre « Oui ». Dans un projet de logiciel, la réponse est probablement « Non, nous allons le faire toutes les semaines ». Et dans un projet EPC, la réponse serait « Monthly ».
À un moment donné, la loi sur la diminution des rendements s’insinue pour dire : « La remise de rapports de projet plus rapidement ne nous permettra pas d’accroître l’efficacité. »
Examen de votre travail
Vous avez maintenant quelques idées à faire, vous avez utilisé la méthode de répartition du travail pour subdiviser vos données et vous avez observé certains des signes d’avertissement que les données sont définies trop finement. Maintenant, il est temps de pencher le calendrier contre le mur, de revenir en arrière et d’examiner le projet avec une certaine perspective. Étonnamment, beaucoup de chefs de projet ne le font jamais. Ils sont tellement pris dans l’obtention des derniers détails définis et sont tellement occupés à subdivisant les tâches encore et encore qu’ils se poussent jusqu’à l’échéance de mise en production et ne cherchent jamais à voir si ce qu’ils ont fait sera un cauchemar à gérer.
Dans certains cas, les cadres sont sûrs de toutes ces formations mba que « plus de détails est mieux » et ils poussent pour ces tâches de 5 minutes ou 15 minutes sur des projets d’une durée de six mois.
Il est toujours plus facile de modifier le projet avant de démarrer qu’à tout moment plus tard. Par conséquent, le temps de génération dans votre activité de création de planification vous permet de retravailler la planification si nécessaire.
C’est trop ?
Parfois, les responsables de projet examinent l’étendue de ce qu’ils ont créé et se rendent compte qu’ils sont à un niveau de détail trop précis. Si c’est le cas, le correctif est évident. C’est peut-être beaucoup de travail, mais vous vous remercierez plus tard pour simplifier le planning en passant à un niveau supérieur.
Parfois, l’image n’est pas si facile. Dans certains cas, ce n’est qu’une fois l’ensemble de la planification assemblé que le responsable de projet peut voir à quel point il est complexe. Les projets complexes sont, par nature, plus risqués, et le risque dans l’économie d’aujourd’hui est un facteur de sélection clé pour les projets. Voici quelques questions qui méritent d’être prises en compte avant le démarrage d’un projet aussi complexe :
Pouvons-nous le faire par morceaux ? Certains projets à risque peuvent être divisés en portions plus petites et, à mesure qu’ils sont plus petits, leur risque diminue. Toutefois, si vous utilisez cette stratégie, chaque projet discret doit avoir sa propre valeur lorsqu’il est terminé.
Faut-il repenser l’étendue ? Parfois, les actions les plus simples sont de revenir aux concepteurs de l’œuvre en premier lieu, d’expliquer la complexité qui semble apparente dans le calendrier et de voir si le travail peut être repris. Cela conduit souvent à une réflexion innovante qui n’aurait jamais eu une chance de se produire.
Faut-il le faire ?
Certains projets n’ont jamais été conçus pour être, et le temps le moins cher pour les annuler est la veille de leur début. Si le risque du projet n’est que maintenant évident, mieux vaut le réaliser maintenant que plus tard. Lorsque vous inscrivez les résultats de l’exécution de votre planification dans le processus de gestion de portefeuille de projets (PPM), vous pouvez constater que le risque du projet plus complexe a le score de travail beaucoup plus mauvais dans une échelle de retour sur investissement.
Un peu agile... non, un projet Agile
J’ai promis de dire quelques choses sur la gestion de projet Agile et si vous êtes un fan d’Agile et que vous avez lu jusqu’ici, j’apprécie votre patience. La gestion de projets logiciels par le biais de la méthode Agile est une sorte de philosophie, mais c’est une philosophie de plus en plus populaire avec ceux qui ont été brûlés sur des projets de développement logiciel massifs qui ont échoué.
Dans un monde de développement de logiciels Agile, nous essayons de décomposer notre projet en « sprints » d’une à trois semaines et l’objectif de chaque mini-projet est de se retrouver avec du code utilisable. Dans ce cas, nous travaillons avec des contraintes assez connues afin que notre niveau de résolution soit à peu près choisi pour nous.
Nous avons une fenêtre d’une à trois semaines, les ressources sont disponibles et nous allons affecter du travail à chaque ressource. Le nombre de tâches possibles que nous pouvons définir dans cette structure est limité et cela permet de conserver un niveau de résolution approprié. Oui, vous pouvez avoir des problèmes dans Agile en définissant des tâches beaucoup trop courtes. « Définir le champ1 : 10 minutes, Définir le champ2 : 10 minutes, Définir le champ3 : 10 minutes », etc. mais c’est beaucoup moins courant.
Agile a été conçu pour un environnement de développement d’entreprise dans lequel nous créons des logiciels pour une utilisation interne, et son utilisation est souvent étendue au développement de logiciels commerciaux. (Nous utilisons la méthode ici chez HMS pour notre propre développement de TimeControl.) La méthode Agile aboutit à un service de développement plus maniable et agile, mais elle ne sera pas applicable à tous les secteurs ou même à tous les éditeurs de logiciels. Si vous effectuez la gestion de projet dans un environnement logiciel, ma recommandation est de lire sur Agile, d’en apprendre, puis d’adopter les éléments (tous, certains ou aucun) qui vous rendront le plus efficace.
Conclusion
Comme pour la plupart des aspects de la gestion de projet, il n’y a pas de réponse fixe aux questions qui semblent à première vue si évidentes. Le nombre de tâches que vous avez dans votre projet et la durée de chacune de ces tâches est quelque chose que vous devez rechercher vous-même pour décider ... mais décider que vous devez.
Le choix du niveau de résolution de votre projet est une responsabilité de gestion de projet qui peut être un facteur clé de réussite dans la gestion du calendrier du projet.
À 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).