articles, méthodes, partages d'expérience et rdv du management de projets et de l'agilité
Nathalie Hesters, Product Manager pour Microsoft Project et Visio, a réalisé cette nouvelle vidéo qui présente la solution Microsoft de bout en bout en matière de management de projet.
En une douzaine de minutes, elle réalise une démonstration par l’exemple depuis l’établissement de critères de sélection des projets jusqu’à l’exécution, le suivi de la progression et les reporting associés à ce portefeuille et à l’ensemble des projets qui le compose.
MSP® – Managing Successful Programmes définit le management de programme comme « l’action d’organiser, diriger et déployer de manière coordonnée un dossier ou un projet et des activités de transformation, pour atteindre des résultats et des profits d’importance stratégique pour l’entreprise ».
On voit que la définition est assez proche de celle de PMI: «Un programme est, en gestion de projet, un ensemble de projets concourant à un même objectif, organisé transversalement dans une entreprise ou un organisme en général», avec une mise en exergue de la dimension transformation des Programmes dans MSP.
MSP rassemble les Bonnes Pratiques de gestion de programme déjà mises en œuvre pour réussir un changement transformationnel en appliquant une approche de management de programme. Le guide comprend un ensemble de Principes et de Processus flexibles à utiliser pour manager un programme. Cette approche a été utilisée et adoptée aussi bien dans le secteur public que privé. Les expériences des divers utilisateurs de l’approche de management de programme ont contribué à un enrichissement de la dernière édition de la méthode, parue en 2007 (la prochaine arrive très prochainement, en Août 2011).
Trois qualifications MSP sont disponibles : Foundation, Practitioner et Advanced Practitioner. Les candidats doivent réussir l’examen Foundation avant de passer un examen Practitioner.
Le premier examen de MSP consiste en un questionnaire à choix multiples de 50 questions auxquelles les candidats doivent répondre en 40 minutes. Il teste les connaissances du candidat sur la terminologie de la MSP. Le seuil de réussite est fixé à 30 réponses correctes (60 %). L’objectif du niveau Foundation est de mesurer si le candidat est capable de travailler et d’utiliser les principes fondamentaux de MSP dans un environnement de programme.
Le deuxième examen est un test objectif de deux heures et demie qui consiste en 9 questions. Le seuil de réussite est fixé à 90 points sur 180 (50 %). Cet examen a pour but de tester la connaissance des concepts de base et la compréhension de la MSP. Le niveau Practioner vise à mesurer le niveau de compréhension des principes et de la théorie du manuel MSP. Il peut également servir de tremplin pour une personne manageant des projets et amenée à manager un programme en lui permettant d’assimiler tous les concepts clés et d’acquérir un meilleur niveau de compréhension.
Ce niveau s’adresse aux gestionnaires de programmes expérimentés. L’examen consiste en une rédaction sur une étude de cas et vise à tester la compréhension et l’application de la méthode. Le temps imparti est de deux heures et demie. Il compte 3 questions pour un total de 75 points. Le seuil de réussite est fixé à 38 points (50,6 %). L’examen se fait à livres ouverts : le matériel de cours, les notes, les exemples, les copies de présentations, etc. peuvent être utilisés. Le niveau Advanced Practitioner est destiné aux directeurs et futurs directeurs de programme, ils doivent démontrer une excellente compréhension des principes et de la théorie du manuel MSP à travers des mises en pratique et un bon niveau général basé sur leur expérience de travail au sein de grands programmes.
http://www.butrain.com/Project-management-training-courses/matrix.asp
Bonnie Cooper, PMP ®
L’organisation matricielle est définie par ses fonctions verticales et ses processus ou projets horizontaux. Une matrice faible, dans le contexte du management de projet, est une organisation dirigée principalement par ses équipes fonctionnelles et les projets sont instaurés pour piloter le changement interne ou créer un avantage stratégique. Dans cet environnement, les parties prenantes du business travaillent à temps partiel sur les projets et peuvent percevoir les tâches de projet comme une distraction de leur travail quotidien régulier.
Les parties prenantes techniques jonglent souvent avec des missions multiples sur des projets en plus des tâches ad hoc opérationnelles et les problèmes des systèmes en production prendront toujours une priorité supérieure, diluant le focus sur le travail de projet. Dans cet environnement, des managers fonctionnels ont une énorme d’influence sur les missions de projet, les évaluations, la priorisation et la performance des ressources.
Le travail dans une organisation matricielle faible peut être une expérience très irritante pour des chefs de projet et le plus grand nombre de ceux qui ont travaillé pour moi ou participé à mes formations ont exprimé ces trois préoccupations :
Qui ne voudrait pas être dans le plein contrôle sans distractions et travailler avec une équipe de superstars ? Dans le monde que je viens de décrire, il n’en est pas probablement ainsi. Quelles stratégies peut-on mettre en œuvre pour traiter ces préoccupations ? Et, plus important, comment pouvons-nous transformer ces préoccupations en avantages ?
Comment créez-vous un sens d’urgence et de but afin que le membre individuel de l’équipe se concentre sur les tâches de votre projet ? Voici quelques-unes des choses que je fais :
Pendant la phase de démarrage d’un projet, je parle à chacun de la signification du projet pour l’organisation. Pourquoi il a été lancé, le but business, le problème qu’il résout ou la nouvelle opportunité qu’il créera. Ce que j’ai découvert est que les personnes se sentent bien quand elles savent qu’elles travaillent sur des choses importantes.Des équipes de projet doivent avoir le jeu de compétences nécessaires pour compléter leurs tâches, mais il n’est pas inhabituel d’obtenir quelqu’un qui est plus disponible qu’approprié pour le travail.
Je me concentre sur les basiques de la délégation de tâche, je me préoccupe énormément que le travail soit découpé en livrables concrets et qu’il y ait une grande clarté dans le travail à réaliser. Si de la formation ou de l’expertise sont exigées pour informer sur le travail, cela est prévu. Si le mentoring technique interne est nécessaire, cela est arrangé. J’essaye de fournir un chemin clair aux individus vers la réussite et je constate que cela se traduit souvent en que l’individu choisit de travailler sur les tâches de mon projet plutôt que sur tout autre travail plus ambigu.
Ma vue est que le succès dans un environnement matriciel se rapporte à l’influence, les relations et l’engagement.J’encourage les membres de l’équipe à prendre leurs responsabilités et les managers fonctionnels de la même façon et j’enrôle le support des sponsors pour entretenir la visibilité et l’importance de projet. Je construis la confiance en démontrant un intérêt personnel dans les résultats, dans le développement des personnes et en étant conscient des priorités organisationnelles. Je suis fortement organisé à propos des tâches et des livrables, particulièrement les activités du chemin critique.
J’ai pris le temps de visionner cette vidéo réalisée lors de TechEd 2011 qui permet de mieux faire le lien entre le monde du développement logiciel et celui des chefs de projet et PMOs qui utilisent les outils de Microsoft.
De plus, Microsoft nous propose un Webcast sur ce sujet le 8 Juin à 14:00 (en Anglais): suivre ce lien pour s’inscrire.
La vidéo se décompose en une introduction (les premières 19′), 2 démonstrations suivi de quelques astuces et liens.
La première démonstration (qui commence environ 19′ après le début de l’enregistrement) se focalise sur le besoin de visibilité du PMO sur l’état d’avancement du développement logiciel. En effet, quand l’équipe de développement utilise Team Foundation Server (TFS) pour définir les itérations et interagir avec le « backlog » de fonctionnalités à développer, ces mises à jour en temps réel pourront être répercutées dans MS Project Server utilisé par les PMs ou le PMO.
La seconde démo (vers les 35′) se porte plutôt sur la partie amont et le processus d’évaluation de charge et de durée. Les deux outils peuvent en effet interagir pour avoir plusieurs échanges et co-construire l’échéancier entre le team leader de développement dans TFS et le chef de projet dans MS Project Server.
Après ces deux démos instructives, les intervenants reviennent sur les aspects de mise en place et de configuration des outils (1h04′) et concluent par des liens et témoignages (1h10′).
http://www.pmi.org/eNews/Post/2011_04-08/NLU_The-DNA-of-the-PMO.html
Jack S. Duggal, MBA, PMP
Les Project Management Offices (PMOs) existent depuis quelque temps et sont devenus communs dans beaucoup d’organisations. Malgré cela, le but principal et la fonction d’un PMO continuent à être mis en doute et débattus. La situation devient encore plus complexe dans des organisations dans lesquelles les PMOs ont proliféré à différents niveaux avec des chevauchements ou des conflits de fonctions. D’autre part, parfois, quand il y a la clarté de but, un focus trop étroit peut limiter la valeur du PMO. De même que l’ADN contient les instructions génétiques utilisées dans le développement et le fonctionnement de tous les organismes vivants connus, existe-t-il un code ou un modèle contenant tous les éléments pour construire un PMO réussi ?
La forme spécifique, la fonction et la structure d’un PMO pour votre organisation dépendront d’un nombre de facteurs dont :
Cependant, beaucoup d’éléments principaux d’un PMO peuvent être identifiés et agencés.
Les participants à mon SeminarsWorld ® « la Construction de la Prochaine Génération de PMO et de Management de Portefeuille », séminaire des 10 dernières années ont aidé à examiner le cœur des fonctions du PMO. Le défi était de décoder l’ADN, ou identifier les éléments principaux de PMO réussis, qui puissent être évolutif et s’adresser à n’importe quel type d’organisation ou de business.
Pour construire une vue holistique du PMO, une structure intégrée est nécessaire. L’ADN du PMO aide à organiser les fonctions de PMO en six larges catégories comme indiqué dans le diagramme ci-dessous.
Support de décision stratégique : Facilite le management de portefeuille, fournissant des informations pour la sélection et la priorisation de projet, mettant en évidence des informations critiques pour évaluer le risque, la capacité en ressources et la gestion des exigences et permettant le support de décision pour l’alignement avec le business, la réalisation des bénéfices et la gestion de la valeur.Les susdits éléments peuvent être trouvés dans un PMO typique, individuellement, ou dans des combinaisons de deux ou plus, mais rarement tous les six domaines sont-ils reliés de façon holistique.
Comment appliquez-vous l’idée de l’ADN à votre PMO ? Évaluez votre PMO depuis la perspective de chacun des six éléments et évaluez vos forces, faiblesses et des chaînons manquants. Le point actuel de douleur et les besoins fonctionnels de l’organisation détermineront la priorité de votre attention.
L’idée de l’ADN du PMO est l’interaction et l’impact de tous les six éléments l’un sur l’autre. Ceux-ci doivent être liés, équilibrés et optimisés pour supporter la valeur du PMO.
http://www.projectmanagers.net/profiles/blogs/metrics-in-project-management
La métrique peut fort bien ne pas être le sujet le plus sexy dans le management de projet. Mais le succès du bureau de management de projet (PMO) dans lequel vous travaillez et votre réussite de chef de projet peuvent dépendre du fait d’avoir ou pas un programme de métriques en place. Dans une période économique difficile, il y a des opportunités encore plus surprenantes pour un PMO de prouver sa vraie valeur pour l’organisation. Les informations de cet article peuvent vous aider à créer votre programme de métriques ou d’évaluer si votre programme existant en fait assez pour justifier votre existence.
Une métrique, par définition, est tout type de mesure utilisée pour mesurer un certain composant quantifiable de performance. Un métrique peut être directement obtenu par l’observation, comme le nombre de jours de retard, ou le nombre de défauts logiciels trouvés; ou le métrique peut être dérivé de quantités directement observables, comme des défauts par mille lignes de code, ou un indice de performance de coût (« Code Performance Index : CPI »). Quand utilisée dans un système de contrôle pour évaluer le projet ou la santé de programme, une mesure est appelée un indicateur, ou un indicateur clé de performance (« Key Performance Index : KPI »).
L’intérêt intense dans les métriques dans la communauté de management de projet a engendré un sous-domaine entier d’étude appelée le management de métrique. La métrique de projet peut être catégorisée en trois catégories principales :
C’est souvent réalisé par le PMO, s’il existe. Un praticien de PM, Anthony Politano (voir son blog), a même préconisé que les sociétés devraient avoir un Officier En chef de Performance (« Chief Performance Officer : CPO »), qui serait responsable de la collecte et l’analyse de métriques et de communiquer ces mesures au management pour la prise de décisions stratégiques.
En donnant la métrique au management, il est important de conserver le facteur de temps à l’esprit. Le vrai succès ou le vrai échec peuvent ne pas être apparents jusqu’à bien longtemps après qu’un projet soit formellement clôturé. Par exemple, une nouvelle application peut s’avérer être un échec colossal six mois après être mise en production, quand elle atteint finalement ses objectifs d’utilisation prévus.
Les exemples de métrique de macro-niveau incluent : nombre de projets réussis, pourcentage de projets ratés et nombre d’heures passées par projet ou programme.
C’est seulement en observant la métrique au niveau des tâches que le statut de livrables de niveau plus haut peut être vérifié, et que l’on peut alors le communiquer aux parties prenantes et clients. Les types différents de projets exigeront différents types de métriques : un projet de développement logiciel demande des mesures différentes de, disons, un projet de fusion et acquisition.
Comment progressons-nous par rapport à l’échéancier ? Schedule Performance Index (SPI) = Earned Value ÷ Planned Value Cost (SPI)Une phrase commune que vous pouvez entendre sur les métriques est : “ce qui ne peut pas être mesuré, ne peut pas être managé”. Clairement le manque de mesures peut rendre les choses plus difficiles pour un chef de projet.
En même temps, les mesures sont utiles seulement si elles sont précisément cela : utiles. Le suivi des métriques seulement pour avoir quelque chose à mettre votre rapport d’avancement n’est pas une utilisation effective de votre temps, ou du temps de votre équipe.
Si vous voulez mettre en place un programme de métriques efficace, mettez du temps de côté pour planifier ces choses dans cet ordre:
La façon dont vous présentez votre métrique dépend de qui la demande. Le cadre exécutif veut d’habitude seulement connaître l’état général du projet et se sentir « confortable »”, tandis que l’auditeur du PMO veut savoir que vous avez “deux jours de retard en raison du changement de portée approuvé, mais que vous remaniez l’échéancier pour les rattraper.”
La meilleure façon de présenter vos informations est d’habitude la plus simple. Quelques progiciels de gestion de projet incluent une fonctionnalité de tableau de bord automatisée, qui peut ou pas pouvoir répondre à vos besoins. Des affichages visuels, comme un simple graphique pour illustrer des tendances, ou les classiques “ feux tricolores”, sont des façons efficaces de montrer le statut d’indicateurs majeurs de métrique. Un graphique de feu de signalisation simple peut être construit en Excel, utilisant des couleurs pour indiquer le statut. Typiquement :
Votre rapport de feu de signalisation devrait montrer des indicateurs détaillés et un indicateur cumulatif pour comprendre le statut d’un simple coup d’œil.
En utilisant un format de feux de signalisation, assurez-vous de bien définir les règles sur quand changer de couleur sur les feux; travaillez avec le sponsor de projet ou le PMO pour le faire si ce n’est pas déjà normalisé. Vous pouvez avoir fait l’expérience d’essayer de vous décider sur quand exactement vous devriez tourner ce petit point à l’orange, ou ne pas être autoriser de le faire passer au rouge parce que votre manager ne veut pas que vous le fassiez.
Par exemple, pour un indicateur à base de calendrier, la règle peut être “faire passer l’indicateur à l’Orange quand le nombre de tâches en retard est supérieur à deux.” Les Indicateurs peuvent aussi être étalonnés sur des cibles mensuelles pour que les tendances globales puissent être visualisées. Il vaut mieux tourner le feu de signalisation à l’Orange quand le planning entier a cinq jours de retard lors du premier mois, que de ne le passer Orange que si vous atteignez 15 jours de retard au troisième mois, quand il est trop tard pour réagir.
Comme vous continuez à accumuler les métriques des projets dans le portefeuille de projets de votre société, vous construisez une base de données de valeur en matière de benchmark interne. Comparez vos métriques à ceux d’autres projets dans votre portefeuille pour voir où des améliorations de processus peuvent être faites, ou bien où vous pourriez introduire des exigences de conformité. Vous pouvez aussi comparer vos métriques aux données de benchmark de projets d’autres sociétés dans la même industrie.
Une ressource pour les dernières nouveautés dans le management de métrique est le « Project Management Institute’s Metrics Special Interest Group (MetSIG) ». Le plus important événement MetSIG est son Congrès Mondial Online qui se tient chaque année en avril. Le Congrès est une série d’un mois de « webinars » en ligne sur 
des sujets concernant les métriques. Comme un témoignage de l’importance des métriques dans la communauté de management de projet, le MetSIG a évalué que presque 50,000 participants suivaient le Congrès MetSIG 2008 et que 50,000 de plus visionnent les présentations vidéo archivées (voir Www.metsig.org pour plus d’informations).
Le management de projet en tant que discipline continue à croître et ne montre aucun signe de ralentissement. Comme Greg Balestrero, le Président-Directeur Général de PMI l’avait cité dans son discours d’ouverture au Congrès MetSIG 2007, plus de 87% d’organisations remontent déjà le statut de projet aux Conseils d’administration et 17% des rapports de PMOs aux PDGs (KPMG, Global IT Project Management Survey, 2005).
Le défi est de s’assurer que le statut de projet inclut les métriques qui démontrent la valeur du management de projet. Comme vous l’avez vu, il y a beaucoup d’outils et techniques disponibles pour communiquer et gérer la métrique à un niveau projet (tactique) ou PMO (stratégique). Saisissez cette occasion de penser à comment les personnes autour de vous perçoivent la valeur de vos services de management de projet et voyez si vous pouvez penser à des façons de promouvoir et protéger votre position comme un champion de management de projet dans votre organisation.
http://www.fatcat.com.au/news/home/Ask+an+Advisor/418_0.html
Un nombre élevé et disproportionné de projets sont annulés par le management à 18 mois.
Comme avec tout projet, il y a un flux et un reflux naturel. Un rythme naturel. Ce que je trouve intéressant est que le rythme semble s’installer dans ce que j’appelle la Règle des 18 Mois. La règle déclare que :
Un nombre disproportionné de projets est annulé par le management à 18 mois. N’oublions pas que beaucoup de secteurs ont un rythme naturel. Un exemple est technologique. Le rythme technologique le plus célèbre est la Loi de Moore qui prévoit que la croissance dans le nombre de transistors par puce doublera tous les vingt-quatre mois. D’autres lois technologiques qui ont un rythme naturel incluent la Loi de Kydler pour le stockage sur disque (~12 mois) et la Loi d’Haitz pour la production de LED’s (~18 mois).
Pourquoi y-a-t-il une Règle de 18 Mois pour les projets ? Y aurait-il une certaine loi naturelle dans le travail ? La réponse est simple : oui. La nature humaine.
En regardant derrière moi les projets que j’ai managés dans ma carrière, le cycle de 18 mois d’annulation des projets réapparaît à travers les industries, le contexte, la technologie, la taille d’organisation et les nationalités. La règle semble universelle. Pourquoi ? Dix-huit est le nombre maximal de mois pendant lesquels le management peut souffrir. La douleur est la répétition de re-justification d’un projet dont on attend toujours les bénéfices.
Pensez à un projet donné. La plupart débutent en milieu d’année avec un financement et des ressources alloués à grand-peine par le management en se basant sur le mérite et l’impact potentiels. Quand le cycle budgétaire suivant arrive, le projet est bien en route et le financement est presque assuré étant donné que le projet a démarré depuis moins d’une année et que personne ne s’attend à ce qu’il ait déjà un impact. Le résultat est que les ressources sont maintenues en place et le projet continue à progresser.
Le deuxième cycle est une question différente. Quand le cycle budgétaire revient, il y a des questions levées sur le projet : est-ce que ce projet est toujours important ? Y aurait-il des projets plus importants que nous devrions financer au lieu de celui-là ? Atteignons-nous les progrès escomptés ?
Pourquoi ces questions ? Parce que chacun dans la chaîne de management doit re-justifier le projet pour encore une autre année de financement. C’est ce deuxième tour qui cause toute l’angoisse. Le résultat est que le management arbitrera s’il faut se battre pour une autre année de financement ou simplement laisser le projet mourir et éviter cette douleur. Comme nous pouvons tous l’apprécier, éviter la douleur est une réaction humaine naturelle.
Si le management pouvait voir la valeur (quelque chose qui justifie la douleur), approuver que le projet continue ne serait pas un problème. Là où la plupart des équipes de projet s’attirent des ennuis est qu’elles ne saisissent pas cette réaction d’évitement de douleur du management. Dans leurs esprits, le management devrait seulement l’obtenir et avoir confiance en équipe. Le résultat est qu’un grand pourcentage de projets sont tués à 18 mois parce que l’on n’a pas démontré leur valeur.
Attendez ! Dites-vous. Nous avions un accord que ce serait un projet de plusieurs années et que les bénéfices viendraient à la fin. Est-ce que ceci ne prouve pas que la Règle des 18 Mois ne s’applique pas ? Non. Si vous croyez vraiment que vous pouvez éviter le problème en obtenant un accord au départ, alors vous ne comprenez pas la nature humaine. Au cas où votre projet passerait le jalon des 18 mois, la douleur grandit avec chaque cycle ultérieur. Ce qui signifie que vous devez montrer une valeur et un impact toujours croissants pour continuer. La douleur ne part pas. En réalité, elle augmente .
Ce n’est pas la faute de la direction. C’est la faute de l’équipe de projet qui échouerait à comprendre le désir du management d’éviter la douleur.
1) Comprendre le cycle de votre organisation (ou votre client) pour vous assurer que vous comprenez le timing. Quand les budgets et/ou les stratégies sont-ils bouclés chaque année ?
2) Définir votre portée de projet et de produits pour être certains que ce que vous livrez a un impact/une valeur avant que la règle ne soit appliquée.
3) Pour les projets qui s’étendent au-delà de 18 mois, découpez-les et faites de chaque partie un projet distinct. Pourquoi ? Esquiver le problème d’évitement d’une douleur qui s’intensifie avec le temps. Chaque projet remet l’horloge à zéro.
Dans mon expérience, j’ai vu la règle appliquée à des projets qui devraient avoir été tués au départ et à d’autres qui n’auraient jamais dus être tués. Cette apparente prise de décisions aléatoire du management peut être perturbante et démoralisante dans une organisation.
Si vous êtes dans le management, regardez-vous dans le miroir et comprenez que la nature humaine joue un rôle dans votre prise de décision de tuer des projets. Aidez vos équipes à le comprendre.
Si vous menez un projet, utilisez les stratégies de management de projet simples afin d’éviter ce que dans le passé vous aviez attribué à des caprices du management.
Bonne chance !
by Claudia Weninger, Insights from Inside Project Management Journal®
Le management de projet contribue à la performance organisationnelle. Mais comment la mesurer ? Les indicateurs sont la solution, mais quels indicateurs sont à la fois nécessaires et importants ?
Article original de Aubry, M. et Hobbs, B., (2011). A Fresh Look at the Contribution of Project Management to Organizational Performance. Project Management Journal 42, pages 3 à 16. dans le Project Management Journal.
La performance organisationnelle peut être définie comme une construction subjective ancrée dans les valeurs et les préférences des parties prenantes (Cameron, 1981).
La Structure de Valeur Compétitive (Competing Value Framework selon Quinn et Rohrbaugh), qui a été utilisée dans diverses industries, est basée sur les rapports tendus qui existent dans toutes les organisations où des besoins, des tâches, des valeurs et des perceptions doivent rivaliser.
Un article dans la publication de Février 2011 du Project Management Journal intitulé “un Nouveau regard sur la Contribution du Management de projet à la Performance Organisationnelle,” examine comment le management de projet contribue à la performance organisationnelle et quels indicateurs sont clefs pour l’évaluation.
Basé sur le jeu de 17 critères de la Structure de Valeur Compétitive, l’article décrit le la mise au point d’un groupe de 79 indicateurs uniques pour évaluer la performance de bureaux de management de projet (PMOs). L’avantage de la structure est l’intégration de la perspective de performance financière avec d’autres concepts pour former une perspective multidimensionnelle. Les quatre groupes d’indicateurs de conceptions principaux sont :
1. Indicateurs dans les Ressources Humaines
Ces indicateurs favorisent une compréhension plus claire du rôle que le PMO peut jouer dans ce domaine. Le PMO a un rôle direct dans le développement de compétences pour le personnel, selon les besoins des projets à venir et des souhaits des salariés. Il a donc une fonction importante dans le management de ressources humaines. En outre, le PMO joue un rôle social et influence l’équilibre vie privée/travail. En résumé, le PMO fournit une contribution significative à la performance organisationnelle quant aux Ressources Humaines.
2. Indicateurs dans les Processus Internes
Ce groupe présente le plus grand nombre d’indicateurs individuels. Beaucoup d’indicateurs ont une relation aux critères d’informations et de communication. Parce que le PMO collabore dans beaucoup de réseaux, il a un rôle central dans le transfert d’informations. En outre, ces indicateurs reflètent la qualité d’informations et la facilité de leurs flux partout dans l’organisation.
3. Indicateurs dans la Conception de Buts Raisonnables
Ce groupe inclut le critère de rentabilité et reflète l’intérêt à sélectionner les bons projets. La contribution du PMO à la performance organisationnelle est reconnue par sa participation dans le management de programme et de portefeuille de projets. Elle intègre les valeurs économiques de rentabilité, d’efficacité de management de projet et de retour sur investissement.
4. Indicateurs dans la Conception de Système ouvert
Ce groupe traite de la flexibilité, l’adaptation et l’innovation dans le management de projet. Un critère clef est la croissance de l’organisation et il inclut les variables qui permettent de mesurer la croissance et de prendre en compte les ventes, les résultats qualitatifs et l’efficacité.
La recherche a utilisé une approche d’étude de cas. Quatre organisations ont participé sur une durée de 2 à 13 ans. Au total, 11 PMOs différents ont été analysés, chacun constituant une étude de cas. Les données ont été rassemblées grâce à des entretiens et un questionnaire. On a demandé aux personnes interrogées d’évaluer les 17 critères de la structure mentionnée ci-dessus. Dans cette recherche, l’évolution de la perception de la contribution du PMO à la performance organisationnelle a été tracée.
Le but de cet étude était de déterminer la valeur du management de projet dans la performance organisationnelle. En se basant sur la Structure de Valeur Compétitive, les auteurs ont développé 79 indicateurs uniques pour évaluer la performance du PMO.
La performance organisationnelle doit être examinée depuis différents points de vue et le PMO est au centre de diverses perspectives sur la performance organisationnelle. Les praticiens des projets qui ont besoin d’informations pour communiquer sur la valeur du management de projet sur la performance organisationnelle sauront tirer profit de la lecture l’article intégral dans le journal.
de Meilir Page-Jones (http://www.waysys.com/ws_content_al_sse.html)
L’auteur de ce billet fait un parallèle que j’ai trouvé amusant et fort à propos entre chasse à l’ours et développement logiciel. Je me propose de transposer cette comparaison au domaine du management de projet…
Regardons la manière dont les personnes peuvent absorber de nouvelles techniques perfectionnées et ensuite les appliquer à leur travail : autrement dit les étapes d’expertise par lesquelles nous passons tous lorsque nous apprenons. Alors que l’idée de départ pourrait être qu’il y ait seulement deux types de personne : novice et expert. L’auteur a en réalité découvert sept étapes d’expertise par lesquelles une personne parvient à passer d’une ignorance totale à une connaissance de niveau international. Ces étapes sont nommées : Innocent, Exposé, Apprenti, Praticien, Compagnon, Maître et Expert. Comme vous le verrez ci-dessous, ces sept étapes peuvent avoir un profond impact sur la réussite ou pas de l’introduction du management de projet dans une organisation.
Lorsqu’un participant avait demandé à Meilir Page-Jones lors d’une conférence à quel point ces sept étapes étaient universelles, il a répondu : « Très universel ». « Vous voulez dire que je pourrais même les appliquer à la compétence en chasse à l’ours ? » a-t-il répliqué inopinément. « Oui » répondit Meilir.
Appliquons les donc ici au management de projet. Mais commençons par le début :
l’exemple de la chasse à l’oursÀ l’Étape 1, la personne n’a jamais vu ni entendu parler d’ours. Cela ne lui viendrait pas à l’esprit à l’Étape 1, si elle rencontrait un ours, que l’on pourrait le chasser. Elle ne se rendrait pas compte non plus qu’un ours est une source potentielle de danger.
À l’Étape 2, la personne a occasionnellement vu un ours et a lu des articles dans des magazines suggérant que l’on puisse chasser les ours. De plus, lors de l’Étape 2, la personne a probablement des amis qui ont chassé des ours. Elle a appris quelques faits étonnants mais fascinants sur les ours et leurs habitudes. Elle est motivée pour en apprendre davantage.
Une personne à l’Étape 3 a suivi un séminaire de 5 jours à propos de la chasse à l’ours. Pendant ce séminaire, les participants se groupent en équipes de trois ou quatre et pratiquent la chasse de très petits ours sous l’œil toujours vigilant d’un instructeur. Après quelques échecs en cours de route, le vendredi après-midi toutes les équipes ont avec succès chassé leur ours. Les apprentis remplissent des formulaires d’évaluation certifiant que “la chasse d’ours est très utile et appropriée dans leur travail.” Cependant, ils sont à peine préparés pour le monde des vrais ours.
Étape 4 : PraticienÀ l’Étape 4, ayant achevé l’enseignement formel de chasse à l’ours, la personne est pleine de confiance. Elle est prête à dépasser le stade des minuscules ours de l’atelier de 5 jours et à sortir pour de vrais ours, de plus grands ours, des ours féroces. Elle est prête pour la Grande Ourse. Son manager tient aussi à l’y envoyer et avec les dernières techniques de chasse à l’ours parce que les utilisateurs veulent de la fourrure et ils la veulent hier. Malheureusement, dans la frénésie résultante, on peut envoyer le chasseur d’ours débutant sans boussole et avec une flèche de mauvais calibre dans son carquois. Dans la chaleur de la confrontation avec l’ours, le Praticien de l’Étape 4 peut aussi oublier ou mal interpréter sa formation théorique en salle de classe et précipiter le désastre. Il est typique que quelques Étape 4s obtiennent quelques ours; mais il est aussi typique que quelques ours obtiennent quelques Étape 4s.
Le compagnon de l’Étape 5 a réchappé aux traumas de l’Étape 4 et possède la mécanique de la chasse à l’ours. À l’Étape 5, il utilise des techniques modernes de chasse à l’ours naturellement et automatiquement; en fait, il ne peut plus s’imaginer comment il a pu ne pas les avoir. Il est précis et productif : le Comité de pilotage indique simplement l’ours à abattre et il le chasse tant dans le budget que dans les délais. L’Étape 5 est le chasseur moderne exemplaire que les personnels de marketing de séminaires de chasse à l’ours s’attribuent dans leurs brochures.
Étape 6 : MaîtreÀ l’Étape 6, le chasseur a intériorisé non seulement la mécanique de la chasse à l’ours, mais aussi les principes qui sont à la base de ces techniques. Il connaît plus que des règles : Il sait pourquoi les règles existent et il sait même quand il est permis de les rompre. Par exemple, un Étape 3 ou 4 pourrait être accidentellement debout contre le vent d’un ours et lui faire peur. Alors qu’un « Maître » peut savoir qu’en portant le Vaporisateur Déodorant de yogi il peut être debout contre le vent sans être détecté et peut ainsi surprendre l’ours en arrivant d’un côté inattendu. À cause de leur profonde connaissance, un Maître de l’Étape 6 est parfaitement capable de former d’autres personnes aux techniques de chasse.
On demande à l’Étape 7 d’écrire des livres et de donner des conférences aux groupes de pratiquants de la chasse à l’ours. Ils sont aussi engagés dans l’extension et la généralisation de techniques de chasse à l’ours pour résoudre de nouveaux problèmes. Par exemple, un Étape 7 peut prolonger la chasse d’ours pour travailler aussi sur la chasse au Yéti ou il peut même développer une Méthodologie nec plus ultra de chasse au Yéti.
Maintenant revenons au monde du management de projet et voyons comment les Sept Étapes d’Expertise s’appliquent à nous.
Un Étape 1 peut ne pas avoir entendu parler de techniques de management de projet. Ou, plus probablement de nos jours, il peut être vaguement conscient de leur existence, mais ne peut pas voir leur pertinence dans sa situation. En effet, il peut être seulement vaguement conscient qu’il y a des problèmes de management de projet dans son entreprise. Si des Étape 1 peuvent encore exister de nos jours, c’est souvent en raison de la façon dont la complexité des projets s’est développée. Les projets sont progressivement devenus de plus en plus complexes dans les années 1970 et les années 1980 quand les utilisateurs ont exigé des solutions de plus en plus perfectionnées soient développées utilisant les technologies de plus en plus puissantes et complexes qui devenaient disponibles. Au fil des crises économiques successives dont le choc pétrolier et la mondialisation effrénée, les équipes virtuelles (géographiquement distantes) ont ajouté une couche importante de complexité. Celle-ci s’est encore accrue avec les contraintes de réduction de coûts via l’outsourcing et l’offshoring dans de nombreuses industries dans les années 2000. Cependant, il n’y a pas pour autant eu de séisme. La terre n’a pas été frappée par un astéroïde de complexité qui aurait brutalement généré trois Tsunamis d’ampleur de plus en plus complexe et qui aurait poussé nos anciennes techniques de management de projet vers l’extinction.
C’est pourquoi l’auteur appelle cette augmentation de complexité celle de « la Grenouille dans la Casserole ». Bien qu’une grenouille se sauve si on la place dans une casserole d’eau chaude, une grenouille qui est placée dans une casserole d’eau froide puis chauffée lentement ne sautera pas pour en sortir et chauffera jusqu’à en mourir. L’augmentation de température est si graduelle qu’il n’y a jamais un moment auquel la grenouille déclare : « c’est soudainement devenu chaud par ici! Je pense que je devrais sauter de là. »
Beaucoup d’Étape 1 éprouvent le syndrome de “la Grenouille dans la Casserole” et essaient d’aborder les problèmes d’aujourd’hui avec les approches des années 1960, 1980, 2000… sans se rendre compte que les problèmes auxquels ils font face sont ceux que des techniques de management de projet plus modernes ont été créées pour soulager.
L’Étape 2 a remarqué que l’eau devient décidément trop chaude, sinon brûlante. Donc il cherche activement les techniques de management de projet qui le sortiront de la casserole ou réduiront au moins la chaleur. L’Étape 2 peut lire des magazines, conférer avec des collègues ou assister à des journées d’aperçu des nouvelles techniques. Son niveau d’intérêt est élevé mais son niveau de connaissance reste faible, limité à quelques termes et définitions et non pas basé sur une expérience pratique de management de projet.
L’Étape 3 a suivi un ou deux ateliers de 5 jours sur les techniques de management de projet. Dans ces ateliers il a abordé des études de cas petites mais réalistes qui ressemblent en miniature à ses propres projets. Les études de cas ont fourni un renfort appliqué au matériel de cours formel et étaient donc indispensables. Cependant, le réalisme apparent transmis par les études de cas donne à l’Étape 3 une confiance souvent injustifiée.
Si un Étape 3 absorbe tout d’un séminaire, il est équipé à minima pour aborder un vrai projet, grandeur nature dans la jungle d’entreprise. D’habitude, cependant, un Étape 3 ne saisit pas la totalité de la complexité ou bien il rencontre des difficultés à dimensionner les techniques de l’étude de cas proportionnellement au projet réel. Vous pourriez dire que la plupart des Étapes 3 en savent juste assez pour être dangereux !
Le rite de passage à L’Étape 4 est l’utilisation de techniques de management de projet sur au moins un projet significatif. Réussir l’Étape 4 est pour beaucoup de personnes la transition la plus difficile des six transitions d’étapes. On demande à un Étape 4 débutant d’adopter des techniques de management de projet qu’il n’a pas encore essayées et de les appliquer à un projet d’entreprise avec son cocktail démoniaque habituel de politiques, de délais et d’exigences changeantes. En même temps, il essaye de se rappeler ce qu’il a appris en cours et d’augmenter proportionnellement les techniques vues lors de la formation à la situation réelle, souvent par un facteur 10 à 100. Il a besoin du conseil d’experts, sans lesquels il rencontrera une série d’échecs mineurs ou plus graves. Beaucoup de personnes jettent l’éponge à ce point et retournent à leurs anciennes habitudes médiocres mais familières. Une grande proportion d’Étape 3 ne passe jamais à l’Étape 4. Si un projet entier est peuplé d’Étape 3, il est fortement probable que le projet lui-même échouera et que les techniques de management de projet seront publiquement mises au pilori puis abandonnées.
L’Étape 5 l’a fait. Son expérience de management de projet est ferme et bien en place et il y a peu de risque de retour arrière. Dans L’Étape 5, les techniques de Management de Projet apportent pour la première fois la productivité promise; et sur chaque projet successif un Étape 5 trouve de nouvelles pierres sur lesquelles affûter son habileté et améliorer sa productivité. Un Étape 5 est auto-suffisant et il est plus souvent une source de conseil en management de projet que son destinataire.
L’Étape 6 est non seulement un technicien connaisseur, mais il possède aussi une fondation méthodologique profonde. Au-delà des « quoi » et des « comment”, L’Étape 6 connaît les « pourquoi » du management de projet. Cette profondeur lui permet de transgresser parfois une règle superficielle, tout en adhérant à un principe méthodologique plus fondamental. L’Étape 6 est un bon instructeur parce que sa connaissance théorique et pratique lui donne les moyens d’aborder les questions difficiles des étudiants.
L’Étape 7 se préoccupe constamment des dernières nouveautés du management de projet et de les partager avec une audience plus large, via des livres, des articles et des interventions lors de conférences. L’Étape 7 recherche les défauts des techniques de management de projet contemporaines et des façons d’améliorer les techniques. Il est toujours à la recherche de nouveaux problèmes et domaines où le management de projet pourrait être développé et généralisé.
Soyez conscient des Sept Étapes d’Expertise et de leurs effets sur la productivité de vos chefs de projet. Examinez où vous en êtes personnellement et où en sont chacun de vos chefs de projet. Définissez pour chaque chef de projet ses buts de moyen à long terme en matière d’expertise et suggérez un plan pour les atteindre.
Prenez en compte ces niveaux d’expertise lors de l’assignation des projets aux PMs. Par exemple, ne confiez jamais un projet crucial seulement à un PM qui en est seulement à l’Étape 3 (apprenti) ou en deçà. Pour les Étape 4 (praticiens), choisissez avec eux les projets qui leur permettront l’accès à l’Étape 5 (compagnon) et 6 (Maître) si possible. Si vous n’avez pas d’Étape 5, assurez-vous d’en acquérir ou d’en développer une rapidement…
t Management Is Finally Getting Real RespectBy Jonathan Feldman, dans InformationWeek le 18 octobre 2010
Selon cet article, des bonnes priorités aux salaires plus élevés, le management de projet reçoit enfin plus qu’un intérêt de pure forme dans beaucoup de sociétés.
L’auteur qui est Directeur Informatique pour une ville de Caroline du Nord y parle notamment des Project Management Offices (PMOs). Il aborde les raisons de créer un PMO : prioriser les projets, standardiser l’approche en management de projet, fournir de la visibilité, suivre le progrès et leurs coûts.
Il explore également la problématique des petits projets qui passe souvent sous le radar des PMOs.
Il conclut par une discussion sur les outils et les certifications de projet en particulier le PMP du Project Management Institute.
Voici quelques modèles fort utiles si vous démarrez un PMO.
Même si nous sommes heureux de fournir ces modèles et des outils pour vous aider dans vos efforts de management de projet, ils sont seulement aussi bons que…
Modèles de Management de projet
Une connaissance business qui monte une boîte de prestations en PMO spécialisé sur les ERP (Entreprise Resource Planning), notamment Oracle, recherche un nouveau membre pour son équipe, de préférence un free-lance. Au delà de ce premier contrat, la volonté est de monter une offre PMO ERP (avec autant d’automatisation réutilisable que possible).
Si vous pensez avoir l’expérience ERP/Oracle nécessaire et les compétences en management de projet et PMO, merci de m’envoyer votre CV que je lirai avec attention et je vous recontacterai dans les meilleurs délais.
Basé à l’extérieur de Paris (20km de Orly) pour l’un des plus grands groupes internationaux originaire de France. Un programme global avec définition d’un modèle cœur pour l’ensemble de la division et son déploiement en France et à l’international. Sur une base logicielle Oracle avec Cognos Business Intelligence. Le poste de PMO à pourvoir complétera une équipe de 2 personnes en place avec les bons réseaux en interne chez le client pour réaliser du bon travail.
Plein temps démarrage le plus rapidement possible (début septembre au plus tard) jusqu’à fin décenbre 2010; avec possibilité d’extension.
« RIP: IT Project » de Susan Lyle Dodia
C’est la fin du 2ème Trimestre et de la première moitié de l’année. Pour beaucoup d’organisations, c’est un moment où projets et programmes sont passés en revue et analysés. Certains seront au bout du compte choyés : plus d’argent, de ressources, d’attention, quelque soient les ressources nécessaires. D’autres projets et programmes ne s’en tireront pas aussi bien et seront brutalement arrêtés ou « mis en veille » jusqu’à ce que mort s’en suive.
Couper le courant sur un projet est une intéressante question de management du changement. Même si en tant que chefs de projet nous signons pour un projet sachant qu’il est, par définition, provisoire, nous voulons que cela se finisse parce que nous avons fini le travail, pas parce que l’organisation n’en veut plus. Et nous sommes très investis émotionnellement dans nos projets, peut-être parce qu’ils sont provisoires et que nous avons envie d’avoir un réel impact pendant notre brève intendance. En conséquence, nous pouvons réellement ressentir un sentiment de perte quand un projet est annulé, et il en est de même pour tout autre membre de l’équipe projet.
Donc j’ai été très intéressé quand j’ai récemment lu par hasard un article dans le magazine CIO : When IT Projects Founder, Emotions Run High de Michel Fitzgerald. “Il est difficile de ne pas ressentir d’émotions quand des projets longs et aux technologies très en pointe sont injustement assassinés, euthanasiés avec bienveillance ou livrés avec des défauts”, écrit Fitzgerald.
Fitzgerald met en lumière un sujet légèrement embarrassant pour beaucoup de personnes de l’informatique. C’est, euh, le, hum, les sentiments. C’est précisément cette réticence à parler de sentiments qui peut causer tant de problèmes quand un projet finit de manière inopinée.
“Chaque projet tué ou à problème a sa propre histoire pathétique particulière ”, dit Fitzgerald. “Certains subissent des événements imprévus – la fin de la guerre froide, un ralentissement de l’économie, une fusion, un changement dans les priorités business. Certain s’enfoncent à cause d’une mauvaise combinaison de technologie, objectifs et compétences. Mais chaque fois que les projets trébuchent ou même meurent, et que des gens se sentent blessés, cela a d’habitude un rapport avec le problème le plus persistant de l’humanité : la communication.”
Si vous devez passer votre été avec un projet moribond, n’oubliez pas de faire attention aux sentiments que les gens ont au sujet de leur travail. Une fois engagé sur un projet, il peut être difficile pour beaucoup de personnes de couper l’interrupteur dans leur esprit et de s’en séparer. Les gens ont besoin de parler de comment ils se sentent à la fin d’un projet et un bon chef de projet les y aidera.
Un exercice facile qui peut aider à faire son deuil à l’équipe de projet est l’exercice des Glads, Sads et Mads (contents, tristes et en colère). Pensez-y comme à une session sur les Leçons Apprises mais pour les émotions! Rassemblez votre équipe, peut-être dans un endroit informel, en dehors du bureau, et faites le tour de table en demandant à chaque personne de partager trois sentiments sur le projet : pourquoi ils sont heureux que le projet finisse, pourquoi ils sont tristes qu’il finisse et pourquoi ils sont en colère qu’il finisse. Cela aide l’équipe à faire sortir ses sentiments de manière ouverte et à entendre des perspectives rafraîchissantes. Ils peuvent être soulagés d’apprendre que d’autres ont également de fortes émotions, et peuvent ressentir du plaisir à voir le niveau d’engagement exprimé par leurs coéquipiers.
Quoi que vous fassiez, n’ignorez pas le côté émotionnel d’un projet technologique annulé. Assurez-vous que les membres de votre équipe ne transportent pas leurs sentiments ou émotions négatifs sur le projet suivant en les aidants à confronter leurs sentiments lorsqu’ils terminent l’ancien projet.
The document in English can be downloaded on PMI.ORG.
A very interesting analysis on multi-project PMOs (Project Management Office) produced by Brian Hobbs, University of Québec, in Montréal, and based on a survey of 500 PMOs.
The whitepaper confirms that PMOs are strongly influenced by the culture and context of their company and organizations and vary in roles, structure, legitimacy… Just like the tomoatoes on the picture, not 2 PMOs are alike while some polarities do exist among them such as:
In the whitepaper, the author also highlights a lack of consensus on the value of PMOs that may partly explain the fact that 50% of PMOs are less than 3 years old while it takes a couple of years to fully deploy one. He further identifies in his analysis 27 functions that PMOs provide with the top 9 being:
So, if you’re running a PMO or planning to create one, I’m sure that you’ll find the 17 key findings of this study very worthwhile reading.
Ne manquez pas ce document en Anglais sur PMI.ORG.
Il s’agit là d’une analyse très intéressante sur les PMOs (Project Management Office) multi-projets qui a été produite par Brian Hobbs, de l’Université de Québec, à Montréal. Elle est basée sur une enquête réalisée auprès de 500 PMOs.
Ce livre blanc confirme que les PMOs sont fortement influencés par les cultures et les contextes des entreprises et des organisations et qu’ils varient dans leurs rôles, structure, légitimité… Tout comme ces tomates, il n’existe pas 2 PMOs absolument identiques même si quelques polarités les rassemblent telles que :
Dans ce livre blanc, l’auteur met aussi en évidence un manque de consensus sur la valeur des PMOs qui peut en partie expliquer le fait que 50 % des PMOs ont moins de 3 ans alors qu’il faut deux à trois ans pour en déployer un pleinement. Il identifie plus loin dans son analyse 27 fonctions que les PMOs fournissent dont les 9 premiers sont :
Donc, si vous managez un PMO ou planifiez d’en créer un, je suis certain que vous trouverez les 17 points clefs de cette étude très éducatifs.
I wrote this post on OBS Live Blog Yesterday.
I propose to start with five key items which are neither complex nor difficult and nevertheless too often poorly implemented.
J’ai publié un article sur le blog Orange Business Live sur ce sujet.
Il propose de commencer par cinq points clés qui ne sont ni complexes ni difficiles.
Brad Egeland a publié sur le blog PM Tips un article sur comment faire marcher le management de projet et plus spécifiquement un PMO dans votre organisation.
Les conseils sont tirés principalement du livre de James Lewis “Fundamentals of Project Management” sur la manière de faire fonctionner le management de projet dans une organisation.
Certains sont un peu « tarte à la crème » mais restent néanmoins valides:
Cette demande vous semble-t-elle étrange ? Êtes-vous comme de nombreux PMs qui fuient les audits comme la grippe H1N1 ? Les considérez-vous comme une perte de temps au mieux et un assassin potentiel de projet dans les cas extrêmes ?
J’ai partagé ces « a priori » mais cela n’est pas une fatalité. Les audits sont utiles, peuvent être productifs et apporter des avantages réels à votre projet ainsi qu’à vous-même.
Je suggère de commencer par le début : qui a commandité l’audit ? Pourquoi ? Qui sont les auditeurs ? Quelle est l’objet précis de l’audit?
J’ai découvert à l’expérience qu’en répondant à la dernière de ces questions, c’est-à-dire la portée de l’audit, on répond souvent aux autres. En effet, une fois partagé et compris, l’objet mettra en évidence plusieurs secteurs d’investigation et de revue. Cela pourrait être les pratiques de management de projet, les dépenses, la qualité des livrables, la sécurité, l’état d’avancement, les détails du plan de projet ou une combinaison de ceux-ci et d’autres.
Avec un peu de réflexion et de discussion avec les auditeurs, cela devrait expliquer les raisons et identifier le commanditaire. Le type d’auditeurs vous recevez, internes ou cabinets de conseil externes, généralistes ou auditeurs spécialisés, en dit également long sur l’importance accordée à l’audit et son but.
Par exemple, pendant un projet de construction et déploiement de progiciel de gestion intégrée (PGI), nous avons eu un audit interne. Une fois compris que le focus était essentiellement de s’assurer que nous contrôlions correctement dépenses et risques, il fut facile pour l’équipe de fournir les évidences de ce que nous faisions dans ces domaines. Nous avons montré notre processus de suivi des dépenses, notre méthode de suivi des affectations, le journal des questions ouvertes et le registre des risques. Le responsable financier a été rassuré par les résultats de l’audit. De plus, les auditeurs nous ont aidés à aller plus loin dans notre management des risques en nous permettant d’organiser une session de revue et de brainstorming sur les risques avec le comité exécutif du projet.
La suggestion suivante est de comprendre le processus que les auditeurs prévoient de suivre. Il est en effet important de comprendre leur approche pour mieux préparer l’équipe à cet événement qu’ils peuvent initialement percevoir de manière négative. En général, cela commence par des entretiens avec des membres clefs de l’équipe et les commanditaires du projet, souvent précédés par des requêtes de documentation pour pré-analyse. L’étape suivante implique des entretiens additionnels pour entrer plus profondément dans des questions spécifiques.
Un exemple basé sur mon expérience personnelle est sur un projet informatique où nous avions rencontré de graves problèmes pendant le déploiement. En tant que PM junior, je n’avais ni l’expérience ni le charisme pour « manager » un auditeur (externe dans ce cas). Il est venu et a exécuté son show sans expliquer le pourquoi et le processus à qui que ce soit. Dès le départ, il a émis des commentaires négatifs. L’équipe est devenue très préoccupée et quelque peu défensive. Les personnes ont fourni tous les documents demandés, mais d’une façon peu structurée. Il n’y avait pas d’histoire d’ensemble pour mettre les données brutes dans leur contexte. L’audit a pris beaucoup de temps et était très stressant pour tous. Au bout du compte, le rapport n’a pas aidé le projet à traverser cette période difficile. Dans ce cas spécifique, un audit, qui pouvait apporter la valeur, n’a réussi qu’à tuer un projet. Je garde encore un souvenir déplaisant de cette expérience certes utile mais par trop douloureuse.
Vous devriez aussi prendre en compte le fait que les auditeurs feront certainement des points de suivi avec la direction et les commanditaires. Ils partageront leur état avancement à ces sessions, exposeront leurs découvertes, testeront leurs idées initiales (pour voir les réactions potentielles) et, plus tard, ils présenteront leurs recommandations (intermédiaires puis finales).
L’année dernière, je fus nommé leader pour l’audit d’une application interne. Comme j’avais été plusieurs fois du coté de l’audité, j’ai placé une attention particulière à expliquer les jalons et l’approche de l’audit. Nous avons discuté du périmètre proposé et de qui ferait quoi. Nous avons partagé nos observations au fur et à mesure avec l’équipe pour éviter les surprises. Nous leur avons donné l’occasion de faire des remarques (ce qu’ils ont fait et nous les avons prises en considération). Nous avons partagé nos recommandations avec l’équipe de projet avant de le faire avec la direction. Nous avons aussi aidé à définir et mettre en place un plan d’action pour adresser les points identifiés. Nous avons même ensuite (après l’audit) assuré un suivi de l’exécution de ces plans d’action. Cela, je suis certain, fut beaucoup plus bénéfique à la société qu’un simple rapport.
Indépendamment du scénario, le point clé pour le PM est de supporter activement les auditeurs pendant leurs investigations. Nous devons leur fournir toutes les informations appropriées en totale transparence et demander à nos membres de l’équipe projet de faire de même. Nous nous attacherons aussi à dégager du temps pour eux dans nos agendas surchargés. Nous voulons être des partenaires positifs et de valeur. En agissant ainsi, nous pouvons espérer gagner le privilège d’être impliqués dans la préparation des documents et sessions pour la direction. Ce peut être limité à valider la justesse des faits rapportés et ceci est déjà très utile. Ce peut être de comprendre ce qu’ils vont mettre en évidence et même de discuter certaines de leurs recommandations intermédiaires.
Dans mon rôle de PM, si les auditeurs me demandent mes attentes de l’audit, je mets en évidence 2 points majeurs :
L’étape suivante est l’achèvement de l’audit et de la production des recommandations. Inévitablement, il y en aura certaines avec lesquelles vous êtes d’accord ou que vous pouvez comprendre. Il y aura d’autres qui seront plus difficiles à accepter. Dans tous les cas, il est absolument critique de rester positif et ouvert. Passer en mode défensif n’aiderait en rien. De plus, gardez à l’esprit que les recommandations des consultants et auditeurs sont une chose; le choix des recommandations sur lesquelles la direction décidera d’agir est une autre affaire (bien plus critique pour vous et votre projet).
Dès que vous comprenez quelles actions correctives ou d’amélioration sont retenues, partagez celles-ci avec l’équipe projet de manière positive. Il est fréquent que le rapport complet des auditeurs ne soit pas diffusé. Seuls les points principaux des rapports sont présentés. Ceux qui engagent l’équipe sur des actions productives.
En conclusion, je suggère que, si votre projet n’est pas encore audité, vous considériez quels domaines pourraient être améliorés par un conseil externe et sollicitiez un audit sur ceux-ci : Demandez de l’aide avant que quelqu’un au-dessus de vous ne décide que vous avez besoin d’être aidés.
Sur de nombreux projets, vous constaterez que les auditeurs vous aideront énormément à améliorer certains aspects comme le contrôle du périmètre, la rigueur dans la gestion des demandes de changement ou l’engagement de vos sponsors dans le management des risques. Les auditeurs portent un œil externe sur votre projet et sont donc bien plus objectifs que vous ne pouvez l’être.
Auditez mon projet !
Cette injonction vous semble-t-elle étrange ? Êtes-vous comme de nombreux PMs qui fuient les audits comme la grippe H1N1 ? Les considérez-vous comme une perte de temps au mieux et un assassin potentiel de projet dans les cas extrêmes ?
J’ai partagé ces « a priori » mais cela n’est pas une fatalité. Les audits sont utiles, peuvent être productifs et apporter des avantages réels à votre projet ainsi qu’à vous-même.
Je suggère de commencer par le début : qui a commandité l’audit ? Pourquoi ? Qui sont les auditeurs ? Quelle est l’objet précis de l’audit?
J’ai découvert à l’expérience qu’en répondant à la dernière de ces questions, c’est-à-dire la portée de l’audit, on répond souvent aux autres. En effet, une fois partagé et compris, l’objet mettra en évidence plusieurs secteurs d’investigation et de revue. Cela pourrait être les pratiques de management de projet, les dépenses, la qualité des livrables, la sécurité, l’état d’avancement, les détails du plan de projet ou une combinaison de ceux-ci et d’autres.
Avec un peu de réflexion et de discussion avec les auditeurs, cela devrait expliquer les raisons et identifier le commanditaire. Le type d’auditeurs vous recevez, internes ou cabinets de conseil externes, généralistes ou auditeurs spécialisés, en dit également long sur l’importance accordée à l’audit et son but.
Par exemple, pendant un projet de construction et déploiement de progiciel de gestion intégrée (PGI), nous avons eu un audit interne. Une fois compris que le focus était essentiellement de s’assurer que nous contrôlions correctement dépenses et risques, il fut facile pour l’équipe de fournir les évidences de ce que nous faisions dans ces domaines. Nous avons montré notre processus de suivi des dépenses, notre méthode de suivi des affectations, le journal des questions ouvertes et le registre des risques. Le responsable financier a été rassuré par les résultats de l’audit. De plus, les auditeurs nous ont aidés à aller plus loin dans notre management des risques en nous permettant d’organiser une session de revue et de brainstorming sur les risques avec le comité exécutif du projet.
La suggestion suivante est de comprendre le processus que les auditeurs prévoient de suivre. Il est en effet important de comprendre leur approche pour mieux préparer l’équipe à cet événement qu’ils peuvent initialement percevoir de manière négative. En général, cela commence par des entretiens avec des membres clefs de l’équipe et les commanditaires du projet, souvent précédés par des requêtes de documentation pour pré-analyse. L’étape suivante implique des entretiens additionnels pour entrer plus profondément dans des questions spécifiques.
Un exemple basé sur mon expérience personnelle est sur un projet informatique où nous avions rencontré de graves problèmes pendant le déploiement. En tant que PM junior, je n’avais pas l’expérience ni le charisme pour « manager » l’auditeur (un externe dans ce cas). Il est venu et a exécuté son show sans expliquer le pourquoi et le processus à qui que ce soit. Dès le départ, il a émis des commentaires négatifs. L’équipe est devenue très préoccupée et quelque peu défensive. Les personnes ont fourni tous les documents demandés, mais d’une façon peu structurée. Il n’y avait pas d’histoire d’ensemble pour mettre les données brutes dans leur contexte. L’audit a pris beaucoup de temps et était très stressant pour tous. Au bout du compte, le rapport n’a pas aidé le projet à traverser cette période difficile. Dans ce cas spécifique, un audit, qui pouvait apporter la valeur, n’a réussi qu’à tuer un projet. Je garde encore un souvenir déplaisant de cette expérience certes utile mais par trop douloureuse.
Vous devriez aussi prendre en compte le fait que les auditeurs feront certainement des points de suivi avec la direction et les commanditaires. Ils partageront leur état avancement à ces sessions, exposeront leurs découvertes, testeront leurs idées initiales (pour voir les réactions potentielles) et, plus tard, ils présenteront leurs recommandations (intermédiaires puis finales).
L’année dernière, j’étais nommé leader pour l’audit d’une application interne. Comme j’avais été plusieurs fois du coté de l’audité, j’ai placé une attention particulière à expliquer les jalons et l’approche de l’audit. Nous avons discuté du périmètre proposé et de qui ferait quoi. Nous avons partagé nos observations au fur et à mesure avec l’équipe pour éviter les surprises. Nous leur avons donné l’occasion de faire des remarques (ce qu’ils ont fait et nous les avons prises en considération). Nous avons partagé nos recommandations avec l’équipe de projet avant de le faire avec la direction. Nous avons aussi aidé à définir et mettre en place un plan d’action pour adresser les points identifiés. Nous avons même ensuite (après l’audit) assuré un suivi de l’exécution de ces plans d’action. Cela, je suis certain, fut beaucoup plus bénéfique à la société qu’un simple rapport.
Indépendamment du scénario, le point clé pour le PM est de supporter activement les auditeurs pendant leurs investigations. Nous devons leur fournir toutes les informations appropriées en totale transparence et demander à nos membres de l’équipe projet de faire de même. Nous nous attacherons aussi à dégager du temps pour eux dans nos agendas surchargés. Nous voulons être des partenaires positifs et de valeur. En agissant ainsi, nous pouvons espérer gagner le privilège d’être impliqués dans la préparation des documents et sessions pour la direction. Ce peut être limité à valider la justesse des faits rapportés et ceci est déjà très utile. Ce peut être de comprendre ce qu’ils vont mettre en évidence et même de discuter certaines de leurs recommandations intermédiaires.
Dans mon rôle de PM, si les auditeurs me demandent mes attentes de l’audit, je mets en évidence 2 points majeurs :
1. Obtenir des recommandations de valeur pour améliorer le projet
2. Équité envers les membres de l’équipe.
L’étape suivante est l’achèvement de l’audit et de la production des recommandations. Inévitablement, il y en aura certaines avec lesquelles vous êtes d’accord ou que vous pouvez comprendre. Il y aura d’autres qui seront plus difficiles à accepter. Dans tous les cas, il est absolument critique de rester positif et ouvert. Passer en mode défensif n’aiderait en rien. De plus, gardez à l’esprit que les recommandations des consultants et auditeurs sont une chose; le choix des recommandations sur lesquelles la direction décidera d’agir est une autre affaire (bien plus critique pour vous et votre projet).
Dès que vous comprenez quelles actions correctives ou d’amélioration sont retenues, partagez celles-ci avec l’équipe projet de manière positive. Il est fréquent que le rapport complet des auditeurs ne soit pas diffusé. Seuls les points principaux des rapports sont présentés. Ceux qui engagent l’équipe sur des actions productives.
En conclusion, je suggère que, si votre projet n’est pas encore audité, vous considériez quels domaines pourraient être améliorés par un conseil externe et sollicitiez un audit sur ceux-ci : Demandez de l’aide avant que quelqu’un au-dessus de vous ne décide que vous avez besoin d’être aidés.
Sur de nombreux projets, vous constaterez que les auditeurs vous aideront énormément à améliorer certains aspects comme le contrôle du périmètre, la rigueur dans la gestion des demandes de changement ou l’engagement de vos sponsors dans le management des risques. Les auditeurs portent un œil externe sur votre projet et sont donc bien plus objectifs que vous ne pouvez l’être.
modeste expérience de PMO pour la mise en place d’un ERP :
Un retour sur mon expérience de PMO pour le déploiement d’un ERP en 2003. Voir slides 13 à 30 pour une vue pratique pour chacun des domaines de compétence identifiés par PMI.
http://intranet.pmi-fr.org/documents/clients/35/docviadeo/PMOLessonsLearned-MichelOperto.pdf
modest PMO experience for an ERP implementation: An experience sharing of an ERP Programme Management Office in 2003. Check slides 13 to 30 for a practical return on experience for each of the PMI competency domains.
DantotsuPM.com 