II. Gérer le projet

Le management de la qualité du projet porte à la fois sur le management du projet et sur ses livrables. Il s'applique à tous les projets, indépendamment de la nature de leurs livrables. En revanche, les mesures et les techniques relatives à la qualité du produit sont spécifiques au type de livrable généré par le projet. Par exemple, le management de la qualité des livrables logiciels implique des approches et des mesures différentes de celles utilisées pour construire une centrale nucléaire ! Dans un cas comme dans l'autre, le non-respect des exigences de qualité peut entraîner des conséquences négatives graves pour certaines parties prenantes du projet, voire pour toutes.

Qualité et classe

Ces 2 notions différentes permettent d'entrevoir plus précisément les attentes que l'on peut placer dans la gestion de cette contrainte.

• Qualité : en tant que performance our résultat livré, c'est "le degré auquel un ensemble de caractéristiques intrinsèques satisfait à des exigences" (ISO 9000)
• Classe : en tant qu'intention de conception, c'est une catégorie attribuée aux livrables ayant la même utilisation fonctionnelle, mais des caractéristiques techniques différentes

Ainsi, alors qu'un niveau de qualité ne satisfaisant pas aux exigences de qualité représente toujours un problème, une classe inférieure ne l'est pas nécessairement. Exemple :

• un logiciel convenable de classe inférieure (nombre limité de fonctionnalités) et de haute qualité pourrait ne pas présenter de problème, au sens  où il serait adéquat pour l'usage auquel il est destiné
• a contrario, un logiciel de classe supérieure (beaucoup de fonctionnalité) mais de qualité médiocre (de nombreux défauts) poserait inévitablement un problème

Adéquation produit/exigences

On l'a vu, en avant-projet, la définition du besoin débouchant sur un cahier des charges a donné lieu à la définition d'une solution adaptée, tenant compte des contraintes qualité-coûts-délais. Lors de la phase opérationnelle du projet, il conviendra de veiller - et les méthodes de management de la qualité (évaluation...) seront mobilisées à cet effet - à l'adéquation du livrable en cours d'élaboration par rapport aux exigences (fonctions principales/fonctions contraintes) qui avaient été arrêtées au moment du lancement du travail. Seront notamment privilégiées, les approches suivantes :

• La satisfaction du client/commanditaire : comprendre, évaluer, définir et gérer les exigences du client afin de satisfaire ses attentes. Cela implique la conformité aux exigences (de façon à ce que le projet produise ce pour quoi il a été entrepris) et l'aptitude à l'emploi (de sorte que le produit ou le service satisfasse aux besoins réels)
• La prévention plutôt que l'inspection : La qualité devrait être planifiée, conçue et intégrée, et non pas rajoutée, par inspection, dans les livrables du management du projet ou dans ceux du projet. Le coût de la prévention des erreurs est généralement bien inférieur au coût de leur correction lorsqu'elles sont détectées par une inspection ou en cours d'utilisation

Stratégie de déploiement

Afin d'encadrer les risques qui pourraient survenir lors du déploiement du livrable, il est important de prévoir les modalités de sortie de la phase opérationnelle et le lancement effectif de l'objet du projet. Cela permettra par exemple de border les impacts négatifs sur l'environnement d'une solution dont la qualité n'est pas satisfaisante ou d'un déploiement dans un contexte non préparé. Si c'est plus difficile à envisager s'agissant d'une réorganisation, c'est quelque chose qui aura dû être pensé dès l'élaboration du plan projet.

En pratique, il peut s'agir d'opérer un déploiement de manière progressive au rythme des métiers concernés ou limité à un périmètre qui va jouer le rôle de "cobaye".

Dans tous les cas un déploiement partiel contrôlé supposera la définition de méthodes d'évaluation pour en suivre l'évolution et procéder rapidement aux adaptations, corrections en vue des autres étapes de déploiement. C'est typiquement l'idée qui sous-tend le concept de prototypage où l'on déploie une première ébauche du livrable cible pour vérifier un certain nombre d'hypothèses et de pistes ; cette idée de proof of concept (POC) peut même dans certains cas de projets vastes et complexes aller jusqu'à éprouver un modèle d'organisation projet ou l'utilisation d'une méthodologie donnée (voir à ce sujet le cas du projet PC-SCOL).