Qu’est-ce que la dérive du périmètre et comment la gérer efficacement

La dérive du périmètre peut affecter tout projet au périmètre défini. Elle peut se produire intentionnellement ou non et provenir de n'importe quelle partie prenante impliquée dans un projet. La dérive du périmètre peut entraîner l'échec du projet en vous faisant manquer une échéance, en épuisant (ou en dépassant) le budget à cause de surcoûts et, qui plus est, en vous amenant tout de même à livrer le mauvais résultat.

Dirigez plus intelligemment à l'ère de l'IA

Rejoignez la communauté DPM pour accéder à du contenu exclusif, des modèles pratiques, des événements réservés aux membres et des conseils hebdomadaires en leadership – l'inscription est gratuite.

Get Free Access

Have an account? Log In

10 causes courantes de la dérive du périmètre

La dérive du périmètre survient généralement lorsque les exigences du projet ne sont pas clairement définies, que les parties prenantes introduisent de nouvelles demandes ou que les équipes apportent des changements sans en évaluer l'impact. Bien que les clients soient souvent tenus pour responsables, les chefs de projet, les membres de l'équipe et les dépendances externes peuvent tous y contribuer.

Voici les causes les plus courantes de la dérive du périmètre et ce que vous pouvez faire pour les prévenir :

• Exigences floues ou mal documentées : Lorsque les livrables, les limites et les critères d'acceptation ne sont pas clairement définis, les membres de l'équipe et les parties prenantes se font des idées différentes de ce qui est inclus. Créez un énoncé du périmètre du projet et vérifiez que tout le monde a la même compréhension avant le début des travaux.
• Évolution des priorités des parties prenantes : Les clients, les sponsors et les parties prenantes internes peuvent demander des fonctionnalités supplémentaires ou changer de direction lorsque les priorités de l'entreprise évoluent. Documentez les décisions importantes et évaluez la façon dont les changements proposés affectent le calendrier, le budget et les livrables avant de les approuver.
• Absence de processus formel de contrôle des changements : Sans processus d'approbation clair, de petites demandes peuvent intégrer le projet sans que personne n'évalue leur impact cumulé. Établissez un processus pour soumettre, évaluer, approuver et documenter les changements de périmètre. Assurez-vous que chacun sait qui détient le pouvoir d'approbation.
• Mauvaise communication et manque d'alignement de l'équipe : Les membres de l'équipe peuvent prendre des décisions indépendamment ou mal comprendre les exigences, ce qui introduit des travaux qui n'étaient pas prévus initialement. Organisez une réunion de lancement du projet et des points de suivi réguliers afin de clarifier les attentes et de signaler les changements potentiels.
• Ajout de fonctionnalités superflues : Les membres de l'équipe ajoutent parfois des fonctionnalités ou des améliorations inutiles parce qu'ils pensent ainsi livrer un meilleur produit. Même les ajouts bien intentionnés consomment du temps et des ressources. Réaffirmez les exigences convenues et exigez une approbation avant d'ajouter des fonctionnalités.
• Estimations et engagements irréalistes : Des estimations trop optimistes peuvent amener les équipes à promettre plus que ce que leur budget, leurs ressources ou leur calendrier peuvent permettre. Impliquez les personnes qui réaliseront le travail dans l'estimation de l'effort, tenez compte des incertitudes et remettez en question les hypothèses avant de vous engager sur les livrables.
• Implication insuffisante des parties prenantes : Lorsque les décideurs ou les utilisateurs finaux ne sont pas impliqués suffisamment tôt, des exigences importantes peuvent apparaître après le début du développement. Identifiez les principales parties prenantes lors de la planification et validez les exigences au moyen de revues, d'ateliers ou de tests utilisateurs avant le début des travaux majeurs.
• Dépendances envers des tiers non gérées : Les fournisseurs, les sous-traitants, les API externes et les fournisseurs de contenu peuvent introduire des exigences imprévues ou du travail supplémentaire. Par exemple, un fournisseur peut fournir des données dans un format incompatible. Identifiez rapidement les dépendances, convenez des spécifications des livrables et tenez compte des problèmes d'intégration potentiels.
• Gestion de projet et responsabilisation insuffisantes : Les chefs de projet acceptent parfois du travail supplémentaire pour préserver les relations avec les clients ou éviter les conversations difficiles. J'ai constaté que de petites concessions non documentées peuvent rapidement devenir des attentes. Suivez les changements, expliquez leur impact et proposez des compromis plutôt que d'absorber du travail supplémentaire.
• Contraintes ou découvertes techniques imprévues : Les systèmes existants, les limites d'intégration ou les exigences techniques négligées peuvent créer du travail qui n'avait pas été anticipé lors de la planification. Effectuez rapidement une analyse technique, validez les principales hypothèses et faites la distinction entre les travaux correctifs nécessaires et les améliorations facultatives avant de modifier le périmètre.

Exemples de dérive du périmètre

La dérive du périmètre peut se produire lorsque les parties prenantes introduisent de nouvelles demandes ou que des dépendances imprévues créent du travail supplémentaire. Ces deux exemples hypothétiques montrent comment la dérive du périmètre se développe, son impact sur les projets et la manière d'y remédier.

Exemple 1 : demandes des parties prenantes pendant les tests utilisateurs

Votre équipe effectue des tests utilisateurs pour le prototype d’un nouveau site web. Le client a approuvé une période de test de deux semaines avec 10 participants et un budget de $5,000.

Après la clôture des tests, un cadre dirigeant demande une présentation distincte et invite cinq parties prenantes supplémentaires. Vous acceptez de les intégrer sans évaluer officiellement l’impact.

	Ce qui s’est passé
Cause	Des parties prenantes supplémentaires ont fourni des commentaires après la période de test convenue.
Impact	Les présentations supplémentaires, l’examen des commentaires et les discussions avec les parties prenantes ont ajouté 40 heures de travail et retardé le projet de 1,5 semaine.
Résolution	Le chef de projet a documenté les demandes supplémentaires et en a présenté l’impact au client. Les deux parties ont convenu de reporter les nouvelles demandes de fonctionnalités à une phase ultérieure et de limiter les examens supplémentaires au périmètre initial.
Leçon tirée	Établissez des échéances claires pour les commentaires, des limites concernant le nombre de participants et des exigences d’approbation. Faites remonter les exceptions avant de vous engager à mobiliser des ressources supplémentaires.

Exemple 2 : dépendances tierces non gérées

Vous gérez un projet de développement de site web doté d’un budget de $100,000 et d’un calendrier de 12 semaines. Votre équipe construit l’interface utilisateur en utilisant la partie serveur d’une autre agence.

Le développement commence après l’approbation de la conception, mais l’agence tierce continue de publier des mises à jour de la partie serveur. Ces changements interrompent régulièrement le fonctionnement du code de votre équipe, entraînant des reprises imprévues.

	Ce qui s’est passé
Cause	L’agence tierce a apporté des modifications continues à la partie serveur sans coordonner les mises en production avec votre équipe de développement.
Impact	Les corrections répétées ont ajouté 200 heures de travail imprévu, augmenté les coûts de $20,000 et menacé de retarder la livraison de huit semaines.
Résolution	Le chef de projet a suspendu les travaux de développement concernés et négocié un calendrier partagé de mises en production avec les deux agences. Le client a approuvé une demande de modification de $10,000 ainsi qu’une prolongation de deux semaines. Les deux équipes ont convenu de geler la version de la partie serveur jusqu’au lancement, évitant ainsi de nouvelles reprises.
Leçon tirée	Identifiez rapidement les dépendances externes, convenez de calendriers de mise en production et établissez un processus de contrôle des changements. N’absorbez pas les reprises continues sans évaluer leur impact sur les coûts et les délais du projet.

Comment éviter la dérive du périmètre

Voici quelques stratégies pour réduire le risque de dérive du périmètre dans vos projets :

• Définissez clairement le périmètre du projet : Faites-le dès le début, en impliquant idéalement l’équipe projet afin d’obtenir son adhésion. Utilisez un cahier des charges pour préciser ce qui relève ou non du périmètre. Communiquez ensuite le périmètre aux membres de l’équipe et aux parties prenantes du projet, y compris au client.
• Établissez des estimations solides fondées sur les exigences : Pour réduire le risque d’erreur d’estimation, impliquez toute l’équipe, prévoyez une période de découverte pour déterminer ce que vous allez construire, utilisez un contrat en temps et matériaux (plutôt qu’à prix fixe) et soyez moins prescriptif concernant les fonctionnalités que vous allez développer. Concentrez-vous sur les résultats attendus.
• Prévoyez des plans d’urgence : Mettez de côté une réserve réaliste de temps et de budget pour les problèmes imprévus (par exemple, les problèmes techniques, les retards de tiers et les reprises). Identifiez les activités à haut risque pendant la planification et préparez des solutions de repli. Les réserves pour imprévus permettent de gérer les travaux inattendus sans faire dérailler le projet, mais ne doivent pas servir à absorber des changements de périmètre non approuvés.
• Créez un plan de gestion des changements : Faites-le au début du projet et utilisez-le pour définir la manière dont vous gérerez les changements de périmètre. Si vous prévoyez d’utiliser des demandes de modification, détaillez le processus de contrôle des changements que vous suivrez.
• Collaborez avec le client : Tout au long de l’exécution du projet, présentez-lui l’avancement du projet ou le rapport d’état du projet, procédez par itérations et impliquez-le tout au long du parcours afin d’éviter les mauvaises surprises.
• Signalez les problèmes de manière proactive : Faites-le lorsqu’ils surviennent ou, idéalement, avant qu’ils ne surviennent (à condition d’avoir trouvé une solution pour y remédier !). Utilisez un plan de gestion des risques pour documenter votre processus de gestion des risques. Tenez à jour et examinez un registre des risques qui recense les risques potentiels.
• Donnez la priorité aux demandes entrantes : Assurez-vous que ces demandes n’ajoutent pas involontairement du périmètre, ne dupliquent pas le travail ou ne conduisent pas à développer des fonctionnalités supplémentaires inutiles. Échangez avec l’équipe pour comprendre chaque demande, son impact sur le budget et le calendrier du projet, ainsi que le résultat attendu pour l’utilisateur, afin de pouvoir établir les priorités en conséquence.

Comment remédier à la dérive du périmètre

Si votre projet est victime d’une dérive du périmètre (ou si vous avez hérité d’un projet dont le périmètre est excessif), pas de panique. Vous avez encore la possibilité de vous sortir de cette situation. 

Voici quelques étapes que j’ai suivies en reprenant un projet en difficulté victime d’une dérive du périmètre :

• Expliquer la situation : Expliquez comment vous en êtes arrivé là et quels sont vos plans de redressement pour remédier à la situation. Inutile de chercher à enjoliver les choses. La situation est ce qu’elle est.
• Recommander des moyens de réduire les dépenses tout en préservant la valeur : Cela peut signifier donner une moindre priorité à certaines fonctionnalités ou faire des compromis sur les éléments « agréables à avoir » jusqu’à pouvoir publier rapidement une version de suivi. Préparez pour votre client une présentation qui expose clairement les compromis associés à chacune de vos approches.
• Ajuster la taille de l’équipe : Cela peut impliquer de se séparer d’une personne dont les performances sont insuffisantes ou de remplacer une ressource plus coûteuse par une ressource moins coûteuse afin de respecter le budget. Ces conversations sont désagréables, mais l’alternative peut être de perdre votre client, ce qui aurait des conséquences bien plus importantes.
• Gérer les conséquences : Parfois, redresser un navire qui coule exige de ravaler sa fierté et de sacrifier la rentabilité globale du projet pour réparer une relation précieuse avec un client. Il peut être nécessaire de consacrer des heures supplémentaires à la finalisation d’un livrable plus tôt que prévu afin de réparer les torts. L’essentiel est de limiter cet effort à une initiative ponctuelle et à court terme, afin qu’il ne devienne pas une mauvaise habitude.

Author's Tip

Parfois, la dérive du périmètre peut être bénéfique. Plutôt que de la considérer comme un ennemi sournois, vous pouvez la voir comme un changement. Et le changement peut être extrêmement bénéfique pour le produit que vous concevez. Ce n’est pas la demande de changement qui affecte le projet, mais la manière dont vous gérez ce changement.

 

Vous devez veiller à la repérer lorsqu’elle survient, surtout lorsqu’elle n’est pas évidente, et à la signaler avant qu’elle ne progresse sans aucune forme de replanification.

FAQ sur la dérive du périmètre

Les réponses à certaines de vos questions les plus fréquentes sur la dérive du périmètre.

Quelle est la différence entre une dérive du périmètre et un changement de périmètre ?

La dérive du périmètre désigne l’ajout incontrôlé d’exigences au projet sans ajustement correspondant du budget, du calendrier ou des ressources. Le changement de périmètre est une modification délibérée et documentée, examinée et approuvée dans le cadre d’un processus de contrôle des changements. La principale différence réside dans l’autorisation. Les changements de périmètre peuvent être nécessaires et bénéfiques, tandis que la dérive du périmètre introduit du travail imprévu qui met en péril la livraison du projet.

Comment identifier rapidement une dérive du périmètre dans un projet ?

Soyez attentif aux signes avant-coureurs tels que les demandes de fonctionnalités supplémentaires, les changements non documentés, l’allongement des listes de tâches et le travail qui dépasse les estimations initiales. Comparez régulièrement l’avancement du projet à la référence approuvée de son périmètre. Je vous recommande de consigner toutes les nouvelles demandes dans un journal des changements et de les examiner lors des points d’équipe. Cela vous aide à repérer les petits ajouts avant qu’ils ne provoquent des retards importants ou des dépassements de budget.

Comment gérer une dérive du périmètre lorsqu’un client demande du travail supplémentaire ?

Commencez par évaluer l’impact de la demande sur les livrables, les coûts et les délais du projet. Expliquez ces impacts à votre client et proposez-lui plusieurs options. Vous pouvez suggérer une demande de changement officielle, remplacer un livrable existant par la nouvelle exigence ou reporter le travail à une phase ultérieure. Quelle que soit votre décision commune, documentez-la et mettez à jour le plan du projet avant de poursuivre.

Comment gérer le périmètre dans une approche Agile ?

Les projets Agile permettent de prendre en compte l’évolution des exigences, mais vous devez tout de même contrôler la quantité de travail à laquelle votre équipe s’engage. Dans Scrum, ajoutez les nouvelles demandes au carnet de produit et travaillez avec le responsable produit pour les classer par priorité en fonction de leur valeur et de l’effort nécessaire.

Si une nouvelle exigence devient prioritaire, envisagez de donner une moindre priorité à un autre élément plutôt que d’ajouter du travail. Lors de la planification du sprint, assurez-vous que les engagements correspondent à la capacité de votre équipe.

Et maintenant ?

Vous souhaitez échanger avec d’autres chefs de projet numériques pour partager des ressources et des bonnes pratiques ? Rejoignez notre communauté de membres et bénéficiez d’un accès à plus de 100 modèles, exemples et échantillons, et échangez sur Slack avec des centaines d’autres chefs de projet numériques.