clarification sur l’utilisation des dépendances de planning, des contraintes et délais

Clarifying the Usage of Schedule Dependencies, Constraints & Deadlines

Kiron D. Bondale
Kiron D. Bondale

http://www.pmhut.com/clarifying-the-usage-of-schedule-dependencies-constraints-deadlines

Par Kiron D. Bondale

Alors qu’un échéancier de projet correctement développé est un objet d’art, mal créé il peut être une source de frustration pour l’équipe projet et un risque pour le succès du projet.

Le développement d’un échéancier avant d’avoir passé du temps à décomposer le contenu d’un projet est probablement le péché primaire de la plupart des faibles planificateurs, mais il est suivi de près par l’utilisation incorrecte de dépendances d’échéancier, des contraintes et des délais.

1. Les dépendances dans l’échéancier représentent une connexion logique entre deux activités discrètes.

Microsoft Project
Partenaire de DantotsuPM

De telles relations devraient être rapprochées de la nature des activités elles-mêmes et PAS de qui exécutera les tâches ou d’autres contraintes similaires.

Les dépendances le plus généralement fournies incluent:

  • Fin-à-début (Finish-to-Start): La relation causale la plus commune et pour laquelle aucune explication n’est nécessaire à son utilisation.
  • Début-à-fin (Start-to-Finish): Rarement utilisée mais utile en développant un échéancier en arrière à partir d’une date finale fixe (rétro-planning).
  • Début-à-début: Cela représente une vraie relation entre deux activités et n’a aucun rapport avec leurs prédécesseurs. Si j’ai deux tâches qui commencent en même temps à cause d’un prédécesseur, ce sera mieux représenté par deux relations de fin-à-début (par exemple les tests des systèmes et la documentation peuvent tous les deux commencer une fois que le développement est terminé, mais il n’y a aucune relation entre les tests et la documentation donc nous ne voudrons pas utiliser une dépendance de Début-à-début dans ce cas). Cette dépendance est souvent utilisée avec un retard pour représenter la connexion entre deux activités qui fonctionnent en parallèle, mais ne peuvent pas commencer exactement en même temps (par exemple appliquer la première couche de peinture et appliquer la deuxième couche de peinture). Un vrai exemple de Début-à-début est une course entre deux coureurs où chaque coureur est représenté comme une activité séparée – tandis qu’ils finiront probablement à des moment différents, tous les deux doivent commencer exactement en même temps.
  • Fin-à-fin (Finish-to-Finish): C’est généralement utilisé pour représenter les activités qui doivent s’achever en même temps afin de pas avoir un impact sur leurs successeurs ou sur un ou plusieurs des objectifs pour le projet. Un exemple en dehors des projets est de préparer la nourriture dans un restaurant. Les chefs doivent s’assurer que le plat principal et les garnitures sont prêts exactement en même temps pour que la présentation puisse être faite sans  impact sur la qualité.

dépendances2. Les contraintes représentent une limitation dans le monde réel

Limitation qui empêche une activité de commencer ou de s’achever quand elle le devrait normalement (par rapport à la date de début de projet ou ses dépendances). Les contraintes sont souvent employées improprement quand la tendance naturelle pour un planificateur novice est de forcer manuellement des dates de début ou des dates finales de tâche. Les exemples valables de contraintes incluent des dépendances de ressource (par exemple l’indisponibilité d’une salle pour recevoir une formation) ou des facteurs externes (par exemple les périodes de d’interdiction de maintenance qui affecteraient les certains types de tâches). Des calendriers de ressource ou de tâche si supportés par le moteur de l’outil de planification fournissent une alternative à l’utilisation des contraintes. Cependant, même avec ces fonctionnalités c’est une bonne idée de documenter la condition spécifique qui a nécessité l’utilisation de la contrainte ou du calendrier pour que si la condition ne s’applique plus à un moment ultérieur, la contrainte puisse être supprimée aboutissant à une performance de planning potentiellement améliorée.

3. Les contraintes et les dates impératives « deadlines »

Les contraintes sont de temps en temps utilisées (particulièrement « finir le » “finish on” ou « ne pas finir plus tard que » “finish no later than”) quand un délai impératif « deadline » marcherait mieux. Tandis que des dépendances et les contraintes impactent la logique et les dates de début ou de fin des tâches, les délais impératifs fournissent un affichage visuel au planificateur qu’un délai « du monde réel » va probablement être manqué. Sur de grands échéanciers, alors qu’il pourrait y avoir de nombreux jalons, il peut y avoir seulement quelques vrais délais impératifs qui doivent être observés. Pour s’assurer que le planificateur est conscient des conséquences négatives potentielles d’un changement de planification, les délais impératifs fournissent les moyens « doux » de notification qui n’empêcheront ni les tâches de se déplacer librement ni l’optimisation de l’échéancier.

attendre4. Les retards(lag)

Ils sont parfois évités en faveur de tâches artificielles insérées entre deux activités dépendantes. Par exemple, une fois que j’ai passé une commande avec mon vendeur, une période de temps passera avant que l’équipement soit livré. L’utilisation d’une tâche pour représenter ce délai de livraison est incorrecte à moins que l’activité ne soit exécutée par l’équipe projet et de plus cela faussera le calcul de pourcentage de complétude du projet tout entier. Une meilleure approche est d’introduire un retard entre les deux activités représentant le nombre de jours ou de semaines prévu pour la livraison.

Je n’ai pas essayé de fournir un aperçu complet de chacune de ces fonctionnalités, mais j’ai  bon espoir que cela clarifie leur utilisation pour que le bon outil soit utilisé pour le bon travail!

5 réflexions sur “clarification sur l’utilisation des dépendances de planning, des contraintes et délais

  1. Très bon article. J’adhère. Il y a des finesses en effet dans la définition causal des liens logiques à bien prendre en compte. Mais pire que ça, il faut aussi s’attacher à la nature du lien logique. Par exemple, un lien logique Fin-Début peut être de type Zone, Produit ou Activité, conformément à ma théorie sur le WBS 3D.

    Cordialement,
    Jean-Yves Moine
    Blog : http://3d-wbs.blogspot.fr/
    Site web : https://sites.google.com/site/jymoine/home

    J'aime

  2. Oui, effectivement, bon article qui rappelle les fondamentaux : ça ne fait jamais de mal :-). La gestion des dépendances, surtout dans un planning coordonnant de nombreux acteurs, est cruciale.

    En effet, trop de prise de risque (pas ou trop peu de marge) peut entraîner un « effet domino » dévastateur sur la tenue globale des délais, mais trop de marge dans la demande d’une fourniture (souvent modélisé par un lag conséquent) conduit à des demandes perçues comme irréalistes et entament la confiance des entités coordonnées en la pertinence du planning global…. Il faut trouver le bon équilibre entre exigences et maîtrise du risque.

    Un autre point saillant dans la difficulté à gérer les dépendances, qui induit généralement beaucoup de frustrations, est la distinction entre les dépendances fortes (mandatory) et les dépendances faibles (discretionary). Certaines dépendances sont extrêmement fortes : exemple, dans le domaine du bâtiment, avoir les murs avant de pouvoir poser les fenêtre d’une maison, mais d’autres sont plutôt des dépendances de « confort », car elles limitent le risque, comme par exemple, dans le domaine du logiciel, avoir accès à une plate-forme similaire à une plate-forme de production pour réaliser des tests dès la phase de développement. Ces typologies de dépendances ne sont, à ma connaissance, gérées par aucun moteur de planification, alors que les dépendances faibles constituent un gisement assez important d’optimisation du planning… De mon côté, lorsque je travaille avec plusieurs acteurs, je leur demande, et je m’astreins, de typer leurs jalons, afin de pouvoir avoir une vision claire des dépendances fortes et de gérer au mieux les priorités.

    Et vous ? Comment faites-vous ?

    J'aime

  3. Ping : les articles les plus lus sur leblogdumanagementdeprojet / DantotsuPM en Octobre 2012 « DantotsuPM.com

  4. Ping : les sources de risques cachés dans les projets « DantotsuPM.com

  5. Ping : PMBOK 4th Edition (2009) – Sequence Activities | Blog AurGa

n'hésitez pas à commenter les billets et à partager vos idées.

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.