Scope Management PMP : tout ce que l’examen peut vous demander

Ce qu’il faut retenir en priorité pour l’examen

• Le chef de projet définit ce qui est inclus et ce qui ne l’est pas.
• Le périmètre doit être approuvé avant que le travail commence (ou à haut niveau en agile).
• Les exigences sont collectées auprès de tous les stakeholders, pas seulement du commanditaire.
• Le gold plating (ajouter des fonctionnalités non demandées) est interdit.
• Tout changement de périmètre est évalué pour son impact sur le planning, les coûts, les risques, la qualité et les ressources.
• La WBS est obligatoire dans les projets prédictifs.
• En agile, le périmètre est flexible mais le changement n’est pas gratuit.

Définitions essentielles

Périmètre produit (Product Scope)

Les fonctionnalités et caractéristiques du produit final. Répond à la question : “Qu’est-ce que le client veut ?” Mesuré par rapport aux exigences documentées.

Périmètre projet (Project Scope)

Tout le travail que l’équipe doit réaliser pour livrer le périmètre produit. Il inclut le périmètre produit, plus toutes les activités de planification et de gestion.

Itération (Sprint)

Période de temps fixe pendant laquelle l’équipe construit un incrément du produit. Si le travail n’est pas terminé dans le temps imparti, le reste est reporté au backlog.

Timebox

Durée fixe allouée à une itération. En agile, le temps est fixe, le périmètre est flexible.

MVP — Minimal Viable Product

Incrément de produit suffisamment complet pour être utilisé par le client, même si d’autres fonctionnalités sont encore à venir. Aussi appelé MMF (Minimal Marketable Feature).

Vue d’ensemble du processus de gestion du périmètre

Planification du périmètre

Le plan de management du périmètre

Artefact principal issu de la planification, il fait partie du plan de management du projet. Il décrit comment atteindre le périmètre, créer la WBS (ou le backlog en agile), gérer les changements et obtenir l’acceptation des livrables.

Le plan de management des exigences

Ce plan répond à trois questions fondamentales :

• Quelles techniques seront utilisées pour analyser et documenter les exigences ?
• Comment les exigences seront-elles analysées, priorisées et les changements gérés ?
• Que faut-il inclure dans la matrice de traçabilité des exigences ?

Planification agile : roadmap et backlog

Product roadmap : Représentation visuelle des grandes composantes du produit par release. C’est un outil de communication et de planification de haut niveau qui évolue avec le projet.

Product backlog : Liste unique et priorisée de tout le travail identifié pour le projet. Chaque story doit inclure la valeur métier, la définition de “done”, les critères d’acceptation et le stakeholder demandeur. Le product owner maintient la priorisation.

Collecter et analyser les exigences

Une exigence manquée peut entraîner des changements majeurs en cours de projet. L’effort de collecte est donc critique, surtout sur les grands projets avec de nombreux stakeholders.

Les exigences peuvent porter sur : les fonctionnalités produit, la qualité, les processus métier, la conformité réglementaire, les exigences de management de projet, ou les aspects environnementaux et sociaux.

Techniques verbales

Brainstorming

Génération d’idées en groupe sans évaluation pendant la phase de production. Les idées sont ensuite classées avec le nominal group technique ou le multicriteria decision analysis.

Interviews

Entretiens individuels ou en groupe. Permettent de recueillir des exigences détaillées sur un aspect spécifique du produit ou du projet.

Focus groups

Discussion dirigée par un modérateur avec un groupe sélectionné de stakeholders ou d’utilisateurs finaux.

Questionnaires et sondages

Adaptés aux grands groupes. Les questions sont construites pour cibler précisément des besoins.

Facilitation (JAD, QFD)

Réunit des stakeholders aux perspectives différentes pour converger vers une définition commune. Utilise une approche de consensus. Le QFD (Voice of the Customer) est utilisé en manufacturing.

Voting

Méthode de prise de décision en groupe. Attention : décider à la majorité peut marginaliser des stakeholders clés dont le vote est minoritaire.

Nominal group technique

Chaque participant écrit ses idées individuellement, les partage avec le groupe, discussion collective, puis classement par vote.

Observation

Job shadowing : suivre un utilisateur dans son travail pour identifier des besoins que l’interview seule ne révèle pas. Particulièrement utile pour les projets d’amélioration de processus.

Prototypes

Modèle du produit présenté aux stakeholders pour recueillir du feedback. Peut être mis à jour plusieurs fois avant de finaliser les exigences.

User stories

Format agile : “En tant que [rôle], je veux [fonctionnalité] afin de [bénéfice métier].”

Techniques graphiques

Mind maps

Représentation arborescente des idées à partir d’un concept central. Aide à générer, classer et enregistrer les exigences visuellement.

Context diagrams

Modélise les frontières du produit et ses interfaces avec les personnes, processus ou systèmes externes. Aide à définir ce qui est dans le produit et ce qui ne l’est pas.

Affinity diagrams

Regroupe les exigences par similitude. Facilite l’identification de zones de périmètre non encore couvertes et l’analyse des relations entre exigences.

Équilibrer et prioriser les exigences

Toutes les exigences ne peuvent pas toujours être satisfaites simultanément. Pour résoudre les conflits, les critères de référence sont : le business case, la charte projet, l’énoncé du périmètre, et les contraintes connues.

Documentation des exigences

Critères d’acceptation : Pour chaque exigence, la question clé est “Comment saurons-nous que le travail livré satisfait cette exigence ?” Ces critères évitent les malentendus coûteux en fin de projet.

Definition of done : Applicable à tous les types de projets. Précise à quel niveau d’avancement un livrable est “terminé” — au niveau de la story, de la release, et du produit final.

Matrice de traçabilité des exigences : Lie chaque exigence aux objectifs du projet et aux autres exigences. Permet de suivre l’origine, le statut et le responsable de chaque exigence tout au long du projet. Indispensable lors des demandes de changement.

Définir le périmètre

En approche prédictive

L’énoncé du périmètre projet (project scope statement) est l’artefact principal. Il précise explicitement :

• Ce qui est inclus dans le projet
• Ce qui n’y est pas inclus
• La liste des livrables
• Les critères d’acceptation
• Les hypothèses et contraintes

La product analysis est une méthode pour affiner la définition du périmètre en analysant les objectifs et la description du produit, via des techniques comme l’ingénierie de systèmes ou le value engineering.

En approche agile

Le périmètre est défini par progressive elaboration. Les stories de haut niveau sont décomposées en stories plus petites au fur et à mesure. Le timebox est la contrainte fixe ; le périmètre s’adapte pour maximiser la valeur dans le temps et le budget disponibles.

Créer la WBS — Décomposer le périmètre

Qu’est-ce que la WBS ?

La Work Breakdown Structure est un outil visuel représentant l’intégralité du périmètre, décomposé en livrables gérables appelés work packages. Sur la WBS, le travail désigne des livrables (des choses à produire), pas des activités (des actions à effectuer).

La WBS est obligatoire dans les projets prédictifs. Tout livrable qui n’est pas dans la WBS n’est pas dans le projet.

Règles de construction

• Construite avec l’équipe et les stakeholders (améliore l’adhésion).
• Chaque niveau est une décomposition du niveau précédent.
• Inclut l’intégralité du périmètre produit et du périmètre projet.
• On s’arrête de décomposer quand le work package peut être estimé, assigné, réalisé sans interruption et sous-traité si nécessaire.

WBS Dictionary

La WBS n’identifie chaque livrable qu’avec un ou deux mots. Le WBS dictionary fournit pour chaque work package le détail nécessaire : description, travail à effectuer, critères d’acceptation, dépendances, durée, coût et ressources. Il prévient le scope creep avant que le travail commence.

Scope baseline

La scope baseline regroupe trois artefacts : l’énoncé du périmètre, la WBS, et le WBS dictionary. Elle est approuvée à la fin de la planification. Tout changement après cette approbation passe par le processus de contrôle intégré des changements (Integrated Change Control).

Décomposition agile des stories

En agile, la décomposition suit quatre niveaux successifs :

1. Haut niveau (epics) : Objectifs ou exigences généraux identifiés au début du projet.
2. Fonctionnalités (features) : Créées à partir des exigences de haut niveau.
3. Stories : Fonctionnalités décomposées en éléments estimables et assignables.
4. Détails (just-in-time) : Règles métier, tests d’acceptation, tâches — définis juste avant la construction de la story.

Méthodes de décomposition : process-based, CRUD (Create/Read/Update/Delete), business rules, user/platform-based, acceptance tests, MoSCoW (Must/Should/Could/Would).

Valider et contrôler le périmètre

Valider le périmètre (Validate Scope)

La validation du périmètre est souvent mal comprise à l’examen. Ce n’est pas la vérification de la pertinence du périmètre en planification — c’est l’obtention de la signature formelle du client sur les livrables, pendant l’exécution du projet.

Le processus est répété tout au long du projet : les livrables vérifiés en interne (par Control Quality) sont présentés au client, qui les accepte ou émet des demandes de changement.

Prérequis avant de valider le périmètre : livrables vérifiés, scope baseline, plan de management du périmètre, plan de management des exigences, matrice de traçabilité, données de performance, rapports qualité.

Contrôler le périmètre (Control Scope)

Le contrôle est continu : mesurer la progression réelle par rapport à la scope baseline, détecter les écarts, gérer les changements de baseline.

Le scope creep — l’ajout non contrôlé de périmètre sans passer par le processus de gestion des changements — est le principal risque. La WBS et le WBS dictionary sont les outils clés pour le prévenir.

En agile, le contrôle s’appuie sur les burndown charts (travail restant) et les burnup charts (travail accompli). Les burnup charts ont l’avantage de rendre visibles les ajouts de périmètre en cours de projet.

Points clés pour l’examen PMP

• Validate Scope ≠ Control Quality. L’un est interne (qualité), l’autre est avec le client (acceptation).
• Decomposition ≠ WBS. La décomposition est l’action ; la WBS est l’outil et l’artefact.
• Deconstruction = Decomposition sur l’examen PMP.
• Le gold plating est toujours interdit, même si l’équipe pense que c’est une bonne idée.
• Tout changement de périmètre après approbation de la scope baseline passe par l’Integrated Change Control.
• En agile, le changement n’est pas gratuit : ajouter une fonctionnalité signifie réévaluer le backlog et potentiellement reporter d’autres items.
• Les besoins du client ont la priorité sur ceux des autres stakeholders en cas de conflit.
• Une exigence hors charte doit être refusée, même si elle semble légitime.

Tableau récapitulatif des artefacts

Basé sur Rita Mulcahy’s PMP® Exam Prep, 11e édition, aligné avec le PMBOK® Guide 7e édition et l’ECO (Examination Content Outline) en vigueur.