Organigramme du processus de demande de changement de projet (portée, coût,…
Un organigramme du processus de demande de modification de projet couvrant le registre des modifications, l'évaluation d'impact, la décision de tolérance, l'approbation du groupe de pilotage et la redéfinition des bases.
Qu'est-ce que le processus organigramme du processus de demande de changement de projet (portée, coût,… ?
Une demande de modification de projet demande de modifier quelque chose qui a déjà été convenu : la portée, le coût ou les dates dans la référence approuvée. C’est ce qui la distingue de la replanification ordinaire. Réordonner les tâches, déplacer une personne entre les flux de travail ou absorber un glissement de deux jours dans le flotteur est le travail du chef de projet et ne nécessite aucune demande. Ce processus commence lorsque quelqu'un demande quelque chose que la ligne de base ne promet pas actuellement, et se termine soit par une ligne de base qui dit quelque chose de différent, soit par la demande fermée et la raison enregistrée.
Il s’agit du contrôle des modifications du projet, et non de la gestion des modifications des services informatiques. Si votre décision est de publier ou non une modification dans un service en direct, avec un CAB, un calendrier de modification, une fenêtre de temps d'arrêt et un plan de restauration, l'organigramme du processus de gestion des modifications chez /fr/templates/processus-de-gestion-des-changements et le processus général de contrôle des modifications chez /fr/templates/processus-de-controle-des-changements couvrent ce terrain. Les questions ici sont de nature différente : combien coûte le changement, ce qu’il entraîne, qui le finance et si l’analyse de rentabilisation est toujours valable. Il ne s’agit pas non plus de gestion du changement organisationnel, de la discipline axée sur les personnes derrière des modèles tels qu’ADKAR, et ce n’est pas non plus une porte d’étape. Si vous décidez de poursuivre à la fin d'une phase plutôt que de modifier la ligne de base, utilisez le processus de décision go/no-go de /fr/templates/processus-de-decision-go-no-go-arbre-de-decision-de-preparation-au-lancement.
Deux décisions portent la palme. Le premier est la tolérance : le changement est-il suffisamment petit pour que le chef de projet puisse l'approuver dans le cadre d'une autorité déléguée, ou suffisamment important pour nécessiter le groupe de pilotage. Sans limites écrites, soit tout arrive au tableau, ce qui le transforme en file d'attente, soit rien n'y arrive et les modifications sont apportées de manière informelle. La seconde est la réponse à laquelle l’autorité chargée du changement est autorisée. Approuver et rejeter sont simples ; defer est celui que la plupart des registres gèrent mal, car un changement stocké sans date de révision est impossible à distinguer d'un changement qui a été ignoré. Ici, le report a son propre chemin de retour vers un examen ultérieur, et le rejet a un état explicitement fermé plutôt que le silence.
Ce que couvre cet organigramme
Dans ce modèle
- Cinq couloirs (demandeur, chef de projet, équipe de projet, finances et autorité de changement/groupe de pilotage) répartis en cinq étapes : demande, évaluation d'impact, autorisation, mise à jour de la ligne de base, et mise en œuvre et clôture.
- Admission via les couloirs du demandeur et du chef de projet : formulez une demande de modification avec sa description et sa justification, enregistrez la modification dans le registre, puis une « Demande suffisamment claire pour être évaluée ? » porte qui renvoie les requêtes légères au demandeur pour ajouter des détails et une justification avant de saisir à nouveau le même contrôle.
- L'évaluation d'impact dans l'équipe de projet et les finances : évaluer la portée, le calendrier et l'impact sur la qualité, estimer le coût et évaluer les risques, valider le coût et la source de financement, puis enregistrer un enregistrement d'évaluation d'impact (options, recommandation et option de ne rien faire incluses) plutôt qu'un fil de commentaires.
- La décision de tolérance, « Dans la tolérance du chef de projet ? », qui achemine l'Intant vers l'approbation sous autorité déléguée et le Dépassement vers la transmission au groupe de pilotage.
- La décision de l'autorité de modification, « Approuver, rejeter ou différer ? »
- Mise à jour de la référence jusqu'à la clôture : mettez à jour la référence du projet, les finances mettent à jour le budget et les prévisions de coûts, communiquent le changement aux parties prenantes, l'équipe de projet met en œuvre le changement dans le plan et la livraison est confirmée avant la clôture de l'enregistrement des modifications.
Quand utiliser ce modèle
- Vous rédigez la section sur le contrôle des modifications d'un plan de gestion de projet ou d'un manuel de PMO et souhaitez que le parcours depuis la demande jusqu'au plan redéfini sur une seule page.
- Les modifications sont convenues lors de réunions et de discussions, de sorte que personne ne peut dire plus tard ce qui a été approuvé, par qui, ou ce que cela a ajouté au coût et à la date de fin.
- Vous devez régler l'autorité déléguée avant le démarrage du prochain projet : ce que le chef de projet peut absorber et ce qui doit revenir au groupe de pilotage.
- Vous confiez un projet à un nouveau responsable ou briefez un nouveau groupe de pilotage, et devez montrer comment les modifications de portée, de coût et de calendrier sont autorisées.
- Un PMO ou un programme standardise le contrôle des modifications dans tous les projets, chacun le faisant différemment, avant de configurer un registre des modifications dans un outil de livraison.
Comment cela fonctionne
Renommez les voies selon vos vrais rôles
Remplacez le demandeur, le chef de projet, l'équipe de projet, l'autorité financière et de changement/le groupe de pilotage par les rôles que vous avez réellement. Sur un petit projet, l'autorité de changement peut être un sponsor unique et les finances peuvent être un partenaire commercial qui examine les chiffres par courrier électronique. Fusionnez les voies plutôt que de dessiner des organes de gouvernance qui n'existent pas, et maintenez le nombre de voies à cinq ou moins pour que le graphique reste lisible.
Écrivez vos tolérances à côté de la décision
"Dans la tolérance du chef de projet ?" n'est utile qu'avec des chiffres derrière. Enregistrez l'écart de coût et de calendrier que le chef de projet peut autoriser, ainsi qu'une règle de portée telle qu'aucun changement dans les livrables, les avantages ou les engagements contractuels convenus. Si vous exécutez PRINCE2, il s'agit de la tolérance déléguée par le conseil d'administration du projet, et cela peut s'accompagner d'un budget de changement afin que les changements de routine n'atteignent jamais le conseil d'administration. Convenez des limites dès l'initiation, pas la première fois qu'elles sont testées.
Définir ce que doit contenir l’analyse d’impact
Transformez « Enregistrer l'évaluation d'impact » en un véritable modèle : effet sur le périmètre, le calendrier, le coût, la qualité et le risque, la source de financement, les options envisagées, une recommandation et l'option de ne rien faire. Nommez qui évalue chaque dimension et combien de temps cela prend, car une évaluation qui prend trois semaines se transforme en une décision prise sans une.
Nommer l'autorité de changement et sa cadence
Lors de l'examen du groupe de pilotage, notez qui sont les approbateurs, si un quorum est nécessaire, à quelle fréquence ils se réunissent et la date limite pour figurer à l'ordre du jour. Décidez explicitement de ce qui se passe entre les réunions : soit une personne nommée peut autoriser en urgence et le signaler lors de la prochaine révision, soit le changement attend. Laisser cela indéfini est ce qui produit des changements approuvés dans les couloirs.
Limiter le report dans le temps
Une modification différée nécessite une date de révision, un propriétaire et un statut actif dans le registre, c'est pourquoi la branche Différer revient ici à une révision ultérieure du groupe de pilotage plutôt qu'à un terminateur. Vérifiez les éléments différés à chaque révision et clôturez ceux qui ont été dépassés, avec la raison enregistrée, afin que le registre reflète les décisions plutôt que de les accumuler.
Définissez la règle de re-baselining, puis publiez et versionnez le graphique
Indiquez quelles modifications approuvées déclenchent une nouvelle référence formelle et lesquelles sont absorbées dans les prévisions, et exigent que la référence de modification soit enregistrée par rapport à la nouvelle version de référence. Conservez les références antérieures afin qu’un écart puisse encore être expliqué des mois plus tard. Partagez ensuite le diagramme où se déroule le travail (à côté du formulaire de demande de modification et dans le manuel du projet) et conservez son propre historique des versions afin de pouvoir montrer quand la procédure a changé et pourquoi.
Questions fréquentes
Quelle est la différence entre une demande de changement de projet et une gestion du changement informatique ?
Ils répondent à différentes questions. Une demande de modification de projet demande si une base de référence convenue (portée, coût, dates et souvent avantages) doit être modifiée, et la décision est commerciale : combien cela coûte, quels sont les retards, qui la finance et si l'analyse de rentabilisation est toujours valable. La gestion des changements informatiques demande si une modification apportée à un service en direct doit être publiée, et la décision est opérationnelle : risque pour les utilisateurs, tests, fenêtre de temps d'arrêt et restauration. Si la conversation implique un CAB, un calendrier de changement et un plan de restauration, utilisez l'organigramme du processus de gestion du changement. S’il s’agit d’un groupe de pilotage, d’une date de fin révisée et d’une ligne budgétaire, c’est le bon diagramme.
Que doit inclure une demande de modification de projet ?
Assez pour que quelqu'un d'autre l'évalue sans réunion : ce qui change et pourquoi, qui l'a soulevé et quand, le déclencheur (une nouvelle exigence, un défaut, une dépendance externe, une décision inversée), l'urgence, qui est concerné et que se passe-t-il si rien ne change. L'évaluation ajoute le reste : effet sur la portée, le calendrier, le coût, la qualité et le risque, la source de financement, les options envisagées et une recommandation. Conservez les deux dans des dossiers séparés. La demande est constituée des mots du demandeur et l'évaluation est la réponse du projet, et leur fusion rend impossible de voir plus tard ce qui a été réellement demandé.
Qui approuve une demande de modification de projet ?
Cela dépend de la taille, c'est à cela que sert la décision de tolérance dans ce tableau. Les modifications qui correspondent à l'écart auquel le chef de projet a été délégué lors du lancement sont approuvées dans la voie du chef de projet et enregistrées. Tout ce qui va au-delà est confié à l'autorité chargée du changement, normalement le groupe de pilotage, le comité de projet ou le sponsor. PRINCE2 désigne l'autorité de changement comme un rôle auquel le comité de projet peut déléguer, parfois avec un budget de changement attaché afin que les changements de routine ne nécessitent pas une décision complète du conseil d'administration, et le contrôle des changements intégré de PMI utilise un comité de contrôle des changements dans le même but. Quel que soit le nom que vous lui donnez, notez les limites : une tolérance indéfinie signifie que soit tout est intensifié, soit rien ne l'est.
Que signifie réellement différer un changement ?
Que la décision soit reportée plutôt que refusée : généralement parce que l'impact n'est pas encore clair, que le changement dépend d'une autre décision, ou qu'il appartient à une phase ou à une version ultérieure. Cela ne fonctionne que si le report est limité dans le temps. Dans ce graphique, la branche Différer est acheminée vers une étape de maintien qui redépose le changement lors d'une révision ultérieure du groupe de pilotage, et non vers un terminateur, car un changement différé sans chemin de retour est un rejet que personne n'a eu à justifier. Attribuez à chaque élément différé une date de révision, un propriétaire et un statut visible dans le registre.
Devez-vous redéfinir la base de référence après chaque changement approuvé ?
Redéfinissez tout ce qui modifie ce que le projet s'est engagé à fournir, à quel moment et pour combien. Sinon, les rapports sur les écarts mesurent un plan que vous avez déjà accepté d'abandonner, et chaque rapport de situation nécessite une explication verbale. Conservez les références précédentes plutôt que de les écraser, enregistrez la référence de modification par rapport à la nouvelle version et notez la date d'approbation. Les petits changements approuvés dans les limites de tolérance sont généralement intégrés dans les prévisions au lieu de déclencher une nouvelle référence formelle : indiquez lequel est lequel dans votre plan afin que deux personnes lisant le même rapport arrivent au même chiffre.
Comment ce processus arrête-t-il la dérive de la portée ?
En rendant visible le coût d’un changement avant qu’il ne soit convenu plutôt qu’après sa livraison. La dérive de la portée est rarement une seule décision importante ; c'est une série de petits ajouts absorbés par une équipe qui ne les a jamais envoyés en évaluation. Les contrôles qui comptent ici sont le registre, donc chaque demande a un enregistrement ; l'étude d'impact, donc personne n'approuve un ajout sans voir ce que cela fait sur les dates et le budget ; et les limites de tolérance, afin que le chef de projet sache exactement où s'arrête sa propre autorité. Le processus ne peut pas empêcher les changements, et ne devrait pas le faire : il les rend délibérés et imputables.