Dérive du périmètre : causes, exemples et comment l'éviter

Qu'est-ce que la dérive du périmètre ?

Dérive du périmètre est l'extension non maîtrisée du périmètre du produit ou du projet sans ajustement correspondant des délais, des coûts et des ressources. Elle se produit lorsque de nouvelles fonctionnalités, de nouveaux livrables ou de nouvelles tâches sont ajoutés après l'accord sur le périmètre, sans que personne n'évalue leur impact, ne les approuve formellement ou ne mette à jour le plan.

Le PMI utilise presque exactement cette définition dans son glossaire, et c'est un test utile : si du travail a été ajouté et que la référence de base du périmètre, le calendrier et le budget n'ont pas changé, vous êtes face à une dérive du périmètre.

Il est utile de distinguer deux types de périmètre. Périmètre du produit désigne les fonctionnalités et fonctions de ce que vous construisez, par exemple un site web avec recherche et paiement. Périmètre du projet désigne le travail nécessaire pour le livrer : conception, réalisation, tests, formation et lancement. La dérive peut toucher l'un ou l'autre. Un client qui demande un chat en direct étend le périmètre du produit ; un commanditaire qui demande à l'équipe de migrer en plus dix ans de données d'archives étend le périmètre du projet.

Le mot « dérive » est important. Un changement important unique est généralement remarqué et discuté. La dérive du périmètre, ce sont de nombreux petits changements, chacun trop mineur, semble-t-il, pour être formalisé : un rapport de plus, une série de révisions supplémentaire, une petite retouche de la page de connexion. Pris isolément, ils paraissent anodins ; ensemble, ils peuvent ajouter des semaines.

Elle est aussi fréquente. Le rapport *Pulse of the Profession* 2018 du PMI indiquait que 52 % des projets achevés au cours des 12 mois précédents avaient connu une dérive du périmètre, contre 43 % cinq ans plus tôt.

Notre guide du périmètre du projet explique comment bien définir le périmètre dès le départ.

Dérive du périmètre vs changement de périmètre, gold plating et inflation fonctionnelle

Tout changement de périmètre n'est pas une dérive. Les projets apprennent en avançant, et les changements approuvés qui apportent de la valeur font partie d'une bonne gestion de projet. La différence, c'est la maîtrise.

Gold plating est une forme de dérive du périmètre qui vient de l'équipe elle-même. Elle part généralement d'une bonne intention, mais consomme du temps et du budget, ajoute des risques et peut introduire des défauts dans des domaines que le client n'a jamais demandés. Inflation fonctionnelle est le terme du développement produit pour le même phénomène, centré sur le produit plutôt que sur le projet.

Quelles sont les causes de la dérive du périmètre ?

La dérive du périmètre a presque toujours plusieurs causes. Voici les plus fréquentes.

Un périmètre et des exigences flous

Si l' énoncé du périmètre est vague (« un site web moderne », « un reporting amélioré »), presque n'importe quelle demande peut être présentée comme faisant partie du périmètre. Des exigences et critères d'acceptation absents ou mal rédigés laissent place à l'interprétation, et cet espace a tendance à se remplir de travail supplémentaire.

Pas de maîtrise formelle des changements

Sans processus défini de maîtrise des changements , il n'existe pas de manière convenue de dire « oui, et voici ce que cela coûte ». Les demandes sont soit acceptées discrètement, soit refusées maladroitement, et les acceptations discrètes deviennent de la dérive.

Des parties prenantes qui contournent le chef de projet

Les demandes envoyées directement à un designer ou à un développeur par e-mail, par messagerie ou en réunion contournent le chef de projet. Le membre de l'équipe veut rendre service, fait le travail, et le plan n'en entend jamais parler.

Le gold plating et les bonnes intentions

Les équipes ajoutent parfois des fonctionnalités ou des finitions pour impressionner le client. Cela ressemble à un bon service, mais consomme du temps non prévu au plan et peut créer des attentes pour les projets futurs.

Des projets longs et des besoins métier qui évoluent

Plus un projet dure, plus l'entreprise qui l'entoure change : nouvelles réglementations, nouveaux concurrents, nouvelle direction. Certains de ces changements sont légitimes, mais ils doivent être évalués plutôt qu'absorbés.

Un parrainage faible et une pression commerciale

Un commanditaire qui ne s'implique pas dans les arbitrages laisse le chef de projet sans appui pour refuser. Sur un projet client, la crainte de contrarier le client (ou un contrat forfaitaire avec un cahier des charges vague) incite à absorber les demandes plutôt qu'à les signaler.

Exemples de dérive du périmètre

Ces exemples montrent à quoi ressemble la dérive du périmètre dans différents types de projets. Dans chaque cas, la demande initiale était raisonnable ; le problème est qu'elle n'a jamais été évaluée au regard du délai et du coût.

Exemple détaillé : comment les petites demandes s'additionnent

Imaginez un projet de site web de 12 semaines avec une date de lancement fixe. En six semaines, le client demande cinq « petites » choses, chacune acceptée de manière informelle :

• Une page d'atterrissage supplémentaire (3 jours).
• Une inscription à la newsletter connectée à sa plateforme d'e-mailing (2 jours).
• Une troisième série de révisions de la maquette de la page d'accueil (3 jours).
• La personnalisation du bandeau cookies (1 jour).
• L'import de 40 anciens articles de blog (4 jours).

Aucune de ces demandes ne semble importante isolément, mais ensemble elles ajoutent 13 jours ouvrés, près de trois semaines, à un plan de 12 semaines. Rien n'a changé dans le calendrier ni dans le budget : l'équipe fait des heures supplémentaires, les tests sont écourtés et le lancement est soit retardé, soit mis en ligne avec des défauts.

Faites maintenant passer les mêmes demandes par la maîtrise des changements. Chacune est consignée, son impact est présenté, et le client choisit : la page d'atterrissage et l'inscription à la newsletter sont approuvées avec une semaine de délai et un budget supplémentaires ; l'import du blog passe en phase 2 ; la série de maquettes supplémentaire est échangée contre une page moins prioritaire. Le projet s'agrandit toujours, mais de manière délibérée.

L'impact de la dérive du périmètre

La dérive du périmètre nuit aux projets en raison de la triple contrainte : périmètre, délai et coût sont liés. Si le périmètre augmente sans que les deux autres bougent, quelque chose d'autre cède, généralement la qualité ou l'équipe.

• Retards de calendrier : le travail supplémentaire repousse les jalons, et c'est souvent le chemin critique qui l'absorbe en premier.
• Dépassements budgétaires : plus d'effort, plus de matériaux et plus de coûts fournisseurs, sans budget pour les couvrir.
• Qualité dégradée : les tests, les revues et la documentation sont rognés pour tenir l'échéance.
• Épuisement de l'équipe : les membres font des heures supplémentaires sur un travail qui ne figure dans aucun plan, ce qui nuit au moral.
• Confiance entamée : les parties prenantes sont surprises quand les dates glissent, alors même qu'elles ont demandé les ajouts.
• Bénéfices retardés : la valeur essentielle du projet parvient aux utilisateurs plus tard qu'elle n'aurait pu.
• Reporting moins fiable : les pourcentages d'avancement perdent leur sens, car la référence de base ne reflète plus le travail réel.

Sur les projets commerciaux, il y a un coût supplémentaire : le travail non facturé. Les agences et cabinets de conseil qui absorbent la dérive du périmètre perdent de la marge sur chaque projet concerné.

Les signaux d'alerte de la dérive du périmètre

La dérive du périmètre se traite plus facilement lorsqu'elle est détectée tôt. Surveillez ces signaux :

• Des tâches apparaissent sur le tableau ou dans les feuilles de temps alors qu'elles ne figurent pas dans le structure de découpage du projet.
• Les demandes arrivent par e-mail, par messagerie ou en réunion, plutôt que par le circuit de réception convenu.
• Vous entendez des phrases comme « tant que vous y êtes », « ça ne devrait prendre que cinq minutes » ou « on pensait que c'était inclus ».
• Les critères d'acceptation sont réécrits après le début du travail.
• L'équipe fait des heures supplémentaires mais le calendrier ne montre aucun changement.
• Des livrables restent « presque terminés » pendant des semaines.
• La courbe du périmètre sur un burn-up chart ne cesse de monter, ou le backlog grossit plus vite que l'équipe ne livre.
• L'effort réel dépasse largement les estimations sur des tâches pourtant bien comprises.
• Des parties prenantes non impliquées dans la planification commencent à façonner la solution tard dans le projet.

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

La prévention consiste surtout à s'accorder clairement sur le périmètre et à convenir à l'avance de la manière dont les changements seront traités. Ces étapes fonctionnent sur les projets traditionnels et hybrides de toute taille.

1. Convenez d'objectifs clairs. Inscrivez des objectifs mesurables dans la charte de projet afin que chaque demande puisse être évaluée à leur aune : aide-t-elle à atteindre l'objectif ?
2. Recueillez correctement les exigences. Impliquez les personnes qui utiliseront le résultat, pas seulement celles qui le paient, et consignez les exigences avec leurs priorités.
3. Rédigez un énoncé du périmètre avec des exclusions. Listez ce qui fait partie du périmètre et, tout aussi important, ce qui n'en fait pas partie. Les exclusions évitent la conversation « on pensait que c'était inclus ».
4. Décomposez le travail. Créer un structure de découpage du projet et un dictionnaire du WBS afin que l'ensemble du périmètre soit visible et que chaque livrable dispose d'une définition.
5. Définissez les critères d'acceptation. Pour chaque livrable, convenez de la manière dont vous saurez qu'il est terminé. Déplacer les critères d'acceptation est l'une des formes les plus discrètes de dérive du périmètre.
6. Obtenez une validation et fixez une référence de base. Faites approuver l'énoncé du périmètre, le WBS et le dictionnaire du WBS par le commanditaire ou le client. Ensemble, ils forment la référence de base du périmètre à laquelle vous mesurerez les changements.
7. Mettez en place la maîtrise des changements avant d'en avoir besoin. Convenez de la manière dont les demandes sont consignées, de qui les évalue, de qui les approuve et de la manière dont le plan est mis à jour. Restez léger sur les petits projets.
8. Créez un circuit de réception unique. Demandez aux parties prenantes d'adresser toutes leurs demandes au chef de projet ou via un formulaire, et demandez à l'équipe de rediriger poliment les demandes reçues par des canaux parallèles.
9. Communiquez régulièrement. Adoptez un rythme régulier de rapports d'avancement et de revues pour que les parties prenantes voient l'avancement et se sentent écoutées, ce qui réduit les demandes informelles.
10. Inscrivez les conditions de changement dans les contrats. Sur un projet client, l'énoncé des travaux doit préciser comment les changements sont demandés, chiffrés et approuvés.

Le modèle de périmètre de projet couvre les objectifs, les livrables, ce qui est inclus et exclu, les critères d'acceptation, les contraintes et les hypothèses, soit l'essentiel du travail préparatoire ci-dessus en un seul document.

La maîtrise des changements est le contrôle le plus important de cette liste.

Comment gérer la dérive du périmètre quand elle survient

Même les projets bien planifiés reçoivent de nouvelles demandes. L'objectif n'est pas de refuser le changement, mais de rendre chaque changement visible et délibéré.

Réponse étape par étape à une nouvelle demande

1. Prenez le temps avant d'accepter. Remerciez la personne et indiquez que vous allez en examiner l'impact. Évitez un oui ou un non immédiat.
2. Consignez-la. Enregistrez la demande dans un registre des changements ou un modèle de demande de modification : ce qui est demandé, par qui et pourquoi.
3. Comparez-la à la référence de base. Est-elle vraiment nouvelle, ou déjà couverte par une exigence ou un critère d'acceptation existant ?
4. Évaluez l'impact. Estimez l'effet sur le calendrier, les coûts, les ressources, la qualité et les risques. Impliquez les personnes qui réaliseraient le travail.
5. Préparez des options. Présentez des choix réalistes plutôt qu'une réponse unique (voir le tableau ci-dessous).
6. Obtenez une décision de la bonne personne. C'est le commanditaire, le client ou le comité de contrôle des changements qui décide, pas le membre de l'équipe qui a reçu la demande.
7. Mettez à jour le plan. En cas d'approbation, mettez à jour l'énoncé du périmètre, le WBS, le calendrier, le budget et le registre des risques, puis redéfinissez la référence de base.
8. Communiquez la décision. Informez le demandeur, l'équipe et les autres parties prenantes de ce qui a été décidé et de ce que cela change.

Comment dire non (ou « oui, et ») à une partie prenante

Opposer un refus catégorique peut abîmer les relations, en particulier avec les clients et les parties prenantes de haut niveau. Il est généralement plus efficace de montrer l'arbitrage et de laisser le décideur choisir :

Centrez la conversation sur les objectifs du projet plutôt que sur les préférences personnelles, et consignez la décision par écrit. Notre guide de la gestion des parties prenantes explique comment mener ces conversations avec différents types de parties prenantes.

La dérive du périmètre dans les projets agiles

Les approches agiles s'attendent à ce que le périmètre change. Cela ne signifie pas que les équipes agiles sont à l'abri de la dérive du périmètre ; cela signifie que le changement est traité différemment.

Dans Scrum, tout le travail connu figure dans le Product Backlog, que le Product Owner ordonne. Selon le Scrum Guide 2020, aucun changement mettant en danger le Sprint Goal n'est effectué pendant un Sprint, et le périmètre peut être clarifié et renégocié avec le Product Owner à mesure que l'on en apprend davantage. Les nouvelles idées vont donc dans le backlog, pas directement chez un développeur, et sont intégrées à un futur Sprint lors du Sprint Planning si elles ont suffisamment de valeur.

Le délai et le coût sont généralement fixes par itération, et le périmètre est la variable. La dérive du périmètre en agile prend une autre forme que dans un projet traditionnel :

• Des parties prenantes qui demandent aux développeurs de glisser du travail dans le Sprint en cours.
• Des Sprint Goals régulièrement manqués parce que du travail non planifié est intégré en cours de Sprint.
• Un backlog qui grossit sans être ordonné ni affiné, si bien que rien n'est jamais dépriorisé.
• Une date de release et une liste complète de fonctionnalités toutes deux considérées comme figées.
• La notion de « Done » qui évolue discrètement, faute d'une véritable Definition of Done.

Un burn-up chart avec une courbe de périmètre distincte rend cela visible : si la courbe du périmètre monte aussi vite que celle du travail terminé, la date de release ne sera jamais atteinte. Le suivi de la vélocité aide aussi ; consultez notre guide du Graphique de vélocité agile.

Outils et modèles pour maîtriser le périmètre

Pas besoin de logiciel spécialisé pour maîtriser le périmètre, mais quelques documents facilitent grandement les choses :

• Modèle de périmètre de projet : objectifs, livrables, inclusions, exclusions, critères d'acceptation, contraintes et hypothèses.
• Modèle de demande de modification : un formulaire de demande de modification et un registre des changements avec l'impact sur le périmètre, le calendrier et les coûts.
• modèle de WBS : codes WBS, niveaux, livrables, responsables, effort et coût.
• Modèle de registre RAID : risques, hypothèses, problèmes et dépendances, y compris les hypothèses dont dépend le périmètre.
• Modèle de document d'exigences métier : exigences et priorités convenues avant la réalisation.

Un logiciel de gestion de projet est utile lorsque les demandes viennent de nombreuses personnes. Les formulaires de demande, les workflows d'approbation et une référence de base visible réduisent le travail réalisé par des canaux parallèles. Notre outil classé n° 1, Wrike, convient bien aux équipes qui veulent des formulaires de demande structurés et des approbations sur plusieurs projets ; d'autres outils le font bien aussi, comme l'expliquent nos classements des logiciels de gestion de projet .

Erreurs courantes à éviter

• Considérer tout changement comme mauvais. Refuser toutes les demandes frustre les parties prenantes et peut conduire le projet à livrer quelque chose dont personne n'a besoin. Maîtrisez le changement ; ne le bloquez pas.
• Accepter des approbations verbales. Ce qui n'est pas écrit sera retenu différemment plus tard.
• Ignorer les petits changements. L'exemple détaillé ci-dessus montre comment de petites demandes non consignées deviennent des semaines de travail.
• Omettre les exclusions. Un énoncé du périmètre sans liste de ce qui est hors périmètre ouvre la porte aux suppositions.
• Laisser l'équipe faire du gold plating. Saluez l'intention, mais réorientez les idées supplémentaires vers des demandes de modification ou le backlog.
• Approuver des changements sans redéfinir la référence de base. Si le plan n'est pas mis à jour, les rapports d'avancement deviennent trompeurs.
• Rendre le processus trop lourd. Un formulaire de dix pages pour un changement d'une journée incite à le contourner. Adaptez le processus à l'ampleur du changement.

Pour une vue d'ensemble de ce qui distingue la maîtrise des changements de la conduite du changement organisationnel, lisez conduite du changement vs maîtrise des changements.

Modèles gratuits sur ce sujet

Parcourir tous les modèles

Questions fréquentes