Changement

Un des plus grands défauts des Chefs de Projet, est la capacité à dire non quand il leur est demandé d’ajouter de nouvelles exigences au projet. Ceci dépend bien sûr du type d’organisation. Les Chefs de Projet qui disent non ne sont pas perçus comme ayant l’esprit d’équipe, et peuvent très rapidement une mauvaise réputation.

Dans certains projets, il y a un empressement à débuter, de ce fait il n’y a pas suffisamment de temps accordé pour la définition des exigences et la description des produits, et le budget est fixé pour le projet. Il peut donc arriver plus tard qu’une fonctionnalité supplémentaire doive être rajoutée au projet, et le Chef de Projet doit savoir comment gérer cette situation.

Ce que j’aime le plus à propos du Thème Changements, est qu’il montre que vous, en tant que Chef de Projet, n’avez pas à répondre oui ou non. Lorsqu’une nouvelle fonctionnalité est demandée, vous pouvez même remercier la personne qui l’a suggérée, et ensuite lui remettre un formulaire de Requête de Changement à remplir, et offrir votre aide si besoin . Vous promettez ensuite de suivre cette requête, en faisant savoir au requérant que la décision sera prise par l’Autorité de Changement ou le Comité de Pilotage.

Le Thème Changements décrit aussi les Rôles et Responsabilités de l’Exécutif et du Comité de Pilotage. C’est important car vous pourrez avoir besoin de le rappeler à l’Exécutif. J’ai vu quelques projets où l’Exécutif pressait le Chef de Projet d’autoriser des changements dans le projet, sans fournir des ressources supplémentaires. Ce thème vous montrera comment gérer ces situations.

La plupart des Chefs de Projet savent qu’ils doivent surveiller les produits du projet; c’est la Gestion de la Configuration. Ca consiste principalement du contrôle des changements, en s’assurant que les bonnes personnes ont accès aux dernières versions des documents de référence, et en fournissant un stockage centralisé et accessible. Certaines entreprises fournissent un système IT documenté et facile à utiliser, pour permettre au Chef de Projet de gérer, contrôler et distribuer les informations du projet.

D’autres entreprises fournissent des systèmes si complexes qu’ils finissent par ne pas être utilisés. La bonne nouvelle est que les systèmes faciles à utiliser sont simples à obtenir, et possèdent la plupart des fonctionnalités nécessaires, notamment l’accès sécurisé aux informations.

Le dernier point avant de continuer est que la plupart des Chefs de Projet ne planifient pas les activités de Gestion de la Configuration, pensant à tort que ce sont des choses qu’ils peuvent faire en soirée, ou pendant une conférence téléphonique. Il est important de prendre du temps pour bien faire ce travail.

Objectif

L’objectif de ce thème est d’aider à identifier, évaluer et contrôler tous les changements potentiels aux produits qui ont déjà été acceptés et référencés. Le Thème Changements ne s’occupe pas seulement de la gestion des requêtes de changement, mais aussi des la gestion des incidences qui surviennent au cours du projet. En effet, il est meilleur de dire que le Thème Changements apporte une approche commune au Contrôle des Incidences et des Changements.

Le changement est inévitable dans chaque projet, et tous les projets ont besoin d’une bonne approche pour identifier, évaluer et contrôler les incidences qui peuvent résulter en changement. Ce Thème fournit une approche au Contrôle des Incidences et des Changements.

Le timing

Le Contrôle des Incidences et des Changements doit être fait pendant tout le cycle de vie du projet. L’objectif n’est pas d’empêcher les changements, mais de les faire évaluer et approuver avant de les réaliser.

Chaque projet nécessite un Système de Gestion de la Configuration qui surveille les produits, enregistre lorsqu’ils sont approuvés et référencés, et aide à s’assurer que les bonnes versions sont utilisées pendant le projets et livrées au client.

Définitions

Gestion de la Configuration

C’est l’activité technique et administrative afférente à la création, à la maintenance et au changement contrôlé de la configuration d’un produit. C’est une jolie manière de dire que la Gestion de la Configuration veille sur les produits du projet.

Item de Configuration

Un item de configuration est le nom donné à un élément (ou item) qui est managé par la Gestion de la Configuration. Ainsi, pour un projet de création d’un nouvel ordinateur portable.

On peut dire qu’un item de configuration est tout ce que vous voulez surveiller pendant le projet.

Version livrée (Release)

Une version livrée est un ensemble complet et cohérent de produits qui sont gérés, testés et déployés en tant qu’entité unique à remettre aux utilisateurs. Un exemple de version livrée pourrait être une nouvelle version d’un ordinateur, avec une certaine version de Système d’exploitation, un certain Processeur, un certain BIOS et certaines versions.

Incidences

PRINCE2 utilise le terme incidence pour désigner tout événement pertinent qui survient, qui n’était pas planifié et nécessite certaines actions de management (ex. une question ou une requête de changement). Les Incidences peuvent être levées à tout moment au cours du projet, et par n’importe qui.

Il y a 3 types d’incidences :

• Requête de Changement
• Hors-Spécification
• Problème/Souci

L’Approche de PRINCE2 en matière de Changements

L’approche de la Gestion des Incidences et des Changements est décidée pendant la Séquence d’Initialisation. Cette approche peut être revue à la fin de chaque Séquence dans le processus de Gestion de la Limite de Séquence.

PRINCE2 a six produits de management qui sont utilisé pour contrôler les incidences, les changements et la Gestion de la Configuration:

• La Stratégie de Configuration : Ce document contient la stratégie de gestion des incidences et des changements pendant le projet (comment identifier les produits, comment les contrôler et comment faire les rapports d’état et les vérifications).
• Enregistrements de Configuration: Ils fournissent un ensemble de données pour chaque produit (comme des métadonnées). Par exemple : le bureau central de la bibliothèque aura une carte pour chaque livre avec des informations spécifiques, telles que la position, la classification, le numéro ISBN, etc.).
• Rapport d’état du Produit: C’est un rapport sur le statut des produits (ex: liste des statuts de tous les produits créés par le Fournisseur X pendant la séquence 3).
• Journal du Projet: C’est un journal utilisé par le Chef de Projet pour toutes les informations informelles. Les informations formelles sont consignées dans des registres.
• Registre des Incidences: Imaginez un tableur pour collecter et maintenir les incidences.
• Rapport d’Incidence: Décrit en détail une incidence. Selon PRINCE2 ,une incidence peut être 1) Requête de Changement, 2) Hors-Spécification, ou 3) problème/souci. Un Rapport d’Incidence pourrait aussi décrire les incidences liées, afin qu’elles ne soient plus un risque.

Stratégie de Configuration

Ce document contient la stratégie de gestion des incidences et des changements pendant le projet. L’une des premières questions qu’un Chef de Projet devrait poser est : Quels sont les standards existant pour le Contrôle des Incidences et des Changements dans l’entreprise ?

Dans le cas d’un environnement de Programme, il existe généralement un modèle de Stratégie de Configuration disponible. La Stratégie de Configuration doit répondre aux questions suivantes :

• Q1: Comment identifier et contrôler les produits ? (Gestion de la Configuration).
• Q2: Comment gérer les incidences et les changements ? (Collecter, Examiner, Proposer, Décider, Mettre en œuvre).
• Q3: Quels outils utiliser pour tracer les Incidences et les informations sur les Produits (ex: SharePoint, Excel, etc.) ?
• Q4: Quelles données conserver pour chaque produit (ex: Enregistrement de Configuration) ?
• Q5: A quelle fréquence le Chef de Projet doit contrôler les incidences et les changements (ex: une fois par semaine, deux fois par mois, etc.) ?
• Q6: Qui est responsable de quoi ? Quels sont les Rôles et Responsabilités ? (ex: qui joue le rôle d’Autorité de Changement ?)
• Q7: Comment prioriser les incidences et les changements ? Quelle échelle utiliser pour la priorisation des incidences ?
• Q8: Quelle échelle utiliser pour la gravité des incidences (ex: 1 à 4, mineur-important-majeur…) ?
• Q9: Quels niveaux de management gèrent les niveaux de gravité des incidences ? (ex: les incidences de gravité 1 sont gérées par le Chef de Projet, mais 2 et 3 par l’Autorité du Changement, etc.).

A l’instar des 3 autres documents de stratégie, la Stratégie de Configuration est créée lors de la séquence d’initialisation par le Chef de Projet, et est approuvée par le Comité de Pilotage.

Comment prioriser les incidences et détecter la gravité

Il existe plusieurs manières de prioriser un requête de changement, et PRINCE2 introduit la méthode MoSCoW pour aider à le faire. MoSCoW signifie Must have, Should have, Could have et Won’t have (for now).

• Must have: (Doit avoir) Le changement est essentiel pour la viabilité du projet, et sont absence affecterait les objectifs du projet. (ex: le produit final de fonctionnera pas comme convenu).
• Should have: (Devrait avoir) Le changement est important et son absence affaiblirait le Cas d’Affaire; mais le projet atteindra quand même ses objectifs.
• Could have (Pourrait avoir): Le changement est utile, mais son rejet n’affaiblirait pas le Cas d’Affaire.
• Won’t have for now: (N’aura pas pour l’instant) Le changement n’est ni essentiel, ni important et peut attendre.

Toutefois, il peut être difficile d’expliquer ces quatre niveaux de priorité aux requérants, et la plupart du temps, ils auront tendance à dire que leur requête est très importante. Voici donc quelques questions simples à poser, qui vous aideront à obtenir une information correcte du requérant :

• Must have: Le produit final ne marchera pas si la requête est rejetée ? (Oui).
• Should have: Le Cas d’Affaire est impacté ? (Oui) - Comment ?
• Could have: Le Cas d’Affaire est impacté ? (Non).
• Won’t have: Le changement est essentiel ou important ? (Non).

Gravité

Ainsi la MoSCoW est bonne for priorisation, quid du classement des incidences ?

Exemple: Vous pouvez utiliser une échelle de 1 à 5 ou des mots tels que mineur, normal, important, majeur and critique.

Vous pouvez associer le traitement d’un niveau de gravité d’incidence à un rôle.

• Mineur > Support du Projet.
• Normal > Chef de Projet.
• Important > Autorité de Changement.
• Majeur > Comité de Pilotage.
• Critique > Direction de l’Entreprise ou du Programme (ex: tolérance du projet excédée).

Autorité de Changement et Budget de Changement

L’Autorité de Changement est une personne ou un groupe de personnes chargé d’examiner et d’approuver les requêtes de changement et les hors-spécification. C’est une responsabilité du Comité de Pilotage, qu’ils peuvent réaliser eux-mêmes, ce qui est le cas lorsque très peu de changements sont attendus. Lorsque plusieurs changement sont attendus, cette tâche demande beaucoup de temps au Comité de Pilotage, et il est alors préférable de la déléguer à une personne ou un groupe de personnes.

Quel type de personne peut jouer ce rôle ?

Tout dépend de la taille et de la valeur du projet, du budget de changement, du montant qui peut être dépensé pour chaque changement, et d’autres facteurs similaires. Ca pourrait être le secrétaire de l’Exécutif, un membre du Comité de Pilotage, ou tout autre personne compétente.

L’Autorité de Changement aura un budget de changement, qui est le montant que le client et le fournisseur ont convenu d’utiliser pour financer le coût des Requêtes de Changement. Il est conseillé d’avoir un budget de changement pour chaque projet. Le Comité de Pilotage peut limiter le coût d’un changement, ou le montant à dépenser pour une séquence.

Le processus de Contrôle des Changements est un outil important pour le Chef de Projet. En effet, si vous avez par exemple des cadres importants de l’organisation qui demandent des changements, et que vous ne voulez ni paraître négatif, ni être forcé d’ajouter des choses qui mettraient le projet en danger. Il suffit de les guider à travers le processus de requête de changement, de les aider s’il le faut à remplir le formulaire associé, et ensuite de passer la requête à l’Autorité du Changement. Vous n’aurez donc pas à dire non, et vous paraîtrez utile par la même occasion.

Procédure de Gestion de la Configuration

C’est l’ensemble de toutes les activités qui contrôle et maintiennent les changements pour chaque produits au cours du cycle de vie du projet, et après la clôture du projet. Il s’agit de veiller sur les Produits du Projet. PRINCE2 suggère les 5 activités suivantes :

• Planification: A quel niveau gérer la configuration - quels produits ?
• Identification: ex: Système de codage ? (projet-produit-version-date).
• Contrôle: Activités de référencement, archivage, distribution de copies etc.
• Suivi d’état: Vérifier et rapporter un groupe de produit.
• Vérification & Audit: Les produits sont-ils en phase avec les documents d’enregistrement de configuration ?

Planification

Décider quels documents et produits contrôler. Qu’est-ce qui est important d’après vous ?

Ex. un Projet de CRM: Vous pourriez contrôler les documents et produits suivants :

Product Principal, tous les composants majeurs, design, processus, documentation

Ex. Un projet événementiel de 100 personnes, vous pourriez suivre:

Listes d’invitation, notes du speaker, les informations sur le service traiteur, etc.

Identification

Décider comment identifier de manière unique chaque produit du projet (Système de codage).

Code Produit, Initiales du Propriétaire, Numéro de version, Date dernière MàJ

Ex. 045-FT-v04-20112304.pdf

— Au cours du Projet —

Contrôle

Il s’agit ici de contrôler les changements qui sont effectués sur les produits au cours du projet, car une fois qu’un produit est approuvé “rien ne bouge, rien ne change sans autorisation ”. Les produits de références sont utilisés pour comparer la situation actuelle avec les objectifs précédents.

Le contrôle s’occupe aussi du stockage et de la distribution des copies, du contrôle d’accès, de l’archivage et d’activités similaires pour le management et les produits spécialistes.

Conseil: Pensez à un récent projet, et de la manière dont vous travailliez sur les contrôles d’accès aux documents, pour empêcher des utilisateurs non autorisés d’effectuer des changements.

Suivi d’état

C’est quelque chose que vous n’avez peut-être jamais fait ou vu dans un projet. Mais il est bon de savoir qu’une telle activité existe et peut être utilisée si requise. C’est très lié aux données stockées dans les enregistrements de configuration, qui ont les champs suivants :

• Identifiant, Version, Dernière MàJ, Statut actuel, Propriétaire, Utilisateurs.
• Date du prochain référencement, items liés, etc.

Vérification et Audit

Il s’agit de vérifier que les produits sont en accord avec les données contenues dans les enregistrements de configuration. Par exemple : Est-ce que certains utilisateurs ont accès aux versions correctes des produits ? Est-ce que les produits sont là où ils devraient être ? Est-ce que leurs numéros d’identification sont corrects ? Est-ce qu’ils sont sécurisés ?

Procédure de Contrôle des Incidences et des Changements

Il s’agit ici de traiter les incidences qui peuvent être des requêtes de changement, des hors-spécification, ou des problèmes/soucis. Il y a 5 étapes dans la procédure de Gestion des Incidences et des Changements : Collecter, Examiner, Proposer, Décider et Mettre en œuvre.

• Collecter: Catégoriser l’incidence, formelle, informelle, type ? (3 types).
• Examiner: Evaluer l’impact sur les objectifs du projet.
• Proposer: Proposer des actions - identifier les options, évaluer et recommander.
• Décider: Accepter ou rejeter la solution recommandée.
• Mettre en œuvre: Appliquer la solution choisie.

Traiter les Incidences de Projet

Le diagramme suivant montre un aperçu de la manière dont les trois types d’incidences sont traitées.

• Requête de Changement - Remplir un formulaire de Requête de Changement (description, priorité, coûts, options, options recommandées, etc.). L’Autorité de Changement décide de l’acceptation ou du rejet de la requête.
• ** Hors-Spécification** - Remplir un Rapport d’Incidence détaillant le hors-spécification. L’Autorité de Changement décide de la marche à suivre.
• Problème / Souci (Autre) - Ces autres incidences peuvent être positives ou négatives. Le Chef de Projet peut les gérer si elles n’excèdent pas le seuil de tolérance. Autrement il demandera conseil au niveau de management supérieur.

Rôles et Responsabilités

• Direction Entreprise ou Programme
  • Fournit la stratégie de l’Entreprise ou du Programme en matière de contrôle des changements, résolution des incidences et Gestion de la Configuration.
• Exécutif
  • Détermine l’Autorité de Changement et le Budget de Changement.
  • Etablit les échelles pour la gravité, les incidences, les priorités.
• Comité de Pilotage
  • Répond aux demandes de conseil du Chef de Projet.
  • Prend des décisions sur les incidences remontées par le Chef de Projet.
• Chef de Projet
  • S’occupe de la procédure de Gestion de la Configuration.
  • S’occupe de la procédure de Contrôle des Incidences et Changements.
  • Crée et maintient le Registre des Incidences et met en œuvre les actions correctives.
• Chef d’Equipe
  • Met en œuvre les actions correctives assignées par le Chef de Projet.
• Assurance Projet
  • Fournit des conseils sur l’examen et la résolution des incidences, et vérifie que les procédures de la Stratégie de Configuration sont bien appliquées.
• Support Projet
  • Administre la Gestion de Configuration.
  • S’occupe des tâches administratives des procédures de Contrôle des Incidences et Changements.
  • Maintient les Enregistrements de Configuration des produits.