Voici quelques articles publiés précédemment qui, je l’espère, sauront vous intéresser si vous êtes confrontés à de sérieuses difficultés sur votre projet, devez être audité ou, à l’inverse, devoir auditer vous-même un projet.
Certaines des leçons que j’ai appliquées, je les ai apprises au prix d’un certain nombre de cicatrices, et de l’observation d’autres de chefs de projet que j’ai rencontrés ou avec lesquels je suis en relation. Il n’y a aucune formule magique ni nec plus ultra; Seulement quelques leçons relativement simples qui démentent la difficulté avec laquelle elles sont mises en œuvre.
Le résultat de l’effort de triage est d’identifier ces projets le plus dans le besoin d’intervention immédiate. De même que dans le monde médical, l’étape suivante après le triage est le diagnostic; il est maintenant temps de se concentrer sur les projets du troisième groupe et exécuter un diagnostic de projet. Si vous êtes assigné au sauvetage d’un projet en échec, voici les premières étapes pour trouver la cause ou les causes premières des difficultés du projet.
Quand j’ai commencé comme un chef de projet, personne ne m’a parlé de gouvernance. Personne ne savait même ce que cela signifiait. Nous avions une méthodologie et un processus et nous pouvions de temps en temps avoir un audit – mais rien de tel que ce que nous avons vu sur les cinq dernières années. Les scandales d’entreprise du début des années 2000, avec la transparence plus grande qu’attendent les régulateurs, actionnaires, clients et même les employés, ont aujourd’hui fait de la gouvernance une partie nécessaire de toutes les initiatives majeures.
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.
La plupart des processus utilisés dans vos organisations sont audités et il devrait en être de même de vos processus de management de projet. Il est aussi important de réaliser des audits de vos projets que de vos processus d’assurance qualité. Le PMBOK décrit l’audit comme “une revue indépendante structurée pour déterminer si des activités de projet observent les règles et procédures organisationnelles et de projet.” Il existe beaucoup de vues différentes et d’approches aux audits de projet mais nous allons coller à l’approche du PMBOK dans cet article.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Si je transpose le billet de Seth au monde du management de projet, voici ce que cela donne.
Je sais que je dois remplir ce formulaire avant de passer devant le comité de financement, mais la façon dont vous vous comportez quand vous concevez le formulaire et la manière avec laquelle vous me demandez de le remplir changera comment je vois tout le reste des choses que vous voudriez que je fasse.
Je sais que je dois aller à cette réunion ou suivre ce processus ou écouter ce discours, mais, justement ici, en ce moment même où vous avez le pouvoir, vous allez établir la manière dont je considère votre organisation toute entière.
Si un PMO travaille dur pour fournir une expérience positive quand le chef de projet n’a aucun choix, le bénéfice du doute qu’il a gagné vaut bien plus qu’il ne coûte.
Redéfinissez ce formulaire, changez votre attitude, ajustez vos processus et inclinez-vous pour montrer votre reconnaissance. Vous en serez récompensés.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Mike Clayton est un auteur et un speaker spécialisé dans le management de projet, la gestion du changement, le leadership, l’influence et le risque. Il est l’auteur de Risk Happens, Brilliant Project Leader et un nouveau livre ce mois-ci intitulé Smart to Wise. Vous pouvez le suivre sur Twitter : @MikeClayton01.
Dans les années 1970, le psychologue social Irving Janis a étudié comment les groupes prennent des décisions. Il a constaté que la dynamique de groupe interdit souvent l’exploration d’alternatives. Les personnes trouvent le désaccord inconfortable, donc le groupe cherche le consensus avant d’être parvenu à une conclusion pleinement satisfaisante. Comme le groupe s’approche du consensus, les voix discordantes sont rejetées ou, dans les faits, sont souvent autocensurées. Janis a écrit : “la recherche de consensus devient si dominante dans un groupe cohésif qu’il a tendance à ignorer l’évaluation réaliste de plans d’action alternatifs.”
Quand nous devenons la proie de la pensée de groupe, les décisions ont tendance à être basées sur “ce que nous savons tous ».
C’est-à-dire que les membres s’interdisent de défier le consensus et les informations pertinentes, idées et défis ne sont pas entièrement explorés. Janis a décrit la pensée de groupe comme se produisant “Quand les efforts du membre pour trouver l’unanimité prennent le dessus sur sa motivation d’évaluer avec réalisme des chemins d’action alternatifs.”
dérive risquée ou polarisation de groupe
Suite à la pensée de groupe, le groupe a tendance à accorder une confiance collective plus forte à la décision que les personnes qui ont pris la même décision de manière individuelle. Donc, avec le découragement des dissensions, les groupes ont tendance à approuver des décisions à plus fort niveau de risque que les individus isolés. Les psychologues s’y réfèrent comme “la polarisation de groupe”.
Les personnes avec des positions plus extrêmes vont probablement développer plus que d’autres des arguments clairs et vont aussi très probablement les exprimer. Les commentaires qui arrivent tôt dans un débat sont plus influents dans la formation des opinions et créent aussi une structure pour la discussion. Quand la pensée de groupe commence à adopter une décision sur un extrême, les membres du groupe peuvent être encouragés à avancer des points de vue toujours plus extrêmes.
Cette dérive risquée est la différence entre le risque moyen pris par des individus et le risque pris par le groupe. Ceci peut générer un changement risqué vers une position à plus fort risque ou, également, un changement prudent vers une position plus opposée à tout risque.
supprimez la pensée de groupe
Dans son livre, The Wisdom of Crowds, James Surowiecki écrit : “dans des discussions ouvertes, peu structurées, libres, les informations dont on aura tendance à parler le plus sont, paradoxalement, les informations que chacun connaît déjà .”
Donc, pour empêcher la pensée de groupe, vous devez vous assurer que de nouvelles informations peuvent être présentées, que l’on peut écouter des positions discordantes et que les critiques peuvent être exprimées.
Nommez un avocat du diable
Demandez à un membre de l’équipe de jouer le rôle « d’avocat du diable » et de chercher à s’opposer à tout consensus par des évidences contraires, des interprétations logiques différentes, des vues ou perspectives nouvelles. Dans leur livre, The Corporate Fool, David Firth et Alan Leigh identifient des façons différentes de bouleverser la pensée douce et le statu quo d’organisations en empruntant aux rôles différents du fou du roi médiéval. « L’anticonformiste » défie des normes et « le chercheur de vérité » énonce des vérités difficiles à entendre. Ceci est tout simplement le remède à la pensée de groupe.
Encouragez chacun à être un évaluateur critique
Il n’y a aucune raison à ne pas tous adopter le rôle d’avocat du diable. L’approche d’Edward de Bono “ Six Thinking Hats ” sur la pensée critique et créative suggère que deux chapeaux – le Chapeau Blanc et le Chapeau Noir – nous encouragent à évaluer logiquement la preuve et avec toutes les données disponibles (le Chapeau Blanc) et à défier, critiquer et évaluer tout ce que l’on a proposé (le Chapeau Noir). En tant que chef de projet, encouragez tous les membres de votre équipe à mettre leurs Chapeaux Blancs et leurs Chapeaux Noirs à certains moments pour éviter de glisser dans la pensée de groupe.
Ne laissez pas le leader exposer une préférence dès le début
Il y a beaucoup de types « de leader » dans une discussion : le responsable, le facilitateur, l’expert ou le patron. Tous ces individus peuvent avoir un impact disproportionné sur la pensée de groupe qui vient du statut qu’ils détiennent. Pour éviter que les membres du groupe soient séduits par le point de vue du leader, demandez-lui de n’exprimer celui-ci que vers fin de la discussion principale. Ceci offre un grand avantage supplémentaire : quand nous exposons notre position, il devient plus difficile de la changer et souvent ceci est même plus vrai quand nous nous considérons comme des leaders ou des experts : nous craignons de perdre la face. En encourageant les leaders et les experts à ne pas exposer leur avis, vous facilitez leur l’évaluation des arguments qu’ils entendent et leur permettez de réévaluer leur propre réflexion.
Configurez des groupes indépendants
Si un groupe est susceptible de céder à la pensée de groupe, il se battra ardemment pour faire adopter son point de vue. En le divisant en deux ou davantage de sous-groupes indépendants, vous encouragez chacun à penser par lui-même. Rassemblez-les ensuite pour partager leurs opinions dans une séance plénière. De cette manière vous entendrez une gamme variée d’arguments.
Invitez de nouvelles personnes dans le groupe
Quand vous introduisez de nouvelles personnes dans un groupe, vous faites plus que seulement introduire des idées fraîches. Sans allégeance au groupe, elles ne ressentiront pas la même pression de conformisme. Et, comme en tant qu’externes, ils ne vont probablement pas partager les dérives et préjugés du groupe, ils devront poser des questions pour comprendre les arguments et ne se contenteront pas de réponses faciles et peu robustes. Surtout, ils apportent une diversité d’idées, de styles de pensées et de connaissances.
Récoltez un retour d’information anonyme
Quand nous contribuons anonymement à un argumentation, nous sommes bien plus à l’aise et allons plus probablement dire ce que nous pensons vraiment. Comment pouvez-vous utiliser des boîtes à suggestion, un forum en ligne ou un intermédiaire indépendant pour encourager un retour d’information honnête et de contributions véritables ?
partagez ce billet avec vos amis, collègues et relations professionnelles
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
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
Depuis les deux ou trois dernières années il semble que le mantra de chacun ait été: « faire plus avec moins ». Les dirigeants d’entreprise ont acheté des logiciels, créé des systèmes et incorporé quelques meilleures pratiques de management de projet dans l’espoir de tirer un peu plus de productivité du « petit » personnel. Essentiellement, cela signifie que les équipes travaillent davantage d’heures à essayer de faire leur travail avec moins de ressources. Ça suffit! Faire plus avec moins n’est pas la réponse à des ressources allant en s’amenuisant ni au besoin de rentabilité.
La vraie réponse est de faire moins avec moins, mais de faire davantage des bonnes choses.
Robert Half, auteur et pionnier dans le domaine de l’emploi a dit, « la combinaison du dur labeur et du labeur intelligent est un travail efficace. »
Dans le monde d’aujourd’hui, cela ne peut pas être plus vrai. Il n’y a pas de temps ou de ressources à perdre sur des initiatives de valeur limitée ou suspecte. Chaque projet doit fournir la valeur maximale business pour les ressources dépensées (et je parle tant du capital humain, que du temps et de l’argent). Cela signifie que les dirigeants d’entreprise doivent porter un regard critique sur le travail qui est réalisé et faire le choix de quelles initiatives seront poursuivies et desquelles ne le seront pas.
La priorisation du travail semble être une approche assez triviale, mais plus facile à dire qu’à faire. Cela exige un réel engagement du sommet jusqu’au bas de la pyramide pour être réussi. Ce qui signifie qu’il peut y avoir quelques parties prenantes qui devront renoncer à leurs projets « favoris » en faveur de quelque chose d’autre qui a le potentiel de fournir une plus grande valeur.
Comment les organisations s’assurent-elles que les personnes travaillent sur les bonnes choses ?
Je suis convaincu qu’une approche partant de la base qui donne le pouvoir aux membres individuels de l’équipe est la première étape et la façon la plus efficace de manager les échéances et les livrables. Cependant, le faire exige un réel engagement du sommet. Les organisations qui comptent sur des leaders de projet pour prendre des décisions d’allocation de ressources ou de priorité sans la pleine et entière confiance du PDG ou de l’équipe de direction finissent avec des membres d’équipe frustrés et des managers démoralisés.
Pour faciliter les choses, beaucoup d’organisations ont un comité de revue de projets qui regarde d’une façon critique chaque projet potentiel. Bien qu’il puisse y avoir des leaders de projet sur le comité de revue, c’est la représentation du dirigeant qui donne à ce comité son pouvoir de dire non. Quand chaque partie prenante qui supporte un projet doit gagner l’approbation du comité de revue, il est moins probable que des projets douteux soient soumis pour considération. Sans entrer à une longue discussion de « business case » et de critères de revue, il suffit dire que la revue de pairs est une excellente façon de distinguer les bons projets des mauvais.
« Suffisance vaut abondance, » a dit Marry Poppins. Voici un bon conseil à suivre. Quand les dirigeants d’entreprise comprennent qu’une fois que les limites en ressource sont atteintes, les requêtes de travail doivent s’arrêter, il devient beaucoup plus facile de faire de la priorisation une priorité. C’est difficile dans une culture où l’attitude « demander et ce sera exaucé » est répandue. Il est facile de lancer une requête de projet par-dessus la barrière si l’attitude du sommet est, « je ne me soucie pas combien de temps cela prendra, contentez-vous de le faire. »
Le problème avec cette mentalité est que tout faire avec moins de gens exige qu’ils travaillent de plus longues heures pour y parvenir. Qui plus est, ces heures supplémentaires excessives sont vraiment une indication d’un projet dans la panade. Trop d’heures supplémentaires mènent à trop de malnutrition, trop peu de sommeil et des salariés trop fatigués et grillés qui feront trop d’erreurs.
Cependant, ce n’est pas le chef de projet qui a l’autorité réelle de faire quoi que ce soit. Cela doit venir du sommet. La résolution des problèmes de sur-allocation de ressources exige un engagement de la direction.
Quand les organisations se concentrent sur les initiatives qui fournissent la plus grande valeur (ceci signifie qu’il pourrait même y avoir quelques bons projets qui ne seront pas exécutés en faveur de projets encore meilleurs), les leaders de projet peuvent passer plus de temps à travailler sur les choses qui importeront vraiment au business.
Autrement dit, ils peuvent en réalité faire moins avec moins, mais davantage des bonnes choses.
Partenaire de DantotsuPM
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
Dans nos vies remplies de projets, nous n’avons pas l’occasion de réfléchir sur les cruels dilemmes auxquels nous faisons souvent face. Les chefs de projet sont dans une position unique parce que la nature du travail de projet nous met au cœur de situations dans lesquelles nous sommes supposés beaucoup savoir, beaucoup voir, beaucoup faire et réaliser des choix difficiles sur une base fréquente et avec une responsabilité considérable.
Que faites-vous quand vous faites face à des dilemmes difficiles ?
Vous venez de recevoir un cadeau d’un fournisseur avec lequel vous avez travaillé l’an passé. C’est un cadeau cher avec une note vous remerciant pour cette affaire et disant attendre avec impatience de nouvelles opportunités. Vous savez que leur contrat est en phase de renouvellement et qu’ils sont en compétition avec deux autres vendeurs.
Rendez-vous le cadeau ? Acceptez-vous le cadeau et vous tenez-vous tranquilles ? Disqualifiez-vous le vendeur sur le contrat de renouvellement ?
Vos choix deviennent encore plus durs quand ils sont en conflit avec des obligations de satisfaire des clients peu réalistes, une direction exigeante et des parties prenantes qui vous challengent.
On vous a demandé de fournir un état d’avancement du projet à la réunion client suivante. Vous commencez à assembler une présentation et mettre en évidence une forte probabilité de retard et l’incapacité à respecter certaines des attentes du client. Le cadre commercial demande de passer en revue la présentation et vous la renvoie après la suppression des points clefs sur les retards et problèmes. Il fait remarquer que vous devez seulement mettre en évidence les accomplissements positifs ou bien la société ne gagnera pas un autre projet relié et en cours d’appel d’offres.
Allez-vous suivre la recommandation du cadre commercial ? Mettez-vous en évidence la vérité au briefing client ? Demandez-vous à être exclu de la rencontre ?
Certaines situations sont relativement claires. Celles-ci incluent le fait de refuser des cadeaux onéreux ou des commissions de fournisseurs; de falsifier des rapports d’avancement de projet; de surfacturer les heures de travail sur le projet; de faire des recouvrements de temps entre de multiples projets; de fausser les rapports de dépenses; et de mettre en œuvre des produits bancales. Celles-ci sont des décisions clairement contraires à la morale et beaucoup d’organisations ont des politiques sur ces sujets.
D’autres scénarios pourraient ne pas être aussi directs : Taire des informations, retarder des approbations, paiements en retards, décisions sous influence, omissions délibérées, conflits d’intérêt, discrimination, le manque de précision intentionnel et désordre ou jargon pour masquer ou brouiller les problèmes.
Les chefs de projet sont régulièrement testés comme ils évoluent dans cette zone de flou entre des choix, conséquences, attentes et valeurs contradictoires.
Les problèmes moraux sont complexes parce que votre décision peut être influencée par vos penchants personnels, organisationnels, sociaux ou culturels.
PMI’s Code of Ethics and Professional Conduct , le code de déontologie de PMI, fournit une ressource pour aider les praticiens en management de projet à considérer leur situation et utiliser leur meilleur jugement moral. Des outils et ressources qui lui sont connectés offrent aussi des avenues pour annoncer et résoudre des questions impliquant un comportement contraire à la morale avec le Comité d’Éthique PMI (PMI Ethics Review Committee).
La déontologie du PMI est ancrée sur quatre valeurs universelles de responsabilité, de respect, de justice et d’honnêteté qui ont été choisies par rapport à leur importance pour la communauté mondiale de management de projet.
Bien que vous puissiez objectez qu’il n’y a pas d’unique réponse juste, la déontologie fournit une structure pour l’introspection et le dialogue.
Voici quelques questions actions pour faciliter vos décisions :
Fournissez un mécanisme sûr pour vos membres d’équipe de projet pour soulever des questions et mettez en place les mécanismes de dialogue pour adresser les problèmes moraux des projets.
Dotez-vous d’une structure de gouvernance de projet attentive et de contrôles de projet pour empêcher les tentations de pratiques contraires à la morale.
Quand vous vous concentrez sur l’éthique, vous augmentez votre fiabilité et votre crédibilité.
Pour traiter avec des dilemmes moraux délicats, il est important de donner l’exemple et de créer un environnement éthique. Souvenez-vous, dans les questions d’éthique, souvent il ne s’agit pas de ce que vous avez fait, mais de ce que vous avez échoué à faire.
Mr. Duggal is the managing principal of Projectize Group LLC, specializing in next generation training, consulting and tools. He is a keynote speaker and a PMISeminarsWorld® leader for Building a Next Generation PMO and Portfolio Management seminarand works with leading companies worldwide.
partagez ce billet avec vos amis, collègues et relations professionnelles
Les informations de cet article ont été tirées, en partie, du livre de Johnson et Hall, “Integrated Project Management.”
La réunion de démarrage est une partie essentielle de n’importe quel engagement de projet. L’effort et la préparation qui y entre peuvent très bien dépendre de la taille du projet et de sa criticité pour votre société. Si c’est un nouveau type d’engagement de projet, ou extrêmement visible, ou pour un client très en vue, la quantité d’effort et de détails mis dans la préparation de la réunion de démarrage peuvent devoir être très élevés. Si c’est un projet qui est semblable à bien d’autres que vous ou quelqu’une dans votre organisation avez déjà exécuté, cela peut exiger seulement une petite quantité de préparation et seulement deux heures de réunion en face à face. La clé pour n’importe quelle réunion de démarrage, est de passer à travers la déclaration de travail, les attentes, les rôles et missions, les livrables et le calendrier de haut niveau. Au minimum, tous ceux-là doivent être discutés et agréés.
Voici quelques questions de base qui doivent être couvertes pendant la réunion de démarrage de projet.
Expliquez pourquoi le projet est entrepris
Le chef de projet devrait rappeler les discussions avec les sponsors de projet, mentionnant les idées et les soucis qui ont mené à l’élaboration du projet; expliquer le besoin perçu et les bénéfices attendus après l’achèvement fructueux du projet; et indiquer la priorité qu’a le projet dans l’organisation. Cette explication aide l’équipe à comprendre l’importance que la direction place sur le projet et assure le management supportera les ressources a engagées le projet.
Présentez la spécification de projet
Le chef de projet devrait noter que la spécification explique exactement ce que le produit du projet devra être et que le succès du projet sera mesuré sur combien le produit répond à la spécification. Le chef de projet explique aussi les procédures pour mettre en œuvre des changements de spécification. Des membres d’équipe expérimentés sont typiquement habitués à ce que des objectifs projets changent pendant l’exécution d’un projet. Ils auront besoin de l’assurance que ces interruptions et intrusions seront bien reconnues par le chef de projet et seront soigneusement contrôlées et gérées.
Présentez les membres de l’équipe
Le chef de projet devrait présenter les membres de l’équipe et expliquer comment leur expertise sera utilisée sur le projet. Il ou elle devrait présenter chaque personne selon quand ils participeront, en suivant le projet du commencement à sa fin. Cet ordre mettra en évidence le flux d’activités. Chaque personne peut parler pour elle-même sur les projets plus petits. Cependant, avec de plus grands projets, le chef de projet devrait faire les introductions pour sauver du temps sur la réunion. Les membres de l’équipe peuvent ou pas se connaître, mais même s’ils sont mis au courant, il est important de favoriser la bonne communication et la coopération en indiquant le rôle spécifique que l’on s’attend à ce que chaque personne joue. De plus, il est utile pour le chef de projet de traiter les introductions pour que les points importants soient couverts et pour être certain que la période d’introduction ne souffre pas d’un membre de l’équipe plus prolixe.
Discutez l’importance des communications et comment cela se déroulera sur le projet
Le chef de projet devrait expliquer les bonnes compétences de communication et comment donner et recevoir le retour d’information. Il ou elle devrait souligner que le chef de projet prend les décisions critiques de projet, qui sont atteintes par la discussion pendant des réunions d’équipe. Il devrait aussi être noté que cela peut être accompli seulement par une communication efficace entre membres de l’équipe. On ne peut jamais donner trop d’importance à la bonne communication et au retour d’information efficace.
Développez des normes d’équipe
Le chef de projet devrait expliquer que les normes servent de directions pour la participation aux réunions d’équipe. Une chose qui est apprise par l’opération d’équipes de travail autogérées est que les normes (aussi appelé les règles de procédure ou d’engagement) jouent un rôle important aux réunions d’équipe et dans la collaboration de l’équipe. Le chef de projet doit expliquer les normes et assurer en général la compréhension et l’importance de concepts comme : “ne laissez jamais une réunion dépasser deux heures,” “arrivez à l’heure,” “restez fidèles à l’ordre du jour,” “venez préparés,” “ne vous interrompez pas pendant les discussions,” “concentrez les désaccords sur des résultats de projet, pas sur les personnalités,” etc.
Discutez de leadership collaboratif
Le chef de projet devrait discuter de leadership collaboratif, soulignant que les membres de l’équipe partagent ce leadership et que c’est fait par un leadership spontané. Cependant, il doit être souligné que la responsabilité de prise de décision critique se trouve toujours avec le chef de projet et la communication critique et la prise de décision doivent passer le PM.
Résolution de conflits et décisions de consensus
Le chef de projet devrait mener une discussion sur les conflits personnels qui peuvent surgir entre membres de l’équipe pendant un projet. On doit expliquer que si le conflit ne devient pas personnalisé, cela peut être canalisé vers le fait d’atteindre de bonnes décisions de projet. On devrait aussi expliquer les principes pour atteindre une décision de consensus.
Passez en revue le plan de projet et le calendrier prévisionnels
Le chef de projet devrait passer d’une copie du calendrier de projet avec des dates de tâche estimées, à chaque participant de la réunion de démarrage. Discutez avec le client et l’équipe qu’ils suivront une série d’étapes pour achever le projet. Passez en revue les dates et jalons prévus dans le calendrier de projet et assurez que tous les participants comprennent les tâches et les dates attendues. L’obtention de l’accord – particulièrement avec le client – sur des dates clefs de projet à cette première étape de l’engagement est critique à l’avancement sur le projet. Sans un tel accord, le projet ne peut pas vraiment commencer parce que vous travaillerez sur un calendrier de projet qui n’a pas encore été accepté.
Une note finale – il est impératif que le chef de projet souligne combien il est important que chaque membre de l’équipe reste concentré sur leurs tâches assignées et communiquent tout problème rencontré le plus tôt possible. Les retards de prise d’action corrective sur des problèmes peuvent causer des retard et dépenses significatifs, qui peuvent en fin de compte être responsables du succès ou de l’échec du projet tout entier. Soulignez que l’on doit donner la priorité aux tâches assignées et que le calendrier doit être respecté.
partagez ce billet avec vos amis, collègues et relations professionnelles
Bien démarrer le projet donne le ton pour tout le projet et positionne souvent l’équipe pour la réussite. Même si cela ne peut pas garantir le succès, avoir un mauvais démarrage de projet est dans la plupart des cas un premier signe d’alarme que le projet se dirige droit dans le fossé. L’événement le plus important pendant le processus d’initiation est la réunion de démarrage/de lancement. C’est cette rencontre entre l’équipe et les parties prenantes qui lance officiellement le projet. Cela pourrait bien être la réunion la plus importante parce que c’est souvent un test du chef de projet et de l’équipe par l’organisation pour voir si chacun est bien en place ou non.
Les bénéfices de la réunion de démarrage incluent :
Affirmation de l’appui du sponsor exécutif et des leaders seniors aux objectifs du projet.
L’explication de l’autorité et de la responsabilité du chef de projet à l’organisation pour obtenir l’appui et demander la coopération.
Une occasion pour l’équipe de se réunir sous la bannière du projet.
Donner les attentes des parties prenantes et de l’organisation quant à ce qui est couvert ou pas dans le périmètre du projet.
Recevoir les réactions sur toute omission dans les bénéfices potentiels du projet et commencer à construire/raffiner les exigences.
Il est important dans cette partie du processus de planification que le chef de projet travaille avec les parties prenantes pour assurer leur bonne représentation pendant la réunion.
Les participants à la session de démarrage devraient inclure :
Le sponsor exécutif et le chef de projet
Membres clefs du comité de direction
Tous les membres de l’équipe projet
Les représentants de l’organisation du client (interne ou externe)
Les représentants d’autres leaders de projets qui pourraient interagir avec ce projet (dans le cas d’un programme)
Puisque c’est la première occasion pour le chef de projet de démontrer sa force et ses compétences, il est important pour le PM de bien mener/faciliter cet événement. Cependant, pour que cette activité soit perçue positivement, le PM doit passer du temps avant la réunion pour la préparer.
Voici quelques suggestions pour aider le PM à bien se préparer pour l’événement et mener une réunion efficace :
La préparation d’une présentation qui est partagée avec les participants décrivant le « business case » pour le projet et la description de la portée à un haut niveau.
Discussion avec les membres de l’équipe des responsabilités et partager cette information pendant la réunion.
Mettre l’accent sur les éléments clefs de la charte de projet ou de la déclaration de travail ou du contrat client. Cela peut inclure des processus comme l’approbation de livrable ou le contrôle des modifications.
Discussion sur la terminologie pour parvenir à un accord sur un jeu de définitions communes.
Établir et/ou revoir les règles de vie d’équipe pour donner des attentes appropriées.
Fournir les détails de contact pour des parties prenantes clefs et exposer les étapes suivantes.
Détailler la suite proposée dans le processus et mettre en évidence les événements marquants prévus ou jalons pour le projet et s’assurer que chacun comprend ce qui arrivera ensuite.
L’identification d’une personne qui servira de preneur de notes de réunion pendant la session (autre que le PM) pour que les questions business, décisions et problèmes soient capturés.
La revue des éléments clefs du produit/service à livrer sur le projet afin de déterminer s’il y a bien une compréhension commune.
La conduite d’une session de « Team Building » si le temps permet et/ou si c’est approprié.
Une fois que l’on conclut la réunion avec succès, le processus de la réunion de démarrage n’est pas fini.
Il y a des activités de suivi que le PM et l’équipe doivent adresser pour assurer que la crédibilité se poursuive :
Revoir et distribuer les notes de la rencontre de démarrage incluant les points d’action.
Ajuster les composants clefs de la portée si certains ont été identifiés et mettre à jour la charte s’ils ont été agréés.
Communiquer sur le lancement du projet aux personnes non présentes ou non invitées à cette réunion.
Lancer une vérification de la portée détaillée et des sessions de validation des objectifs pour commencer la planification.
Documenter les modes opératoires et règles de vie avec l’équipe.
Communiquer les responsabilités convenues pour les divers membres d’équipe et parties prenantes.
Mettre à jour la documentation officielle comme la charte, SOW, etc …
Comme je l’ai mentionné, il n’y a peut-être aucune réunion plus importante que celle de lancement dans la vie du projet. Je m’en rappelle une, dans une organisation que j’ai rejointe, où le chef de projet est arrivé en retard et a quitté la réunion pendant 15 minutes pour faire les copies de l’ordre du jour (qu’il aurait du avoir au départ). Comme vous pouvez l’imaginer, cette réunion était peut-être la meilleure réunion de l’équipe projet qui a ensuite poursuivi sa descente aux enfers. Le projet ne s’est pas bien terminé.
Je suis sûr qu’il y a d’autres trucs que les praticiens ont relevé pendant leurs réunions de démarrage, donc merci de vos commentaires.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Par Jean-Baptiste JOURDANT, Responsable de l’offre Management de projet chez CSP Formation
« -C’est plus possible ! C’est nous qui devons être en relation avec le prestataire ! Tu n’as pas le droit de leur parler en direct !
– OK, OK ! Pas besoin de s’énerver. Je voulais juste accélérer le mouvement et m’assurer que les informations passent bien des utilisateurs aux développeurs…»
Moi, je veux bien. Si le patron de la DSI le dit, je ne vais pas m’y opposer. Mais s’ils connaissaient un peu le sujet, ça m’arrangerait pour mon projet. Comment je vais faire maintenant ? Je suis le chef de projet, mon patron, c’est le commanditaire du projet et je n’ai pas de droit de parler à mes prestataires ! De plus, il y a un nombre d’intermédiaires hallucinants entre les extrêmes de ce projet, de l’utilisateur final au développeur. Avec une dégradation systématique de la compréhension du sujet à chaque étape. Comment faire ?
Avant tout, de quoi parle-t-on ?
Voyons la nature des interlocuteurs possibles sur un projet, dans la chaîne de responsabilités. Ces définitions ne sont pas universelles d’ailleurs et peuvent recouvrir différentes réalités suivant les domaines dans lesquels elles sont utilisées.
La Maîtrise d’Ouvrage (MOA) : c’est donneur d’ordre au profit de qui l’ouvrage est réalisé. En gros, le client.
La Maîtrise d’Œuvre (MOE) : c’est l’entité chargée de réaliser l’ouvrage. Le responsable des opérations nécessaires à son achèvement.
Les délégués : parfois, chacune de ses entités délègue tout ou partie de leur responsabilité à des spécialistes.
On parle de MOAD (MOA déléguée, capable de prendre des décisions) ou AMOA (Assistance à MOA, plutôt exécutante). On peut avoir des entités internes spécialisées (un bureau des projets, par exemple, dans son rôle support) ou des consultants externes.
On parle aussi de MOED (MOE déléguée, avec fort niveau d’engagement) ou d’assistance à MOE (interventions ponctuelles ou exécutions). Ce sont des sous-traitants ou prestataires qui assurent ces fonctions.
La chaine de la « dé-valeur »
Je reviens maintenant sur mon projet de SI, que j’illustrais par le dialogue d’introduction.
Dans la première organisation mise en place, le CP MOA est placé comme « coordinateur » central du projet, avec une structure interne « MOAD » en support des opérations méthodologiques « projet ». Peu de rapport entre cette structure MOAD et la MOE sous-traitée.
Dans cette organisation, 2 comités de pilotage sont mis en place : Comité externe (CP MOA et client externe) et un comité de pilotage interne (CP MOA et CP MOAD). Avec évidemment les hiérarchies concernées. Le responsable et pilote de la réalisation est bien entendu le CP MOA, qui dans les faits cumule (en interne) les responsabilités de MOA et MOE, puisque la MOE est externe.
Évidemment, chaque sous-organisation produit ses tableaux de bord et a sa propre vision de l’avancement et de la santé du projet.
Suite à la soufflante du DSI, une nouvelle organisation est peu à peu mise en place.
Dans cette organisation, la MOA reste dans un rôle purement « défense des intérêts de son client » (commanditaire et utilisateurs). La structure interne de support aux projets reprend un rôle de MOE et devient responsable de la réalisation devant la MOA. Les comités mis en place deviennent le Comité de pilotage de « l’ouvrage » (CP MOA avec les utilisateurs) et le comité de pilotage de « l’œuvre » (CP MOE avec le prestataire et le CP MOA).
Quel bazar !
Dans cette nouvelle disposition à trois chefs de projets et deux comités de pilotage, une couche théorique s’est ajoutée et l’utilisateur s’est encore éloigné du producteur.
Comment faire pour limiter les incompréhensions entre ces représentants ?
Comment assurer une bonne adéquation entre le besoin et le livrable ?
Est-il vraiment nécessaire d’avoir autant de chefs de projets… au même niveau, sur le même projet ?
Ne peut-on pas avoir un unique comité de pilotage ?
Rationalisons !
Tout d’abord les chefs de projets.
Le CP MOA n’est pas le chef de projet. Il porte le besoin et garantit la satisfaction du client. Il recueille, exprime, recadre, arbitre, informe. Il est MOA. On peut l’appeler CP MOA. Mais si un chef de projet MOE est nommé à l’intérieur de l’organisation, ce sera bien lui le chef du projet. Avec une relation « client-fournisseur » interne.
Le CP MOE, est celui qui coordonne l’ensemble des activités sur le projet. Il garantit 2 axes principaux : la communication transverse et l’application de la méthodologie de management de projet. Il s’assure de la bonne information des parties prenantes en temps réel, diffuse les tableaux de bord, gère les risques et s’assure de la résolution correcte de tout problème.
La MOE déléguée pour réaliser l’ouvrage met en place une équipe projet de producteurs et d’experts. Chef de projet MOE délégué ? Oui, bien sûr, mais dans son entité propre.
Nos deux comités de pilotage ?
Plus vraiment. Il reste UN comité de pilotage animé par le CP MOE. De part et d’autres (côté client et côté prestataire) restent des réunions de suivi, de surveillance, d’avancement. Mais il ne s’agit plus de pilotage.
Les livrables méthodologiques ?
Entre les deux organisations, les tableaux de bords (TDB) ont été recentrés sur le chef de projet (CP MOE) et le cahier des charges fonctionnel lui a échu. Si ce n’est pas le cas, il risque de rester une « boîte aux lettres », un organisateur, un gestionnaire de projet. L’appropriation de la maîtrise fonctionnelle est l’espace critique de sa crédibilité.
Conclusion ?
En phase d’avant projet (type SI), lorsque la solution n’est pas encore définie, la MOA définit un pilote de cette phase. Un « chef de projet » en charge de cadrer le projet, identifier les risques majeurs, construire un business plan, recueillir la structure des besoins, évaluer pertinence et faisabilité.
Il peut être le chef de projet MOE responsable de la réalisation, en dialogue avec le commanditaire. Mais, il peut aussi n’être que « l’avocat » de la MOA.
Dans ce cas, il sera important lors de la phase de planification du projet et au plus tard au démarrage de l’exécution, d’avoir défini clairement les rôles et responsabilités de la chaîne de transformation du besoin en charges fonctionnelles, en solution technique puis en solution opérationnelle.
Et quelle que soit l’organisation choisie, le chef de projet, unique, devra :
1° garantir la plus grande fluidité de la communication entre acteurs « éloignés », en créant autant de points de rencontres que nécessaires,
2° maîtriser l’application des meilleures pratiques méthodologiques tout au long du projet.
Responsable de l’offre Management de projet chez CSP Formation
« -C’est plus possible ! C’est nous qui devons être en relation avec le prestataire ! Tu n’as pas le droit de leur parler en direct !
– OK, OK ! Pas besoin de s’énerver. Je voulais juste accélérer le mouvement et m’assurer que les informations passent bien des utilisateurs aux développeurs…»
Moi, je veux bien. Si le patron de la DSI le dit, je ne vais pas m’y opposer. Mais s’ils connaissaient un peu le sujet, ça m’arrangerait pour mon projet. Comment je vais faire maintenant ? Je suis le chef de projet, mon patron, c’est le commanditaire du projet et je n’ai pas de droit de parler à mes prestataires ! De plus, il y a un nombre d’intermédiaires hallucinants entre les extrêmes de ce projet, de l’utilisateur final au développeur. Avec une dégradation systématique de la compréhension du sujet à chaque étape. Comment faire ?
Avant tout, de quoi parle-t-on ?
Voyons la nature des interlocuteurs possibles sur un projet, dans la chaine de responsabilités. Ces définitions ne sont pas universelles d’ailleurs et peuvent recouvrir différentes réalités suivant les domaines dans lesquels elles sont utilisées.
La Maitrise d’Ouvrage (MOA) : c’est donneur d’ordre au profit de qui l’ouvrage est réalisé. En gros, le client.
La Maitrise d’Œuvre (MOE) : c’est l’entité chargée de réaliser l’ouvrage. Le responsable des opérations nécessaires à son achèvement.
Les délégués : parfois, chacune de ses entités délègue tout ou partie de leur responsabilité à des spécialistes.
On parle de MOAD (MOA déléguée, capable de prendre des décisions) ou AMOA (Assistance à MOA, plutôt exécutante). On peut avoir des entités internes spécialisées (un bureau des projets, par exemple, dans son rôle support) ou des consultants externes.
On parle aussi de MOED (MOE déléguée, avec fort niveau d’engagement) ou d’assistance à MOE (interventions ponctuelles ou exécutions). Ce sont des sous-traitants ou prestataires qui assurent ces fonctions.
La chaine de la « dé-valeur »
Je reviens maintenant sur mon projet de SI, que j’illustrais par le dialogue d’introduction.
Dans la première organisation mise en place, le CP MOA est placé comme « coordinateur » central du projet, avec une structure interne « MOAD » en support des opérations méthodologiques « projet ». Peu de rapport entre cette structure MOAD et la MOE sous-traitée.
Dans cette organisation, 2 comités de pilotage sont mis en place : Comité externe (CP MOA et client externe) et un comité de pilotage interne (CP MOA et CP MOAD). Avec évidemment les hiérarchies concernées. Le responsable et pilote de la réalisation est bien entendu le CP MOA, qui dans les faits cumule (en interne) les responsabilités de MOA et MOE, puisque la MOE est externe.
Evidemment, chaque sous-organisation produit ses tableaux de bord et a sa propre vision de l’avancement et de la santé du projet.
Suite à la soufflante du DSI, une nouvelle organisation est peu à peu mise en place.
Dans cette organisation, la MOA reste dans un rôle purement « défense des intérêts de son client » (commanditaire et utilisateurs). La structure interne de support aux projets reprend un rôle de MOE et devient responsable de la réalisation devant la MOA. Les comités mis en place deviennent le Comité de pilotage de « l’ouvrage » (CP MOA avec les utilisateurs) et le comité de pilotage de « l’œuvre » (CP MOE avec le prestataire et le CP MOA).
Quel bazar !
Dans cette nouvelle disposition à trois chefs de projets et deux comités de pilotage, une couche théorique s’est ajoutée et l’utilisateur s’est encore éloigné du producteur.
Comment faire pour limiter les incompréhensions entre ces représentants ?
Comment assurer une bonne adéquation entre le besoin et le livrable ?
Est-il vraiment nécessaire d’avoir autant de chefs de projets… au même niveau, sur le même projet ?
Ne peut-on pas avoir un unique comité de pilotage ?
Rationalisons !
Tout d’abord les chefs de projets.
Le CP MOA n’est pas le chef de projet. Il porte le besoin et garantit la satisfaction du client. Il recueille, exprime, recadre, arbitre, informe. Il est MOA. On peut l’appeler CP MOA. Mais si un chef de projet MOE est nommé à l’intérieur de l’organisation, ce sera bien lui le chef du projet. Avec une relation « client-fournisseur » interne.
Le CP MOE, est celui qui coordonne l’ensemble des activités sur le projet. Il garantit 2 axes principaux : la communication transverse et l’application de la méthodologie de management de projet. Il s’assure de la bonne information des parties prenantes en temps réel, diffuse les tableaux de bord, gère les risques et s’assure de la résolution correcte de tout problème.
La MOE déléguée pour réaliser l’ouvrage met en place une équipe projet de producteurs et d’experts. Chef de projet MOE délégué ? Oui, bien sûr, mais dans son entité propre.
Nos deux comités de pilotage ?
Plus vraiment. Il reste UN comité de pilotage animé par le CP MOE. De part et d’autres (côté client et côté prestataire) restent des réunions de suivi, de surveillance, d’avancement. Mais il ne s’agit plus de pilotage.
Les livrables méthodologiques ?
Entre les deux organisations, les tableaux de bords (TDB) ont été recentrés sur le chef de projet (CP MOE) et le cahier des charges fonctionnel lui a échu. Si ce n’est pas le cas, il risque de rester une « boîte aux lettres », un organisateur, un gestionnaire de projet. L’appropriation de la maîtrise fonctionnelle est l’espace critique de sa crédibilité.
Conclusion ?
En phase d’avant projet (type SI), lorsque la solution n’est pas encore définie, la MOA définit un pilote de cette phase. Un « chef de projet » en charge de cadrer le projet, identifier les risques majeurs, construire un business plan, recueillir la structure des besoins, évaluer pertinence et faisabilité.
Il peut être le chef de projet MOE responsable de la réalisation, en dialogue avec le commanditaire. Mais, il peut aussi n’être que « l’avocat » de la MOA.
Dans ce cas, il sera important lors de la phase de planification du projet et au plus tard au démarrage de l’exécution, d’avoir défini clairement les rôles et responsabilités de la chaine de transformation du besoin en charges fonctionnelles, en solution technique puis en solution opérationnelle.
Et quelle que soit l’organisation choisie, le chef de projet, unique, devra :
1° garantir la plus grande fluidité de la communication entre acteurs « éloignés », en créant autant de points de rencontres que nécessaires,
2° maîtriser l’application des meilleures pratiques méthodologiques tout au long du projet.
partagez ce billet avec vos amis, collègues et relations professionnelles
Un ami m’a invité à lire cet article centré sur la nécessité de connaissances ou au moins de compréhension des finances de base pour tout informaticien. Je pense qu’il s’applique également à la profession de chef de projet. Même si nous ne sommes pas tous très versés ou fanas des aspects financiers, ceux-ci sont souvent au cœur du sujet pour déterminer la poursuite ou l’arrêt d’un projet, sa réussite ou son échec final. Un cours « finances pour non financiers » est d’ailleurs en général très apprécié comme j’ai pu le constater dans plusieurs entreprises.
Vous pouvez avoir les meilleures équipes et respecter tous vos jalons, mais en fin de compte, les projets vivent ou meurent par leurs données financières.
Avec un budget informatique moyen s’établissant à 2-8 % de revenu et 30-50 % de capital investi, on penserait logiquement que, en moyenne, l’informaticien a, sinon une connaissance robuste des données financières de l’informatique, au moins une compréhension raisonnable de l’essentiel, pour qu’il puisse voir comment ses activités quotidiennes contribuent à ces chiffres.
Eh bien, réfléchissez-y à nouveau. Seul le sommet de la direction informatique comprend vraiment ce que les chiffres représentent – ou plus précisément, supposent représenter parce que, comme nous verrons plus loin sur, il y a une marge significative d’erreur. Le reste, qui signifie la grande majorité du service informatique, a peu d’idée comment leur travail quotidien impacte les résultats financiers de la société. Ils ne s’en soucient probablement pas particulièrement, pas parce qu’ils ne sont pas des professionnels, mais parce qu’ils ne le considèrent pas comme une partie de leurs responsabilités. Ils sont là pour faire l’analyse, le développement, le support ou autres ; les finances sont le travail de leurs managers – ou pour les comptables du département financier.
Et pourtant, c’est le travail quotidien de ces personnes, construit sur des corrélations complexes entre des équipes de spécialistes, qui font ces résultats. Comment des personnes qui estiment que les données financières informatiques ne font pas partie de leurs responsabilités peuvent-elles fournir les informations précises qui seront en bout de ligne converties en données financières de l’ordre de 2-8 % du revenu et 30-50 % des investissement de capitaux ?
La réponse, bien sûr, est qu’ ils ne le peuvent pas. Par exemple, un sondage de PSB Research en mai 2009 auprès de décideurs de l’informatique a constaté que presque les trois quarts d’entre eux estiment leur marge d’erreur de 5-20 % dans leurs coûts réels, tandis que seulement 12% auraient une marge d’erreur de moins de 5 %. Pour un $100m de budget informatique, cela signifie que les chiffres pourraient être erronés de 5 à 20m pour trois sur quatre de toutes les sociétés interrogées. Autrement dit, il pourrait être de $80m comme de $120m – ce qui n’est pas exactement de la menue monnaie.
Le sondage confirme simplement ce que la plupart d’entre nous soupçonnent de toute façon. Au cours de beaucoup de mes années dans l’industrie, dans des services informatiques et aux ventes de logiciels, j’ai régulièrement entendu dire que les gens – incluant des cadres supérieurs – admettent ouvertement qu’ils ne savent pas la différence entre dépenses d’investissement et opérationnelles (opex) ! Ou bien, ce qu’est la dépréciation et comment elle s’applique aux systèmes d’information. Ou encore la différence entre un compte de résultats et un bilan. Ou comment les provisions augmentent l’exactitude du rapport mensuel. Ou la différence entre un budget et un prévisionnel. Pour voir comment vous vous en sortez sur l’essentiel des données financières, prenez ce rapide test 1-minute survey et voyez les résultats. Vous pouvez aussi passer à travers le IT Financials Glossary et tester votre compréhension de l’essentiel [de la terminologie financière anglo-saxonne].
Ce ne serait pas si terrible si les contrôleurs financiers jouaient leur rôle de gardien et de protecteur et étaient capables de capturer de telles erreurs. Malheureusement, ce n’est pas toujours le cas. Beaucoup de sociétés souffrent du dilemme classique d’informaticiens ne connaissant pas assez la finance et de financiers ne connaissant pas assez l’informatique. Donc, l’informatique donne des chiffres à la finance, qui doit souvent les prendre pour argent comptant. C’est aussi vrai pour les budgets que pour les données réelles. Ces mêmes chiffres sont alors parfois refacturés en interne au business, qui pourrait avoir peu d’idée de ce qu’ils payent puisqu’ils doivent à leur tour les prendre à leur valeur nominale.
OK, et alors ? Qui s’en soucie ? L’informatique est de la technologie et de la livraison et direction de systèmes pour le business, n’est-ce pas ? Depuis quand les finances font-elles partie de la description de poste ? Eh bien, elles pourraient ne pas faire partie de la description de poste, mais les chiffres pilotent tout. Vous pouvez assembler les meilleures équipes de projet, atteindre tous vos jalons et produire tous vos livrables, mais en bout de course, vos projets et leurs applications informatiques résultantes vivent ou meurent selon leurs résultats financiers. Et ceci est vrai de la planification d’investissement et prévisions budgétaires à la gestion des coûts et leur imputation :
Planification d’investissement : de pauvres pratiques financières peuvent aboutir aux choix de mauvais projets d’une perspective justification business (« business case ») (lisez : le projet va probablement échouer malgré les meilleurs efforts de chacun)
Prévisions budgétaires : des budgets de projet peu réalistes, par définition basés sur des suppositions et des estimations, deviennent souvent gravés dans le marbre, au lieu de se développer naturellement par prévision mensuelle. Pour la plupart des projets, c’est souvent le budget et pas les dépenses, qui sont erronés.
Management des coûts : une attention insuffisante aux données financières aboutit à une énorme quantité de suivi et de rapports frustrants et sans valeur-ajoutée, laissant les projets et applications informatiques exposées à des réductions de coûts par défaut.
Imputation : les clients business ont souvent peu d’idée de ce qu’ils payent puisque le projet informatique et les responsables d’applications sont d’habitude incapables de comprendre leur difficultés financières, aboutissant à un focus sur les coûts plutôt que sur la valeur.
Pour conclure, tout le personnel informatique – et pas seulement la direction – doit augmenter sa compréhension financière générale, parce qu’en fin de compte ce sont les actions de chacun qui contribuent à l’exactitude, la ponctualité et la crédibilité des chiffres totaux.
Cela exigera la mise en œuvre de processus financiers de base pour les prévisions budgétaires et le management des coûts dans une structure de management de projet qui va au-delà de la seule livraison du projet. Au moment où la balle est passée aux équipes de support, la référence de base financière est d’habitude à peu près établie et peut seulement augmenter après cela.
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
In the literature on project management, the role of project sponsors seems to appear in the 70s. It is at this time that project management spread to all the industries and activities instead of being limited to big construction projects, military and the aeronautics. Certain companies then started to reorganize by project and it rapidly appeared that there were not enough business leaders to lead directly all projects. These leaders had to rely on more operational project managers while keeping a business sponsor’s role and remain the ultimate person responsible for the project.
Being a project manager as many readers of this blog, becoming the sponsor of a project is like crossing the mirror. The PM whom I am has very strong expectations (but nevertheless realistic) of his(her) sponsors. If I became a sponsor, which would or should be my first concerns?
Certainly first of all to define precisely my role and expectations of the PM, in the same way as he or she will have expectations of what I should bring to the project. It is thus necessary to establish mutualtrust between us based on clearly established roles and responsibilities, regular communications, and common rules. Let us establish these jointly during a first working session.
Business Champion, legitimacy.
To perform successfully his role, the sponsor must be listened to and recognized by his peers in the business and by his management. It is therefore critical that I get in touch with all stakeholders of the project. I need to understand clearly their expectations of the project, their necessary level of involvement, and to listen to their points of view. It will be in particular useful at this time to obtain an access to their expert resources of the domain. And, also these discussions shall enable me to appreciate the problems to be addressed from the insiders’ view.
Direction and support in decision-making
Here is one of my sponsor’s key roles. It is a matter of giving a direction and management support to the project manager. It is thus imperative that I have an excellent and very clear overall view of the objectives of the project and that I am able to articulate and to communicate these simply and effectively. And this for all the stakeholders: the project manager and his team of course, but also the management of my company, including or maybe even in particular towards those who seem less impacted by the project but have a large influence in the company (not always high-ranking individuals).
Review and approval of plans and deliverables
Beyond the adequacy of the deliverables and project plans to the concrete objectives of the project, my sponsor’s role is to improve these project’s deliverables and to approve them formally. The best sponsors that I had as PM, had the capacity to see farther than the deliverables in themselves. They perceived early how these products would be welcomed according to the expectations of the many stakeholders. They anticipated the potential negative reactions to prevent these, often by modifications which may seem to be cosmetic but which made a huge difference. They were always one or two steps forward in their reflection with regard to my inevitably more operational focus.
Guaranty the availability of the assigned resources in due time (Including my own)
I shall be demanding and even inflexible on the provision in due time of the resources promised to the project team to succeed. How could I be strict on any drift of the project if the authorized means are not provided? The most difficult one will be probably my own availability to the project manager. It must be easy to obtain, immediate, and especially with a 100 % of my attention dedicated to the project on these occasions.
Remove the obstacles
In addition to supplying the necessary resources, I have the duty to unlock complex situations or crisis that the PM despite of all his/her efforts (because it is first of all his/her role to do so) would not know how to address. It does mean removing the responsibility from the PM’s shoulders but rather supplying the required support when necessary.
Establish and decide on the priorities
What should we do? Delay the project production date by a few days or to exceed the budget? The PM will supply me the arguments in favor and against these two alternatives, and possibly his/her recommendation. The decision will be on me and I shall have to take into account all of the following: the objectives and the imperatives of the business, the operational and commercial impacts, the stakeholders… This type of decision cannot be put off and, very often, no decision is worse than making an error which we will correct later.
Examine regularly the progress
A combination of formal and informal sessions seems to me an efficient approach. Formal project committees and the other gates or milestones reviews are necessary but often insufficient. Indeed, reading a report or listening to a well prepared presentation speech will not allow me to understand what’s really happening. It is necessary to read between lines, to hear the unsaid, the intangible, to appreciate the difficulties of the PM and to have a real human relationship. In my past projects, brief (30 minutes) and regular (weekly) sessions appeared to me to be the most effective.
Promote frank and open communications (put down the masks!)
To get the vital info, including the bad news that are difficult to hear, I need on my side to be frank and open with the PM. To communicate without taboo or hidden agenda is a must do. Except information that could place the company at risk such as the legal issues (some financial information for example, or reorganizations and mergers/acquisitions), everything can be explained with a little bit of intelligence and trust.
Provide standards of performance
To be opened and approachable does not mean being permissive. My best sponsors were inflexible with me and my team. I had very clearly their support and knew perfectly what they expected from me. We had high standards of quality and performance and these were mutually shared.
Develop an organization which learns from its mistakes and successes
Finally, as the sponsor of an important project of the company and thus member of its senior management, I owe to develop the skills and the know-how of the resources which are under my leadership and to make sure that The lessons learned will benefit future projects.
partagez ce billet avec vos amis, collègues et relations professionnelles
J’ai lu un article de Ty Kiisel qui m’a fait penser aux quelques points à garder à l’esprit lorsque l’on a opportunité de présenter son projet à un ou plusieurs dirigeants.
Comme Ty, j’ai pu apprécié que l’un des points communs des dirigeants est qu’ils ont très peu de temps. Aussi, leur temps d’attention pour notre projet est très limité et il vaut mieux ne pas gâcher l’opportunité de s’adresser directement à eux si elle se présente. Cela dit, le temps de tout un chacun est précieux. Le temps est une denrée qui nous est donnée en quantité limitée à notre naissance. Donc, soyons concis, adaptons notre propos à notre interlocuteur, attisons son intérêt, soyons précis…
Les 10 points proposés par Ty méritent d’être lus. J’en retiendrais 3 qui sont réellement primordiaux selon mon expérience et j’en ajouterais un que je n’ai pas trouvé dans la liste:
1. Vue d’ensemble (mon addition personnelle): Rappelons le contexte dans lequel s’insère notre projet. N’assumons pas qu’ils se souviennent de qui nous sommes ou l’objet de notre projet. Ils ont beaucoup de choses à gérer en parallèle. Démarrons par la manière dont notre projet supporte un ou plusieurs de leurs objectifs stratégiques avant d’entrer dans les détails. Poursuivons ensuite par un résumé du contenu, coûts, délais, et jalons majeurs du projet. Expliquons où nous en sommes par rapport à ceux-ci.
2. Faisons simple: Soyons directs. Exposons les faits et pourquoi leur implication est nécessaire. Ne les inondons pas d’informations, soyons concis, n’utilisons pas de jargon. Procéder autrement serait un gaspillage de temps et ils penseraient que nous sommes incapables de faire une synthèse efficace et de nous exprimer clairement.
3. Proposons des solutions: Offrons une ou deux options (mais pas plus). Comme Ty l’indique dans son article, il ne nous servirait à rien de présenter des problèmes sans proposition de solution. Ils savent décider entre deux solutions mais c’est notre responsabilité de présenter des options cohérentes et documentées qui mettent en évidence avantages, inconvénients, coûts et impacts sur le projet.
4. Soyons spécifiques sur ce que nous attendons d’eux: Un mémo ou un coup de fil pour débloquer une situation, plus d’argent, de temps, de ressources, un arbitrage, une décision sur les priorités…
partagez ce billet avec vos amis, collègues et relations professionnelles
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 :
Obtenir des recommandations de valeur pour améliorer le projet
É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.
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
Does this title sound odd to you? Are you like many PMs trying to escape audits as much as possible? Do you consider them as a waste of time at best and a potential killer in extreme cases?
I did also share these feelings but it does not need to be this way. Audits are very worthwhile, and can be productive and of real benefit to you and your project.
I suggest starting from the inception: who has requested the audit? why? who are the auditors? what is the scope?
I found with experience that finding the answer to the latter of these questions, i.e. scope of the audit, will often shed light on the others. Indeed, once shared and understood, the scope will highlight several areas of investigations and review. It could be the project management practice, the costs, the quality of deliverables, the security, the progress against schedule, the details of the project plan or any combination of these and more.
With a little bit of thinking and discussions with the auditors, it should become clear why this audit and who has requested it. Also, the type of auditors you get, internal versus external, large consulting firms versus specialized players, will tell a lot about the importance granted to the audit and its aim.
For example, we were audited during an Enterprise Resource Planning (ERP) system construction and deployment. It was an internal audit. Once we understood that the focus was essentially to ensure that we were in control of project spend and managing the risks correctly, it was easy for the team to provide clear evidence of what we were doing in these areas. We showed our expenses tracking process, time tracking method, issues log and risk register. The Chief Finance Officer was reassured by the findings. Additionally, the auditors helped us to further highlight our top risks to the steering committee during a specific risk management brainstorming and review session with them.
Next suggestion is to learn about the process that the auditors plan to follow. It’s important to understand their approach to better prepare the team for this event that they may initially perceive negatively. Usually, it starts with a few interviews of key project team members and stakeholders, eventually preceded by some documentation request and analysis. The next step often involves further interviews to deep dive into specific areas.
An experience I had about the importance of the above was on a IT project where we were in deep trouble during deployment. As a young PM, I did not have the experience or clout to « manage » the auditor (an external one in this instance). He came in and ran his show without explaining the process to anybody. He made negative comments quite early on. The team became very concerned and somewhat defensive. People provided all materials requested but in a rather unstructured way. There was no overall framework/story around the raw data. The audit took long and was very frustrating for all. In the end, the report did not help the project through its difficult times. In this specific instance, an audit, that could have brought value, ended up killing the project and I still have bad feelings about this useful but painful experience.
You should also consider that the auditors will most certainly have some checkpoints with management and audit sponsors. They will share their progress at these sessions, expose findings, test the water on initial ideas (to see potential reactions), and at a later stage present recommendations (draft and final).
Last year, I was the lead for the audit of an internal application. As I had been several times on the receiving end of audits, I placed specific focus in this instance on explaining the milestones and approach for the audit. We explained the scope and who would do what. We shared the findings with the team as they became available to avoid surprises. We gave them the opportunity to comment (which they did and we took their input into account). We shared our recommendations with the project team before management and also helped define and put in place action plans to address the identified issues. We even followed up after the audit on execution of these action plans. This, I am sure, was much more beneficial to the company than a one-off report.
Whatever the scenario, the key for the PM is to actively support the auditors throughout their investigations. We shall provide all relevant information in full transparency and ask our team members to do the same. We shall also make time for them in our busy agendas. We want to be valuable and positive contributors. As we do so, we may gain the privilege to be involved in the preparation of the documents and sessions for management. It could be limited to validate the correctness of facts but that is already very worthwhile. It could be to understand what they will highlight up to discussing some of their draft recommendations.
In my PM role, when asked by the auditors about my expectations of the audit, I highlight 2 items:
Get valuable recommendations to improve the project
Fairness towards team members.
Next stage is when the audit reaches completion and produces its recommendations. Unavoidably, there will be some you agree with or can understand. There will be others that are tougher to accept. In any case, it is absolutely critical to remain positive and open. Moving into defensive mode will never help. Also, keep in mind that consultants/auditors recommendations are one thing; which of these recommendations management will decide to act upon is something else (that is more critical to you and your project) .
As soon as you understand which corrective or improvement actions are retained, share these with the team in a positive manner. In my experience, it is often the case that the auditors report is not shared; only highlights of the reports are presented that foster the team towards productive actions.
As a conclusion, I suggest that if your project is not yet being audited, you consider which areas could be improved using external advice and eventually solicit an audit on these: Get help before someone above you decides that you need to be helped.
On many projects, you will find that auditors will greatly help you to firm up some aspects such as scope control, change management rigor or raising the involvement of your project sponsors in risk mitigation. They look at your project with an external and therefore more objective than you ever can be.
partagez ce billet avec vos amis, collègues et relations professionnelles
Certaines des leçons que j’ai appliquées, je les ai apprises au prix d’un certain nombre de cicatrices, et de l’observation d’autres de chefs de projet que j’ai rencontrés ou avec lesquels je suis en relation. Il n’y a aucune formule magique ni nec plus ultra; Seulement quelques leçons relativement simples qui démentent la difficulté avec laquelle elles sont mises en œuvre.
Quand j’ai commencé comme un chef de projet, personne ne m’a parlé de gouvernance. Personne ne savait même ce que cela signifiait. Nous avions une méthodologie et un processus et nous pouvions de temps en temps avoir un audit – mais rien de tel que ce que nous avons vu sur les cinq dernières années. Les scandales d’entreprise du début des années 2000, avec la transparence plus grande qu’attendent les régulateurs, actionnaires, clients et même les employés, ont aujourd’hui fait de la gouvernance une partie nécessaire de toutes les initiatives majeures.
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 ? 
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.
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).
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.
Does this title sound odd to you? Are you like many PMs trying to escape audits as much as possible? Do you consider them as a waste of time at best and a potential killer in extreme cases?
For example, we were audited during an Enterprise Resource Planning (ERP) system construction and deployment. It was an internal audit. Once we understood that the focus was essentially to ensure that we were in control of project spend and managing the risks correctly, it was easy for the team to provide clear evidence of what we were doing in these areas. We showed our expenses tracking process, time tracking method, issues log and risk register. The Chief Finance Officer was reassured by the findings. Additionally, the auditors helped us to further highlight our top risks to the steering committee during a specific risk management brainstorming and review session with them.
You should also consider that the auditors will most certainly have some checkpoints with management and audit sponsors. They will share their progress at these sessions, expose findings, test the water on initial ideas (to see potential reactions), and at a later stage present recommendations (draft and final).
We shared our recommendations with the project team before management and also helped define and put in place action plans to address the identified issues. We even followed up after the audit on execution of these action plans. This, I am sure, was much more beneficial to the company than a one-off report.
As a conclusion, I suggest that if your project is not yet being audited, you consider which areas could be improved using external advice and eventually solicit an audit on these: Get help before someone above you decides that you need to be helped.
DantotsuPM.com 