Astuces pour le management des Changements dans le Projet

L’article de Dave Nielsen sur PMHUT m’a paru mériter une traduction pour les chefs de projets francophones qui n’auraient pas envie de faire l’effort de le lire en Anglais. Pour les autres: http://www.pmhut.com/project-change-management-tips

La première partie sur les causes de changements est intéressante car nous pensons la plupart du temps aux utilisateurs ou clients qui vont changer d’avis ou affiner leurs demandes au fil du projet, alors que d’autres sources auront beaucoup plus d’impact:  réductions budgétaire, délais plus courts, ressources clés qui nous sont retirées, pression de la compétition…

La seconde partie est pleine de bons conseils pour démarrer du bon pied avec une réutilisation de l’existant dans l’entreprise, la modération dans ses ambitions, la prévision des moyens nécessaires à gérer les modifications (c’est la part qui dans mon expérience est la plus mal faite), l’éducation de tous sur le processus et la formalisation des décisions de changement.

Un bon article qui rappelle les fondamentaux de manière simple et concrète.

J’ajouterais seulement à la liste:

  • Le fait que tout changement important devrait nous amener à revoir si le Business Case du projet est toujours viable
  • Lors de l’estimation de charge pour la nouvelle modification avoir une bonne idée de son impact éventuel sur du travail déjà réalisé (et peut-être à amender ou refaire).

Bonne lecture!

De Dave Nielsen

Il y a deux domaines de connaissance qui détermineront combien le produit que vous construisez satisfera les besoins pour lesquels il a été construit. Le premier est la gestion des exigences, ou le management de la portée. La manière dont vous capturez les besoins initialement et les tracez partout dans la conception et la construction aura un impact profond sur combien votre produit répondra aux exigences de votre client. Le deuxième est la gestion des changements. Les besoins que votre produit adressera ne sont pas statiques aussi s’engager dans un projet qui ne pourrait supporter des changements aux besoins originaux est voué à l’échec.

Les changements des exigences ne sont pas la seule source de changement. Il est très courant pour les parties prenantes et les analystes d’identifier davantage de besoins fonctionnels comme ils définissent les premiers. Laissez-moi vous donner un exemple. Disons que vous construisez une boutique en ligne (un site Web commercial) et vous avez besoin d’un moyen d’alerter votre client d’une vente promotionnelle que vous conduisez sur un sous-ensemble de vos produits. Vous découvrez que la plate-forme que vous utilisez pour construire le site Web supporte une nouvelle sorte de fenêtre contextuelle donc vous décidez que celle-ci est la meilleure façon de répondre à ce besoin. L’approche de fenêtre contextuelle a une application potentielle beaucoup plus large donc vous décidez que la fenêtre contextuelle serait également en réalité la meilleure façon de traiter le choix d’expédition, mais vous avez déjà conçu cette fonction sans utiliser de fenêtre contextuelle. C’est une source légitime de changement.

Il y aura d’autres sources de changement qui n’ont aucun rapport avec des besoins. Prenez le budget comme exemple. Vous pouvez avoir amorcé votre projet pendant un temps « de boom » dans l’économie quand les finances de votre organisation étaient robustes et vos sponsors ont prévu une solution « plaquée or » de leurs besoins fonctionnels. Maintenant l’économie est dans une récession et le budget n’est plus disponible pour la solution « plaquée or » donc vous devez réduire la portée du projet.

Le calendrier / les délais peuvent aussi être sources de changement. Vous pouvez avoir amorcé votre projet quand un temps de réalisation de 18 mois aurait mis votre produit sur le marché avant votre compétition, mais maintenant vous apprenez que la compétition a le projet d’annoncer leur version du produit au marché et ils ont fait de la publicité pour une introduction dans 15 mois. Vous devez maintenant changer vos plans pour livrer sous 15 mois afin de préserver votre position commerciale.

La gestion des exigences et le management des changements travaillent main dans la main pour réaliser le produit dont votre client a besoin pour réussir, quand ils en ont besoin et pour un juste coût. Votre projet va nécessairement échouer peu importe à quel point les besoins sont bien recueillis si vous n’avez pas de bon processus pour gérer les modifications. Un bon processus sera efficace dans l’exécution des bons changements justes et le rejet des mauvais. Pour ce faire, le processus doit identifier les activités qui collecteront des informations précises sur lesquelles baser une décision et les bonnes personnes pour prendre la décision.

1. Ajustez le processus à votre organisation. Si votre organisation n’a jamais mis en œuvre de management de changement vous serez forcés de définir les tâches et les responsabilités pour supporter le processus à partir de zéro. Rappelez-vous juste que vous avez 2 buts clefs : réunir toutes les informations précises nécessaires aux décideurs pour approuver ou rejeter le changement en question et avoir les bonnes personnes pour prendre ces décisions. Vous voulez réaliser ces objectifs avec la moindre quantité d’agitation possible. Ne sautez pas d’étapes qui supporteraient ces buts, mais ne créez pas d’étapes inutiles pour satisfaire la vision de quelqu’un d’autre et ne pas rendre les étapes excessivement onéreuses. Ajustez des processus existants si votre organisation en a. Par exemple, vous pouvez ne pas avoir un processus de management des changements de projet, mais un processus pour gérer les changements dans les activités opérationnelles. Examinez ce processus pour voir quelles activités s’adapteraient aux besoins de votre projet. Vous devriez être capables pour le moins de réutiliser le formulaire de demande de changement du processus existant. On devrait aussi prendre en considération la méthodologie de développement logiciel choisie pour le projet, si le produit est un logiciel applicatif. Des méthodes de développement de type agiles ne devraient pas être surchargées par des activités de gestion des changements.

2. le contrôle des changements n’est pas « une taille unique pour tous ». Il y aura des changements sur lesquels vous aurez besoin de toutes les tâches votre processus. Ceux-ci auront tendance à être les plus grands, par exemple l’introduction d’un nouveau jeu de fonctionnalités ou un changement significatif de budget ou de calendrier. Les changements qui n’impliquent pas de modification majeure de portée, planning, ou budget ne devraient pas exiger qu’un sponsor prenne une décision. Concevez votre processus de management des modifications pour accommoder tout autant les changements majeurs où une décision devrait être prise par un sponsor, que les changements mineurs où la décision peut être prise par vous-même, ou un autre membre de l’équipe.

3. Prévoyez du temps dans votre plan pour l’analyse et les activités d’investigation qui seront nécessaires pour déterminer le coût de mise en œuvre d’une requête de changement. Il est impossible de prévoir combien de temps sera nécessaire parce que vous ne pouvez pas prévoir combien de changements vous recevrez ni leur complexité. Si vous saviez quels changements vos parties prenantes vont demander, vous les intégreriez dans les besoins initiaux. Une façon de s’attaquer à ce manque d’informations est de créer un tampon avec un pourcentage de l’effort estimé et de suivre à la trace ses heures utilisées. Un inconvénient de cette approche est qu’il est très difficile de prédéterminer qui aura besoin du tampon. Les développeurs et les testeurs seront typiquement consultés pour l’évaluation d’effort dans des projets logiciels, mais des analystes métier et d’autres peuvent aussi être nécessaire pour examiner les demandes. Vous devrez identifier un recours quand le tampon sera entièrement épuisé. Vous pouvez demander un changement pour obtenir davantage de temps d’analyse. Vous pouvez aussi fermer le processus au public et retarder toute nouvelle analyse jusqu’à l’itération suivante, si vous faites du développement logiciel itératif.

4. Éduquez votre équipe et vos parties prenantes sur le processus que vous définissez pour votre projet. Les experts de sujet (les Subject Matter Experts : SME) qui seront appelés pour analyser et rechercher afin de décider du coût des changements demandés doivent comprendre leurs rôles dans votre processus, comment le processus les engagera et comment leurs délais seront établis. Les parties prenantes devraient aussi être formées sur comment le processus gérera les changements qu’ils demanderont. Ils devraient connaître les informations et le niveau de détail qu’ils devront fournir, les attentes et les demandes sur leur temps pour répondre aux questions que les SME peuvent avoir au cours de leur analyse, la temps de réponse auquel ils peuvent s’attendre quand ils demandent un changement, le processus de prise de décision et comment le processus communiquera avec eux. Tous les membres de l’équipe et les parties prenantes devraient être formés sur le processus, y compris les sponsors.

5. Suivez à la trace chaque modification dans un journal de modifications. Ce journal deviendra une source centrale d’informations sur les changements soumis. Les Informations qui devraient être suivies à la trace incluront : identifiant, date reçue, créateur, statut actuel, propriétaire actuel, décision, coût (effort ou argent) et date de mise en œuvre (si applicable). Le journal deviendra un outil de communication clef tant pour vous que pour votre équipe. Il devrait être affiché dans un emplacement central, fournir un accès en lecture à chacun sur l’équipe et l’accès en écriture à vous ou à la personne responsable de gérer le changement sur votre projet. Ne négligez pas d’enregistrer l’effort ou le budget global dépensé sur les requêtes de changement. Ces informations seront utiles pour expliquer où le budget ou le temps ont été dépensés.

6. N’oubliez pas de redéfinir les références de base de votre projet après un changement de portée, durée, budget, ou des standards de qualité qui seraient décidés. La plupart des chefs de projet se rappelleront toujours de mettre à jour leur plan MS Project après un changement, mais pas tous ne se rappelleront de changer d’autres artefacts comme les rapports, les diagrammes et les graphiques qui visualisent la performance du projet et l’atteinte des objectifs. Quand vous ajustez votre plan MS Project afin de refléter une nouvelle date finale, n’oubliez pas de changer votre Coût Budgété du Travail Exécuté (Budgeted Cost of Work Performed : BCWP) et de recalculer votre Indice de Performance des délais (Schedule Performance Index : SPI).

Ces astuces ne feront pas fonctionner un mauvais processus de management des modifications, ni ne remplaceront un processus de management des modifications, mais ils vous aideront à définir un bon processus et faciliteront sa mise en œuvre.

n'hésitez pas à commenter les billets et à partager vos idées.

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 )

Photo Google

Vous commentez à l’aide de votre compte Google. 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 )

Connexion à %s

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.