1. Livres & vidéos
  2. Réussir un projet avec la méthode PMBOK®
  3. Domaine de performance de la livraison
Extrait - Réussir un projet avec la méthode PMBOK® Outils et techniques appliqués aux projets IT
Extraits du livre
Réussir un projet avec la méthode PMBOK® Outils et techniques appliqués aux projets IT
2 avis
Revenir à la page d'achat du livre

Domaine de performance de la livraison

Introduction

Le domaine de performance de la livraison évalue la capacité d’un projet à transformer une ambition en livrables.

Prenons l’exemple d’une entreprise dont l’ERP est obsolète. Cela entraîne des risques de sécurité, des erreurs et des coûts de développement croissants. L’entreprise va donc réfléchir au remplacement de son ERP pour répondre aux besoins de sécurité, fiabilité et au coût de maintenance. La livraison consiste donc à convertir cette valeur attendue en un résultat concret : un ERP répondant aux ambitions.

Pour optimiser cette réponse à la valeur attendue, le domaine de performance de la livraison traite :

  • des exigences ;

  • du périmètre du projet ;

  • de la qualité.

Valeur attendue

1. Documentation de la valeur

Comme nous l’avons vu précédemment, en amont du projet, l’organisation définit la valeur attendue pour l’entreprise.

Cette valeur peut être financière (gains, ROI,) ou non financière (conformité à une loi, satisfaction des utilisateurs…).

Ce document est rédigé par l’initiateur du projet (qui est le plus souvent le sponsor) et sera utilisé pour convaincre l’entreprise du besoin de lancer le projet. 

La plupart du temps, un business case contient les éléments suivants (non exhaustif) :

  • la problématique (peut être une opportunité ou un problème) ;

  • les options envisageables ;

  • les bénéfices attendus ;

  • une note de cadrage (estimation macro des ressources et du budget nécessaires) ;

  • les risques ;

  • les contraintes ;

  • une proposition de gouvernance.

Tous ces éléments étant préalables au projet, ils doivent rester de haut niveau, car ils seront détaillés par le chef de projet et son équipe au lancement.

Ce document permet de bien définir la valeur attendue.

Dans notre exemple, la valeur peut être résumée ainsi : « doter l’entreprise d’un nouvel ERP afin de réduire les coûts de maintenance de xk€, et d’assurer...

Exigences

1. Définition et collecte

Grâce aux points précédents, nous savons quelle est la valeur attendue par l’entreprise (business case), et comment le projet y répondra (fiche projet/énoncé du périmètre).

Ainsi, le chef de projet sait, par exemple, quel ERP sera choisi (ou à défaut par quel moyen le choix sera fait), et comment il sera construit et déployé.

Un autre aspect majeur de la gestion de la livraison consiste à récolter et traiter des exigences.

Les exigences sont des caractéristiques que l’on doit retrouver dans le produit final pour satisfaire un besoin.

Les exigences peuvent être collectées tout au long du projet. Néanmoins, la phase d’identification des parties prenantes en constitue la principale source.

Reprenons notre exemple de projet ERP : le chef de projet rencontre plusieurs départements de l’entreprise (Supply Chain, finance, IT…) afin d’identifier et qualifier les parties prenantes (voir domaine de performance dédié). À cette occasion, les parties prenantes émettent un certain nombre d’exigences quant au nouvel ERP ou au projet en lui-même. Nous pourrions imaginer par exemple que le département RH, soucieux de trouver facilement du personnel qualifié sur le nouvel ERP, favorise un ERP leader du marché. 

Les exigences...

Périmètre : définition et décomposition

Comme nous venons de le voir, la valeur attendue, puis la collecte des exigences, les études de faisabilité… conduisent à finaliser une définition claire du périmètre du projet.

L’étape suivante consistera à découper ce périmètre pour en organiser la livraison.

1. Découpage du périmètre en WBS

Une des références de base les plus utilisées est le WBS (pour Work Breakdown Structure). Il s’agit du découpage du projet en différents niveaux de plus en plus fins.

Il sert ensuite de point de départ pour créer une référence de base des coûts, ou un échéancier.

Ce découpage est particulièrement adapté aux projets prédictifs, ou waterfall.

Il existe deux types de WBS : basé sur les livrables (le plus fréquent), ou basé sur les phases du projet.

Le WBS est structuré en trois niveaux :

Le niveau le plus élevé en premier correspond à un groupe de livrables (exemple : développement du logiciel).

Le niveau intermédiaire est une catégorie plus détaillée de ces livrables (exemples : tests logiciel, mise en production).

Le dernier niveau est appelé un lot de travail et correspond à...

Finalisation des livrables

Une fois les livrables décidés, puis produits, ils doivent répondre à certains critères pour être considérés comme terminés.

Ces critères doivent être définis en amont.

Parmi les éléments permettant la réception d’un livrable, nous pouvons noter les notions suivantes :

1. Critères d’acceptation

Ils sont listés en amont du projet dans l’énoncé du périmètre. Ils font suite aux exigences des parties prenantes, mais également aux exigences légales ou liées aux politiques de l’organisation.

En cas de projet client, ces critères sont discutés et documentés en amont avec le client.

2. Mesure de performance technique

La mesure de performance technique évalue l’efficacité, la qualité et la conformité d’un livrable par rapport aux exigences techniques définies, en se basant sur des indicateurs précis tels que la vitesse, la fiabilité, et les fonctionnalités.

3. Definition of Done (DoD)

Utilisé dans les projets agiles, le DoD est une définition commune à l’équipe de ce qui peut être considéré comme recevable. Ainsi, quel que soit le membre de l’équipe qui livre, le livrable aura toujours été qualifié...

Qualité

Dernier aspect de ce domaine de performance : la qualité des livrables produits. 

Pour rappel, la qualité désigne la capacité d’un livrable à répondre aux attentes. 

1. Planification de la qualité

La gestion de la qualité est planifiée et documentée dans le plan de gestion de la qualité, qui fait partie du plan de management du projet.

Pour déterminer le niveau de qualité à atteindre, le projet s’appuie notamment sur :

  • le périmètre du projet ;

  • la charte projet ;

  • le registre des risques ;

  • les exigences des parties prenantes ;

  • les actifs organisationnels (exigences, procédures et outils propres à l’entreprise) ;

  • facteurs environnementaux (normes, lois, marché par exemple).

2. Coût de la qualité

L’animation de la qualité se nomme également « l’assurance qualité ».

Il s’agit de mener les actions nécessaires pour s’assurer de la bonne connaissance du niveau de qualité, et de la recherche de solution et d’amélioration.

Le terme « coût de la qualité » désigne tous les coûts engendrés pour la gestion de la qualité, les actions à mener pour détecter les écarts et la non-conformité...

Changements

Qu’il s’agisse d’une nouvelle exigence, ou d’un besoin de revoir le produit à la suite de défauts qualité constatés, le périmètre et les livrables peuvent nécessiter une modification en cours de projet.

En fonction de l’approche de développement, le processus ne sera pas le même.

1. Cas des changements en approche prédictive

À l’inverse de la méthode agile, qui permet des changements fréquents, l’approche prédictive se base par nature sur un plan précis.

Ce même plan est construit pour répondre à un périmètre arrêté.

Par exemple : une roadmap peut être très détaillée au départ si l’équipe projet connaît parfaitement l’ERP à déployer, les implications pour l’entreprise, les fonctionnalités à délivrer…

De ce fait, un changement en cours de projet va impacter l’ensemble de la planification. Il doit donc obéir à certaines règles, qui sont définies en amont dans le plan de gestion des changements (et/ou dans les processus de l’entreprise).

Certaines entreprises ou certains projets disposent par exemple de comités de gestion du changement qui ont pour mission d’identifier et de traiter les demandes de...

Conclusion

Pour ce domaine de performance, comme pour d’autres, les projets performants savent naviguer entre planification et adaptation.

Le processus consistant à verrouiller le périmètre d’un projet dès la phase de découverte des exigences peut sembler antinomique avec les enjeux d’agilité et d’accélération des livraisons.

Le travail du chef de projet et de son équipe consiste donc à identifier les opportunités et impacts des demandes de changements pour les comparer à la valeur en jeu, tout en maintenant une vision globale permettant d’identifier les effets d’un changement.

C’est par exemple une des fonctions du Product Owner, qui garantit la valeur et l’alignement des fonctionnalités avec les besoins des parties prenantes.

Liste des artefacts impactés

Journaux et registres

Journal des hypothèses

Document qui consigne toutes les hypothèses formulées pour le projet, incluant leurs impacts potentiels et les validations à effectuer au fur et à mesure de l’avancement du projet.

Backlog

Liste priorisée des tâches, fonctionnalités, ou éléments à réaliser dans le cadre du projet. Utilisé principalement dans les projets agiles, il est mis à jour régulièrement en fonction de l’évolution des priorités.

Journal des changements

Suivi des demandes de changement et de leur statut d’approbation

Registre des risques

Document qui consigne les risques, leur probabilité, l’impact et les stratégies de réponse. 

Plans de gestion

Plan de gestion du périmètre

Stipule comment le périmètre du projet sera défini, validé, et contrôlé, en incluant les processus pour gérer les changements de périmètre.

Plan de gestion des exigences

Stratégie pour recueillir, analyser, documenter, et gérer les exigences du projet.

Plan de gestion de l’échéancier

Décrit comment le calendrier du projet sera développé, géré, et contrôlé pour assurer le respect des délais.

Plan de gestion de la qualité...