Ils disent qu’ils souhaitent une résolution

Cet article fait partie de notre collection « From the Premier pays ». Il décrit certains défis courants que vous pouvez être confrontés 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 qui doivent être nécessaires pour optimiser une planification de projet. Il explique comment différents secteurs nécessitent généralement différents types de planifications (par exemple, le développement de logiciels, EPM (ingénierie, approvisionnement et construction) et l’arrêt des installations. Il traite également de plusieurs facteurs dans le choix de la résolution de projet (par exemple, la longueur du projet, les ressources impliquées, la gestion ou la division des ressources, la vitesse et l’effort requis pour la collecte des données et la planification des mises à jour des données).

Pour télécharger la version Word de cet article, voir They say they want a resolution: white paper (Project Server 2010).

Pour plus d’articles, consultez les livres blancs « À partir des sables».

Ils disent qu’ils souhaitent une résolution

Avec des titres à la place, le sujet du jour est la résolution de votre projet.

De nombreux documents sont disponibles sur la façon d’effectuer une planification, mais l’une des leçons les plus importantes est difficile à tirer : le nombre de tâches que vous devez avoir dans votre planification de projet et la durée de chaque tâche ?

Régulièrement, je suis confronté à des planifications de projet qui semblent assez complexes ou à des responsables de projets qui semblent difficilement à identifier les problèmes dans leur planification, car la planification se trouve à un tel niveau récapitulatif. J’ai vu un projet de plus de cent ans (oui, en fait) qui était parfaitement approprié en longueur et dans lequel certaines tâches avaient des dizaines d’années. J’ai également vu des planifications de projet qui n’ont duré qu’une heure ou moins et 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.

Le logiciel que nous utilisons aujourd’hui peut gérer des milliers de tâches et un large éventail de durées.

Quelle est la bonne approche ?

Quelle doit être la durée des tâches et combien devons-nous avoir pour optimiser notre planification de projet ? Je l’appelle la résolution du projet.

Différents traits pour les différentes personnes

Étant donné que les conditions requises peuvent être différentes pour différents secteurs d’activité, différents types de projets et différentes situations, voyons comment déterminer le nombre de tâches à placer dans votre planification et la durée des tâches.

Différents types de projets appellent naturellement différents types de planifications. Examinons trois exemples différents :

  1. 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 se prêtent aux tâches d’une journée à deux semaines. L’allocation de ressources ici est souvent affectée au niveau individuel.

    Les personnes qui ont adopté le processus Agile pour développer des logiciels s’approchent de « sprints » courts d’une ou deux semaines et au sein de ce sprint ont placé des tâches de courte durée, mais la durée globale du projet est toujours mesurée en semaines. Nous en parlerons plus tard sur le développement Agile.

    Affichage Diagramme de Gantt des sprints Agile.

  2. EPC - Ingénierie, approvisionnement et construction. Les projets EPC sont l’endroit où la méthodologie de planification des chemins critiques a commencé. Dans ce type de projet, quelque chose de très important est développé. Il peut s’agit d’un projet de défense de grande envergure, tel que le projet Dussier qui a donné son départ à des diagrammes PERT, ou d’une plate-forme aérienne, d’un nouveau bâtiment ou d’une centrale électrique. Dans ces types de projets, il existe une phase d’ingénierie dans laquelle le projet terminé est lancé. La phase d’ingénierie a généralement certains aspects qui n’ont jamais été conçus auparavant. La phase d’approvisionnement examine la localisation, le contrat et la gestion de la livraison de fournitures ou de sous-contrats pour les éléments du projet. Dans la phase de construction, le produit final est construit, puis commandé pour utilisation. Nous pensons généralement à des planifications de projet EPC sur plusieurs mois ou plusieurs années avec des durées d’activité de quelques semaines à deux mois. Il n’est pas rare d’avoir entre 5 000 et 20 000 tâches sur un tel projet. La planification des ressources ici est presque toujours affectée au niveau de compétence plutôt qu’à l’individu, et (juste pour vous faire plaisir), de nombreux sous-projets peuvent être effectués dans un programme ou un projet maître pour faciliter la gestion.

    Affichage diagramme de Gantt de plusieurs projets et sous-projets.

  3. Arrêt de l’usine. Lorsque vous faites une planification de projet pour l’arrêt d’une usine et un délai pour la maintenance, vous travaillez dans l’un des environnements de planification les plus complexes possibles. Un arrêt d’usine pour la maintenance est de deux points : planifié et d’urgence. Laissez le type d’urgence de côté pendant un moment . il s’agit d’un monde en lui-même. La durée d’un arrêt planifié de la production dépend fortement du type d’usine. Une unité de production d’alimentation électrique, par exemple, peut faire un arrêt de production « rapide » et un traitement rapide dans 12 mois. Une affinement par affinement peut durer de 4 à 6 semaines. Mais le type de planification de projet de construction que je trouve le plus intéressant est une fabrication telle qu’un papier en acier, un papier ou quelque chose de similaire. Il existe des milliers ou des dizaines de milliers de ce genre dans le monde entier, et ils doivent faire l’objet d’une maintenance régulière chaque année environ.

    Le coût de l’arrêt pour ces situations est généralement mesuré en coût d’opportunité ; coût du produit qui ne sera pas produit pendant que l’usine est inactive et en cours de maintenance; Ce coût est mesuré en heures, et le coût peut être plus élevé de 150 000 à 250 000 $ de l’heure ! Ainsi, la pression est de minute en minute pour que le travail soit terminé. Dans ce type de situation, l’arrêt dure généralement 5 à 8 jours et le délai d’une journée unique est calculé en millions. Si vous n’êtes habitué qu’à des planifications plus longues et plus traditionnelles, vous pouvez penser que, dans quelques jours, « combien de tâches y a-t-il en général ? » mais il n’est pas rare qu’un tel arrêt compte entre 2 000 et 4 000 tâches, chacune d’une durée de 15 minutes à deux heures. Les affectations de ressources ici sont réalisées par compétences, mais l’levelage des ressources est rarement effectué sur le personnel. Le coût par heure étant si intense, peu importe que vous insériez plus de personnes sur le projet, il vous suffit de le faire en un rien de temps. Dans ce cas, l’a leveling des ressources est souvent effectué pour les goulots d’étranglement hautement limités. Par exemple, « nous ne pouvons intégrer que deux personnes dans la salle électrique, donc cela doit être géré discrètement ».

    Affichage diagramme de Gantt des tâches séquentielles.

Ok, nous avons maintenant trois types d’exemples, et il y en a beaucoup d’autres, mais ces trois exemples serviront très bien la discussion. Dans le type un (développement logiciel), nous recevons des tâches qui sont généralement d’un jour ou deux jours à deux semaines. Dans le type 2 (EPC), nous recevons les tâches qui sont des semaines ou des mois. Dans le type 3 (arrêt de l’usine), les tâches sont mesurées en unités de 6 minutes (1/10e d’heure), 10 minutes, 15 minutes (1/4 de l’heure), jusqu’à quelques heures. Il est évident que dans certains cas, les tâches courtes sont pertinentes et, dans d’autres, les tâches longues sont plus appropriées. En suivant la même logique, il est parfois logique d’avoir un nombre considérable de tâches et parfois non.

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 semblerait compliquée dans un calendrier d’arrêt de six jours et qu’une tâche de 15 minutes serait hors place dans le projet EPC ou logiciel. Mais en plus de revenir à cet article et de dire : « Vandersluis dit qu’il s’agit d’un projet logiciel pour que les tâches ne soient que de 1 à 10 jours » (et ne faites pas cela), quelles caractéristiques du projet nous indiquent le niveau de résolution à choisir ? Examinons quelques exemples évidents :

Quelle est la durée du projet ?

Commençons par le plus évident. Si votre projet doit prendre quelques jours, comme dans notre exemple d’arrêt, le fait d’avoir des tâches de plusieurs jours n’a aucun sens. Commencer avec une approche de haut en bas est souvent productif lorsque nous voulons sous-diviser l’étendue. Utilisez la réflexion sur la structure de la répartition du travail. Commencez par les principaux composants. Pensez à n’avoir pas moins de 4 éléments et pas plus de 20 éléments.

S’agit-il d’une règle ? Non, bien sûr que non.

C’est logique. Moins de 4 vous fait vous demander pourquoi vous avez divisé le travail et plus de 20 est trop difficile à retenir en même temps. Personnellement, je n’ai pas plus de 8 éléments par élément WBS et c’est en raison d’un article lu il y a des années qui suggérait qu’un octogone était la forme simple la plus complexe que l’esprit pourrait immédiatement reconnaître.

Réfléchissez un instant à ce sujet. Vous pouvez identifier un cercle, un triangle, un carré, un square, un hexagone de 6 côtés, un heptagon de 7 côtés (ok, celui-ci est difficile à visualiser) et un octogone.

Pouvez-vous identifier une forme à 9 côtés sans compter ? Je ne peux pas. C’est ce qu’on appelle un « non-gon » pour vos trivias.

Par conséquent, personnellement, je m’efforce d’atteindre la limite de 8 éléments, mais ma règle générale est de 4 à 20.

Pour chaque élément que vous avez examiné, réfléchissez à la façon dont vous devez diviser le travail. Là encore, pensez à la règle 4-20. Mais le secret consiste à savoir quand s’arrêter. Les responsables de projets plus nouveaux sous-divisent et sous-divisent et sous-divisent jusqu’à ce que chaque étape vers le bas soit une tâche gérée. Voici quelques bonnes questions que vous pouvez vous poser sur la longueur d’une tâche :

  • Quelle action dois-je prendre si cette tâche était en retard ? Si la réponse est « nothing » (rien), cela indique que la tâche que vous pensez est trop petite pour être utile à gérer. Si c’est le cas, vous recherchez trop de détails. Back up a level, take a step back, and see if you are done.

  • 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 programmée, mais il est intéressant de réfléchir même si un instant. S’il faut plus d’efforts pour gérer la tâche qu’il ne le fera, cela indique que la tâche est définie à un niveau de détail trop précis.

  • Combien de temps s’agit-il de cette tâche ? Lorsque nous sous-divions le travail, nous perdons parfois de vue la minuscule d’une tâche. Les grandes phases au niveau supérieur étaient peut-être des semaines, mais à mesure que nous descendons de quelques niveaux de granularité, nous pouvons facilement nous trouver dans l’trap of defining a task to be managed that is only a few minutes long. Lorsque nous en arriveons à de petites tâches, nous devons nous demander quel serait l’avantage de les gérer.

Nous allons appliquer une vérification de réalité à ce dont je vient 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 pas utile de prendre des mesures. Dans un projet logiciel de six mois, une tâche d’une semaine avec un jour de retard ne vaut probablement pas la peine d’être prise en compte. Dans un projet d’arrêt de six jours, une tâche d’une semaine avec un jour de retard est une urgence importante. En d’autres termes, une tâche d’une semaine dans le projet EPC peut être trop fine pour un niveau de détail ; dans le projet logiciel, c’est probablement à peu près la bonne chose à faire ; et dans le projet d’arrêt, il doit certainement être décomposé en détails.

Combien de ressources sont impliquées ?

Je sais que nous travaillons simplement sur l’étendue, mais lorsque nous examinerons le type de résolution dont nous avons besoin, il est intéressant de réfléchir au nombre de personnes qui travailleront sur une tâche. Dans un projet EPC de grande envergure, par exemple, nous pouvons avoir des dizaines de travailleurs d’une compétence impliquées dans une phase de travail. Toutefois, lorsque nous nous retrouveons 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. Ainsi, dans ce cas, les tâches qui nécessitent de nombreuses compétences différentes doivent probablement être divisées.

Dans un projet logiciel, nous avons tendance à penser à presque tous les individus comme une ressource hautement technique avec des fonctionnalités uniques. En outre, dans les projets logiciels, il est courant d’avoir de nombreuses tâches qui sont ré assignables au sein d’un service, mais une seule tâche affectée à une seule personne. Ainsi, lorsque nous avons des tâches qui sont allouées à un niveau d’une seule personne d’un groupe de ressources ou d’un service particulier (par exemple, la programmation d’interface), nous sommes suffisamment proches pour dire que nous n’avons pas besoin de plus de détails.

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

La façon dont les ressources sont gérées est un facteur déterminant dans la sous-division de vos tâches. Dans les projets EPC de grande taille, par exemple, les projets sont souvent coupés en sous-projets qui sont transformés en sous-traitants importants. Dans ce cas, nous devons faire deux choses :

  • Définissez le travail d’une manière qui permet à un responsable de projet de surveiller le sous-rapport avec la certitude que l’avancement en cours est 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-logiciel comprenne ce qu’elles signifient sans ambiguïté.

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

Lorsque nous regardons des projets blancs tels que des logiciels, des études fondamentales ou des ingénieries, nous sommes plus susceptibles de rencontrer une structure de gestion de matrice dans laquelle les responsables de projets ne possèdent aucune ressource et nous devons travailler entre les responsables de service qui allouent ces ressources à de nombreux projets différents. Dans ce cas, les questions clés sont les suivantes :

  • Combien de projets est une ressource susceptible de fonctionner sur une journée unique ?

  • Combien de temps faut-il à un employé pour passer d’un projet à un autre ?

  • Le travail est-il défini de telle manière que les employés et les responsables du service des ressources comprennent comment leur attribuer les compétences qui leur sont les mieux allouées ?

Lorsque nous regardons un projet d’arrêt ou de construction, nous avons tendance à travailler sur des membres d’équipe conçus à cet effet. Dans ces situations, un responsable de l’équipe de ressources peut gérer l’équipe électrique (même si cette équipe inclut des menuisiers et des personnes à charge de canal), une équipe de raccordage ou une équipe de restauration de l’unité de production. Le travail doit être organisé de telle sorte que l’équipe puisse rester occupée tout au long du travail d’équipe et qu’il n’arrive pas au-dessus d’un autre membre d’équipe travaillant déjà dans cette zone. Étant donné la forte pression sur la réalisation d’un projet d’arrêt, le travail est souvent organisé par travail d’abord, planifié, puis regroupé et subdivisé par un responsable d’équipe de ressources afin que chaque responsable d’équipe puisse se déplacer avec uniquement ses tâches dans un document et avec l’ensemble du projet en contexte dans un autre. 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é au dixième ou au trimestre de l’heure.

À quelle vitesse pouvez-vous collecter des données et combien d’efforts cela prend-il ?

Cela semble être une question débile lorsque vous êtes habitué à voir vos données de projet 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, il peut s’agit d’une question clé. Par exemple, lorsque vous travaillez avec de nombreux sous-traitants, il est probable que vous receviez une mise à jour hebdomadaire ou mensuelle. En fait, la création de la clause de mise à jour de gestion de projet dans votre contrat est essentielle. Dans ce cas, vous devez intégrer les données de ces différentes sociétés dans les vôtres, vérifier que les données de progression sont logiques, puis faire vos propres analyses et rapports. En 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 des ressources au milieu du prochain travail d’équipe. Dans ce cas, le personnel du projet se déplace sur toute la centrale pendant le travail d’équipe, en recueillant les données aussi près que possible en temps réel et en ayant des responsables d’équipe de ressources et des foremen qui utilisent des feuilles « take-down » pour « prendre en compte » la progression de leurs affectations. Dans un projet de logiciel ou de recherche, vous travaillez probablement sur une planification hebdomadaire ou quelque chose comme celui-ci avec des individus signalant leur propre progression et en passant par des approbations sur un jour ou deux.

Il s’agit d’un point important à prendre en considération 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é de collecte, d’approbation, d’intégration, d’analyse et de rapport des données régulièrement cycliques, tout comme la prise en compte du coût de collecte des données et du retour sur investissement de ces données collectées.

À quelle fréquence allons-nous mettre à 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 à utiliser pour mettre à jour raisonnablement votre projet et fournir à la gestion les outils de prise de décision nécessaires pour guider le projet et les ressources dans la bonne direction.

J’ai vu certains responsables de projet dire qu’ils souhaitent passer à la gestion de projet et à la collection de projets « en temps réel » et que cela peut être possible en théorie, il est difficile à réaliser dans la pratique.

Lorsque nous regardons les données de gestion de projet, nous faisons certaines hypothèses. Nous partons du principe que :

  • Les données sont toutes là. Nous ne nous attendons pas à voir 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 prévoyons pas que la moitié des tâches ont été mises à jour il y a quelques minutes, mais que l’autre moitié n’a pas été mise à jour pendant deux semaines.

  • Les données ont toutes un certain niveau d’approbation. Nous attendons du responsable de projet qu’il se tienne derrière les 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 flous avec les coûts et les ressources, sauf si nous avons spécifiquement conçu nos rapports et analyses de cette façon.

Je demande souvent aux cadres qui sont ravis du concept de gestion de projet en temps réel ce qu’ils feront si nous pouvions contourner les points que je vient de poser ci-dessus. « Êtes-vous prêt à prendre des décisions de gestion tout au long de la semaine ? » Je vous le demande. La réponse doit dépendre du niveau de résolution. Dans un projet d’arrêt, il est préférable que la réponse soit « Oui ». Dans un projet logiciel, la réponse est probablement « Non, nous allons le faire toutes les semaines ». Et dans un projet EPC, la réponse serait « Mensuelle ».

À un moment donné, la loi de diminution des retours démarre pour dire : « La livraison de rapports de projet plus rapidement ne nous permettra pas d’accroître l’efficacité. »

Examen de votre travail

Vous avez maintenant eu de l’aide à la réflexion, vous avez utilisé la méthode Work Breakdown pour sous-diviser vos données et vous avez vu certains des signes d’avertissement signalant que les données sont trop finement définies. Il est maintenant temps d’adosser la planification au mur, de revenir en arrière et d’examiner le projet avec une certaine perspective. Il est surprenant que de nombreux responsables de projets ne le font jamais. Ils sont si occupés à obtenir les derniers détails définis et sont si occupés à sous-divisant les tâches encore et encore qu’ils se poussent jusqu’à l’échéance de mise en ligne et ne cherchent jamais à savoir si ce qu’ils ont fait sera une tâche facile à gérer.

Dans certains cas, les cadres sont certains de toute cette formation MBA que « plus de détails est préférable » et qu’ils poussent pour ces tâches de 5 ou 15 minutes sur des projets d’une durée de six mois.

Il est toujours plus facile de modifier le projet avant de le commencer qu’à tout moment plus tard. Par donc, créez du temps dans votre activité de création de planification pour retravailler la planification si nécessaire.

Est-ce trop ?

Parfois, les responsables de projet analysent l’étendue de ce qu’ils ont créé et se rendent compte qu’ils sont trop fin à un niveau de détail. Si c’est le cas, le correctif est évident. Cela peut être beaucoup de travail, mais vous vous remerciez par la suite pour simplifier la planification en passant d’un niveau à un autre.

Parfois, l’image n’est pas aussi simple. Dans certains cas, ce n’est qu’une fois la planification entière assemblée que le responsable de projet peut voir à quel point il est complexe. Les projets complexes sont, par nature, plus risqués et les risques dans l’économie d’aujourd’hui sont un facteur de sélection clé pour les projets. Avant le début d’un projet aussi complexe, vous pouvez vous poser les questions suivantes :

  • Pouvons-nous le faire en plusieurs parties ? Certains projets à risque peuvent être décomposés en parties de petite taille et, en tant que projets plus petits, leur risque est faible. Toutefois, si vous utilisez cette stratégie, chaque projet discret doit avoir sa propre valeur lorsqu’il est terminé.

  • Devons-nous reconsidérer l’étendue ? Parfois, les actions les plus simples sont de revenir aux concepteurs du travail en premier lieu, d’expliquer la complexité qui semble apparente dans la planification et de voir si le travail peut être resserré. Cela conduit souvent à une réflexion innovantes qui n’aurait jamais eu l’occasion de se produire.

Devons-nous le faire ?

Certains projets n’ont jamais été destinés à l’être, et le temps le moins coûteux pour les annuler est le jour avant leur démarrage. Si le risque du projet n’apparaît que maintenant, il est préférable de le réaliser maintenant que plus tard. Lorsque vous resserez les conclusions de votre planification dans le processus de gestion de portefeuille (PPM) Project, vous pouvez penser que le risque d’un projet plus complexe présente un score de travail bien pire dans une échelle de retour sur investissement.

Un nimble... non, un projet Agile

J’ai promise de vous dire quelques choses sur la gestion de projet Agile et si vous êtes un fan Agile et que vous avez lu cela jusqu’à présent, je vous remercie de votre patience. La gestion des projets logiciels par le biais de la méthode Agile est une philosophie, mais il s’agit d’une philosophie de plus en plus populaire avec les personnes qui ont été gravées sur des projets de développement logiciels énormes qui ont échoué.

Dans un monde de développement logiciel Agile, nous essayons de décomposer notre projet en « sprints » d’une à trois semaines et l’objectif de chaque mini-projet est de finir par du code utilisable. Dans ce cas, nous travaillons dans le cadre de contraintes relativement connues afin que notre niveau de résolution soit à peu près choisi pour nous.

Nous avons une période 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 fini et cela se prête au maintien d’un niveau de résolution approprié. Oui, vous pouvez avoir des difficultés dans Agile en définissant des tâches beaucoup trop courtes. « Définir champ1 : 10 minutes, Définir champ2 : 10 minutes, Définir 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 sur HMS pour notre propre développement de TimeControl.) La méthode Agile se traduit par un service de développement plus souple et plus souple, mais elle ne s’appliquera pas à tous les secteurs d’activité, ni même à tous les éditeurs de logiciels. Si vous êtes en train d’effectuer la gestion de projet dans un environnement logiciel, il est recommandé de lire Agile, d’en apprendre davantage, puis d’adopter les éléments (tous, certains ou aucun) qui vous seront plus efficaces.

Habillage vers le haut

Comme pour la plupart des aspects de la gestion de projet, il n’existe aucune réponse définie aux questions qui semblent d’abord 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écidez 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 de réussite clé dans la gestion de la planification du projet.

À propos de l’auteur

Chris Vandersluis est le président et le fondateur de Hms, hms Software basé au Canada, un microsoft certified Partner. Il dispose d’un degré d’économie de Mc Galerie University et plus de 30 ans d’expérience dans l’automatisation des systèmes de contrôle de projet. Il est membre de longue date de l’Project Management Institute (PMI) et a contribué à la recherche des chapitres Du groupe d’utilisateurs du Microsoft Project (MPUG) de Contrôle d’ensemble. Les publications pour lesquelles Chris a écrit incluent Classement, Heavy Construction News, Computing Canada magazine et PMI’s PMNetwork, et il est régulièrement habitué à Project Times. Il enseigne la gestion avancée Project à l’Université Mc University et parle souvent dans les fonctions d’association de gestion de projet en Amérique du Nord et dans le monde entier. HMS Software est l’éditeur du système de gestion du temps orienté projet TimeControl et est Microsoft Project solution solution depuis 1995.

Chris Vandersluis peut être contacté par courrier électronique à l’adresse : chris.vandersluis@hms.ca

Si vous souhaitez lire d’autres articles relatifs à EPM par Chris Vandersluis, consultez le site d’aide EPM de HMS ( https://www.epmguidance.com/?page_id=39) .