Dépendance inter-projets
Alias : dépendance externe, dépendance de programme, interdépendance.
Définition
Une dépendance inter-projets peut placer le demandeur sans autorité directe sur celui qui fournit le résultat ; ce n'est pas une condition de sa définition. Il faut préciser qui peut engager la livraison et arbitrer un conflit. PMLeadr recommande de la gérer par un engagement écrit (quoi, quand, qui confirme), une date de vérification antérieure à la date de besoin, et un plan B décidé à l'avance (périmètre réduit, solution de contournement, report). Une dépendance « confirmée à l'oral » est une hypothèse.
Le programme ou le portefeuille tient le registre de ces dépendances, parce qu'une seule livraison en retard peut décaler plusieurs projets. Dans un cadre à l'échelle, elles sont rendues visibles lors de la planification commune.
Exemple
[SCALEUP], initiative « approbation multi-niveaux » : le troisième niveau d'approbation dépend de la version 3.4 du connecteur d'un partenaire ERP externe, non livrée au 30 septembre 2026. Le scénario où le partenaire livre le 1er octobre rend les tests possibles, pas faits : le dossier de comité doit écrire « testable », pas « testé », et la story concernée reste hors périmètre tant que la recette n'a pas eu lieu.
À ne pas confondre avec
- La dépendance de tâches dans un réseau : elle exprime un lien d'antériorité, sans établir à elle seule l'autorité du chef de projet sur les exécutants.
- Le risque : la dépendance est certaine ; le risque est qu'elle ne soit pas honorée à temps.
- Le contrat : il encadre la dépendance, il ne la supprime pas.
Voir aussi
Fiches : GP06 — Identifier et piloter les dépendances entre projets, GP07 — Tenir un RAID log utile aux arbitrages, ST05 — Relier un projet SI aux flux des opérations et de la supply chain. Kits : T05 — RAID log et dépendances. Termes : registre des risques, RAID log, réversibilité contractuelle, portefeuille de projets.