5.0 Gérer les modifications

 

Aperçu (5.0. P1)

 

Tout le monde en convient : la seule constante dans le monde, c’est le « Changement ». Vous pouvez concevoir des plans parfaits, mais ils ne représentent rien face à n’importe quel changement potentiel qui viendrait à survenir. Plus la durée de votre projet est longue, plus vous aurez probablement affaire à des changements. C’est la raison pour laquelle le processus TenStep conçoit très bien que les processus de définition initiale (processus 1) et de planification (processus 2) ne soient pas parfaits. Votre équipe et vous-même devez accomplir le meilleur travail que vous pouvez, étant donné l’état de vos connaissances au moment où vous l’effectuez. Et c’est déjà bien ainsi. Par la suite, vous devez gérer les modifications.

Au cours d’un projet, plusieurs formes de changements, reliées entre elles, peuvent se passe.

  • Des modifications du contenu

  • Des modifications de la configuration

  • Des changements généraux (pas des modifications du contenu ni de la configuration)

Diagramme de flux simplifié

Cette section du processus TenStep couvre tous les aspects des modifications. Pour la plupart des projets, l’aspect le plus important, au niveau du changement, est le management des modifications du contenu, et c’est de cet aspect qu’il est le plus question au cours de l’exécution de ce processus.

Modifications du contenu (5.0. P2)

« Contenu »  est le terme utilisé pour désigner la totalité du travail ainsi que les limites du projet. Le contenu est utilisé pour définir ce que le projet livrera et ce qu'il ne livrera pas. Pour les plus grands projets, la définition du contenu peut inclure les livrables importants qui sont créées, les organisations concernées, les transactions affectées, les types de données incluses, etc.

Si vous regardez les raisons pour lesquelles les projets échouent, vous vous trouvez habituellement confronté à deux problèmes : Soit que l'équipe n'a pas passé assez de temps à définir le travail, soit qu’ il y avait un manque de management du contenu du projet. Même si le chef de projet a réalisé du bon travail au niveau de la définition du contenu, la partie difficile est de gérer le projet à l’intérieur de ce contenu, tel qu’il a été convenu au départ.

Le but du management du contenu du projet est de protéger la viabilité de la Charte de projet approuvée et celle des exigences commerciales, elles aussi approuvées. En d’autres termes, la Charte de projet définit le contenu global du projet, alors que les exigences commerciales définissent les livrables dans le détail. L’équipe du projet s’est engagée pour une date limite et un budget, sur la base de cette définition, à la fois générale et détaillée, du contenu du projet. Si un changement des livrables est effectué pendant le projet (et habituellement cela signifie que le client réclame des éléments supplémentaires), les estimations initiales du coût, de l'effort de travail, et de la durée peuvent ne plus être valides. Si le commanditaire accepte d'inclure le nouveau travail dans le contenu du projet, le chef de projet a le droit d’exiger que les coûts, l'effort de travail et/ou la durée soient modifiés (habituellement, ils s’accroissent) pour justifier ce travail supplémentaire. Ces nouvelles estimations de coût, d'effort de travail et de durée deviennent alors le nouvel objectif approuvé.

Parfois le chef de projet pense que la gestion du contenu revient à dire « non » au client. Cela peut rendre le chef de projet nerveux et le mettre mal à l’aise.

Ce qu’il faut garder à l’esprit, c’est qu’une gestion efficace du contenu n’a d’autre intérêt que d’amener le commanditaire à prendre des décisions qui entraîneront des modifications du contenu.

Cela est très important. Peu de clients peuvent voir et exprimer chaque spécification à l'avance. Par conséquent, il y a habituellement des changements qui doivent être introduits dans le projet. Ces changements peuvent s’avérer tout à fait nécessaires pour la solution et il peut y avoir des raisons commerciales valides pour lesquelles ils devront être pris en compte. Le chef de projet et l’équipe de projet doivent savoir quand ces changements deviennent incontournables. Ils doivent alors suivre un processus prédéfini de modification du contenu. Ce processus fournit, en fin de compte, les informations appropriées au commanditaire du projet et lui permet de décider si la modification doit être approuvée, en se basant sur la valeur marchande ainsi que sur l'impact pour le projet, en termes de coûts et de délais.

Modification de la configuration (5.0. P3)

Management de la configuration est une expression par laquelle on désigne l’identification, le suivi et la gestion de l’ensemble des données techniques du projet, ou celle de leurs caractéristiques (metadata). Dans certaines entreprises, ce processus est défini de manière plus étroite et ne concerne que la gestion des éléments physiques. Voir 5.1.3.1 Gestion de la configuration pour plus de détails. 

Les changements généraux (5.0. P4)

Votre projet sera confronté à des changements qui n’entrent pas nécessairement dans la catégorie « gestion des modifications du contenu » ou « gestion de la configuration ». Ces autres changements peuvent être groupés dans une catégorie plus générale de la gestion des modifications. Par exemple, admettons qu'un des membres de votre équipe soit parti et doit d'être remplacé. Ce ne serait pas un exemple de modification du contenu et ce n'est pas une modification de la configuration. C'est un changement général. Dans ce cas, vous devriez inscrire le fait qu'un changement au niveau des ressources humaines s'est produit, déterminer l'impact du changement, mettre en place un plan pour contrôler le changement, etc. À bien des égards, vous suivrez un processus semblable à celui d'une demande de modification du contenu, bien que ce changement, ainsi que l'impact sur votre projet, ne soit pas le résultat d'une telle demande.

Une des différences principales entre la gestion des changements généraux et la gestion des modifications du contenu c’est que vous prévoyez, au cas où une modification du contenu serait demandée et approuvée, de modifier votre budget et votre échéancier pour les adapter à cette modification. Vous n’attendez pas la même chose des changements qui ne touchent pas au contenu et au budget. Ainsi, dans l'exemple ci-dessus, quand un membre de l'équipe doit être remplacé, il se produit en fin de compte, un changement qui aura probablement un certain impact sur le projet. Cependant, une modification approuvée de l’échéancier ou du budget. En fait, un changement général du type décrit ci-dessus peut occasionner un certain impact sur l’échéancier et/ou le budget. Cependant, notre hypothèse de travail pour classer un changement en tant que changement général et pas en tant que modification, c’est qu’une modification de l’échéancier et/ou du budget n’est pas automatiquement attendue comme la conséquence d’un simple changement.

  5.0.1 Définir le contenu

  5.0.2 Créer le plan de management du contenu

    5.1 Gérer les modifications / Processus

    5.2 Gérer les modifications / Techniques

    5.3 Gérer les modifications / Références rapides

 

4.3 Gérer les problèmes majeurs / Références rapides

5.0.1 Gérer les modifications / Définir le contenu

Afrique du Sud (Anglais) Allemagne (Allemand) Algérie (Français) Australie (Anglais) Les pays Arabes du golfe Belgique (Néerlandais) Brésil (Portugais) Bulgarie (Bulgare) Canada (Anglais) Chili (Espagnol) Chine (Chinois) Croatie (Croate) Équateur (Espagnol) Espagne (Espagnol) États-Unis (Anglais) France (Français) Grèce (Grec) Hongrie (Hongrois) Inde (Indien)
Israël (Hébreu) Italie (Italien) Kosovo (Albanais / Serbe) Macédoine (Macédonien) Malaisie (Malaisien) Mexique (Espagnol) Pakistan (Anglais) Pérou (Espagnol) Pologne (Polonais) Portugal (Portugais) Québec (Français) République Tchèque (Tchèque) Roumanie (Roman et Moldave) Royaume-Uni (Anglais) Russie (Russe) Singapour (Anglais) Suède (Suédois) Suisse (Allemand) Suriname (Néerlandais)
Ukraine (Ukrainien)