La fenêtre Organiser permet de gérer des contenus. Elle donne accès à haut niveau aux objets suivants : affichages, rapports, modules, tables, filtres, calendriers, mappages, champs et groupes. L’organisateur propose des actions dans les boutons du centre : copier, annuler, renommer et supprimer. Ces actions agissent sur les objets présentés dans la partie de gauche ou de droite.
Par défaut, la partie de droite présente les objets contenus dans votre projet. La partie de gauche présente les objets présents dans le fichier modèle Global.MPT. Les objets du modèle Global sont produits par Microsoft et sont accessibles à tout moment depuis les menus de Project. À sa première utilisation, l’objet est copié dans le fichier de projet et l’utilisateur peut y modifier les paramètres comme il le souhaite. De cette manière, les objets gardent leur forme originale intacte et les paramètres choisis par les utilisateurs sont préservés dans le fichier du projet.
Il est également possible de modifier les objets du modèle Global. Par exemple, si vous avez créé un calendrier pour votre entreprise et que vous aimeriez l’utiliser dans d’autres projets, vous pourriez l’ajouter au modèle Global. De cette manière, votre calendrier apparaîtra dans le menu de Project et vous pourrez l’utiliser dans tous vos projets.
Pour lancer l’organisateur, vous pouvez passer par plusieurs chemins, mais notamment sous l’onglet Fichier dans la section Information.
Planifier dans un projet c’est ce qui consiste à prioriser et à sélectionner quelles tâches seront effectuées par les ressources pour une période de référence donnée. Il faut distinguer la phase de planification et l’exercice de planification. L’exercice de planifier les tâches s’opère sur l’ensemble de l’exécution d’un projet ou de plusieurs projets. Mais avant de procéder à la planification d’un projet il faut : avoir terminé la création de l’échéancier ; avoir affecté des ressources aux tâches et être prêt à démarrer.
Vous devrez exécuter périodiquement ces trois étapes. Nous verrons plus loin quelles sont les actions à prendre pour chacune de ces étapes. Voyons maintenant à quel moment survient cette période de référence et pourquoi la planification ne porte que sur cette période. Pour nous aider, voici une ébauche du cycle de vie d’une tâche :
Cycle de vie des tâches
Création des tâches dans l’échéancier.
Affectation de ressources aux tâches.
Première planification des premières tâches du projet.
Démarrage de l’exécution du projet.
Mise-à-jour du projet.
La planification des tâches de la période de planification.
Exécution ! Si le projet n’est pas fini : retour à l’étape 5.
Fin du projet.
Au moment où les tâches sont ajoutées à l’échéancier, il n’est pas encore possible de les planifier. Il faudra au moins leur affecter une ressource pour pouvoir déterminer le moment où la ressource sera disponible pour l’exécuter. Une fois l’échéancier et les affectations complétés, il faudra réaliser une première planification. Cette première planification portera seulement sur les premières tâches du projet. Une vue globale de l’ensemble des tâches sera réalisée pour évaluer le volume de travail des ressources pour l’ensemble du projet, mais la planification ne porte que sur le court terme.
Vous pouvez maintenant démarrer votre projet. C’est à ce moment que vous devez débuter la planification périodique des tâches. Cette planification périodique porte sur les tâches de la période de référence ou de planification (les tâches à court terme). À la fin de la période de planification, vous devrez exécuter le cycle à nouveau. Au fil du temps, les tâches lointaines s’approcheront. Un jour, elles arriveront proche de la période de planification et seront évaluées à moyen terme. Elles finiront par arriver dans la période de planification et seront planifiées formellement. On peut dire que les tâches futuristes deviennent de plus en plus réalistes. Elles deviendront réalisables une fois qu’elles seront formellement planifiées. Ce n’est qu’une fois qu’elles seront complétées qu’elles deviendront réelles.
Planification périodique des tâches du projet
Pour simplifier l’explication, utilisons une période d’une semaine.
L’exercice de la planification ne peut être valide que si le projet est à jour et que tout le travail à faire est à une date postérieure à la date du jour. Pour mettre le projet à jour, l’utilisateur doit entrer les valeurs réelles du travail effectué la semaine dernière. Dans certains cas, des feuilles de temps peuvent être utilisées ou, plus simplement, les boutons de pourcentages du menu Tâche. S’il y a lieu, on doit entrer du travail supplémentaire. Ultimement, on informe le logiciel du statut actuel des tâches du projet. Si une tâche a pris du retard, le travail qui n’a pas été terminé tel que prévu doit également être prévu à nouveau la semaine prochaine ou après.
2. La planification.
Une fois que les données réelles concernant la semaine passée sont entrées et que le travail non terminé est prévu à nouveau la semaine prochaine ou après, on dit que le projet est à jour. Vient le temps de planifier. On regarde l’utilisation des ressources pour la semaine prochaine et, pour les ressources trop utilisées, on priorise et repousse les tâches qui ne sont pas exécutables. En d’autres mots, les tâches qui ne sont pas prêtes ou de priorité moindre sont repoussées. On passe également en revue les ressources sous-utilisées pour voir si nous ne pourrions pas les utiliser plus efficacement.
3. L’exécution.
La dernière étape est l’exécution même des tâches. On doit s’assurer que tout se passe bien pour éviter les pertes de temps et afin d’essayer d’anticiper les éléments bloquants. Si une tâche se bloque, on doit tirer d’autres activités pour essayer de recoller les pots cassés.
Pourquoi dois-je planifier ?
En fait, vous planifiez déjà. C’est obligatoire de faire un minimum de planification. Même que souvent les gens le font intuitivement, simplement parce qu’il faut bien voir qui va faire quoi la semaine prochaine. Sinon on va manquer de temps et on va en perdre. On voudra donc faire une planification formelle surtout si le nombre de ressources est grand et/ou si le nombre de tâches et de projets est aussi élevé. Vous éviterez de perdre du temps et pourrez réellement gérer les priorités des tâches en fonction des priorités de l’entreprise.
Le cœur de MS Project repose sur une base de données
Pour bien comprendre le logiciel Project de Microsoft, il faut comprendre qu’il s’apparente à une base de données et non à un tableur. Plusieurs confondent les logiciels de type tableur avec les logiciels de base de données. Il y a certes des similitudes mais il faut tout de même les différencier. Ce qui ressemble le plus entre les deux, c’est certainement la grille principale. Dans le cas de la base de données, cette grille représente des champs et des enregistrements. Dans le cas du tableur, la grille représente des colonnes et des rangées formant des cellules auxquelles on réfère par une adresse. Par exemple, la cellule C4 représente la troisième colonne et la quatrième rangée.
Dans MS Project, les colonnes n’ont pas de références mais plutôt des noms. Ce sont des champs. Un champ prend une valeur pour chaque rangée de la grille, peu importe l’ordre des colonnes. Il est possible que pour certaines rangées, un champ soit laissé vide. Cela dépendra du type de champ. Prenons un exemple : un carnet d’adresses.
Un cas simple de base de données : Publipostage
Dans votre carnet d’adresses, vous choisissez de définir des champs représentant les coordonnées des gens que vous désirez y noter : Nom, Prénom, #Téléphone, adresse de messagerie, no, rue, #app, ville, code postal, pays et plusieurs autres. Pour chaque personne, vous pouvez créer un enregistrement dans la base de données et cet enregistrement sera affiché sur une ligne de la grille. Il est probable qu’un de vos contacts n’ait pas de numéro de fax ou autre. À partir de ce carnet, vous pouvez rechercher, trier et filtrer vos contacts par le champ de votre choix. Vous pouvez également utiliser ce carnet pour envoyer des publipostages à l’aide de Fusion.
Les données dans MS Project
Sous MS Project, le même principe s’applique. On retrouve la table des tâches et la table des ressources. Ces deux tables font partie d’une même base de données enregistrée sous le fichier de projet : Projet1.mpp par exemple. Cette base de données contient bien d’autres tables, mais nous nous en tiendrons ici à ces deux tables et à leurs interrelations. Nous appellerons ces interrelations des « affectations ». Les affectations sont sauvegardées dans une troisième table dans la même base de données. Nous utiliserons donc trois tables : Tâche, Ressource et Affectation.
La table Tâche contient des tâches et les champs de tâches comme la durée, la date de début et plusieurs autres champs de tâches. Il en est de même pour la table Ressource. Cette dernière contient des champs de ressources, tels que le taux horaire, le calendrier de travail et plusieurs autres champs de ressources.
Les affectations dans MS Project
La table des affectations n’est pas directement remplie par l’utilisateur. Elle se remplit lorsque l’utilisateur affecte une ou plusieurs ressources à une ou plusieurs tâches. Chaque affectation unique (une seule combinaison entre une tâche et une ressource est possible) crée un enregistrement dans cette table. La relation entre la table des tâches et la table des ressources est de m à n. Ce qui implique que toutes les ressources peuvent être affectées à toutes les tâches. La figure ci-dessous illustre parfaitement cette réalité.
On peut observer que la ressource 1 « ABC Inc. » est affectée aux tâches 1, 2 et 3, respectivement « Ouvrir », « Percer » et « Visser ». En créant ces affectations, MS Project copie un certain nombre de champs de tâche et de ressource vers les champs de l’affectation. Par exemple, la date de début de l’affectation sera identique à la date de début de la tâche au moment de créer l’affectation, mais pourrait changer par la suite. Les enregistrements d’affectations sont créés à partir du moment où l’on inscrit le nom d’une ressource dans la colonne « Nom de Ressource » de la table des tâches. Il existe d’autres moyens d’affecter une ressource à une tâche, mais le résultat sera plus ou moins le même. À partir du moment où il y a au moins une ressource affectée à une tâche, Project affiche son nom dans le diagramme de Gantt à droite des tâches.
Il est essentiel de comprendre où sont enregistrées les données de votre projet pour être capable de les retrouver et de les interpréter. Par exemple, si vous cherchez un prédécesseur, vous devrez fouiller dans la table des tâches et si vous désirez valider les taux, ce sera dans la table des ressources. Il existe des cas plus difficiles comme la sur-utilisation ou le travail. Cela fera l’objet d’un prochain article.
Nous avons vu dans un article précédent que la criticité des tâches est déterminée par une comparaison entre la marge et un seuil fixé par l’utilisateur. C’est de cette manière que MS Project détermine si une tâche est critique ou non. C’est ainsi que se forme le chemin critique. Nous avions terminé l’article en disant que cette marge était calculée par rapport à la date de fin du projet. Mais qu’arriverait-il si notre projet avait plusieurs dates de fin ? Ou disons plusieurs livrables programmés à des moments différents. Il serait alors faux de calculer la marge des tâches basée sur une seule et même date de fin. Heureusement, avec MS Project il est possible pour l’utilisateur de fixer d’autres dates qui permettront à MS Project de calculer la marge des tâches. On pourra ainsi créer plusieurs chemins critiques dans un projet.
Les chemins non-critiques
Les chemins non-critiques ne sont que des chemins critiques disposant de marge. Sachant cela, il serait judicieux de les appeler « chemin de tâche », qu’ils soient critiques ou non-critiques. Pour créer un chemin de tâche, il faut donner à MS Project une date à laquelle le chemin se terminera. Cette date agira de la même manière que la date de fin du projet au niveau du calcul de la marge des tâches du chemin où elle se trouve. Pour la créer, nous devons attribuer une contrainte de fin à une tâche ou sur un jalon se trouvant sur ce chemin. Dans l’exemple plus bas, nous avons apposé cette contrainte sur un jalon représentant la fin contractuelle d’un livrable de notre projet. Deux types de contraintes peuvent être utilisés à cette fin : « doit finir le » ou « fin au plus tard le ». Cette dernière étant plus souvent utilisée dans la pratique.
Multiples chemins critiques
La structure présentée ci-bas montre une technique permettant de représenter séparément les dates importantes et les activités du projet. La grande majorité des projets ont plus d’un livrable et assez souvent ces livrables ont des dates de livraison différentes. Chaque livrable requiert des activités qui lui sont propres. Il devient nécessaire de calculer la marge de ces tâches en fonction de la date du livrable auquel ces tâches conduisent. Pour chaque contrainte de fin appliquée au jalon du livrable, nous aurons un nouveau chemin de tâche. Étant donné que ces jalons ont un rôle clé dans le projet et comme ils auront un impact très important sur les calculs des dates du projet, une bonne pratique propose de placer ces jalons de livraison dès les premières lignes du projet dans une section bien identifiée à cette fin. La figure ci-bas montre comment il est possible de repérer facilement ces livrables avec leur date de livraison propre.
Les deux réalisations que nous avons (lignes 11 et 16) ont une marge différente et ces marges sont calculées en fonction d’une date de contrainte. Cette contrainte a été apposée au jalon représentant le livrable associé à la réalisation. Ces livrables sont complètement indépendants de la date de fin du projet. La fin de l’aménagement est actuellement prévue pour le 5 décembre et nous savons que nous devons terminer avant le 12 décembre. MS Project calcule donc la marge du livrable de l’aménagement à 5 jours. En même temps, nous prévoyons terminer les travaux TI le 24 novembre et nous avons jusqu’au 5 décembre, ce qui donne 7 jours de marge. Aucune tâche du projet n’est critique et nous avons même quelques jours d’avance.
En utilisant cette technique, vous serez capable de mesurer l’impact de changements sur la marge de votre projet et non simplement de savoir si cela vous met en retard ou non. Ainsi, un problème survenu dans le passé ayant eu un impact majeur sur la marge du projet, mais ne l’ayant pas mis en retard, pourrait être identifié comme la cause première du retard au moment où de petits problèmes retardent officiellement le projet.
Cette technique est d’autant plus intéressante qu’elle produit un tableau de bord des retards et avances anticipés en temps réel dans un projet, livrable par livrable. Sachez qu’il reste possible de se comparer avec le planning de référence, mais il arrive parfois que cette comparaison devienne de plus en plus difficile à faire au fur et à mesure que le projet change. Sachant que la date de livraison est quant à elle contractuelle, c’est avec cette dernière qu’il faut se comparer.
Si vous essayez de reproduire cette technique, vous remarquerez peut-être que votre réalisation construction devient critique. C’est simplement parce qu’elle termine le projet. La date de la contrainte étant plus tardive que la date de fin du projet, cette dernière a priorité. Vous devez ajouter une tâche manuelle pour repousser la date de fin à une date postérieure à toutes vos contraintes. Plusieurs techniques permettent de faire cela.
En terminant, sachez qu’il vaut toujours mieux gérer des projets avec une marge de manœuvre. Gardez donc vos projets et vos chemins de tâchesnon-critiques ! Ça vaudra mieux !
La marge sert à savoir si c’est critique et si on est en retard !
On entend souvent dire que telle ou telle activité d’un projet se trouve « sur le chemin critique » du projet. Une formule souvent utilisée pour donner de l’importance à cette activité et tenter de la prioriser face à une autre. Mais qu’en est-il pour MS Project ? Le chemin critique dans MS Project n’existe pas en tant que tel, au sens où il n’a pas de paramètre propre. Il est représenté par un ensemble de tâches consécutives qui forment le chemin le plus long du projet, c’est-à-dire que les tâches qui le composent n’ont pas de marge. D’ailleurs, ce chemin peut exister également sans être critique. Nous verrons comment utiliser les chemins non-critiques dans un prochain article. Pour déterminer si une tâche est critique ou non, MS Project propose à ses utilisateurs, dans les options avancées, de fixer un seuil de criticité à un nombre de jours à partir duquel les tâches seront considérées critiques.
Par défaut, ce seuil est fixé à 0 jour. Vous ne pouvez que choisir des valeurs positives et entières pour ce champ. Par exemple, si vous fixez le seuil à 2 jours, les tâches ayant 2 jours ou moins de marge seront considérées critiques. Il ne s’agit que d’une simple comparaison mathématique à savoir si la marge est inférieure ou égale à ce seuil.
SI ( MARGE <= SEUIL ) { CRITIQUE = OUI } SINON { CRITIQUE = NON }
Marge libre vs marge totale
Pour chaque tâche, le champ Critique est donc directement dépendant de la marge que la tâche a à sa disposition. Il peut s’agir de marge libre ou de marge héritée par le chemin de tâche. La figure ci-bas montre en vert la marge libre de la tâche 4. Comme elle s’exécute en parallèle avec la tâche 3 et que cette dernière dure plus longtemps, la tâche 4 a donc 3 jours de marge libre. Cette marge correspond à la différence entre la durée des deux tâches (5 jrs − 2 jrs = 3 jrs). On observe également le même phénomène avec la tâche 5. En effet, elle a 6 jours de marge libre puisqu’elle s’exécute en parallèle avec la tâche récapitulative 6. La combinaison des deux marges libres des tâches 4 et 5 donne à la tâche 4 un total de 9 jours de marge totale.
Pour notre exemple, nous avons laissé le seuil de criticité à sa valeur par défaut (0 jour). Nous voyons que les tâches 3, 4 et 5 ne sont pas critiques puisque, comme nous l’avons vu, elles ont une valeur positive de marge. Les tâches 7 à 10 forment le chemin critique de notre projet. Ensemble, elles partent de la date de début du projet et mènent à sa fin. C’est d’ailleurs par ce chemin que la date de fin sera calculée.
Dans la figure ci-haut, le projet débute le 24 octobre et se termine le 10 novembre, pour une durée de 14 jours ouvrables. Les tâches 7 à 10 étant liées avec une relation « fin à début », nous pouvons simplement additionner leurs durées et obtenir la durée du projet, puisque l’autre section du projet s’exécute en parallèle et ne dure que 8 jours. Cet exemple montre qu’un chemin critique se forme toujours du début à la fin du projet. Tous les projets ont donc un chemin critique à partir de la date de début jusqu’à la date de fin. Sur ce chemin, les tâches n’auront jamais de marge, à moins que nous en décidions autrement. En résumé, la criticité des tâches dépend de la marge de chaque tâche, qui elle est calculée en fonction de la date de fin de la dernière activité du projet. Si une tâche se trouve sur le chemin le plus long du projet, elle ne pourra avoir de marge.
Pour que cela fonctionne bien dans un projet réel, il faut que le projet n’ait qu’une seule et même date de fin pour tous les livrables et il ne faut pas que le projet utilise des dates fixes pour marquer le passage d’étapes. Heureusement, MS Project ne se limite pas à un seul chemin critique. Il est possible pour l’utilisateur de fixer d’autres bases qui permettront à MS Project de calculer la marge des tâches en fonction d’autres dates que la date de fin du projet. On pourra ainsi créer plusieurs chemins de tâche dans un projet. Nous verrons cela dans un prochain article.
Vous travaillez dans un groupe de quelques gestionnaires de projets ?
Vous avez plusieurs projets à gérer ?
Les ressources œuvrent dans plusieurs projets au cours de la semaine ?
Si vous êtes dans cette situation et que vous travaillez avec MS Project, vous vivez probablement un problème de clonage de ressources. Le clonage survient lorsqu’un ou des gestionnaires utilisent des fichiers de projet différents pour leurs multiples projets.
Par exemple, vous êtes chef de projet de construction résidentielle pour un entrepreneur général qui construit des résidences unifamiliales. L’entreprise a récemment fait l’acquisition de 4 nouvelles rues dans un développement immobilier municipal. Vous gérez la construction de plusieurs de ces maisons. Vos clients sont des futurs acheteurs de maisons et ils ont tous des besoins et exigences différentes en ce qui a trait au plan initial de la maison, au plan de projet, au déroulement du projet et à la date de livraison de la maison. Pour mieux suivre ces différentes exigences, vous choisissez de démarrer un projet pour chacun des clients que vous avez.
Pour la construction des résidences de vos clients, vous faites affaires avec plusieurs fournisseurs indépendants tels que : plombiers, charpentiers, excavation, coffrage, menuiserie, toiture, portes et fenêtres, etc. Pour certaines tâches, vous employez une ressource à tout faire puisqu’il arrive fréquemment que certaines tâches doivent être faites avant et après le travail de ces entreprises indépendantes. Cette ressource travaille donc dans tous vos projets pour effectuer les diverses tâches souvent imprévues pour assurer la continuité de vos projets.
Avec MS Project, la liste des ressources d’un projet fait partie intégrante du fichier de projet *.mpp. Comme vous avez créé un fichier de projet pour chaque résidence, vous avez donc des listes de ressources distinctes.
Fichier : Pr1.mpp
Début du projet : 1 mai
Livraison du projet : 20 juin
Fichier : Pr2.mpp
Début du projet : 15 avril
Livraison du projet : 31 mai
Fichier : Pr3.mpp
Début du projet : 1 avril
Livraison du projet : 20 mai
Liste des tâches journalières de la semaine 19 :
Lundi – Excavation
Mardi – Coffrages et bétonnage
Mercredi – Décoffrage
Jeudi – Imperméabilisation
Vendredi – Remblais
Lundi – Charpente
Mardi – Électricité et plomberie
Mercredi – Installation du gypse
Jeudi – Nettoyage
Vendredi – Plâtrage
Lundi – Peinture
Mardi – Sablage plancher
Mercredi – Vernis plancher
Jeudi – Grand ménage
Vendredi – Inspection
Liste des ressources journalières de la semaine 19 :
Lundi – Excavation J.G. Inc
Mardi – Béton Beaulieu
Mercredi – Béton Beaulieu
Jeudi – Julien #1
Vendredi – Excavation J.G. Inc
Lundi – Michel Janvier et fils.
Mardi – Conduits Rive-Sud
Mercredi – Michel Janvier et fils.
Jeudi – Julien #2
Vendredi – Michel Janvier et fils.
Lundi – Peintres et Cie
Mardi – Planchers du monde
Mercredi – Planchers du monde
Jeudi – Julien #3
Vendredi – Inspecteur M.L.
Dans l’exemple ci-haut, nous avons 3 fichiers de projets distincts avec des listes de ressources distinctes. Les tâches qui sont à effectuer pour chaque projet sont effectuées par des ressources externes et différentes pour les 3 projets puisqu’ils sont à différentes étapes de construction. Cependant, les tâches qui doivent être effectuées le jeudi doivent être faites par notre homme à tout faire : Julien. Comme nous utilisons Julien dans nos 3 projets, nous l’avons dans la liste des ressources des 3 projets. Et comme nous avons 3 listes de ressources, nous avons donc 3 copies de Julien (des clones).
Cette situation est très problématique puisque MS Project ne sait pas qu’il s’agit effectivement du même Julien et ne peut nous indiquer que ce dernier aura 3 tâches à faire la même journée.
La solution : Le partage de ressources
La stratégie pour mettre en place le partage de ressources consiste à créer un pool de ressources unique et central qui servira à exécuter les tâches des autres projets. Ce pool de ressources réside dans un fichier différent des fichiers des projets. Dans l’exemple ci-dessous, le pool de ressources se situe dans le fichier Ressources.mpp. Les tâches des projets Pr1 à Pr3 seront effectuées par les ressources de ce pool.
Pour permettre aux ressources du pool de travailler sur des tâches situées dans d’autres fichiers de projet, il faut créer une liaison grâce aux fonctions de partage de ressources. Pour créer cette liaison : à partir du fichier de projet qui contient les tâches, sous l’onglet Ressources, Affectations, en cliquant sur le bouton Liste de ressources partagées.
Dans la fenêtre Partager des ressources, sélectionnez le fichier contenant le pool de ressources et cliquez OK. Ce dernier fichier doit être déjà ouvert en lecture/écriture dans MS Project. Une fois cette opération complétée, le partage de ressources est en place. Enregistrez les deux fichiers liés pour conserver le partage de ressources.
ATTENTION !! Une fois que le lien est créé, vous ne pouvez plus renommer ou déplacer les deux fichiers liés. Vous ne devez pas changer le chemin d’accès à ces fichiers.
Cette technique de partage de ressources est très efficace si vous êtes un seul gestionnaire de projet qui gère plusieurs projets, puisque tous les fichiers résideront sur votre ordinateur et un seul utilisateur ouvrira ces fichiers. Le résultat est flamboyant puisque les 4 fichiers sont tous ouverts en lecture/écriture simultanément et l’utilisateur n’y voit que du feu. Le gestionnaire consolide ses 3 projets en un seul et obtient les conflits entre ses multiples projets comme le montre la capture d’écran ci-dessous.
Le partage de ressources en réseau et dans le cloud.
Plusieurs entreprises utilisent le partage de ressources sur un lecteur réseau, ce qui donne la possibilité à d’autres utilisateurs de démarrer d’autres projets qui utilisent eux aussi le même pool de ressources. Il faut cependant faire très attention aux droits d’accès aux fichiers de ces utilisateurs. D’autres utilisent des outils comme Dropbox ou d’autres systèmes de stockage de fichiers en nuage. Il faut être très prudent lorsqu’on utilise cette stratégie de partage de ressources entre plusieurs utilisateurs sur un système de synchronisation nuagique. Les chemins d’accès inscrits dans les fichiers Ressources.mpp et Prx.mpp lors de l’initiation du partage ne sont pas toujours statiques et peuvent changer en fonction de l’utilisateur.
Les trucs et astuces avec MS Project que l’on doit absolument connaître.
Vous avez peut-être lu notre article sur la bête noire d’office, où on disait que le type de tâche nous faisait la vie dure. Vous trouverez plus bas des explications sur les types de tâche qui vous aideront à bien travailler avec MS Project. Mais avant de parler de types de tâche, voyons tout d’abord pourquoi ce paramètre existe. Pour cela nous parlerons de la relation mathématique qui existe entre la quantité de travail et la durée d’une même tâche.
1- L’équation du travail et les paramètres de tâches.
Comme nous le savons, MS Project calcule toujours la quantité de travail d’une tâche, grâce à l’équation suivante :
Le travail : représente la quantité d’effort devant être accompli pour exécuter une tâche. (Le nombre d’heures à faire)
La durée : représente le nombre de jours ouvrables compris entre la date de début et la date de fin d’une tâche. Les jours ouvrables/chômés sont définis par le calendrier de projet.
Les Unités d’affectation : indiquent le taux d’allocation des ressources affectées pour effectuer le travail pendant la durée de la tâche.
Vous aurez sûrement compris qu’il ne s’agit pas simplement de calculer le travail, mais bien de solutionner une équation. Ce qui veut dire que le résultat de cette équation peut être autant le travail, la durée ou les unités. Il faut simplement isoler l’inconnu. Pour une tâche effectuée par une personne pendant une journée, le résultat recherché est le travail. Mais pour une autre tâche de 200 heures, effectuée par 6 personnes, on recherche le temps que ça leur prendra pour compléter le travail. On cherche la durée.
C’est très pratique, mais concrètement, ce n’est pas si simple que ça peut avoir l’air. Sachant que cette équation sera toujours solutionnée par Project, qu’advient-il si on change le travail ? Afin d’équilibrer l’équation, changera-t-il les unités d’affectation ou la durée ? Et… Si on change le nombre de ressources (unités d’affectations), est-ce la durée ou le travail qui sera modifié ? Vous me répondrez que ça dépend, n’est-ce pas ? Ça dépend de la tâche elle-même. De ce qu’il y a à faire.
Effectivement, on voudra, si on diminue le nombre de ressources pour une tâche nommée « Brainstorm », que le travail diminue, et pour une tâche nommée « peindre », que la durée augmente. Donc, pour déterminer quel est l’inconnu de l’équation, il faut comprendre la différence entre l’activité « brainstormer » et « peindre ». Comme MS Project ne comprend pas cette différence, les programmeurs de chez Microsoft ont inventé le champ de tâche « Type de tâche » pour pallier à cette problématique.
L’utilisateur indiquera à Project quel paramètre sera inchangeable pour la tâche. Il permettra donc à Project de déterminer quel est l’inconnu dans l’équation et de le recalculer suite à un changement de la part de l’utilisateur.
Il existe 3 types de tâche tout simplement parce qu’il y a trois paramètres dans notre équation.
(Travail Fixe) (Durée Fixe) (Capacité Fixe)
2- Les types de tâches
Avec MS Project, les tâches sont obligatoirement paramétrées avec un des trois types de tâche. Par défaut, les gens chez Microsoft nous proposent « capacité fixe ». Dès la création d’une nouvelle tâche, cette dernière sera calculée de manière à ne pas changer le taux d’affectation de ses ressources. Ainsi, si on changeait la durée de la tâche, le travail serait recalculé et inversement, puisque c’est la capacité qui est fixe.
N.B. Ici on utilise la terminologie du logiciel pour « Capacité fixe » mais il semble qu’il y ait une erreur de traduction puisqu’en anglais ils utilisent « fixed unit » donc « unité fixe ». Comprenez simplement que pour « capacité fixe », il s’agit du type où les unités ne changent pas.
Le type de tâche par défaut ne convient pas à toutes les tâches. Il est donc essentiel de judicieusement sélectionner le bon type pour chaque tâche de votre projet. De plus, la vie n’étant pas si simple, vous rencontrerez certainement des tâches qui ne soient d’aucun de ces trois types. Dans ces cas, vous devrez valider manuellement que vos modifications ont bien changé ce que vous désiriez.
Le tableau ci-haut montre tous les cas de figure de changements effectués sur un paramètre de l’équation pour chaque type de tâche. Il vous aidera à choisir le type qui convient le mieux à votre tâche. Dans les cases orangées, il nous donne la solution aux cas où l’utilisateur change le paramètre qui est fixé par le type de tâche. Vous remarquerez qu’en aucun cas les unités ne seront modifiées. Vous avez en rouge les deux seuls cas où Project change les unités. Ils sont en rouge parce qu’avec les versions 2010 et 2013, la valeur affichée à l’écran ne correspond pas au taux qui est calculé. Il y a un bug d’affichage de cette valeur lorsqu’elle est calculée par Project.
Donc en guise de conclusion, retenez qu’il est très important de sélectionner le bon type de tâche et surtout de surveiller de près les changements aux paramètres de l’équation quand vous changez des valeurs de votre projet.
