Cet article fait partie des Séries 101 sur l’analyse des retards, qui est également disponible sous le bulletin de LinkedIn.
Dans l’industrie de la planification judiciaire, deux documents sont régulièrement cités lorsqu’il s’agit de s’appuyer sur une méthode standard d’analyse des retards: le Delay and Disruption Protocol (2017) de la Society of Construction Law (SCL) et l’International Recommended Practice 29R-03 on Forensic Schedule Analysis (2011) de l’Association for the Advancement of Cost Engineering (AACE). Cet article se concentre sur les méthodes décrites dans le SCL Delay and Disruption Protocol (the “SCL Protocol”).
Dans les articles précédents, nous avons vu que les mesures de retard peuvent suivre des perspectives distinctes. Nous avons aussi constaté que les chemins critiques pourraient suivre des perspectives distinctes. Dans cet article en deux parties, nous verrons quelle méthode repose sur quelle perspective de retards et de chemin critique, et quelles sont les conséquences du choix d’une combinaison plutôt que d’une autre. La Partie 1 est disponible ici.
Note: Quelques problèmes d’affichage ont été signalés avec l’affichage d’images animées via l’application pour téléphone LinkedIn. Regardez sur la page web de LinkedIn pour une meilleure expérience.
Six méthodes, six questions (suite)
Les méthodes d’analyse Impacted As-Planned et Time Impact Analysis ont été abordées dans la Partie 1. Les quatre autres méthodes sont abordées ci-dessous.
La méthode Time Slice Windows
Cette méthode répond à une question qui pourrait être formulée comme suit:
Au fur et à mesure de l’évolution du projet, quel a été l’effet réel des retards pris par les activités qui devaient permettre de respecter la date d’achèvement lors de chaque mise à jour du planning? Optionnellement : et quel a été l’effet probable des mesures de reprogrammation établies lors de chaque mise à jour du planning?
La méthode Time Slice Windows consiste à évaluer les retards ayant un effet sur la date d’achèvement du projet entre les différentes mises à jour du planning, d’où la nécessité de s’appuyer sur le chemin critique contemporain à différents moments (dates des données). L’étape principale de la méthode se concentre sur les effets réels des retards survenus le long de ce chemin critique : les retards sont évalués rétrospectivement.
En pratique, cette méthode consiste à comparer la date d’achèvement du projet d’un planning par rapport à celle du planning précédent : le décalage de la date d’achèvement du projet représente le retard tel que réalisé pris entre les deux dates de données. La période entre les deux dates est appelée Time Slice.
Cependant, lorsque les mises à jour du planning comprennent non seulement des mises à jour de l’avancement des travaux, mais aussi des modifications des durées prévues et/ou de la logique des travaux restants, les retards réels ne peuvent pas eux seuls réconcilier le décalage de la date d’achèvement. Dans ce cas, une étape supplémentaire est nécessaire. Cette étape consiste à évaluer l’effet des changements de la partie prospective des plannings. Cela est due à que la date d’achèvement résulte d’une combinaison des retards encourus à ce jour et de la prévision de retards ou d’accélérations supplémentaires. L’étape supplémentaire vise à identifier ces retards non planifiés et donc à faire le lien entre une mise à jour du planning et la suivante.
La méthode Time Slice Windows est plus complexe que les méthodes précédentes car elle nécessite plusieurs étapes intermédiaires qui sont ensuite répétées pour chaque mise à jour du planning. Voici une illustration générale des mécanismes impliqués dans le cas d’une première tranche avec des retards à la fois réels et planifiés. Les détails de la mise en œuvre de cette méthode feront l’objet d’un article spécifique.
La méthode As-Planned versus As-Built Windows
Cette méthode répond à une question qui pourrait être formulée comme suit:
Au fur et à mesure du développement du projet, quel a été l’effet réel des retards dans les activités qui étaient censées faire avancer la date d’achèvement à différents moments ?
Notez que cette question est similaire à celle de la méthode Time Slice Windows. Elle consiste à évaluer les retards qui conduisent à la date d’achèvement du projet à différents moments (dates de données), d’où l’utilisation d’une série de chemins critiques contemporains (un pour chaque date de données). L’agrégation de cet ensemble de chemins critiques contemporains constitue ce que l’on appelle le chemin critique réel. La méthode se concentre également sur les effets réels des retards survenus le long du chemin critique : les retards sont évalués rétrospectivement.
Dans une certaine mesure, la méthode Time Slice Windows est un cas particulier de la méthode As-Planned versus As-Built Windows (« APvAB »):
- Alors que pour la méthode Time Slice Windows, le chemin critique est évalué à l’aide des plannings actualisés du projet, la méthode APvAB autorise un plus large éventail de sources : elle peut être basée sur les plannings, mais aussi sur les rapports d’avancement mensuels, les taux de productivité ou tout autre outil ou donnée permettant de déterminer quelle séquence dominait la date d’achèvement du projet à une date de données donnée.
- Dans la méthode APvAB, le projet est découpé en fenêtres de temps : il peut s’agir des dates de mise à jour du calendrier (comme c’est le cas pour les tranches de temps), mais aussi de tout événement permettant de diviser l’évaluation en périodes de temps gérables. Le choix des limites des fenêtres fait l’objet d’un article que je prépare actuellement pour notre bulletin Cutting Edge Delay Analysis Series.
- L’étape facultative de la méthode Time Slice Windows est mécaniquement similaire à l’évaluation d’une nouvelle ligne de base dans le cadre de la méthode APvAB. Cette question sera également abordée dans un prochain article consacré à la mise en œuvre complète de la méthode As-Planned versus As-Built Windows.
La méthode consiste à (i) établir le déroulement des activités tel que réalisées du projet, (ii) identifier le chemin critique réel, (iii) diviser le projet en fenêtres temporelles, (iv) mesurer le retard du projet à la fin de chaque fenêtre, et (v) identifier les événements responsables du retard du projet qui ont changé entre le début et la fin de la fenêtre. La mise en œuvre détaillée sera abordée dans un futur article dédié, mais une vue d’ensemble est disponible ci-dessous.
La méthode Retrospective Longest Path
Cette méthode répond à une question qui pourrait être formulée comme suit:
En fin de compte, quel a été l’effet réel des retards sur les activités qui ont conduit à la date d’achèvement ?
Cette question est similaire à celle de la méthode As-Planned versus As-Built Windows. En effet, cette méthode est similaire à l’APvAB en tous points, à l’exception de l’évaluation du chemin critique. Au lieu de s’appuyer sur les chemins critiques contemporains ou réels, cette méthode est basée sur la séquence des activités qui ont finalement conduit à la date d’achèvement du projet. Il s’appuie sur le chemin critique tel que réalisé, qui est rétrospectif.
L’idée générale de cette méthode est la même que celle de la méthode As-Planned versus As-Built Windows, à l’exception du chemin critique qui est basé sur une reconstruction des événements après les faits, au lieu d’être basé sur les mises à jour disponibles à l’époque. La méthode Retrospective Longest Path prend en compte la séquence des événements sans tenir compte du fait que ces événements n’étaient peut-être pas prévisibles (a posteriori). En revanche, la méthode APvAB ne prend en compte que les informations connues au moment où les événements de retard ont eu lieu (en « aveugle »). Les forces et les faiblesses de chacune d’entre elles seront abordées dans un prochain article.
La méthode Collapsed As-Built
Cette méthode répond à une question qui pourrait être formulée comme suit:
Pour un ensemble donné d’événements de retard, quand est ce que le projet aurait-il été achevé, en supposant qu’en l’absence de ces événements, les tâches non affectées du projet auraient duré le même temps que ce qu’elles ont réellement duré ?
Cette méthode est généralement appliquée une fois le projet achevé. La méthode vise à déterminer ce qu’aurait été l’achèvement du projet si certains événements de retard ne se seraient pas produits. Elle est également connue sous le nom de but-for, car l’objectif est d’établir ce qui se serait passé en l’absence de certains événements.
La méthode Collapsed As-Built est séduisante parce qu’elle semble élégante et intuitive : il s’agit d’extraire les événements de retard du planning tel que réalisé et de comparer la date d’achèvement du projet réalisée avec celle du planning désormais réduit.
Résumé
Les six méthodes d’analyse des retards décrites dans le Delay and Disruption Protocol du SCL reposent sur diverses combinaisons de retard ou de chemin critique prospectives, retrospectives et contemporaines . En effet, elles répondent à des questions différentes :
- La méthode Impacted As-Planned
Au début du projet, quel était l’impact probable d’une série donnée de retards, en supposant qu’en l’absence de ces retards, le reste du projet se déroulerait comme prévu sur la ligne de base?
- La méthode Time Impact
À une date donnée, quel est l’impact probable d’un ensemble donné de retards, en supposant qu’en l’absence de ces retards, le reste du projet se déroulerait comme prévu par le planning mis à jour à la date des données?
- La méthode Time Slice Windows
Au fur et à mesure de l’évolution du projet, quel a été l’effet réel des retards des activités qui étaient censées conduire la date d’achèvement lors de chaque mise à jour du planning? Optionnellement : et quel a été l’effet probable des mesures de reprogrammation prises lors de chaque mise à jour du planning?
- La méthode As-Planned versus As-Built Windows
Au fur et à mesure du développement du projet, quel a été l’effet réel des retards dans les activités qui étaient censées faire avancer la date d’achèvement à des différents moments?
- La méthode Retrospective Longest Path
En fin de compte, quel a été l’effet réel des retards sur les activités qui ont réellement conduit à la date d’achèvement?
- La méthode Collapsed As-Built
Pour un ensemble donné d’événements de retard, quand est ce que le projet aurait-il été achevé, en supposant qu’en l’absence de ces événements, les tâches non affectées du projet auraient duré le même temps que ce qu’elles ont réellement duré?
