Comment changer les références de base d’un projet

Par Gérard Perron, PMP

Les « baselines », selon l’expression de nos collègues anglophones, constituent la colonne vertébrale du projet. Il est occasionnellement nécessaire de les changer, mais ce n’est pas évident de le faire sans dénaturer le projet et surtout de le faire dans le respect des parties prenantes. Le présent article présente la notion de « références de base », selon la traduction du référentiel du PMI (Project Management Institute), et la manière de les changer.

Il faut considérer les références de base comme dynamiques. Elles évoluent avec la progression du projet. Comme il s’agit d’éléments sur lesquels les parties prenantes se sont entendues, il faut qu’elles aient donné leur accord, qu’elles aient été consultées ou du moins qu’elles aient été informées. Le plan de communication du projet devrait préciser comment les changements aux références de base doivent s’effectuer et surtout le niveau d’implication des différentes parties prenantes.

Qu’entend-on au juste par « références de base »?

Essentiellement, ce sont les données principales du projet sur lesquelles tout le monde s’est entendu. De façon plus spécifique (même si c’est un peu technique), je vais me référer au référentiel du PMI[1] pour préciser la notion de « références de base ».

  • « Le cycle de vie retenu pour le projet et les processus qui seront exécutés au cours de chaque phase.
  • Les processus de management de projet sélectionnés par l’équipe.
  • Le niveau de mise en œuvre de chaque processus sélectionné.
  • La description des outils et techniques à utiliser pour exécuter ces processus.
  • La façon dont les processus sélectionnés seront utilisés pour le management du projet, y compris les dépendances et les interactions entre ces processus et les données essentielles d’entrée et de sortie.
  • La façon dont le travail sera effectué pour atteindre les objectifs du projet.
  • Le plan de management des modifications précisant la façon dont les modifications seront surveillées et maîtrisées.
  • Le plan de management de la configuration précisant comment la gestion de la configuration sera conduite.
  • La façon de maintenir l’intégrité des références de base des mesures de performances.
  • Les besoins et les techniques de communication entre les parties prenantes.
  • Les revues de management essentielles, pour ce qui est de leur contenu, étendue et calendriers, de façon à traiter les problèmes importants non résolus et prendre les décisions en suspens.

Parmi tous les exemples de références de base, on peut citer :

  • La référence de base de l’échéancier,
  • La référence de base de performance des coûts, et
  • La référence de base du contenu. »

Ce qu’il faut retenir de cette énumération c’est qu’il s’agit des données importantes du projet. Elles se réfèrent aux spécifications du projet, à ses normes de qualité ou aux objectifs visés concernant le budget, l’échéancier ou les ressources impliquées.

Le chef de projet sera responsable de contrôler le respect des références de base et de gérer les changements qui y seront apportés. Ceci signifie que si une partie prenante est témoin d’un changement aux références de base, elle doit communiquer cette information au chef de projet. Ce dernier devra préciser le délai (une semaine, deux semaines…) à respecter pour effectuer un changement aux références de base. Ce délai dépendra de la rapidité à analyser les répercussions du changement sur l’ensemble du projet et à obtenir les autorisations nécessaires.

Origine du changement aux références de base

Les exigences de changement proviennent essentiellement de quatre sources[2] :

Le client

Il peut vouloir modifier le contenu du projet en y apportant des changements aux caractéristiques du produit ou du service. Il peut changer le coût du projet pour tenir compte des modifications à sa situation financière. Il peut aussi désirer modifier l’échéancier pour respecter des étapes importantes de son évolution.

☝        Lors de l’organisation d’un colloque où j’étais chargé de projet, le client pour qui nous organisions le colloque a modifié ses objectifs de rentabilité. Il avait revu ses états financiers et devait générer plus de revenus. Le comité organisateur a donc dû revoir le plan de commandite pour s’ajuster à la nouvelle exigence du client.

La réglementation

Un gouvernement local ou national qui amène un changement législatif ou réglementaire peut obliger une modification importante au projet pour respecter la nouvelle règle. Dans un marché qui se mondialise, les règles peuvent même être internationales.

D’origine externe

Dans un monde en changement, il faut s’attendre à des bouleversements des conditions politiques, économiques ou sociales. De même, les changements climatiques sont de plus en plus nombreux et obligent des ajustements souvent rapides et importants.

D’origine interne

Les ressources humaines du projet peuvent être à l’origine d’un changement (une ressource affectée ailleurs, la maladie…). Le développement du produit peut s’avérer plus complexe ou plus simple que prévu. Un partenaire peut avoir un retard important qui occasionne un délai de fabrication ou de livraison.

Quelque soit l’origine de la demande de modification aux règles de base, il faut la gérer et les principales règles de conduite sont les suivantes :

  • « Tous les changements doivent être gérés par une personne : le chef de projet.
  • Tous les changements doivent être communiqués au chef de projet.
  • Des règles claires doivent être établies en regard du calendrier pour soumettre des changements (hebdomadaire, aux deux semaines…), afin que le suivi soit systématique. Le suivi des changements permet d’informer les parties prenantes, de documenter et d’analyser les problèmes, et de négocier l’assistance nécessaire à la gestion efficace des changements.[3] »

Dans tous les cas, le chef de projet ne doit pas hésiter à prendre en charge les changements aux règles de base le plus rapidement possible (en se rappelant que le suivi aux règles de base doit se faire sur une base régulière et non au hasard). Il doit se rappeler que l’évaluation de l’impact des changements sur l’ensemble du projet et la révision des plans demande du temps. Le chef de projet peut se donner ses propres lignes directrices pour gérer les changements. En voici des exemples :

  • « la personne qui gère les changements aux règles de base gère aussi les changements dans les membres de l’équipe.
  • Lorsqu’une crise survient, il ne faut pas paniquer, mais suivre la procédure prévue.
  • Informez toutes les parties prenantes intéressées des changements approuvés et exécutés.
  • Clarifiez les niveaux d’autorité et d’approbation et assurez-vous que les bonnes personnes exécutent ces tâches.
  • Prévoyez une réserve de temps, de ressources et d’argent pour les changements.
  • Avant d’approuver un changement, vérifiez son impact sur l’ensemble du projet.
  • Évaluez les différentes solutions de rechange. Tenez compte des contraintes établies. Faites des compromis seulement lorsque c’est nécessaire.
  • Changez les règles de base quand c’est nécessaire, mais assurez-vous de travailler en complicité avec le client.
  • Soyez patient et évaluez l’impact d’un changement avant d’en implanter un nouveau.
  • Documentez bien les changements que vous faites (quand, pourquoi, qui a approuvé, le coût…). Ce sera utile pour expliquer, au besoin, le pourquoi et surtout ça servira d’information pour le futur.
  • Évaluez le changement pour vous assurer qu’il n’y a pas de conséquences imprévues.[4] »

C’est généralement coûteux de faire des changements dans les références de base d’un projet. Il faut donc s’assurer qu’ils sont nécessaires. Dans son livre « Managing the project team[5] », Vijay K. Verma propose un processus en sept étapes pour évaluer des changements à un projet. Nous en présentons ici un résumé.

Première étape : Cueillir l’information sur le changement ou le problème

Quels changements sont maintenant nécessaires et qui ne l’étaient pas lors de la planification du projet?

Deuxième étape : Réviser les objectifs du projet

Les nouvelles données exigent-elles une redéfinition des objectifs du projet?

Troisième étape : Préciser les priorités concernant le coût, l’échéancier et le contenu du projet.

Le dépassement de coût est-il acceptable?

Est-il pertinent de changer le contenu du projet?

Qu’est-ce qui est pire, un dépassement de coût ou un délai de livraison?

Est-ce qu’une compression des coûts va raccourcir l’échéancier de livraison?

Quatrième étape : mettre à jour l’information et l’impact sur les différents éléments du projet.

Quel est l’impact du changement sur l’échéancier, le budget, la qualité, l’enchaînement des tâches et la communication avec les parties prenantes?

Cinquième étape : Inventorier des alternatives pour atteindre les objectifs du changement.

Soyez imaginatif et mobilisez les membres de votre équipe et les parties prenantes concernées.

Sixième étape : Évaluer les solutions de rechange

Quels sont les risques et le rapport coût/bénéfice de chaque solution?

Septième étape : Prendre une décision et réviser le plan de projet.

Le changement est-il dûment approuvé et est-il bien documenté?

 

Conclusion

Il est important de se rappeler que pour bien réussir un changement il faut travailler en équipe avec les parties prenantes impliquées. Une bonne communication est la clé de la réussite.

À propos de l’auteur

Gérard Perron occupe des postes de gestion depuis 1977. Son expertise est reconnue en développement économique (développement local et coopératif) de même qu’en développement organisationnel (gouvernance d’entreprise et gestion de projet). Il a écrit un livre sur la gestion participative et un autre sur la gestion des coopératives. Il a collaboré à d’autres ouvrages en gestion organisationnelle et en développement coopératif. En 1997 et en 2003, il est choisi « Professionnel en développement économique de l’année » au Québec. Depuis octobre 2003, il est consultant spécialisé en développement économique et organisationnel. De 2007 à 2009, il fut aussi directeur général  du Project Management Institute, Section Lévis-Québec. Il est certifié « Project Management Professional » et donne régulièrement de la formation en gestion de projet (leadership, communication, initiation, préparation à la certification PMP…).

[1] Project Management Institute, Corpus des connaissances en management de projet (Guide PMBOK), 4e édition, 2008, Section 4.2.3

[2] Vijay K. Verma, Managing the project team, Project Management Institute, 1997, pages 46 à 49.

[3] Vijay K. Verma, Managing the project team, Project Management Institute, 1997, page 49, traduction par l’auteur.

[4] Idem, pages 49 et 50.

[5] Vijay K. Verma, Managing the project team, Project Management Institute, 1997, pages 50-51.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :