On parle de projets, de programmes, de portefeuilles. Tout ceci implique un lien entre les projets, des dépendances.
Mais en fait, quelles sont vraiment ces dépendances, comment les identifier, les analyser et les gérer ?
Nous verrons dans cet article les différents types de dépendances entre projets, et comment en identifier, avec exemples à l'appui.
Les différentes dépendances entre projets
Découvrons déjà les différentes formes de dépendances qui peuvent se manifester entre plusieurs projets.
1) Les dépendances de périmètres
On commence ici par le plus évident : étudier le périmètre des projets.
Vous avez donc deux cas :
- Les dépendances de similitude
- Les dépendances de besoin
Exemple de dépendance de similitude :
Imaginez des projets de mise à jour de parc informatique.
Pour des raisons de logistique et de charge d’équipe, on peut décider d’avoir un projet par pays, par exemple.
Dans ce cas, tous les projets en question sont semblables, le périmètre étant la mise à jour du parc informatique.
Seuls vont changer les localités et probablement la quantité d’équipements.
Vous avez donc une dépendance de périmètre, qui sera le plus souvent gérée au sein d’un programme ; nous y reviendrons ultérieurement.
Exemple de dépendance de besoin :
Passons maintenant au déploiement d’un ERP.
Avant d'installer votre logiciel, vous allez devoir acheter (ou solliciter dans le cas de IaaS = Infrastructure As A Service) du matériel pour l’installer.
En faisant simple, vous aurez donc un projet d’installation logiciel qui dépend du projet d’installation matériel.
Dans le développement logiciel, vous avez également des dépendances liées à l’accès aux ressources technologiques.
Lorsque vous suivez des Frameworks comme l’ITIL ou le Cobit, vous devez suivre précautionneusement des procédures de mise en service et de tests des modifications effectuées sur un système.
Très souvent vous devrez attendre, ou coordonner les modifications venant de deux ou plusieurs projets.
2) Les dépendances de ressources
Sauf dans de très gros projets ou programmes, les ressources humaines assignées à un projet le sont en général à temps partiel.
Vous avez donc des personnes qui partagent leur temps entre plusieurs projets.
Même en supposant que le plan de charge soit optimisé, constamment accessible, ce qui est planifié ne se passe pas toujours comme prévu, sinon, cela ne serait pas drôle.
Vous pouvez donc avoir des personnes, qui, à certains moments seront concentrées sur un projet, plutôt que sur un autre, ce qui impactera d’autres projets.
Un point souvent sous-estimé concerne les dépendances vis-à-vis de la disponibilité des utilisateurs pour valider les cahiers des charges ou la mise en production.
Si vos utilisateurs sont occupés sur un projet, il se peut qu’ils ne puissent pas se libérer pour un autre projet au même moment.
3) Les dépendances de planning
Très souvent conséquence des dépendances citées ci-dessus, vous avez les dépendances de planning :
Dans un diagramme de Gantt, les différentes dépendances que nous pouvons avoir sont les suivantes :
- Dépendance de début à début (DD) : la tâche suivante ne peut pas commencer avant que la tâche précédente ne commence.
- Dépendance de début à fin (DF) : la tâche suivante ne peut pas commencer avant que la tâche précédente ne soit terminée.
- Dépendance de fin à début (FD) : la tâche suivante ne peut pas être terminée avant que la tâche précédente ne commence.
- Dépendance de fin à fin (FF) : la tâche suivante ne peut pas être terminée avant que la tâche précédente ne soit terminée.
Ces dépendances sont également valables entre projet : la tâche 1 du projet B peut dépendre de la tâche 5 du projet A.
4) Les dépendances budgétaires
Lorsqu’un sponsor (personne ou département) finance des projets, vous aurez une dépendance implicite : le budget est limité.
Les projets sont approuvés avec un budget déterminé.
Initialement le budget total est suffisant pour la somme des budgets projets.
Néanmoins, pendant le déroulement des projets, des apports additionnels peuvent être demandés.
Cela fait en sorte que l’on atteigne la valeur totale du Budget.
Il devient donc impossible de demander des augmentations de budget dues à des changements ou des imprévus.
Pire encore…
On est obligé d’arrêter ou de réduire la taille d’un projet pour prioriser d’autres.
Comment identifier les dépendances
Voici les étapes pour identifier ces différentes dépendances :
1) Identification des dépendances
Le travail d’identification des dépendances ne peut pas être fait par le chef de projet, tout seul.
En effet, il n’a pas la vision globale de tous les projets, des systèmes, des ressources et de l’entreprise.
Une première évaluation doit donc être faite par le Bureau de Projet, le responsable de Portefeuille ou de Programme.
L’identification des dépendances est un exercice qui est lié à l’analyse des contraintes et des risques du projet et fait donc partie des documents de base du projet :
- Analyser les différents plannings au niveau micro et macro
- Analyser les plans de charges et identifier les ressources communes à plusieurs projets
- Analyser les plans d’achats de matériel, logiciel et services pour identifier des fournisseurs communs, des contraintes de livraisons
- Profiter des revues de portefeuilles de projet pour que les échanges entre chefs de projets permettent d’identifier, dépendances, contraintes et risques communs.
- Utiliser les informations disponibles aux niveaux Programmes et Portefeuilles
Au niveau chef de projet, l’analyse détaillée se fera lors de la définition des tâches et activités du projet.
L’idéal est d’avoir constamment en tête la question suivante :
« Ai-je des dépendances ou des contraintes concernant telle ou telle activité ? »
2) Documentation des dépendances
Comme il a été dit précédemment, les dépendances doivent être documentées dans la description des contraintes et dans le registre des risques.
Une dépendance ne devrait pas être considérée comme un problème majeur.
En effet un problème majeur doit être résolu.
Résoudre une dépendance équivaut en général à la supprimer, ce qui, immanquablement, impliquera une modification du projet.
a) Documentation des contacts
Un point essentiel est de bien documenter le lien externe de la dépendance avec les contacts précis des personnes associées, en général un autre chef de projet.
Cela permet de régulièrement prendre contact avec le ou les personnes en question, afin de faire le point sur la dépendance et éventuellement mettre à jour la documentation du projet.
b) Gestion des dépendances de planning
Dans le cas spécifique des dépendances de planning, utilisez les outils à disposition pour lier activités et projets via des systèmes, ce qui permettra d'obtenir des mises à jour automatiques.
Autrement, une gestion manuelle de ce type de dépendance devient très rapidement fastidieuse et sujette à oubli ou erreur de mise à jour.
3) Accompagnement des dépendances
Comme expliqué précédemment, les dépendances sont donc en général enregistrées comme des contraintes ou des risques.
Elles doivent donc être revues régulièrement dans le cadre du suivi du registre des risques et par la revue générale du projet.
a) Suivi régulier des dépendances
Dans la mesure où nous parlons d’influences externes, il est également essentiel d’avoir un suivi régulier.
Cela peut se faire directement avec les chefs de projets des projets associés, comme avec le Bureau de Projet ou le(s) responsable(s) de Portefeuille(s).
b) Gestion des instabilités
Le fait d’avoir des dépendances externes, crée un facteur d’instabilité pour le projet dont il faut en avoir conscience.
Il en résultera probablement des modifications du projet durant son déroulement.
c) Communication et responsabilité
D’un point de vue de la communication, bien que les dépendances soient externes, il faut garder à l’esprit que la responsabilité de la gestion de celles-ci incombe au chef de projet.
Ce dernier doit effectivement le faire, et ne pas se placer en victime au cas où l’impact sur le projet serait non négligeable.
Cela pourrait impliquer un changement important, comme un dépassement du budget ou un retard de livraison.
Des exemples
Pour illustrer la gestion des dépendances entre projets, examinons deux exemples concrets.
1) Construction d’un lotissement de maisons individuelles
Prenons un exemple de la vie quotidienne :
La construction de lotissement de maisons individuelles.
D’un point de vue gestion de projet, on parlerait d’un programme.
Pas sûr que cela soit le terme utilisé dans la vie réelle, mais utilisons cet exemple pour revoir un peu les dépendances entre projets.
Considérons que la construction de chaque maison est un projet.
Pour la partie infrastructure du lotissement, nous avons un ou plusieurs projets pour insérer le lotissement dans la zone urbaine :
Pour faire simple : Voirie, eau, tout-à-l’égout, électricité, téléphonie/internet.
a) Dépendances de périmètre (et en conséquence de planning)
À la base, il faudra un minimum d’infrastructure du lotissement pour que les ouvriers puissent accéder aux terrains et que le matériel puisse être livré.
On peut imaginer qu’il est nécessaire d’avoir l’électricité sur chaque lot pour travailler correctement.
Un plan de mitigation pourrait inclure l'utilisation d'outils autonomes ou des alimentations portables.
À la fin, chaque maison devra être raccordée aux systèmes d’eau, d’électricité…
Si le circuit public n’est pas prêt, la maison pourra être connectée, mais sans résultat.
b) Dépendances de planning
Sans entrer dans les détails, la construction de la maison se fait suivant un planning prédéfini :
- Fondation, murs porteurs, toiture, plomberie, électricité, peintures, finitions…
Tout ceci doit suivre une séquence précise, pour éviter les impacts d’un corps de métier sur le travail des autres et d’éventuels retravaux.
c) Dépendances de ressources humaines
On peut imaginer que le même artisan soit embauché pour travailler sur plusieurs maisons.
Il ne pourra pas travailler sur toutes les maisons en même temps, il faudra établir une séquence.
d) Dépendances « logistiques »
Une maison étant un espace fini, il ne sera pas possible d’avoir tous les artisans au même moment dans la maison, pour les raisons suivantes :
- Manque de place
- Dimensionnement de la source d’électricité
- Perturbations comme les odeurs, le bruit, les poussières
Tout ceci devra donc être coordonné correctement.
- Stockage des matériaux : il se peut que l’espace soit limité et qu’il ne soit pas possible de tout stocker en même temps
- La réception des matériaux : un point critique : sans matériaux les artisans ne pourront pas travailler
Avec cette approche, même superficielle, nous pouvons voir les principales dépendances entre projets, et la complexité de gérer l’ensemble.
2) Mise à jour de systèmes
Prenons un exemple classique.
Un besoin de mise à jour de logiciels.
Cela peut être dû à la fin de support annoncée, de l’obsolescence de certains composants logiciels, ou tout simplement la fin de vie d’un logiciel.
Ici également, supposons que nous découpions nos activités en projet précis :
- Mise à jour du logiciel ou des logiciels
- Mise à jour du système d’exploitation
- Mise à niveau du matériel
Très souvent, la mise à jour logicielle impliquera une mise à jour du système d’exploitation qui peut demander une mise à niveau du matériel.
Nous avons donc des dépendances technologiques qui impliquent des dépendances de planning.
Si la mise à jour du matériel s’avère nécessaire, vous aurez des dépendances liées aux achats et à la livraison.
Lorsque vous mettez à jour plusieurs logiciels, vous avez des contraintes de fonctionnement.
Ces derniers font que certains logiciels devront être mis à jour en même temps, d'autres en séquence, afin de minimiser le temps d’interruption pour les utilisateurs.
D’un point de vue ressources, toutes vos équipes ont des tailles fixes.
Et il sera nécessaire de séquencer la mise à jour du système d’exploitation par exemple, vu qu’il n’est pas possible de le faire sur tous les serveurs en même temps.
Conclusion
Aujourd’hui, peu de projets peuvent être considérés comme vraiment indépendants, « standalone ».
La plus grande dépendance est celle liée aux ressources humaines, peu de personnes étant allouées à 100% au projet. Cela implique régulièrement la création de risques dans ce sens.
Nous avons également très souvent des contraintes liées à l’accès aux systèmes, dépendances qui sont très fréquemment sous-estimées :
- Il n’est pas toujours possible d’effectuer plusieurs modifications sur un système, un produit en même temps, et tout cela doit être correctement coordonné.
Enfin les dépendances de planning sont également nombreuses, et idéalement devraient être gérés automatiquement, par l’intermédiaire des outils PPM à disposition.
