PMI®, PMP®, PMBOK® Guide and CAPM® are either marks or registered marks of Project Management Institute, Inc.
Copyright © STS Sauter Training & Simulation SA, Lausanne, Switzerland
Planifier le management du contenu
Théorie
Les principes clés en bref:

Après avoir identifié les principaux livrables et décrit les objectifs du projet dans la Charte de projet, le moment
est venu d’affiner le contenu du projet.

Avant d’agir, planifions!

Avant d’analyser le contenu, planifier la façon de procéder à l’analyse du contenu est un pas important vers
l’efficacité et le succès.

Le profil du projet, les aptitudes de l’organisation et la sensibilité du commanditaire à l’égard des activités
définissant le contenu influenceront la façon dont le contenu sera géré.

Profils de projet

On considère habituellement quatre catégories de projet principales, selon la complexité de l’organisation et le

niveau de définition du contenu.

Approche de la définition du contenu:

Approche en cascade ("waterfall")

Pour les projets qui ont un niveau de définition détaillé, une approche “waterfall” convient car le contenu peut être
détaillé et analysé.
Seuls des projets de ce type peuvent être contraints par le contenu, les ressources et la durée étant déterminées
en fonction du contenu désiré.

Les projets opérationnels et les projets de complexité classique peuvent souvent être gérés de cette façon.

Élaboration progressive (ou par vagues)

Lorsque le contenu ne peut pas être entièrement déterminé ou détaillé au cours du processus de planification, on
peut envisager une approche de la planification du contenu en plusieurs vagues successives.

L’objectif de la première vague est de fournir une analyse, une démonstration de faisabilité, un prototype ou une
étude de faisabilité qui seront utilisés pour planifier la seconde phase du projet.

Dans ce cas, le contenu n’est pas déterminé au cours de la première “vague” ou de la première phase du projet,
mais il demeure la contrainte principale, les ressources et la durée étant déterminées en fonction du contenu
analysé.

Les projets de complexité classique ou les projets d’innovation sont gérés de la sorte.

Approche itérative

On peut aussi bien utiliser l’approche itérative lorsque, au tout début du projet, le contenu n’est pas déterminé ou
pas encore détaillé, ou lorsque le contenu n’est pas une contrainte majeure du projet

Lorsque l’on utilise l’approche itérative, les contraintes sont liées aux ressources ou aux délais. Le contenu sera le
meilleur que l’on puisse fournir compte tenu de la charge et des délais. Cette approche est très indiquée lorsque
l’on doit éviter de faire de la dorure sur tranche, ou encore lorsqu’il faut effectuer de fréquentes analyses de la
valeur du projet pour confirmer la poursuite du projet.

On peut adopter cette approche pour les projets d’innovation ou les projets pionniers.

Les méthodes Agile comportent des approches itératives, avec un accent tout particulier sur l’implication du client.

La catégorie du projet ou ses caractéristiques, ainsi que l’approche sélectionnée sont présentées dans le Plan de
management de projet.

Éléments additionnels du plan de management de projet

Deux aspects majeurs du plan de management de projet sont utilisés par le commanditaire, le chef de projet, et
d’autres parties prenantes clés du projet pour répondre aux questions suivantes:
Littérature:

Vous trouverez des informations complémentaires concernant ce sujet dans les ouvrages suivants:

PMBOK® Guide - Cinquième Édition 5.0 Planifier le management du contenu

Comment faire
Comment élaborer un plan de management du contenu:

1. Déterminez les caractéristiques du projet qui vont influencer le management du contenu.

2. Négociez l’approche du projet avec les membres de l’équipe de projet et avec le commanditaire.
3. Avec le PMO (Project Management Office ou Bureau des Projets), ou en utilisant l’expérience du passé,
sélectionnez les processus, les modèles et les outils qui seront utilisés par les membres de l’équipe de
projet pour collecter les exigences du projet et en décomposer le contenu.
 Exemple
La Banque Alpha a démarré un projet visant à fournir aux utilisateurs de téléphone mobile des fonctions de micro-
paiement, avec un contrôle de crédit en ligne et un débit direct.

Afin d’analyser le contenu du projet, les membres de votre équipe de projet recommandent de développer tout
d’abord un prototype avec un fabricant de carte SIM, et d’évaluer ensuite les données de sortie afin de vérifier la
faisabilité et de réévaluer l’étude économique.

Ce projet est une initiative pionnière qui pourrait modifier la façon dont on utilise un téléphone portable.

Il a été décidé d’utiliser la planification par vagues pour affiner le contenu. Le prototype constituera la première
"vague", un test utilisateur en réel fera l’objet d’une seconde "vague", et le service sera finalement développé en
fonction des données de sortie des deux premières "vagues".

Check-list
□ Avez-vous examiné les expériences antérieures qui se sont bien passées? Réutilisez-les de façon à faire
accepter plus facilement votre plan de management du contenu.
□ Avez-vous impliqué les membres de votre équipe de projet pour évaluer l’approche globale?
□ Avez-vous accès à un PMO ou à un département Qualité pour vous inspirer de processus existants pour
développer votre plan de management du contenu?

Pièges!

 N’établissez pas un plan de management du contenu tout seul; ce serait plus difficile de le faire accepter.
 Adaptez les processus en fonction des besoins de votre projet. Une taille unique ne convient pas dans tous
les cas!
Recueillir les exigences
Théorie
Les principes clés en bref:

L’identification des exigences des parties prenantes est l’une des toutes premières activités de planification dans la
plupart des projets.

Cela consiste à enregistrer les souhaits et attentes quant aux livrables du projet.

A ce stade, les discussions et autres entrevues sont très ouvertes et ne sont limitées que par les objectifs définis
dans la charte du projet.

L’enregistrement des exigences est réellement une activité fondamentale pour le projet: c’est le seul moyen pour
l’équipe projet de piloter l’avancement et l’achèvement du contenu du projet.

Tout comme les objectifs, les exigences doivent être:

 Spécifiées (et non pas vagues) et suffisamment détaillées: plusieurs itérations peuvent être nécessaires
pour atteindre le bon niveau de détail.
 Mesurables: l’équipe doit être en mesure de savoir si une exigence est remplie ou non.
 Acceptables: les principales parties prenantes doivent être d’accord sur les exigences.

L’équipe en charge de recueillir les exigences doit établir les relations entre les exigences et les objectifs du projet,
les livrables et les conditions de test. Ceci est réalisé à l’aide d’une matrice de traçabilité des exigences. Une telle
matrice sera mise à jour en aval pour garder la traçabilité des exigences dans la conception de la solution et dans
les scénarios de tests.

Une telle matrice assure que, une fois le livrable accepté, les exigences sont satisfaites.Elle a son importance
également quand l'équipe de projet veut négocier ou modifier le contenu du projet: les exigences concernées sont
alors facilement identifiables.

Lorsque la définition des exigences est trop difficile (c’est le cas lors de projets très innovants ou utilisant des
technologies nouvelles), il peut être plus sage de développer un prototype afin d’aider les parties prenantes à se
faire une idée.

Le chef de projet va se focaliser sur trois objectifs:

1. Lister les exigences.

2. Gérer les attentes des parties prenantes (s’assurer que la liste des exigences ne s’allonge pas inutilement,
que les attentes essentielles sont prises en compte et traitées).
3. Obtenir un accord et une compréhension commune entre l’équipe projet et les utilisateurs/clients du
produit/service.

Pour plus d’informations sur le sujet:

Exigences et contenu du projet

Littérature:

Pour plus d’informations, nous vous recommandons de lire l’ouvrage suivant:

PMBOK® Guide - Cinquième Édition 5.1 Recueillir les exigences

Comment faire
Exigences et contenu du projet

Lorsque l’on définit le contenu du projet, les besoins, attentes et souhaits des parties prenantes doivent être
traduits en exigences mesurables.

Les exigences définissent quelles caractéristiques le projet ou le produit doit avoir. Elles sont neutres vis-à-vis
des solutions, ce qui signifie qu’elles ne disent pas le comment.

Toutes les parties ayant un intérêt dans le projet, les arties prenantes, doivent arriver à un accord sur les
exigences, ce qui s’avère souvent difficile au vu des intérêts possiblement contradictoires de chacun.

Comment mener la définition des exigences:

Le chef de projet doit clarifier les exigences de façon proactive et en temps opportun. Il doit s’assurer que toutes
les parties prenantes sont complètement en accord sur le contenu du projet. Le commanditaire (maître d’ouvrage)
procède aux arbitrages ultimes lorsque c’est nécessaire. Le commanditaire est responsable de s’assurer de la
représentation des utilisateurs finaux ou des clients dans le projet.

Il existe certaines techniques pour mener à bien la définition des exigences:

Interviewez les principales parties prenantes, auparavant identifiées, sur les objectifs du projet.

 Comment peut-on atteindre chacun des objectifs

 Quelle est l’importance de chaque exigence pour l’atteinte des objectifs?

Mettez en œuvre des techniques de créativité, comme par exemple:

 Atelier (réunir les parties prenantes qui vont utiliser le produit/service et l’équipe projet qui va le
développer)
 Brainstorming (enregistrer toutes les idées des parties prenantes)
 Méthode de Delphes (envoyer des questionnaires individuels à plusieurs experts et consolider les
réponses)
 Mind Mapping (à partir du centre d’intérêt principal, développer un arbre portant des listes d’exigences de
plus en plus détaillées)

S’il existe des exigences explicites, claires et bien formulées, alors procédez comme suit:

 Vérifiez que les exigences ne sont pas contradictoires entre elles. Si c’est le cas, reformulez-les.
  Vérifiez, conjointement avec l’équipe projet, le client et les autres parties prenantes, que tout le monde est
d’accord sur les exigences. Prenez le temps nécessaire pour le faire!
 N’oubliez pas les contraintes (par exemple: ne pas dépasser un certain budget): les contraintes sont aussi
des exigences!
 Formulez les exigences de la manière la plus précise qui soit, jusqu’à ce qu’elles soient clairement
mesurables et vérifiables. Relevez toutes les hypothèses et formulez les critères d’acceptation.
 Vérifiez si les exigences sont écrites sur un mode neutre et si elles permettent différentes solutions
techniques. Le "quoi" ne doit pas déterminer le "comment".
 Pour éviter les malentendus, notez explicitement ce qui n’est pas inclus dans le projet.
 Définissez les priorités entre les exigences. Faites la distinction entre ce qui est vraiment nécessaire et ce
qui est seulement souhaitable.

Si les exigences sont plutôt vagues, imprécises ou mal formulées, veuillez procéder comme suit:

 Essayez de déterminer les besoins qui se cachent derrière les formulations ou de comprendre les
problèmes sous-jacents.
 Formulez les exigences vous-même, en premier lieu. Ensuite discutez-en avec les parties prenantes du
projet, jusqu’à ce que tout le monde soit d’accord.
 Poursuivez alors selon les points décrits plus haut.

Une fois que les exigences sont correctement formulées et bien définies:

Classifiez les exigences:

 Exigences du projet (exigences de management du projet, exigences organisationnelles, exigences

relatives à la communication et à la documentation, etc.)
 Exigences du produit (exigences relatives aux affaires, exigences fonctionnelles et techniques, exigences
relatives à la qualité, etc.)

Établissez une priorité entre les exigences:

 À partir des interviews des parties prenantes

 Il faut traiter les exigences contradictoires et résoudre les incohérences.
 Les critères habituellement utilisés pour les exigences sont "critique" / "majeure" / "importante" /
"mineure". Si les priorités ne sont pas claires (toutes les exigences sont déclarées critiques), demander un
ordre de priorité arbitraire entre elles.

Négociez les exigences et les livrables une fois évalués les coûts et les délais:

 Un projet a, au moins, ces trois objectifs – qui peuvent être contradictoires. Si le délai prévu est trop
court, le contenu peut être réduit, par exemple.

Créez une matrice de traçabilité pour suivre les exigences tout au long de la vie du projet.

Exemple
Christina a été affectée au projet "MTBA" en tant que cheffe de projet. Ce projet a pour objet le lancement d’une
application rendant possible le paiement de petits articles à l’aide d’un téléphone mobile.

Au cours des phases d’avant-projet, le commanditaire a déjà contacté les parties prenantes qu’il a identifiées, pour
obtenir leurs principales exigences.

Les exigences déjà identifiées sont enregistrées dans la liste suivante:

Christina remarque quelques problèmes dans cette liste:

 Il n’est pas sûr que toutes les parties prenantes aient été contactées.
 Toutes les exigences sont de priorité 1 ou 2.
 Le point 2 n’est pas une exigence mais plutôt la description d’une solution.
 L’exigence 5 est trop vague. Considère-t-on tous les téléphones existant dans le monde? tous ceux vendus
par la société? tous ceux vendus au cours des 5 dernières années?… En l’occurrence, et à ce stade, cette
exigence est difficile à vérifier.
 Les exigences 3 et 6 sont contradictoires.

Pour traiter ces points, elle décide de suivre la démarche suivante:

1. Elle va jeter un coup d’œil sur les projets antérieurs pour voir si la liste des parties prenante est complète.
2. Elle va rajouter les exigences de management du projet.
3. Elle va mettre à contribution un groupe de représentants des utilisateurs dans le cadre d’un atelier, avec la
participation des parties prenantes et de l’équipe projet, dans le but de passer en revue ces exigences et
éventuellement d’en identifier de nouvelles. Ceci se fera en plusieurs itérations:
A. une session de brainstorming pour identifier les opportunités;
B. un atelier pour filtrer ces opportunités en fonction des objectifs et de la faisabilité (au cours de cet
atelier, les exigences seront triées par affectation d’une valeur numérique unique);
C. une interview de spécialistes du sujet à l’aide de la méthode Delphi.
4. Une fois compilée, la liste des exigences sera présentée par l’équipe projet au commanditaire pour
approbation, afin d’obtenir un engagement sur un accord de compréhension mutuelle.
5. Une matrice de traçabilité des exigences sera élaborée par l’équipe projet pour s’assurer qu’elles seront
respectées.

Prioriser les exigences

La société d’assurance Vimax a décidé de refondre

complètement son site web. Pour le moment, elle dispose
de pages statiques décrivant d’une manière très générale
les services offerts.

Un premier brainstorming avec les équipes marketing,

assurance habitation, assurance vie, ainsi qu’avec le
département informatique a permis de disposer d’une
longue liste d’exigences possibles pour le contenu du projet:

 Calcul en ligne des primes

 Edition en ligne des polices d’assurance
 Accès en ligne aux polices d’assurance
 Conseil expert à partir d’une analyse automatique des polices existantes et des informations sur la
personne assurée
 Comparaison avec les concurrents présents sur le marché
 Calcul des avantages fiscaux
 Collecte par Internet des informations sur le client pouvant être évaluées par les agents d’assurance
 Saisie en ligne des réclamations
 Suivi du statut d’un dossier
 Libre choix des agents d’assurance pour les clients
Comme il est impossible de satisfaire tous ces souhaits en raison de contraintes de budget et de délai, la question
de la priorisation s’impose…

Le chef de projet, M. Strauss, veut procéder comme suit:

1. Chacun des besoins est transformé conjointement en exigences mesurables sur une page A4.
2. Au cours de plusieurs réunions avec la même équipe, les bénéfices attendus de chaque exigence sont
analysés en distinguant le "bénéfice pour la société" du «bénéfice pour le "client".
3. Tout ceci est retranscrit dans un tableau comportant trois colonnes: "exigence", "bénéfice pour la société"
et "bénéfice pour le client".
4. Ensuite, le bénéfice est quantifié en Euros. Chaque équipier doit faire cet exercice individuellement, puis
un accord sur le montant acceptable est trouvé en groupe de discussion.
5. Le bénéfice de chaque exigence est ensuite comparé à son coût (de réalisation et de maintenance).
6. Cette comparaison fait apparaître des priorités entre les différentes exigences.
7. La liste des exigences avec leurs coûts et leurs bénéfices est soumise au management.
8. Une décision commune est prise sur les exigences qui seront incluses dans le contenu du projet.

Check-list

□ Avez-vous pris en compte toutes les parties prenantes? À ce stade, il est habituel d’en identifier de
nouvelles.
□ Avez-vous consigné par écrit toutes les questions et tous les risques identifiés pendant les interviews ou
les réunions? Les premiers risques sont identifiés lors de cette étape.
□ Avez-vous décrit toutes les exigences d’une manière spécifique et mesurable?
□ Est-ce que les exigences prennent en compte de façon explicite les intérêts des parties prenantes les plus
importantes?
□ Est-ce que les exigences comportent des critères d’acceptation spécifiques à chaque produit?

Pièges!

 Accepter l’introduction d’exigences qui ne correspondent pas aux objectifs du projet. Une partie prenante,
frustrée que ses objectifs ne sont pas retenus parmi ceux du projet, peut vouloir les faire passer sous la
forme d’exigences.
 Limiter ses recherches aux parties prenantes listées. De nouvelles parties prenantes peuvent être
identifiées.
 S’intéresser uniquement aux exigences! Certaines parties prenantes ont des difficultés à exprimer des
exigences; elles peuvent arriver à présenter plutôt des solutions à l’équipe de projet.
 Accepter les exigences ambiguës!
 Ne pas s’entendre sur les exigences avec les parties prenantes et particulièrement avec les exploitants!
 Accepter des exigences irréalistes, qui ne correspondent pas aux conditions générales!
Définir le contenu
Théorie
Les principes clés en bref:

Le contenu du projet définit les livrables attendus du projet, leurs caractéristiques et leurs critères d'acceptation.

Le but est d’élaborer un énoncé du contenu du projet sur lequel l’ensemble des parties prenantes est d’accord.

Les méthodes traditionnelles d’analyse, telles que les avis d’experts ou l’analyse détaillée du produit, vont fournir
les détails nécessaires.

A côté de ces techniques, il existe d’autres alternatives qui peuvent être employées, telles que les sessions de
brainstorming ou de pensée latérale.

 Le brainstorming permet de s’assurer que toutes les solutions possibles sont identifiées, y compris les plus
improbables.
 La pensée latérale permet d’évaluer le produit ou service d’un point de vue différent, ce qui stimule
l’émergence d’idées originales.

L’énoncé du contenu du projet couvre tous les livrables du projet. Ceci comprend effectivement le produit ou
service attendus, mais aussi les livrables annexes comme les documents de management du projet.

Concepts associés:

 Charte du projet
 Structure de découpage du projet (SDP)
 Gestion des modifications
 Acceptation du projet

Littérature:

Pour plus d’informations, nous vous recommandons de lire l’ouvrage suivant:

PMBOK® Guide - Cinquième Édition 5.2 Définir le contenu

Comment faire
Comment arriver au contenu d’un projet

Décrivez, en étroite relation avec les parties prenantes, ce que doivent être les livrables du projet et consignez-le
par écrit dans un énoncé du contenu du projet.
Au fur et à mesure que les livrables sont définis, vous pouvez développer la structure de découpage du projet
avec l’équipe de projet.

Rappelez-vous que le résultat du management du contenu (documentation des exigences, énoncé du contenu
du projet, structure de découpage du projet) doit être vérifié pour disposer d’une référence de base du projet
solide qui, par la suite, rende possible le traitement des demandes de modification.

Exemple

Planifier le contenu du projet

Le nouveau chef de projet désigné a vécu des expériences négatives au cours de son dernier projet.

Il est déterminé à éviter les mêmes problèmes dans ce nouveau projet, qui est actuellement en phase de
planification.

Dans le dernier projet, le management de projet n’a pas défini le produit avec le niveau de détail nécessaire dès le
début. En conséquence sont apparus plusieurs désaccords sur le fait que certaines fonctionnalités étaient des
demandes de modification ou des parties de la spécification originale du produit.

Ceci a conduit à des évolutions de contenu, des dépassements de budget et de délais, et bien sûr a singulièrement
compliqué l’acceptation du projet.

Ainsi, le chef de projet tire de son expérience qu’il est important de parvenir à un accord sur le contenu du projet
dès le tout début de celui-ci.

Dans l’énoncé du contenu du projet, il veut particulièrement faire attention à comment définir ce qui est
contenu dans le projet et comment le vérifier.

Rédiger un descriptif sommaire du produit (à partir de la charte du projet):

 Utiliser la documentation des exigences.

 Déterminer la structure du projet.
 Montrer le produit et toutes ses parties sous la forme de graphiques.
 Décrire les parties du produit (livrables), allouer les exigences et effectuer une revue qualité avec
les parties prenantes.
  Décomposer les parties du produit avec l’ensemble de l’équipe de projet, jusqu’à atteindre le
premier niveau d’une structure de découpage du projet.
 Positionner les livrables (par exemple: formation) dans la structure de découpage du projet,
organiser les revues qualité et une analyse des risques.
 Livrables: description du contenu du projet approuvée, liste approuvée des livrables, des critères
d’acceptation, des hypothèses et des exclusions.

Comment réagir aux modifications

 La référence de base pour identifier les modifications est constituée par les versions actuellement valides
et approuvées de:
 la documentation des exigences,
 l’énoncé du contenu du projet,
 la structure de découpage du projet,
 Pour chaque modification, un formulaire de demande de modification doit être rempli et traité suivant les
modalités de gestion des modifications en vigueur dans la société.
 Le chef de projet met à jour périodiquement la référence de base du contenu, ainsi que le plan de
management du projet (coûts, délais, autres références de base) en fonction des impacts des
modifications approuvées.

Comment conduire les acceptations du projet

 La référence de base pour les acceptations du projet est constituée par les versions actuellement valides et
approuvées de:
 la documentation des exigences,
 l’énoncé du contenu du projet,
 la structure de découpage du projet (et son dictionnaire).
 Le maître d’ouvrage et toute autre partie prenante impliquée n’acceptent immédiatement les livrables
achevés que pour éviter de retarder d’autres tâches du projet. C’est pourquoi il est très important de
planifier les activités d’acceptation du projet et aussi de rester concentré lors de la réalisation de ces
activités délicates. Il faut préparer par avance des scénarios de tests pour les projets complexes.
 Lorsqu’un livrable n’est pas accepté mais n’impacte pas d’autres livrables en aval, on peut l’accepter sous
réserve et émettre une demande de modification corrective pour s’assurer d’une correction ultérieure.
 Une correction ayant une incidence sur les autres objectifs du projet suivra également le processus de
demande de modification, mais son traitement nécessitera plus de détails sur les impacts.
 Les acceptations doivent être documentées et signées.

Check-list
□ Avez-vous défini comment arriver à l’énoncé du contenu du projet et comment réaliser l’assurance qualité?
□ Avez-vous décrit le contenu du produit en incluant:
 les limites du projet?
 les hypothèses et contraintes?
 les livrables?
 les modalités d’acceptation du produit?
 les risques connus?
 les documents de spécification que vous devez élaborer?
□ Avez-vous levé toutes les ambiguïtés?

Pièges!

 Oublier de mentionner les hypothèses qui sont fondamentales pour le succès du projet.
 Avancer sans disposer d’un accord formel sur la façon de prendre en compte les modifications.
 Ne pas avoir un accord formel sur les modalités d’acceptation et sur les critères d’une acceptation réussie
– les conséquences pour le projet peuvent être importantes: variation du contenu, reprises, chaos,
dépassements de budget et de délais.
Créer la Structure de Découpage du
Projet (SDP)
Théorie
Les principes clés en bref:

Lorsque l’énoncé du contenu du projet a été clarifié, l’étape qui suit est de le diviser en livrables élémentaires. De
cette façon, les choses deviennent plus précises, faciles à comprendre et à gérer (affectations, responsabilités,
estimations, etc.).

La structure de découpage du projet (SDP) est la façon habituelle de procéder à cette division: elle présente les
livrables du projet et sa décomposition en parties élémentaires. La SDP est une représentation en arborescence
des livrables, allant des livrables principaux jusqu’à leurs éléments constitutifs détaillés.

Les éléments du niveau le plus détaillé sont appelés lots de travail. Pour concevoir la SDP, le chef de projet va:

 Impliquer l’équipe (la création de la SDP est basée sur les données d’entrée de l’équipe et constitue une
bonne occasion de développement de l’équipe).
 Choisir un mode de représentation adapté aux besoins du projet. La liste des lots de travail restant la
même, seule la représentation graphique change.
 Découper l’un après l’autre chaque livrable en parties plus petites, jusqu'à ce que les livrables soient
compréhensibles pour tout le monde et soient d’une taille gérable (un tel livrable élémentaire est appelé
lot de travail).
 Donner un code d’identification à chaque élément de la SDP.
 Penser à détailler les livrables et non pas à la manière de les réaliser (détailler le «quoi» et non pas le
"comment").
 S’assurer, avec l’aide de l’équipe de projet, que rien n’est oublié.

Pour chaque lot de travail, les informations nécessaires sont collectées auprès de l’équipe. Ces informations sont
habituellement:

 un identifiant pour le lot de travail (Code SDP),

 un énoncé du travail à réaliser,
 le nom du responsable du lot de travail,
 les jalons de planning (contraintes, dates cibles),
 les critères d’achèvement (d’acceptation),
 les hypothèses y afférentes.

Cette information est enregistrée dans le Dictionnaire de la SDP. Une entrée est créée pour chaque livrable qui
apparaît dans la SDP.

Plus tard, des informations complémentaires peuvent être rajoutées, comme l’effort nécessaire, le coût, les
ressources affectées, et toute autre information nécessaire à la bonne compréhension du lot de travail.

La SDP et le Dictionnaire de la SDP (avec l’énoncé du contenu du projet) sont les références de base du contenu
du projet. Tout ce qui n’est pas décrit dans la SDP n’est pas dans le projet.
Concepts apparentés:

 Livrable
 Activité
 Résultats (livrables) intermédiares

Littérature:

Vous trouverez d’autres informations sur le sujet dans les livres suivants:

PMBOK® Guide - Cinquième Edition 5.3 Créer la SDP

PMI Practice Standard for WBS Modèles de SDP adaptés à différents domaines
industriels (en anglais uniquement)

Comment faire
Comment élaborer la structure de découpage du projet?

1. Lire l’énoncé du contenu du projet plutôt deux fois qu’une.

2. Faire la liste des livrables du projet les plus importants à partir de l’énoncé du contenu du projet.
3. Ces livrables peuvent souvent être eux-mêmes subdivisés.
4. Les sous-livrables requis pour chaque livrable principal sont alors listés.
5. Ces sous-livrables peuvent souvent être eux-mêmes subdivisés.
6. Ce processus de division s’arrête lorsque les conditions suivantes sont remplies:
A. La charge de travail de chaque lot de travail (livrable) peut être estimée.
B. La charge de travail n'est pas trop longue, compte tenu du temps entre deux rapports de projet.
C. Un budget peut être élaboré.
D. Le lot de travail peut être clairement affecté à une personne, un groupe de personnes ou à un
fournisseur.
E. Le lot de travail peut être facilement décrit et apparaître clair à tout le monde.

Comment décrire un lot de travail?

 Utiliser un modèle pour faciliter la lecture ultérieure.

A. Au minimum, donner: l’identifiant, l’énoncé du travail à réaliser, le nom du responsable du lot de
travail, tout jalon de l’échéancier (contraintes, dates cibles), les critères d’acceptation, les
hypothèses y afférentes et le compte de contrôle.
 Pour les lots de travail les plus importants, ou en cas de sous-traitance, les formulaires «Lot de travail»
doivent être signés par le chef de projet et par l’organisme ou la personne en charge du travail.
 Le formulaire "Lot de travail" peut ainsi être utilisé comme contrat entre le chef de projet et l’organisme ou
la personne en charge du travail.

Quelques exemples typiques de SDP sont présentés ci-dessous. Inspirez-vous d’eux pour votre prochain projet ou
adaptez l’un deux aux besoins spécifiques de votre projet.

Prenons l’exemple d’une grande société internationale qui a lancé le projet de construction d’une machine. La SDP
du premier niveau peut être représentée de différentes façons:
 Exemple
Le comité exécutif de la Banque Alpha a décidé récemment de remplacer les distributeurs automatiques (ATM –
Automated Teller Machines) par un nouveau modèle. Le projet "ATM" vient donc d’être lancé.

Les membres de l’équipe de projet ont commencé à subdiviser les livrables. Ils s’intéressent au "quoi faire".

Les acheteurs ont beaucoup aidé l’équipe de projet, notamment sur la décomposition des livrables requis pour
passer un ordre d’achat correct. Ils se sont limités à quatre lots de travail:

 Ces lots de travail (remplir le formulaire de commande de l’ATM, etc.) sont très clairs pour eux (et pour le
reste de l’équipe).
 Ils ont une bonne idée de qui est responsable de chaque lot de travail.
 Ils connaissent la charge de travail nécessaire que cela représente (en gros toutefois).
 Ils ont identifié quelques contraintes (le formulaire de commande de l’ATM peut être signé seulement par
le directeur des achats, etc.).
 Ils savent comment faire accepter une commande d’ATM (quelles informations sont nécessaires à chaque
étape).

Pendant la création de la SDP, le chef de projet a été surpris d’entendre parler de plomberie. Grâce à un expert
qui a travaillé par le passé comme électricien sur la préparation d’un site d’ATM, ce livrable a été identifié (un petit
drainage est installé sur les sites de ATM pour éviter l’humidité).
La Structure de Découpage du Projet (avec l’équipe) est la meilleure technique pour s’assurer que rien n’a été
oublié.

Check-list
□ Est-ce que tous les livrables du projet ont été décrits?
□ Est-ce que tous ces livrables sont définis de façon suffisamment précise?
□ Est-ce que ces livrables peuvent être affectés à une personne, un fournisseur ou un groupe de personnes
– ou alors les activités ont-elles besoin d’être subdivisées plus finement?
□ Les résultats attendus du travail sont-ils décrits avec exactitude?
□ Les exigences relatives à la qualité ont-elles été spécifiées?
□ L’estimation de la charge de travail a-t-elle été déterminée?
□ Est-ce que les dépendances ont-elles été mises en évidence?
□ La date de livraison a-t-elle été établie?
□ Le formulaire "Lot de travail" est-il signé par toutes les parties?
□ Est-ce que des dispositions particulières ont été spécifiées (par exemple: méthode, documentation,
documents, dessin, etc.)?

Pièges !

 Tous les livrables ne peuvent pas être décomposés dès le début du projet, notamment parce que les
informations dont on dispose à ce moment sont encore insuffisantes. En conséquence, la Structure de
Découpage du Projet doit être mise à jour à intervalles réguliers.
 Une personne ne doit pas développer la SDP toute seule! L’élaboration de la SDP est clairement un travail
d’équipe. Ceci permet une meilleure compréhension du projet en tant qu’ensemble.
 Assurez-vous que la SDP comporte les livrable du management de projet, de même que d’autres livrables
annexes (par exemple: acheter de nouveaux PC pour l’équipe, préparer une salle de réunion dédiée, etc.).
 Evitez de ranger la SDP dans un tiroir! Tous les membres de l’équipe de projet doivent pouvoir y accéder
en permanence dans les bureaux du projet. En conséquence, il est tout indiqué de représenter la SDP sur
un support de grand format placé à un endroit où tout le monde peut la voir.
 Ne pas oublier d’attribuer des identifiants: chaque livrable doit avoir son propre code d’identification,
connu sous le nom de "Code SDP".
 Lorsque le travail est affecté en interne, par exemple à un autre département, on oublie souvent d’établir
une description formelle des lots de travail. C’est précisément là le danger!
 Les lots de travail doivent être contresignés par toutes les parties. A défaut de quoi vous courez le risque
ne rien obtenir d’autre que des promesses creuses. Le personnel que vous avez contacté risque d’être
brusquement requis ailleurs et de vous laisser en plan.
Vérifier et maîtriser le contenu
Théorie
Les principes clés en bref:

Le contenu du projet définit le travail qui doit être effectué dans le cadre du projet pour livrer le résultat (ou le
produit) convenu.

Pour réussir son projet, le chef de projet doit gérer le contenu du projet en relation avec les parties prenantes, ce
qui signifie:

 le définir et le planifier (voir la leçon sur la définition du contenu du projet),

 le valider et le maîtriser.

Cette leçon traite de la validation et de la maîtrise du contenu du projet.

En ce qui concerne la maîtrise du contenu, le chef de projet doit:

 Maîtriser en permanence le contenu convenu, notamment par rapport aux contradictions, et aussi anticiper
celles qui peuvent apparaître.
 Identifier et décrire les modifications lorsqu’elles surviennent.
 Mettre en œuvre des actions pour éviter les modifications ou pour les traiter conformément à la procédure
formelle de gestion des modifications.

L’objectif de la validation du contenu du projet est que les produits finaux soient acceptés au fur et à mesure par
le client.

En pratique, maîtrise et validation sont plutôt problématiques en raison de contradictions non identifiables et de
désaccords sur le respect des exigences qui apparaissent pendant l’acceptation, ou encore parce qu’il y a plusieurs
points de vues sur la façon de traiter les modifications et les acceptations.

La principale origine de ce genre de problèmes est l’absence d’un accord précis avec les parties prenantes sur la
référence de base du contenu.

Pour éviter ces problèmes, la référence de base doit être établie au préalable et approuvée par les parties
prenantes. Elle est constituée des livrables suivants:

 la documentation des exigences (qui définit le besoin),

 l’énoncé du contenu du projet (qui définit entre autres le produit, les exigences et les critères de
l’acceptation),
 la structure de découpage du projet (description détaillée de tous les livrables).

Concepts apparentés:

 Gestion des modifications

 Acceptation du projet

Littérature:
Pour plus d’information, nous vous recommandons de lire:

PMBOK® Guide - Cinquième Édition

5.5 Vérifier le contenu

5.6 Maîtriser le contenu

Comment faire
Comment maîtriser le contenu du projet

Condition préalable: Vous avez défini une référence de base du contenu au cours de la planification du projet et
vous l’avez fait approuver par les parties prenantes. Que doit comprendre le contenu du projet? Voir l’énoncé du
contenu du projet et la structure de découpage du projet. Comment fonctionne votre procédure de traitement
des modifications? Voir le plan de management du contenu.

1. Vérifier en permanence si la production du contenu est faite conformément à la référence de base du

contenu. Est-ce que tous les travaux nécessaires sont réalisés, et uniquement eux? Conformément à la
structure de découpage du projet? Conformément à l’échéancier du projet?
2. Essayer d’anticiper les influences possibles sur le projet qui peuvent déboucher sur des modifications du
contenu du projet et agir sur elles.
3. Si vous constatez des contradictions ou des écarts par rapport à la référence de base (par exemple: des
exigences supplémentaires ou complémentaires:
o Agissez pour les corriger.
o Identifiez les modifications qui ne peuvent pas entrer en ligne de compte.

Attention: les exigences superflues (par exemple: les collaborateurs ajoutent de leur propre chef de
nouvelles fonctions) sont aussi des écarts qui doivent être corrigés.

4. Assurez-vous que les modifications nécessaires sont formellement prises en compte, conformément à
la procédure de maîtrise des modifications. Les modifications non maîtrisées entraînent des écarts de
contenu et rendent obsolètes le budget et le délai du projet!
5. Mettre à jour les documents du projet dès l’approbation des modifications, c'est-à-dire:
 la référence de base du contenu,
 le plan de projet (avec les conséquences en termes de coûts et délais!).

Pour éviter les malentendus, il est important de toujours travailler conformément aux états mis à jour,
vérifiés et approuvés conjointement avec les parties prenantes!

Comment réussir les acceptations (Valider le contenu)

Condition préalable: Vous avez défini une référence de base du contenu au cours de la planification du projet et
vous l’avez fait approuver par les parties prenantes:

 Comment sont réalisées les acceptations? Voir le Plan de management du contenu.

 Qu’est-ce qui est accepté? Voir les livrables dans l’énonce du contenu du projet et dans la structure de
découpage du projet.
 Quand une acceptation est-elle réussie? Voir les critères généraux d’acceptation dans le plan de
management du contenu et les critères spécifiques d’acceptation du produit (exigences, etc.) dans la
référence de base du contenu.

1. Assurez-vous que les livrables sont acceptés suivant le planning. Si une référence de base existe, il ne
devrait pas y avoir de problème, sinon, à coup sûr il y en aura!
2. Obtenez une confirmation écrite de l’acceptation par le client ou la partie prenante et mettez à jour la
synthèse des acceptations.
3. Assurez-vous que les défauts sont documentés d’une manière compréhensible.
4. Vérifiez si le défaut est bien une erreur (exigence non respectée) ou si le client a modifié ses exigences.
5. Corrigez les erreurs et présentez à nouveau le livrable pour acceptation.
6. Discutez avec le client des défauts qui vous semblent être des modifications des exigences, et convenez
ensemble de reporter leur correction dans une version ultérieure du produit. Ou alors, si c’est nécessaire,
suivez formellement la procédure de gestion des modifications (avec tous les impacts sur les coûts et les
délais).
 Exemple
Pourquoi les modifications sont-elles non maîtrisées?

Comme le chef de projet a été renvoyé, Pierre doit prendre en charge le projet «Intranet Vimax».
Malheureusement, il se rend compte très rapidement que le management du projet est insatisfaisant parce que les
coûts sont dépassés et les délais s’allongent indéfiniment. En plus de ça, l’équipe est démotivée: les équipiers se
plaignent des multiples adaptations qu’ils doivent à tout moment effectuer sur leur travail, surtout après tous les
efforts fournis pour produire des solutions optimales.

Après une brève analyse, Pierre conclut qu’il n’y a pas d’exigences réellement mesurables sur certains aspects
critiques et que l’équipe prend des décisions, parfois très importantes, sans consulter le responsable concerné.

Exemple "Accéder en ligne aux polices d’assurance":

 On n’a pas précisé si l’accès se fait par le nom, le numéro, le lieu ou tout autre critère; quel est le mode
d’accès le plus fréquent; quel est le temps de réponse attendu, etc.
 Le programmeur en charge a pris les décisions sans en référer à qui que ce soit et, pour être sûr de ne
rien oublier, a mis en place tous les mécanismes d’accès possibles; en conséquence, le temps de réponse
est trop long: après s’être fait présenter le programme, son responsable lui a demandé toute une série
d’ajustements!

Bien que les développements soient commencés, Pierre n’a d’autre choix que d’immédiatement mettre en place
une référence de base, afin de pouvoir identifier les modifications et de réaliser les acceptations, s’il veut que le
projet redevienne maîtrisable.

Il décide d’arrêter les travaux en cours et d’entreprendre une révision de la référence de base du contenu en
collaboration avec les parties prenantes et l’équipe de projet. Ceci signifie:

 un énoncé du contenu du projet (avec des exigences mesurables) qui est approuvé lors d’une revue
qualité.
 un plan de management du contenu pour gérer le contenu (avec la définition des procédures de
modification et d’acceptation) qui est lui aussi approuvé.

Bien que toutes les parties prenantes n’aient pas apprécié les actions de Pierre, les résultats lui ont rapidement
donné raison: le travail à faire a une référence de base connue de tout le monde, les périodes de turbulence ont
pratiquement disparu, les modifications sont facilement identifiées, la procédure d’acceptation est compréhensible
pour tout le monde, le contenu du projet est sous contrôle, les délais sont tenus et les coûts respectent le budget!

Des validations bien organisées

En raison d’expériences malheureuses sur les validations de son précédent projet (désordres, absence de
synthèse, client indisponible, discussions sur les fonctions manquantes, etc.), Pierre, le chef de projet, est résolu
de mettre un terme à ce genre de problèmes dès le début du projet.

Pour cela il a intégré la procédure de validation dans le plan de management du contenu, discuté et approuvé par
toutes les parties prenantes.

Le projet "Intranet Vimax" est en cours d’acceptation par le client, et Pierre est bien organisé. Son tableau de
synthèse des acceptations reflète toujours l’état actuel:
Dans la procédure de validation, il a été convenu de distinguer deux groupes de défauts:

 NOK: non accepté. Le défaut doit être corrigé immédiatement puisque soit la poursuite des tests n’est pas
possible soit cette partie du produit ne peut pas être utilisée.
 OKR: accepté sous réserve que le défaut soit corrigé plus tard (dans les livraisons suivantes).

Cette distinction permet au chef de projet de se concentrer sur les défauts les plus critiques. La procédure de
validation est plus claire et les mesures d’urgence diminuent. Parallèlement, on gagne en qualité et en temps.

En se basant sur la référence de base du contenu, les testeurs valident les différents livrables, décrivent les
défauts de telle sorte qu’on puisse les traiter, les classent en OKR et NOK et rapportent en permanence au chef de
projet.

Le chef de projet analyse le classement, consulte les testeurs si nécessaire et fait passer chaque défaut en
correction immédiate (NOK) ou différée (OKR). Comme Pierre s’est bien préparé au cours de la planification et de
la définition du contenu, et comme ses actions sont cohérentes, il a la maîtrise des acceptations du projet.

Check-list
□ Est-ce qu’une bonne référence de base du contenu existe comme condition préalable à la maîtrise et à la
vérification du contenu du projet?
□ Y a-t-il un accord sur la manière de procéder en cas de modification?
□ Vérifiez-vous régulièrement que le travail est fait conformément à la référence de base du contenu?
□ Intervenez-vous rapidement s’il y a un écart?
□ Intervenez-vous si vous remarquez un perfectionnisme exagéré?
□ Distinguez-vous clairement les défauts (à corriger) des modifications? Maîtrisez-vous le workflow (flux des
travaux)?
□ Mettez-vous en œuvre une gestion des modifications cohérente?
□ Mettez-vous à jour le plan de projet et la référence de base du contenu pour prendre en compte les
impacts des modifications approuvées et permettre à toutes les parties impliquées dans le projet de
trouver elles-mêmes la dernière version valide?
□ Avez-vous obtenu un accord sur la manière de réaliser les validations du projet?
□ Mettez-vous en œuvre la procédure de validation d’une façon cohérente avec le plan de management du
contenu?
 Pièges !

 Ne pas être capable de se baser sur une référence pour identifier les modifications!
 Ne pas définir comment les modifications doivent être traitées!
 Tolérer les modifications, ou bien ne pas imposer une procédure formelle de gestion des modifications!
 Les exigences et les critères d’acceptation ont été mal ou pas du tout définis, ou n’ont pas été approuvés!
 Incapacité à réaliser une revue qualité sur les exigences relatives à l’énoncé du contenu du projet ou à la
structure de découpage du projet, en raison d’un manque de temps ou pour toute autre raison!
 Le client ne met pas à disposition du personnel pour réaliser les acceptations, ou même ne les réalise pas
du tout
 Les acceptations sont souvent reportées!
 De nouvelles exigences sont faites au cours de la réalisation des acceptations!
 Les résultats des acceptations ne sont pas consignés par écrit!