The Project Sponsor Role in the Engagement par Brad Egeland
Il va sans dire que le sponsor de projet est un rôle très important sur le projet. Sans le sponsor de projet – et son argent et engagement – le projet ne se sera jamais réalisé. Du point de vue de l’organisation de réalisation, il est votre client principal, le payeur de factures, celui auquel vous voulez vraiment faire plaisir. Il est celui qui pourrait appeler votre PDG si vous ne produisez pas bien. Il signe pour les livrables, il approuve les paiements et il négocie les jalons. Il est la voix du client. Gardez-le heureux et vous avez réalisé un des trois déterminants clés du succès de l’engagement de projet. Mais il y a une autre face. Regardons ceci du point de vue du sponsor de projet.
Le sponsor de projet, dans sa prise de rôle, accepte la responsabilité complète envers l’organisation d’atteindre les objectifs du projet. Le sponsor de projet est, en réalité, le patron. Le sponsor est typiquement une personne expérimentée dans l’organisation qui a un fort impact sur le business. Il a l’expérience nécessaire sur le projet entrepris, ou la capacité organisationnelle de faire que les choses se fassent. Le sponsor pourrait aussi avoir pour titre senior manager, directeur, PDG, ou CIO. Le sponsor voit comment faire les choses de façons qui sinon pourraient normalement demander une éternité au chef de projet. Le sponsor passe aussi en revue le progrès d’ensemble du projet et sert de source de support s’il y a des conflits.
L’individu qui assume le rôle de sponsor de projet sera responsable de :
Choisir le chef de projet (ceci peut varier selon que ce soit un projet interne ou externe)
Établir les objectifs de projet
Fournir le leadership pour l’ensemble de l’équipe
Vendre le projet aux parties prenantes
Résoudre les risques et problèmes cruciaux, si le chef de projet ne peut pas le faire
S’assurer que le chef de projet communique sur le progrès et adopte la meilleure approche
S’assurer que l’on fournisse l’approbation pour passer à la phase suivante du projet
Approuver les changements majeurs
Fournir la direction sur le projet
Potentiellement aider dans l’obtention de ressources de valeur quand le projet en exige
Assister du chef de projet sur évaluation et les rapports de performance
Avant la prise de rôle de sponsor de projet, il y a quelques questions clés que l’individu identifié doit se poser à lui/elle-même et à d’autres, car une évaluation et un engagement personnel seront nécessaires.
La liste suivante identifie une brève « liste de contrôle d’acceptation » qui pourrait être utilisé par un/une sponsor de projet sur un projet informatique typique pour mesurer sa volonté et sa capacité à prendre ce projet spécifique.
Le projet est déjà en voie de réalisation et est en mauvaise forme.
J’ai le temps disponible pour me dédier à être un/une sponsor de projet.
Je mettrai en application des décisions défavorables si besoin pour mener le projet à son terme.
Je suspendrai ou annulerai le projet si approprié.
Le succès est possible en travaillant avec le chef de projet / l’équipe.
Je pourrai vendre le projet aux parties prenantes quand nécessaire.
Je peux obtenir et motiver les ressources nécessaires pour le projet.
Les informations de cet article ont été tirées, en partie, du Livre de Charvat intitulé “Project Management Nation.”
partagez ce billet avec vos amis, collègues et relations professionnelles
Vous reconnaissez l’importance de processus réussis, répétables et fournissant régulièrement des statuts et états d’avancement.
Mais vous pouvez parfois ressentir que ces processus et rapports créent plus de travail ennuyeux qu’ils ne le méritent et répondent simplement à une demande organisationnelle.
Beaucoup d’organisations, particulièrement celles avec un bureau de management de projet (PMO), imposent certaines méthodologies qui consistent typiquement à préparer des plans et rapports à remplir. Ceux-ci incluent:
Les indispensables (bonnes pratiques)
Une Structure de découpage du travail (Work Breakdown Structure : WBS);
des références de base pour contenu, échéancier et coût;
un plan de management de projet; et
des plans de communication pour les parties prenantes
Les Facultatifs
Organigramme
Matrice d’approvisionnement
Analyse de marché
Cela demande du temps et des efforts que d’évaluer la méthodologie et les processus. Souvent, les personnes ne veulent pas remettre en cause une pratique qui est en place depuis longtemps même si cette pratique a rempli son utilité première. Alors, comment savoir si vous fournissez trop d’informations aux parties prenantes ? Les données que vous rassemblez régulièrement et vos rapports peuvent ne même pas être analysés, ni des actions prévues en réponse.
Comment pouvez-vous assurer que vos processus sont efficaces et ajoutent de la valeur ?
Réalisez des Enquêtes à la Fin de Chaque Projet
Engagez une tierce partie neutre pour mener une enquête à la fin de chaque projet.
Demandez à votre équipe si tous les aspects des processus prescrits ont vraiment été suivis et sinon, pourquoi.
Demandez aux clients et aux parties prenantes si le produit fini, le service ou le résultat ont satisfait à leurs exigences et sinon, voir si le problème concernait le processus.
Vérifiez combien de temps vous avez dépensé chaque semaine ou chaque mois à vous conformer aux processus.
Questionnez la valeur des processus, leur utilité et les idées d’amélioration.
Quelques personnes peuvent ne pas comprendre pourquoi le processus existe. Elles pourraient demander d’avoir une vue d’ensemble, par exemple, de comment la métrique sur le projet est utilisée par ceux qui ne sont pas dans l’équipe – et de comment mieux préparer les plans et rapports requis à l’avenir.
Revoyez les réunions de Projet et les Rapports
Évaluez vos réunions pour vous assurer que tous participants qui sont là ont besoin d’y être. Chacun devrait avoir un rôle spécifique et pouvoir prendre des décisions.
Puis, à la fin de chaque réunion, évaluez le temps requis pour préparer et conduire la réunion, la valeur des plans d’action qui en ont résulté et les décisions qui ont été prises.
Pour évaluer l’utilité des rapports de projet, demandez à vos parties prenantes. Demandez s’ils lisent ces rapports.
L’équipe devrait aussi évaluer toutes les demandes d’informations Ad hoc comme une autre façon d’évaluer si les rapports existants adressent les préoccupations clés des parties prenantes.
Déterminez combien de temps est passé à préparer chaque rapport et si un modèle standard est vraiment utilisé.
Créez un Plan d’Amélioration de Processus
Après avoir évalué vos processus et rapports et identifié pourquoi ils ne fonctionnent pas ou des sujets d’amélioration, vous pouvez créer un plan d’amélioration de processus.
Ce plan décrit les changements proposés et leurs avantages. Il indique aussi comment les améliorations seront implémentées et évaluées dans l’avenir.
Partenaire de DantotsuPM - Cliquez sur ce logo pour contacter Ventura pour vos besoins en Management de Projet et PMO
Mettez Votre Processus au Défi
En travaillant dans notre environnement mondial de projet qui est en rapide et constant mouvement, le temps doit être utilisé efficacement pour répondre aux défis et priorités stratégiques de nos organisations.
Les approches testées et vérifiées d’hier peuvent ne pas être appropriées aujourd’hui. Seuls les processus que l’on considère exemplaires devraient être poursuivis.
Les processus qui ont besoin d’amélioration devraient être améliorés et les autres qui ne sont pas utilisés devraient être arrêtés.
partagez ce billet avec vos amis, collègues et relations professionnelles
Partenaire de DantotsuPM - Cliquez sur ce logo pour contacter Ventura pour vos besoins en Management de Projet et PMO
Bonjour, l’un de nos partenaires, Ventura Networks, recherche pour son client plusieurs consultants fonctionnels et techniques BSCS iX maîtrisant la langue anglaise pour une mission qui débuterait 2ème quinzaine de Novembre ou première de Décembre. Premier lot 4 semaines avec déplacement à l’étranger nécessaire.
Ce logiciel est un système bout en bout convergent qui permet d’offrir des services efficaces de gestion de la clientèle et de facturation en temps réel pour les services voix, données, contenus et autres services Internet. Il s’appuie sur les applications iX Rating, iX Billing, et les applications en ligne de service client en libre-service et de gestion des partenaires, toutes basées sur l’architecture LHS de pointe iX.
Si vous êtes intéressés et possédez l’expertise requise, envoyez votre CV à Ludovic le Moulec
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Le programme MSP® (Managing Successful Programmes – Gestion de programmes réussis) de l’OGC rassemble les meilleures pratiques de gestion de programmes.
Partenaire de DantotsuPM
MSP® – Managing Successful Programmesdé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).
L’infrastructure MSP repose sur trois concepts clés:
6 Flux Transformationnels – Les flux suivent le cycle de vie d’un programme, de sa conception à la livraison de la nouvelle capacité, des résultats et des bénéfices.
7 Principes – Ils résultent des leçons apprises, positives et négatives, et sont tirés des retours d’expérience de programmes. Ce sont les facteurs communs sur lesquels repose la réussite de tout changement transformationnel.
9 Thèmes de Gouvernance – Ils définissent l’approche d’une organisation vis-à-vis du management de programme. Ils permettent aux organisations de mettre en place un leadership, une équipe de livraison, des structures organisationnelles et des contrôles appropriés pour atteindre la meilleure chance de réussite.
Les objectifs de MSP :
Offrir aux organisations un standard et un concept cohérent de gestion des programmes
Permettre une gestion plus efficace avec des rôles et responsabilités clairement définis prévenant le gaspillage de ressources
Fournir aux dirigeants un instrument qui leur permet de gérer les changements sans perdre de vue leurs objectifs business
Atteindre les résultats grâce à un processus formel d’identification, de gestion, de réalisation, et de mesure du résultat.
Favoriser l’utilisation balancée des ressources grâce à la priorisation des projets. Le fait que les projets soient considérés dans leur ensemble améliore la gestion des risques, le respect des délais, budgets et normes de qualité
Permettre la mise en place efficace de changements et une transition fluide de l’entreprise d’aujourd’hui vers l’entreprise de demain
Les examens MSP
Trois qualifications MSP sont disponibles : Foundation, Practitioner et Advanced Practitioner. Les candidats doivent réussir l’examen Foundation avant de passer un examen Practitioner.
MSP niveau de Base
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.
MSP Expert
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.
MSP Expert Supérieur
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.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
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 :
Un désir d’avoir tous les membres de l’équipe leur reportant directement
Avoir tous les membres de l’équipe hautement qualifiés et les plus performants
Avoir des membres de l’équipe qui soient entièrement dédiés au projet
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 ?
Abordons d’abord la question de manager une équipe transversale où les personnes ont seulement envers vous, le chef de projet, une relation en ligne pointillée.
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.
J’essaye toujours de découvrir quels objectifs individuels ont les personnes et comment le projet pourrait les aider à les atteindre (une nouvelle compétence, de la reconnaissance, un avancement de carrière, etc). Un manager technique m’a dit une fois que les projets importent à son personnel quand le résultat est d’apprendre quelque chose de nouveau, d’acquérir une compétence recherchée, ou de gagner en la visibilité dans l’organisation; ainsi, si la stratégie organisationnelle ne le permet pas, faire appel aux buts personnels d’un individu est un autre facteur de motivation.
Plus important encore, je développe des relations fortes avec des managers fonctionnels/de ressources. Je gagne leur confiance en vérifiant que leurs salariés sont productifs et non errant perdus dans le projet.
En règle générale, je laisse les gens me dire quand ils peuvent livrer (plutôt que dicter des délais), mais ensuite, je les tiens responsables de leurs engagements.
Maintenant, en ce qui concerne la question des compétences et de la performance.
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.
Dans une organisation technologique, les écarts de compétence (des acteurs « utilitaires » plutôt que des superstars), se concentrent d’habitude sur un manque de connaissance d’architecture complète, de connaissance business, une incapacité de communiquer, ou une incapacité de correctement évaluer le travail. Je traite ceci en requérant la participation d’un expert technique qui peut fournir le design, le coaching et estimer le support nécessaire à l’acteur « utilitaire ».
Du coté business, d’habitude la question est un manque de connaissance du processus entier (et un manque d’analystes fonctionnels). Ma stratégie est ici de rendre cette connaissance explicite en conduisant les examens à 360 degrés d’un processus avec tous les joueurs business impliqués pour m’assurer que le plan est amélioré de notre connaissance collective. J’essaye d’avoir autant d’écrits que possible (même si ce sont simplement des listes de contrôle et des diagrammes de flux), pour que cela fournisse la nécessaire pour la formation, les tests et les apports futurs de données au projet.
Avoir des stars sur votre équipe est un plaisir. Ils comprennent tout immédiatement et savent que faire; mais, soyons honnêtes; les stars ne veulent pas souvent faire les tâches banales ou ennuyeuses. Avoir un mélange de niveaux est clef pour faire réaliser tout le travail dans le projet et vous donne la capacité de jouer sur les forces de chacun. Il n’y a rien de plus satisfaisant que de donner à quelqu’un l’occasion d’aller au-delà de ses capacités et si réussi, cela crée plus d’options et de talents qualifiés pour le projet suivant.
J’essaye et j’encourage les chefs de projet à travailler directement avec des individus quant à leur performance avant d’escalader vers les managers fonctionnels. En tant que chef de projet dans une organisation, les chances sont grandes que vous travaillerez avec les mêmes personnes à plusieurs reprises. Si vous n’établissez pas de confiance et un rapport sain avec ces personnes, les mêmes difficultés se reproduiront dans chaque projet. Avant d’escalader, découvrez si les problèmes sont dus à un manque de clarté de tâche ou à des conflits d’équipe. Peut-être il y a des choses dans le projet que vous pouvez réparer pour aider quelqu’un à devenir radicalement plus performant.
Si vous devez impliquer le manager fonctionnel, essayez de travailler avec l’individu et son manager fonctionnel pour mettre en évidence les points de tension et demander du support pour rendre chacun d’eux fructueux; autrement dit, avant que vous ne vous n’escaladiez, démontrez que vous avez essayé de trouver des solutions avec la personne. Le licenciement d’un membre de l’équipe est un dernier recours, mais ne devrait se produire que s’il esr vraiment incompétent ou perturbateur dans l’équipe. La clé est que le manager fonctionnel ait a) vu votre empressement de le faire fonctionner et b) démontré son engagement à vous aider à trouver une résolution juste au problème de performance.
Finalement, sur la question du focus, comment est-ce que j’empêche les personnes d’être distraites par d’autres travaux ?
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.
Je m’assure que la planification de projet prend en compte le cycle de l’activité business; par exemple, j’évite de prévoir un projet de finance pendant les mois de fin d’année fiscale, ou un projet d’adhésion pendant la campagne de renouvellement de droits annuels. Pourquoi donner une raison aux gens d’être distraits ? Si on me donne un délai impératif, je l’utilise comme un motivateur pour piloter le centre de ressource. Des délais impératifs sont généralement pilotés par des raisons business ou réglementaires et je les démultiplie pour créer l’urgence dans le projet et gagner le support pour donner aux tâches de ce projet la priorité sur d’autres travaux.
Je suis fortement organisé sur la réalisation des tâches et je suis ce qui est dû chaque semaine. J’essaye d’avoir affaire directement avec les membres de l’équipe à propos de délais manqués car habituellement ces manquements révèlent plus que de la distraction et de l’incompétence. Si c’est une question de priorités, je ne suis pas timide pour impliquer le manager de ressources et les sponsors business à me supporter pour obtenir pour les recentrer sur les tâches de mon projet. Finalement, j’essaye toujours de supporter la situation critique des managers de ressources/fonctionnels qui jonglent avec des priorités multiples. Si les délais peuvent être ajustés, j’essaye de les ajuster. Je veux créer de la bonne volonté en supportant une crise à l’extérieur de mon projet, mais être en même temps ferme (et communicatif) sur les activités qui sont sur le chemin critique.
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.
Je défends l’équipe et reconnais que les échéanciers doivent être réalistes et tenir compte des défis uniques du management dans la matrice!
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
Application Lifecycle Management: Microsoft Project Server 2010 and Microsoft Team Foundation Server 2010, Better Together
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′).
cliquer sur l'image pour visionner la vidéoPartenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
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 :
Vos défis et besoins actuels;
la taille et le type de votre organisation, la nature et la portée des projets; et
la maturité en management de projet de votre organisation.
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.
Les Six Éléments de l’ADN du PMO
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.
Exécution et performance : Se concentre sur les aspects tactiques d’exécution de projet en fournissant des processus standardisés, des méthodologies, des outils, des modèles, de la formation et le support pour améliorer les capacités de construction et d’exécution.
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.
Gouvernance : Établit une structure de prise de décision pour lier le stratégique avec le tactique et facilite et remonte les décisions clés sur le projet/programme, y compris la configuration des politiques et procédures et l’établissement de mécanismes de gouvernance comme des portes de passage de jalon.
Gestion de la performance et des rapports : Fournit des informations consolidées et la transparence avec des rapports appropriés qui aident dans le suivi et le management de la performance du projet, programme et portefeuille.
Management des communications et des relations : Identifie les liens et des dépendances, détecte des problèmes et des goulots d’étranglement systémiques, résoud les problèmes de communications et d’interface à travers les silos organisationnels et développent et gèrent des relations avec les parties prenantes.
Management de changement organisationnelle : puisque le management de projet est le management du changement, le PMO peut aider à faciliter et préparer le changement.
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.
Partenaire de DantotsuPM - Cliquez sur ce logo pour contacter Ventura pour vos besoins en Management de Projet et PMO
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
Métriques dans le management de projet : Plus que des chiffres
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 »).
Définition du management de métrique
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 :
Mesures de management de projet pures (Exemple : exactitude des estimations)
Les indicateurs de succès de projet (Exemple : satisfaction des parties prenantes)
Les indicateurs de réussite business (Exemple : « Return On Investment : ROI »).
Au niveau macro, le management de métrique signifie identifier et suivre les objectifs stratégiques.
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.
Au micro niveau, le management de métrique signifie identifier et suivre les objectifs tactiques.
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.
Les critères suivants sont les mesures tactiques les plus communes dont les gens aiment être informés.
Comment progressons-nous par rapport à l’échéancier ? Schedule Performance Index (SPI) = Earned Value ÷ Planned Value Cost (SPI)
Où en sommes-nous par rapport au budget ? Cost Performance Index (CPI) = Earned Value ÷ Actual Cost Resources
Sommes-nous dans les prévisions d’heures de travail dépensées ? Nombre d’heures supplémentaires.
Les changements de périmètre sont-ils été plus importants que prévu ? Nombre de demandes de changement.
Les problèmes de qualité sont-ils réparés ? Le nombre de défauts réparés par test de recette.
Sommes-nous à jour de notre liste d’actions ? Nombre de problèmes en attente de résolution.
Mise en place d’un Programme de Métriques
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:
Comment allez-vous collecter les informations ? (Astuce : Rendez-le facile. Utilisez des informations déjà produites pour d’autres objectifs.)
Quelles méthodes utiliserez-vous pour traiter et analyser les informations ? (Astuce : plus l’analyse mène à l’action meilleure elle est.)
Comment et quand ferez-vous un rapport sur les résultats ?
Un mot spécial sur les rapports
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 :
Vert signifie “Jusqu’ici tout va bien”.
Orange “Attention – A surveiller”.
Rouge “une attention urgente est nécessaire”.
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.
Amenez le management de métrique au niveau supérieur
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
Pourquoi est-ce 18 et pas 12 ou 24 ?
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.
Comment une équipe évite-t-elle la règle ? Par les quelques étapes simples suivantes :
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.
En comprenant la Règle des 18 Mois, vous pouvez assurer que vos projets auront l’impact que vous désirez.
Bonne chance !
partagez ce billet avec vos amis, collègues et relations professionnelles
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 ?
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.
Des indicateurs clefs pour évaluer la performance organisationnelle de PMOs
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é.
Une approche Étude de cas
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.
Conclusion
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.
Partenaire de DantotsuPM - Cliquez sur ce logo pour contacter Ventura
partagez ce billet avec vos amis, collègues et relations professionnelles
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
Étape 1 : Innocent
À 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.
Étape 2 : Exposé
À 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.
Étape 3 : Apprenti
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 obtiennentquelques ours; mais il est aussi typique que quelques ours obtiennent quelques Étape 4s.
Étape 5 : Compagnon
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.
Étape 7 : Chercheur
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.
les Sept Étapes d’Expertise appliquées au management de projet
Étape 1 : Innocent
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.
Étape 2 : Exposé
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.
Étape 3 : Apprenti
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 !
Étape 4 : Praticien
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.
Étape 5 : Compagnon
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.
Étape 6 : Maître
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.
Étape 7 : Chercheur
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é.
Finalement — quelques recommandations
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…
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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…
L’équipe les personnalisant pour répondre aux besoins de votre organisation et à la vitesse de votre activité.
L’équipe les mettant en œuvre pour supporter et cultiver la maturité des capacités de management de projet de votre organisation
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.
Le poste
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.
Quand ?
Plein temps démarrage le plus rapidement possible (début septembre au plus tard) jusqu’à fin décenbre 2010; avec possibilité d’extension.
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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:
number of Project Managers in the PMO versus no PMs in the PMO
decision making authority versus supportive
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:
Report project status to upper management
Develop and implement a standard methodology
Monitor and control project performance
Develop competency of personnel, including training
Implement and operate a project information system
Provide advice to upper management
Coordinate between projects
Develop and maintain a project scorecard
Promote project management within organization
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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 :
Un certain nombre de chefs de projet dans le PMO ou bien aucun
Une autorité décisionnelle ou bien un rôle de support
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 :
Donner le statut des projets auprès de la direction
Développer et mettre en œuvre une méthodologie standardisée
Surveiller et contrôler la performance des projets
Développer la compétence du personnel, y compris sa formation
Déployer et exploiter un système d’information de projet
Fournir un conseil auprès de la direction
Fournir une coordination entre projets
Développer et maintenir un tableau de bord (scorecard) de projet
Promouvoir le management de projet dans l’organisation
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
Le sponsor de projet, dans sa prise de rôle, accepte la responsabilité complète envers l’organisation d’atteindre les objectifs du projet. Le sponsor de projet est, en réalité, le patron. Le sponsor est typiquement une personne expérimentée dans l’organisation qui a un fort impact sur le business. Il a l’expérience nécessaire sur le projet entrepris, ou la capacité organisationnelle de faire que les choses se fassent. Le sponsor pourrait aussi avoir pour titre senior manager, directeur, PDG, ou CIO. Le sponsor voit comment faire les choses de façons qui sinon pourraient normalement demander une éternité au chef de projet. Le sponsor passe aussi en revue le progrès d’ensemble du projet et sert de source de support s’il y a des conflits.
t Management Is Finally Getting Real Respect
DantotsuPM.com 