Gestion de configuration des données projet

Le projet en configuration

Mettre les éléments du projet en configuration est surement une bonne pratique, mais il ne faut pas se tromper sur les éléments dont on a besoin de réellement suivre l’évolution (ou les écarts) ainsi que le processus associé.

Généralement le planning, porteur des données de coûts, de délais et de charge du projet est enregistré à l’état de référence et actualisé (les écarts apparaissent tout le temps).

Il est impossible sur un planning de 1000 ou 10000 tâches de gérer en configuration l’intégralité du domaine des tâches même si un certain nombre de possibilité existe pour analyser en détail les évolutions. Le rôle du PMO est de suivre et d’alerter régulièrement sur l’évolution de la situation et les écarts les plus importants.

Le processus de gestion de configuration suppose la désignation d’éléments particuliers dont le projet a besoin de maîtriser l’évolution (cause et impact) et d’un processus spécifique qui autorise ces changements (arbitrage).

Dans le cadre d’une relation contractuelle (bon, un projet se traite toujours avec un client qu’il soit externe ou interne) c’est réellement une décision du projet (avec son client) et selon la nature du contrat, de désigner les éléments importants pouvant avoir un impact significatif sur le résultat final comme l’exploitation du projet, le financement, l’organisation, ….

Un processus

Définir les articles de configuration du projet

Cela pourrait être

  • Pour des dates :
    • Des jalons contractuels (entre client externe et maitrise d’œuvre)
    • Des jalons objectifs internes (entre direction de projet / chef de Projet et WP)
  • Pour les couts (et charge)
    • De cout à terminaison du projet (entre client externe et maitrise d’œuvre)
    • Le coût à terminaison des WP (entre direction de projet / chef de Projet et WP)
    • Accessoirement, le flux de trésorerie, les charges globales ou échéancées …

Un changement ne pourra entrer dans le processus de configuration seulement si le chef de projet le décide (un changement de facto sur une date courante impactant un élément de configuration ne pourra à lui seul déclencher le processus).

Établir les seuils de déclenchement

Concernant les seuils une évolution pourrait être considérée comme :

  • majeure, si après acceptation projet – et la direction des projets
    • Un jalon contractuel sur le chemin critique est décalé de plus de 3 mois
    • Un jalon contractuel qui n’est pas sur le chemin critique est décalé de plus de 6 mois
    • Le cout à terminaison du projet est augmenté de plus de +5%
  • mineure, si après acceptation projet – et la direction des projets
    • Un jalon contractuel sur le chemin critique est décalé de plus de 1 mois
    • Un jalon contractuel qui n’est pas sur le chemin critique est décalé de plus de 3 mois
    • Un jalon objectif interne est décalé de plus de 6 mois
    • Le cout à terminaison du projet est augmenté de plus de +2%

Faire vivre le système (Processus)

Ces impacts seront discutés pour validation en comité de configuration et résultera, le cas échéant, la mise en place d’une nouvelle référence projet.

NB : les activités étant liées, seul sera retenu l’effet maximal (un jalon interne impactant un jalon objectif impactant un jalon contractuel) et immédiat (on focalise sur le jalon contractuel le plus proche).

Tout autre évolution, comme rappelé plus haut, sera notée, présentée et justifiée lors du processus périodique de contrôle de projet – mensuel en interne et trimestriel en externe.

Conclusion

Dans tous les cas, je conseille de débuter le processus par le minimum d’éléments de configuration et de contrainte de seuil et de compléter/ajuster en tant que de besoin.

En savoir plus …

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.