articles, méthodes, partages d'expérience et rdv du management de projets et de l'agilité
The PMI collection of case studies highlights how organisations are implementing project management practices and using PMI products, programmes or services to fulfill business initiatives and overcome challenges.
A wealth of knowledge and experience sharing from the best PMs.
PMI’s 2014 Pulse of the Profession®, le rapport annuel du PMI examine chaque année l’impact du management de projets, programmes et portefeuilles de projets.
Cette édition 2014 met en exergue le fait que pour rester compétitives, les organisations doivent placer un focus stratégique tout autant sur les personnes que sur les processus.
Lisez notamment les pages 12 et 13 dédiées au rôle prépondérant des sponsors « actifs » de projets et au processus de gestion des modifications.
Si vous quittez votre rôle pour passer à autre chose, ou juste simplement partir quelques semaines en vacances, il y a quelques petites choses que vous devriez faire pour vous assurer qu’un transfert en douceur et efficace ait lieu. Plus vous mettez d’efforts à guider votre collègue sur la façon dont les choses sont faites, plus de chance aura votre projet de s’épanouir entre leurs mains. Voici quatre choses que chaque chef de projet devrait faire dans le cadre du processus de transfert pour assurer une transition en douceur.
J’ai souvent entendu dire que le médecin chinois est rémunéré pour garder ses clients en bonne santé plutôt que les soigner lorsqu’ils sont malades. Cette bonne approche devrait-elle s’appliquer au chef de projet qui suivrait les signes vitaux de son projet afin de les adresser avant que le projet ne soit sérieusement malade.
L’un des rôles du chef de projet est d’éliminer le plus rapidement possible tout obstacle qui empêcherait l’équipe de progresser. Nous sommes donc souvent en mode « résolution de problème », essayant de répondre aux questions qui surgissent, d’éviter et/ou atténuer les risques. Il est utile de nous poser la question de savoir si ce que nous essayons de résoudre est réellement le problème ou seulement un symptôme du problème.
Ce livre s’adresse à la fois aux dirigeants d’entreprise, aux managers de projets et aux candidats à la certification projet. Il pourra être une aide utile aux étudiants recherchant des exemples concrets, mais aussi à toute personne menant des projets professionnels ou personnels sans avoir le titre de manager de projet.
De toutes les compétences j’ai apprises dans les dernières 7 années passées à changer ma vie, une compétence se détache : Apprendre à être confortable avec l’inconfort.
Si vous avez jamais fait partie d’une équipe hautement effective, pour un projet ou au fil du temps, vous savez qu’il existe des composants importants pour augmenter le potentiel de l’équipe.
L’idée des suivis de temps est plus douloureuse que sa réalité. La résistance initiale au suivi du temps est normale : changer des habitudes nécessite un peu de temps pour s’y habituer. Mais en réalité, pouvez-vous et votre équipe (et l’organisation) ne pas savoir où passe votre plus précieuse ressource : votre temps, et comment il impacte le projet ?
Si vous recevez un retour sur investissement convenable de vos pratiques actuelles de gestion de vos listes de tâches à faire, vous obtiendrez d’énormes retours – en matière de productivité, de relations améliorées et dans votre bien-être personnel – en ajoutant ces items votre Liste des tâches à ne pas faire…
Revoyons dans ce billet 3 des outils les plus testés et essayés que les chefs de projet peuvent utiliser et qui vont réellement faire la différence entre un projet réussi ou pas tout à fait.
«C’est une observation banale que le travail s’étend afin de remplir le temps disponible pour son achèvement ».
Voici comment réellement se préparer pour une présentation en public
4 manières de vous assurer que votre tout nouveau PMO ne soit pas un vilain bébéVOUS avez été choisis pour diriger le PMO. La mauvaise nouvelle est que vous n’avez jamais fait rien de tel auparavant! Par où même commencer ?
Dans les sociétés qui ont un PMO, il pourrait y avoir quelques occasions d’interagir entre chefs de projets, mais cela peut devenir plus solitaire dans des organisations fonctionnelles où les chefs de projet sont dispersés à travers de nombreux services ou encore pire où il peut seulement y avoir un ou deux chefs de projet dans toute la société.
Deux des plus grandes questions que me posent les gens sont : quels sont exactement les rapports de management de projet et lesquels sont les meilleurs à observer ?
Les chefs de projet ont assez souvent des documents à préparer et à valider avant diffusion. Voici un processus très simple qui permet de structurer son approche.
1. “Find Your Job” which offers tips on how to land a job that will take you where you want to go. Once you’re working,
2. “Find Your Project” which offers advice on how to get involved in your first actual project, whether it’s official or not.
3. “Find Your Skills” provides great information on how to become a better project manager once you’re at it.
4. “Find Yourself” offers suggestions on how to become the leader you know you were meant to be.
Nous sommes donc souvent en mode « résolution de problème », essayant de répondre aux questions qui surgissent, d’éviter et/ou atténuer les risques. Il est utile de nous poser la question de savoir si ce que nous essayons de résoudre est réellement le problème ou seulement un symptôme du problème. Notre réponse ou réparation rapide s’attaque-t-elle à la cause première/racine du problème ? Est-ce une étape dans la bonne direction pour réparer le problème de fond ? Si oui, ok pour cette réparation rapide. Mais cela n’est pas toujours le cas …
Cet article est inspiré d’une session de formation que j’avais organisée et suivie pour le bureau de l’association PMI France-Sud. Jerry Brightman, un expert renommé du leadership et Président de la société The Leadership Group, fut l’animateur de cette session.
Prenons un exemple pour illustrer le sujet : un membre de l’équipe entre dans votre bureau pour annoncer un possible retard sur l’un de ses futurs livrables. Je propose que nous suivions ce cas pas à pas pour mieux comprendre ce qui pourrait arriver.
1. Nous voyons un problème, ou pour être plus exacts le symptôme d’un problème.C’est-à-dire selon la définition du mot symptôme : « un signe, une indication, une manifestation; quelque chose de causé par et indicatif d’une certaine maladie ou désordre. » Dans notre exemple, le symptôme est le signal de l’un des membres de l’équipe qu’il ne livrera probablement pas sa partie dans les temps.
Ce livrable est sur notre chemin critique, nous proposons de fournir un peu d’aide supplémentaire à la personne pour l’achever dans les délais prévus.
Supposons que cela fonctionne et répare en effet le symptôme. Dans notre exemple, la tâche à réaliser est de nouveau dans les temps.
a) Attaqué la cause première/racine du problème et
b) Évalué les effets secondaires potentiels de la réparation rapide ?
Par exemple, l’aide supplémentaire sur une tâche provoque un retard sur une autre tâche dont nous avons utilisé des ressources, ou elle produit des requêtes d’autres membres pour obtenir davantage de ressources, ou elle démotive les membres de l’équipe qui fournissaient des efforts supplémentaires importants pour rester dans les temps sur leurs propres parties du projet, ou …
Mauvais moral dans l’équipe, menaces de retards sur d’autres parties du projet, absentéisme …
La boucle est engagée. Cette réparation rapide initiale peut avoir placé tout le projet à risque.
La proposition est de s’efforcer par tous les moyens d’éviter d’entrer dans cette spirale.
Dans l’étape 1, quand nous observons le symptôme (la menace du retard d’un livrable qui se trouve sur le chemin critique), nous prenons un peu de recul pour comprendre pourquoi le symptôme est là et quelle en est la cause. Nous nous posons ainsi qu’à l’équipe certaines questions telles que:
Nous voyons que les réponses aux susdites questions peuvent nous amener dans un 2ème étape à une réparation rapide peut-être totalement différente et qui devrait être plus adaptée pour adresser la cause première/racine et éviter ou anticiper certains des effets secondaires.
Comme Seth Godkin l’avait mis en évidence dans un article : Raser les ours polaires ne résoudra pas le réchauffement climatique.
Ou encore, comme mon enseignant en premiers secours le répétait à ses étudiants : « Ne mettez pas de pansement sur une blessure qui n’est pas désinfectée. »
Therefore, we’re quite often in problem solving mode, trying to resolve issues that arise, avoiding and mitigating risks. A useful thing to keep in mind is to always consider whether we are really addressing the issue or only a symptom of the issue. Is our quick fix action aimed at the root cause of the issue or is it a step in the right direction as we fix the symptom? If yes, that’s ok and we shall apply the quick fix. But it’s not always the case…
This post is inspired by a training session I organized and attended for the management board of the PMI France-Sud non-profit organization a couple of years ago. Jerry Brightman, a renowned leadership expert and President of a company called The Leadership Group, was kind enough to facilitate this session.
Let’s take an example to illustrate the topic: a team member comes into your office to announce a probable delay on one of his deliverables. I propose that we walk through this case to better understand what could be happening.
1. We see a problem, or to be more precise the symptom of a problem.I.e. by definition of a symptom: « a sign, indication, manifestation; something caused by and indicative of a certain disease or disorder. » In this example, a team member signals that he may not be delivering his part of the project on time.
This deliverable is on our critical path, we propose to provide some additional assistance to the person to get the task completed on time.
Let’s assume that indeed this fixes the symptom. In our example, the task is back on track.
a) addressed the root cause of the problem and
b) assessed the potential side effects of the quick fix we applied?
For example, the additional help provided provokes a delay on another task from which we pulled some resources, or it generates requests from many others to get more resources, or it demotivates team members who were going the extra-mile to be on time, or…
Bad morale in the team, threats of delays in other parts of the project, absenteeism…
The loop goes on. The initial quick fix may have placed the entire project at risk.
The proposal is to try by all means to avoid entering into this spiral.
In step 1, when we see the symptom (the threat of a late deliverable that is on the critical path), we take a step back to understand why the symptom is there and what caused it. We will want to ask a few questions such as:
We see that the answers to the above questions may drive us in step 2 to a completely different quick fix that should be better suited to address the primary/root cause and avoid or anticipate some of the side effects.
As Seth Godkin highlighted it in of his posts: Bear shaving will not resolve global warning.
Or what my first aid teacher repeated to his students: « Do not put a Band-Aid on a non disinfected wound. »
Are you trying like many project managers to avoid audits like the plague?
Do you consider that an audit is at best a waste of time and at worse a weapon in the hands of psychopaths in search of victims, in this particular instance, you and your project?
Embed from Getty ImagesI shared some of these « a priori » but it is not a fate. Audits are both useful and necessary. They can be very productive, generate benefits and create real advantages for your project as well as yourself.
I discovered by experience that answering the latest, i.e. the precise scope of the audit, often allowed me to find the answers to the previous questions. Indeed, when the object of the audit is shared and understood, it often sheds light on several target domains of investigation and detailed review.
The audit can focus on the project management practices, the control of the expenditures, the quality of the deliverables, security aspects, progress tracking and management, project plan details or varied combinations of these and other topics not listed here. A little bit of thinking and discussion with the auditors should make the deep reasons surface and help to identify the requester.
Additionally, the type of auditors you get, internal or external, generalists or specialized consulting firms, expert auditors of the PM processes or technicians, tells a lot about the purpose and the importance granted to the audit.
Embed from Getty ImagesFor example, during a project for the integration and deployment of Enterprise Resource Planning software (ERP), we were internally audited. Once established that the focus was essentially to make sure that we controlled adequately the expenditures and were efficient at managing the risks, it was easy for the team to supply the evidences of what we were doing in these domains. We showed our processes to control the costs, our methods to follow-up on personnel assignments, the log of open questions and our risks register. The chief financial officer, who had asked for the audit, was reassured by the conclusions and few recommendations of the auditors on which of course we took prompt actions.
Besides, the auditors helped us to go farther in our management of the risks by facilitating the set-up of a brainstorming session on risks with the entire executive committee of the project (which we had requested without success in the past).
It is indeed important to understand their approach to better prepare the team for this event which they are likely to perceive as invasive, stressful and negative.
Generally, the first steps in any audit consists in conversations with keys members of the team as well as the executive committee of project. This can be preceded and/or followed by demands for diverse project documents for analysis. The following phase is composed of additional sessions and analysis to dive more deeply into specific domains and details, in particular looking at « how » processes or tasks are conducted.
A counter example of a not so useful audit taken from my personal experience took place on an IT project where we had met tough problems during software deployment. As a junior project manager, I had neither the experience nor the charisma to « manage » the auditor (an external one in this instance). He arrived and ran his show with no explanations of his purpose and the process he wanted to follow (if he had one) to anyone. Furthermore, from the beginning, he sent numerous negative messages about the project’s results. The team, disorientated by this lack of an understandable structure and no visibility on what was happening, quickly became worried and a little bit defensive. The team members supplied all project documents requested, but in an unstructured way, without any articulation of the many components. The storyboard was missing to position these raw materials in their context.
The audit took a lot of time and was very stressful for all. In the end, the audit did not succeed to help the project get over this difficult period. In that specific instance, an audit, which could bring value, only managed to kill a project which certainly had some weaknesses but these could have been corrected. I still (15 years later) keep a very bitter taste of this certainly useful experience but by far too painful for the team and the company.
You should take into account the fact as the auditors will certainly provide interim reports at regular checkpoints with the management and the requesters. During these sessions, they will share the progress, to expose their discoveries and « astonishments ». Often, this is useful for them to validate/test the waters on their initial ideas (to observe the potential sponsors’ reactions) and, later, they will present their recommendations (intermediate and final).
A few years ago, I was asked to lead the internal audit for the deployment of a set of IT applications. Since I had been several times on the other side of the audit, I tried to pay specific attention to explain the objectives, the milestones and the approach of the audit (the first and second hints mentioned in this article). We discussed with the project sponsor and the project manager the proposed perimeter and who would do what. We shared our observations as we went along with the team to avoid bad surprises (the third suggestion above). We gave them the opportunity to comment on our observations: which they did and we considered these (not necessarily accepted them). We shared our recommendations with the project team before doing it with the management which they greatly appreciated. We also helped to define and set up action plans to address the identified points of weakness. We have also, after the audit, provided a follow-up on the execution of these action plans. I am sure that it was much more beneficial to the company than a simple audit report.
Regardless of the scenario, the key point for the project manager is to support actively the auditors during their investigations. Supply them with all the required information in total transparency and ask members of our project team to do the same. Make time for them in your overloaded agenda. Be open, positive and value-add partners. This way, you can hope to gain the privilege to be involved in the preparation of documents and reporting sessions towards management. It can be limited to validating the correctness of the facts and details and this alone is already very useful. It could be to understand what they are going to shed a light on and also discuss some of their intermediate recommendations to start to prepare action plans.
In my PM role, if the auditors ask me for my expectations of the audit, I make 2 major points:
a) Fairness towards the members of the team.
b) Quality of the recommendations to improve the project
The following stage is the completion of the audit and the production of the recommendations. Inevitably, there are some items you will agree with and can easily understand. Others will be more difficult to accept.
In any case, it is absolutely critical to remain positive and open. Switching to defensive mode would not help at all. Furthermore, keep in mind that the recommendations of the consultants and auditors are one thing, the selection of which recommendations on which to act upon is another matter (that is more important to you and your project). This selection/decision will be performed by the management or the project executive committee. As soon as you understand which corrective and improvement actions are retained, share these with the project team in a positive manner. It is quite often that the full report of the auditors will not be disclosed. Only the key (retained) points will be shared, those engaging the team on productive actions.
If your project is not yet the object of an audit, consider which domains could be improved by an external advice and seek an audit on these. Ask for help before somebody above you decides that you need to be helped. On many projects, you will see that the auditors will greatly help you improve some aspects like controlling the scope, increasing the rigor in change management or better engaging your sponsors and key stakeholders in risk management. The auditors look at your project with an external eye and are thus far more objective than you can ever be. Furthermore, they carry a legitimacy which can help you to communicate tough messages to your project executive committee, in particular when some things to be rectified are in their areas of responsibility. It could be a lack of involvement of some parts of the organization in the project or their own contribution and attitude to control of the scope and the risks.
Cette demande vous semble-t-elle relever du masochisme ?
Êtes-vous de ces très nombreux chefs de projet qui fuient les audits comme la peste noire ?
Considérez-vous qu’un audit est au mieux une perte de temps et au pire l’arme de psychopathes à la recherche de victimes, en l’occurrence, vous et votre projet ?
Embed from Getty ImagesJ’ai partagé, au moins en partie, ces « à priori » mais cela n’a rien d’une fatalité. Les audits sont utiles et nécessaires.
J’ai découvert par expérience que répondre à la dernière interrogation, c’est-à-dire la portée de l’audit, permet souvent de trouver les réponses aux questions précédentes. En effet, une fois que l’objet de l’audit est partagé et compris, il met souvent en évidence plusieurs domaines cibles d’investigation et de revue détaillée. Il peut s’agir des pratiques de management de projet, du contrôle des dépenses, de la qualité des livrables, des aspects sécurité, du suivi de l’état d’avancement, des détails du plan de projet ou de diverses combinaisons de ceux-ci plus d’autres non listés ci-dessus.
Avec un peu de réflexion et de discussion avec les auditeurs, vous devriez parvenir à faire remonter à la surface les raisons profondes et ainsi identifier le commanditaire.
D’autre part, le type d’auditeurs vous recevez, internes ou cabinets de conseil externes, généralistes ou auditeurs spécialisés, experts des processus ou techniciens en dit également long le but et l’importance accordée à l’audit.
Embed from Getty ImagesPar exemple, pendant un projet d’intégration et déploiement de progiciel de gestion intégrée (PGI), nous avons fait l’objet d’un audit interne. Une fois compris que le focus était essentiellement de s’assurer que nous contrôlions correctement les dépenses et les risques, il fut bien plus facile à 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, commanditaire de l’audit, a été rassuré par les conclusions et recommandations des auditeurs sur lesquelles nous avons bien sûr rapidement engagé des actions. De surcroît, les auditeurs nous ont aidés à aller plus loin dans notre management des risques en favorisant l’organisation d’une session de brainstorming sur les risques avec le comité exécutif du projet, ce que nous n’étions jusqu’alors pas parvenu à faire.
Il est en effet important de comprendre leur approche pour mieux préparer l’équipe à cet événement qu’ils vont initialement percevoir de manière stressante et négative. En général, la première étape des auditeurs consiste en une série d’entretiens avec des membres clefs de l’équipe et du comité exécutif de projet, précédés et/ou suivis de demandes de divers documents projet à fin d’analyse. L’étape suivante est composée d’analyse et de sessions additionnelles pour plonger plus profondément dans les questions et détails spécifiques, en particulier sur le « comment » sont réalisés certains processus et tâches.
Un contre-exemple basé sur mon expérience personnelle s’est déroulé sur un projet informatique où nous avions rencontré de graves problèmes durant le déploiement. En tant que chef de projet junior, je n’avais ni l’expérience ni le charisme pour « manager » l’auditeur (un externe dans ce cas). Il est arrivé et a fait un véritable show sans expliquer ni le pourquoi ni le comment (le processus qu’il allait suivre) à qui que ce soit. De plus, dès le départ, il a émis de nombreux commentaires négatifs sur le projet. L’équipe, désorientée par ce manque de repères et de visibilité sur ce qui déboulait, est rapidement devenue préoccupée et quelque peu défensive. Les personnes ont certes fourni tous les documents du projet, mais de façon peu structurée, sans articuler les composants entre eux. Il manquait une histoire d’ensemble pour positionner ces données brutes dans leur contexte. L’audit a nécessité beaucoup de temps et fut très stressant pour tous. Au bout du compte, le rapport n’a pas su aider le projet à traverser cette période difficile. Dans ce cas spécifique, un audit, qui aurait pu apporter de la valeur, n’a réussi qu’à tuer un projet qui avait certainement quelques faiblesses mais n’auraient-elles pu être corrigées ? Je garde un souvenir fort déplaisant de cette expérience qui me fut utile par la suite bien que trop douloureuse sur le moment.
Vous devez aussi prendre en compte le fait que les auditeurs feront certainement des points de suivi avec la direction et les commanditaires. Lors de ces sessions, ils vont partager l’état avancement, exposer leurs découvertes et « étonnements », tester leurs idées initiales (pour observer les réactions potentielles du management) et, plus tard, présenter des recommandations (intermédiaires puis finales).
Il y a quelques années, je fus nommé leader, en interne à ma société, pour l’audit d’un déploiement d’applications informatiques. Comme j’avais été plusieurs fois du côté de l’audité, j’ai essayé de porter une attention particulière à bien expliquer l’objectif, les jalons et l’approche de l’audit (première et deuxième suggestions de cet article). 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 (la troisième suggestion ci-dessus). Nous leur avons donné l’opportunité de commenter ces observations : ce qu’ils ont fait et que nous avons pris 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 de faiblesse identifiés.
Nous avons même ensuite (après l’audit) assuré un suivi de l’exécution de ces plans d’action. Ceci, je suis certain, fut beaucoup plus bénéfique à la société qu’un simple rapport d’audit.
Indépendamment du scénario, le point clé pour le chef de projet est de supporter activement les auditeurs pendant leurs investigations. Leur fournir toutes les informations appropriées en totale transparence et demander à nos membres de l’équipe projet de faire de même. Dégager du temps pour eux dans nos agendas surchargés. Être des partenaires ouverts, 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. Ceci peut être limité à valider l’exactitude des faits et détails rapportés et c’est déjà très utile. Ce peut aussi être de bien comprendre ce qu’ils vont mettre en évidence et même de discuter certaines de leurs recommandations intermédiaires afin d’élaborer de premiers plans d’action.
Dans mon rôle de PM, si les auditeurs me demandent mes attentes de l’audit, je mets en évidence 2 points majeurs :
a) Équité envers les membres de l’équipe.
b) Qualité des recommandations afin d’améliorer le projet
L’étape suivante est l’achèvement de l’audit et la production des recommandations. Inévitablement, il y en a certaines avec lesquelles vous êtes d’accord ou que vous pouvez aisément comprendre. Il y en a d’autres qui sont plus difficiles à accepter. Dans tous les cas, il est absolument vital 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 ou le comité exécutif de projet 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 intégral des auditeurs ne soit pas diffusé. Seuls les points principaux et retenus sont présentés. Ceux qui engagent l’équipe sur des actions productives.
Si votre projet ne fait pas encore l’objet d’un audit, considérez quels domaines pourraient être améliorés par un conseil externe et sollicitez 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é. 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. De plus, ils ont une légitimité qui peut vous aider à faire passer certains messages difficiles à votre comité exécutif de projet, en particulier si certaines choses à rectifier leur incombent. Par exemple un manque d’implication de certaines parties de l’organisation dans le projet, ou leur propre contribution dans le contrôle du périmètre et des risques.
http://www.easyprojects.net/blog/2014/01/31/project-accountability-101-dont-play-blame-game/
Il est très facile de commencer à montrer des choses du doigt quand les choses tournent mal. Le blâme pourrait être jeté sur vous et votre équipe pour bon nombre de raisons, certaines sans rapport, certaines injustifiées, certaines valables. Si non relevé, ceci pourrait significativement affecter votre réputation et réduire votre statut dans l’organisation.
Alors, comment les chefs de projet peuvent-ils contrôler une telle crise, particulièrement quand l’incident de déclenchement est quelque chose que l’équipe ne peut pas prévoir, comme un client qui change d’avis ou un membre de l’équipe qui tombe malade ?
La première chose que le management va faire pendant une crise est d’établir une chronologie. Ils demanderont à voir vos rapports pour toutes informations significatives. Ceci peut inclure le périmètre du projet, des listes de tâches, des communications documentées et des notes de réunion. Bien que ces documents puissent finir de confirmer votre culpabilité, ils peuvent aussi vous dédouaner de toute responsabilité si l’incident est hors de votre contrôle. Gardez de manière organisée, les enregistrements de chaque communication de projet et si possible faites-en une sauvegarde sous forme digitale ou avec un stockage physique. Vous ne savez jamais quel pourrait être le facteur déterminant dans un procès portant sur plusieurs millions de dollars.
La faute est la responsabilité directe, vérifiable d’un incident, tandis que le blâme voit une faute, qu’elle existe vraiment ou non. La faute est beaucoup plus facile à manager que le blâme, parce qu’elle peut être prouvée et réfutée si vous avez la documentation adéquate. Le blâme, quant à lui, porte le poids de qui le donne. Si un PDG vous blâme, les gens écoutent, que ce soit vrai ou pas.
Quand vous constatez que vous ou votre équipe êtes vraiment en tort, reconnaissez-le immédiatement et trouvez une solution. Rester silencieux et cacher des informations aggravera seulement les avis à votre encontre et rendra plus difficile de rétablir votre réputation.
Comme mentionné dans le point précédent, une méthode cruciale pour éviter le blâme est de maintenir les communications. Soyez le premier à offrir volontairement des informations. Plus vous soulignez votre implication réelle (ou son manque) dans l’incident, participez au développement d’une solution et montrez de l’empathie avec les parties affectées, plus on vous verra comme faisant partie de la solution, pas du problème. Le blâme jeté sur votre équipe peut diminuer et céder la place à une discussion plus raisonnable.
En communiquant avec le management, soyez attentif à ce que les peuvent avoir éprouvé et votre position de potentiel « méchant » dans cette histoire. Bien que la confiance en soi et une position ferme soient bonnes, en montrer trop peut vous faire paraitre arrogant et insouciant. Aussi, essayez de ne pas faire de promesses ou affirmations que vous ne pourrez pas tenir à 100 %, parce que la répercussion d’une fausse déclaration peut être bien pire que ne rien dire du tout.
Tout incident déclencheur invoquera probablement beaucoup d’émotions négatives. Beaucoup vous seront probablement adressées à vous et à votre équipe projet. Il y doit avoir une action visible et mesurable de votre part pour réparer n’importe quel problème. Prenez la responsabilité de ce que vous pouvez (mais ne vous embrochez pas sur votre propre épée en le faisant) et répondez aux personnes affectées rapidement et efficacement.
Au début d’un projet il y a normalement une bouffée massive d’énergie et vous pensez que vous faites des tas de progrès. Mais cela peut ralentir. Si vous voulez atteindre vos objectifs, vous avez besoin de savoir…
Gardez toute votre équipe efficace avec ces simples astuces.
Avoir tout fini d’ici à vendredi ? C’est beaucoup demander. Alors, donnez des délais aux membres de l’équipe qui soient réalisables. En fait, il est encore meilleur de les impliquer dans la détermination des délais. S’ils s’engagent à compléter une tâche par une date spécifique, ils vont plus probablement l’atteindre que si vous leur avez donné une date.
Découpez les grandes tâches en tâches plus petites pour que chaque sous-partie ait sa propre date de fin. Ceci rendra aussi les délais plus réalisables et plus faciles de contrôler.
Vous pourrez voir dans quelle mesure que vous faites des progrès sur votre projet si vous contrôlez le statut de chaque tâche. Ce contrôle vous aidera aussi à voir si quoi que ce soit (ou quelqu’un) est en train de ralentir, vous permettant de leur parler de maintenir le momentum. Utilisez des informations en temps réel pour vérifier le progrès sur les tâches et vous assurer que tout avance.
Bien sûr, vous avez besoin d’un plan envers lequel mesurer le progrès, assurez-vous donc que vous avez toutes les tâches et des dates d’achèvement proposées annotées pour vous pour vérifier contre.
Il ne suffit pas que vous sachiez quels progrès sont réalisés. Pour que d’autres dans l’équipe sentent qu’ils atteignent leurs objectifs de projet, tout le monde devrait être mis au courant de la progression du projet. Ceci est facile de faire avec ProjectManager.com. Vous pouvez rapidement produire des rapports pour montrer la progression par rapport à l’échéancier et les partager avec l’équipe entière en seulement quelques clics.
La capacité de voir que le projet avance est un excellent motivateur et aidera l’équipe à continuer à aller de l’avant vers ces buts finaux.
Ne faites pas attendre jusqu’à la fin du projet de célébrer les succès ! Trouvez quelques moments pendant le projet quand quelque chose a été réalisé qui vaut la peine d’être mentionné et célébrez ceci. Par exemple, la fin de la phase de test quand vous avez un produit qui est prêt pour la livraison, ou l’achèvement d’un gros morceau pendant la conception. Ce que vous célébrez n’a pas vraiment d’importance tant que c’est lié avec le projet d’une façon ou d’une autre et que vous pouvez utiliser cette opportunité pour démontrer quels progrès sont réalisés et ce qu’il reste à faire. Même de petites célébrations motivent les membres de l’équipe qui vous aideront à leur tour à piloter le projet vers sa réussite.
Un projet massif peut intimider tout le monde sur l’équipe et vous pourriez constater que le travail ralentit parce que les gens se sentent écrasés. Divisez votre projet en phases plus petites et livrez-les un peu à la fois. Ceci peut aider à structurer le travail en composants réalisables et plus faciles à manager. Si c’est moins intimidant, l’équipe sera plus confiante de progresser.
PMI’s 2014 Pulse of the Profession®, le rapport annuel du PMI examine chaque année l’impact du management de projets, programmes et portefeuilles de projets.
Cette édition 2014 met en exergue le fait que pour rester compétitives, les organisations doivent placer un focus stratégique à la fois sur les personnes et sur les processus.
Lisez notamment les pages 12 et 13 dédiées au rôle prépondérant des sponsors « actifs » de projets et le processus de gestion des modifications.
Les mises à jour de statut de projet prennent beaucoup de temps à assembler et à préparer. Combien de temps sauveriez-vous si vous pouviez le réaliser plus rapidement ? Vous pouvez y parvenir sur votre projet avec ces 5 étapes…
Faites en sorte qu’il soit très facile pour les membres de votre équipe projet de se souvenir de quand ils doivent vous fournir une mise à jour de statut en respectant jour et horaire. Avez-vous besoin d’une mise à jour chaque vendredi après-midi ? Un mercredi sur deux au matin ? Cela n’a pas d’importance du moment que c’est régulier et bien communiqué. Ceci permettra aux membres de l’équipe d’entrer dans une routine. Ils peuvent préparer leur mise à jour de statut à l’avance car ils savent quand il sera exigé.
Cela demande plus longtemps aux membres de l’équipe de préparer leur mise à jour de statut s’ils n’ont pas accès aux informations en temps réel. Assurez-vous donc qu’ils peuvent utiliser des données en temps réel pour préparer leur mise à jour !
L’utilisation de logiciel comme ProjectManager.com qui peut capturer des informations de tâches en temps réel signifie qu’ils auront l’accès à tout ce dont ils ont besoin d’un claquement de doigt. Ils pourront assembler leurs mises à jour plus rapidement et donc vous les obtiendrez aussi plus rapidement.
Si vous voulez que des membres de l’équipe vous informent sur certaines informations ou selon un certain format, rendez cela facile à faire pour eux en leur donnant un modèle à utiliser. Chaque semaine ils peuvent simplement éditer la dernière version de votre modèle et la mettre à jour avec les dernières avancées.
Vous obtiendrez toujours les données que vous voulez et ils n’auront pas à trop réfléchir à quoi vous envoyer! Cela vous sauvegardera aussi du temps à les relancer quand ils oublient d’inclure quelque chose de vraiment important, car ils auront ces têtes de chapitre dans le modèle pour les aider à se rappeler de quoi vous avez besoin.
Utilisez le management des tâches et les envois de rappel par courrier électronique en utilisant votre logiciel de management de projet pour demander aux membres de l’équipe de compléter leurs mises à jour de statut à l’heure. Vous pouvez configurer une tâche récurrente dans leur liste de choses à faire pour qu’ils n’aient jamais l’excuse d’avoir oublié !
Si vous pouvez automatiser l’envoi de ces courriers électroniques de rappel, faites-le aussi. Cela marche bien avec les membres de l’équipe qui voyagent beaucoup et pourraient avoir besoin d’un rappel par courrier électronique. Plus vous pouvez automatiser, plus facile ce sera pour vous et plus vous aurez de chances que votre équipe vous envoient leurs mises à jour de statut à temps.
Ceci n’est pas la meilleure façon d’obtenir des mises à jour rapidement, mais ça peut marcher si vous devez faire entrer un membre spécifique de l’équipe dans une routine vertueuse ! Relancez pour les rapports que vous n’obtenez pas dans les temps agréés. Puis relancez-les de nouveau. Et de nouveau! Faire de vous-même une nuisance ne vous gagnera pas le prix du chef de projet le plus décontracté, mais vous obtiendrez ce que vous voulez au final et la prochaine fois, il y a bon espoir que le membre concerné de l’équipe y réfléchira à deux fois avant de laisser passer le délai d’envoi de sa mise à jour de statut.
Le management des tâches et les fonctionnalités de stockage de documents d’outils en ligne tels que ProjectManager.com vous permettent de facilement rationaliser le management des mises à jour de statut de votre équipe. Vous pouvez leur prévoir des tâches, configurer des rappels et partager des modèles.
Alors que l’on nous rebat les oreilles avec le « pacte de responsabilité » entre état et patrons, je pense que les chefs de projet comme d’autres professionnels ont depuis bien longtemps un pacte de responsabilité bien établi.
En effet, le code de déontologie et de conduite professionnel, celui que je connais bien vient du PMI (Learn more and read the Code), décrit les attentes que nous entretenons pour nous et nos collègues praticiens dans l’arène globale du management de projet. Il présente les idéaux auxquels nous aspirons ainsi que les comportements que nous nous devons d’adopter dans nos rôles de professionnels et de volontaires. Il propose même une Structure de Prise de Décision Éthique avec les étapes qui peuvent être utilisées pour guider un professionnel du management de projet confronté à un dilemme éthique au travers d’un processus de prise de décision.
D’autre part, la Matrice d’Affectation des Responsabilités (Responsibity Assignment Matrix : RAM), aussi connue comme la grille RACI (Responsabilité-Autorité-Consulté-Informé), décrit les rôles divers des participants dans l’achèvement de tâches ou produits pour un projet ou une procédure. Elle est particulièrement utile pour clarifier les rôles et responsabilités dans les projets et processus transverses aux organisations.
L’une des manières de l’utiliser qui n’est pas décrite explicitement dans le PMBoK mais qui fonctionne bien pour moi consiste à partir des livrables des organisations en présence. Il est facile avec le RACI de réaliser un tableau partagé de « qui fait quoi ». En effet, les livrables sont très concrets, exacts et beaucoup plus précis que les descriptifs des rôles et responsabilités des organisations. Ceux-ci, pour être honnête, donnent souvent une image de ce que l’on voudrait qu’ils soient idéalement plutôt que la réalité. Pour chaque livrable, il est relativement aisé de tomber d’accord sur qui le produit, avec qui, en le communiquant à qui et qui en porte ultimement la responsabilité car le livrable est concret, palpable.
aussi connue comme la grille RACI (Responsabilité-Autorité-Consulté-Informé), décrit les rôles divers des participants dans l’achèvement de tâches ou produits pour un projet ou une procédure. Il est particulièrement utile pour clarifier les rôles et responsabilités dans les projets et processus transverses aux organisations.
http://www.easyprojects.net/blog/2014/01/24/get-team-use-project-management-tool/
Ça y est, vous vous êtes jetés à l’eau et avez investi dans un nouvel outil de management de projet. Félicitations! Malheureusement, aucun de votre personnel n’est enchanté par ce changement. Ils ont chacun leur propre système et s’y accrochent comme un bébé à son doudou ! Jusqu’à ce qu’ils embrassent le changement, votre onéreux outil de management d’équipe projet va juste être posé là, vide et inutile.
Chaque organisation va rencontrer d »e la résistance au changement, mais ce n’est pas une excuse pour vous pour laisser les choses en l’état et laisser un comportement de tête de mule de certains paralyser le business. Vous devez garder le contrôle et, si possible, les transformer en avocats du nouveau système.
Ci-dessous sont quelques trucs utiles pour y parvenir :
Une des raisons principales pour laquelle les gens n’aiment pas de nouveaux systèmes est la nécessaire courbe d’apprentissage. Il est intimidant d’apprendre un nouveau programme à partir de zéro. La mise en place de sessions de formation fréquentes avant la sortie officielle peut donner aux gens une chance de s’adapter. Adaptez contenu et programme de formation aux personnes à former : Moins une personne est technique, plus elle devra suivre de classes et vice versa. Si possible, faites les étudiants se former entre eux, cela fera aussi un bon exercice de développement de l’esprit d’équipe.
Parfois, cela aide de savoir Pourquoi vous faites quelque chose, au lieu de juste exécuter des ordres. Posez le contexte de la situation, expliquez les difficultés de l’ancien système et comment le nouveau améliorera des choses. Montrez-leur comment ils peuvent bénéficier des nouvelles fonctionnalités et comment elles amélioreront leur efficacité, augmenteront l’exactitude des rapports et diminueront leur stress. De même, montrez les conséquences de la saisie de données incorrectes ou d’une mauvaise utilisation. Faites savoir que l’efficacité de l’outil de management de projet dépend entièrement de comment ils choisissent de l’utiliser.
Une fois que vous avez mis en place des procédures pour une utilisation appropriée de l’outil de management de projet, vous devez vous montrer impitoyable et les faire respecter. L’outil de management de projet est seulement aussi bon que les informations que vous y mettez et donc vous devez régulièrement vérifier l’intégrité de la base de données et rendre les utilisateurs individuellement responsables des entrées qu’ils font. Si quelqu’un fait systématiquement des fautes de frappe dans ses données ou utilise des raccourcis non autorisés, vous devez le réprimander et vous assurer qu’il change son comportement.
Quelques collaborateurs voudront retourner au confort de leur ancien système, que ce soit un vieux logiciel ou une autre méthode manuelle. Si vous le pouvez, vous devez éliminer ces options dès que le nouveau système est en ligne. Supprimez le précédent outil de management de projet de votre réseau (ou supprimez-en au moins l’accès) et découragez l’utilisation de l’ancien système.
Si les membres de l’équipe résistent au changement parce qu’il est « imposé » par la direction, contournez le problème. Recrutez les collaborateurs les plus ouverts d’esprit et demandez-leur d’aider à convaincre les membres de leurs équipes. Les collaborateurs difficiles pourraient être plus réceptifs à leurs pairs.
La Charte Projet est le début officiel du projet. Elle vous autorise formellement vous et votre équipe à commencer le travail sur les tâches requises, donc c’est un document vraiment important. Sans charte, vous n’avez pas le mandat de faire faire des choses, donc, dans un monde idéal, vous devriez insister pour que la charte soit préparée et approuvée avant que vous ne vous engagiez vous ou quelqu’un d’autre à faire n’importe quel travail.
Idéalement, si vous allez être le chef de projet sur ce Projet, vous devriez être assigné au moment où la charte est écrite pour pouvoir l’influencer. Dans les faits, on vous demandera probablement d’écrire tout cela pour le compte de la personne initiant le projet. Alors, si on vous demande d’assembler une charte de projet, qu’est-ce qui devrait y entrer ?
D’abord, votre Charte projet a besoin d’une déclaration des besoins fonctionnels. Autrement dit, pourquoi faites-vous ce projet ? Ceci peut prendre la forme d’une description à un haut niveau du projet et du problème que le projet essaie d’adresser. Cela pourrait inclure un retour d’information de clients, un peu de statistiques ou autres résumés qui expliquent le pourquoi des besoins fonctionnels de ce projet. On pourrait aussi parler des livrables du projet, le produit ou le service qu’il produira, et pourquoi ceux-ci sont importants pour la société.
Ne faites pas trop long. On espère que le raisonnement qui amène à faire le projet est très clair, donc vous devriez pouvoir faire comprendre vos points et expliquer pourquoi le Projet Est important en moins d’une page. Si cela demande plus, vous devriez vous demander pourquoi il est si difficile d’expliquer en quoi cela vaut la peine d’avancer sur ce projet !
À ce point vous ne pourriez pas avoir la spécification complète des besoins, mais vous pouvez au moins exposer les besoins principaux pour le projet. Ceux-ci devraient couvrir les besoins de divers groupes de parties prenantes: les clients externes (utilisateurs finaux) et vos clients internes (comme votre sponsor de projet) peuvent attendre quelque chose de différent du projet.
Une façon d’exposer les besoins est selon qu’ils soient critiques, voulus ou souhaitables. Les besoins sont des choses qui doivent absolument être livrées, les besoins critiques sans lesquels on considérera le projet comme un échec. Les besoins voulus sont des choses que les clients du Projet voudraient avoir, mais ne sont pas impérativement essentiels. Les souhaitables seraient agréable à avoir et sont ces articles qui sont sur « la liste au père Noël » : Si nous avions tout le temps et l’argent du monde, ils seraient très appréciés à la livraison mais tout le monde sait qu’il y a peu de chance de les avoir.
Ceci est une brève section exposant qui est assigné comme chef de projet. Cela va probablement être vous, donc mettez-y votre nom. Cette section devrait aussi couvrir le niveau d’autorité que vous avez. Ceci pourrait inclure la capacité à engager des dépenses jusqu’à un certain budget, la capacité d’assembler une équipe et autres responsabilités ou autorité qui viennent avec le travail.
Si vous ne savez pas exactement ce dont vous allez être responsables, copiez la Charte projet d’un autre projet et copiez-la ! Si vous écrivez cette section, donnez-vous autant de responsabilités que vous vous sentez à l’aise et laissez le sponsor de projet vous dire si vous avez dépassé les limites lorsqu’il passe le document en revue.
La charte de projet devrait inclure un échéancier sommaire. À ce point vous n’avez probablement pas fait beaucoup de planification. Vous pourriez même ne pas encore avoir une équipe projet complète, donc vous pouvez à peine avoir demandé leur apport sur les tâches requises ou combien de temps tout cela prendra. Ajoutez un grand avertissement à l’échéancier des jalons principaux si c’est le cas, déclarant qu’une revue appropriée de l’échéancier aura lieu plus tard et que ces dates peuvent changer.
L’échéancier des jalons majeurs est particulièrement important si vous travaillez avec certaines dates fixes, comme un gel de code de fin d’année, un produit qui doit être lancé à une certaine date ou une disposition réglementaire ou légale qui exige que vous soyez conforme à quelque chose avant une date fixe. Ces dates ne bougeront pas, donc cela vaut certainement la peine de les noter pour les prendre en compte. D’autres dates seront en grande partie des ambitions, mais il est bon d’avoir une idée de quand votre sponsor s’attend à ce que le travail soit achevé. Une façon facile de compléter cette section est d’inclure une copie d’écran de votre outil de management de projet.
À cette première étape dans le projet, vous devrez faire quelques suppositions. Celles-ci sont des choses que vous assumez pour être vraies. Vous les vérifierez plus tard. Un exemple serait que vous aurez l’accès à toutes les ressources dont vous avez besoin. Les assomptions tombent dans trois catégories principales : des suppositions organisationnelles, environnementales et externes, mais vous verrez aussi des façons différentes de les catégoriser et vous pourrez utiliser celles qui fonctionnent le mieux pour vous.
Des suppositions organisationnelles sont liées à comment fonctionne la société, par exemple, quoi que ce soit que vous commandez peut être fourni sous 30 jours. Si cette supposition n’est pas vraie, elle affectera votre prévisionnel de projet quand vous prévoirez d’avoir tout votre kit livré dans 30 jours après commande.
Des suppositions environnementales sont liées à l’environnement dans lequel vous opérez comme le niveau d’autorité et de tolérance qui vous ai donné comme chef de projet.
Des suppositions externes touchent aux choses à l’extérieur de la société, comme des conditions du marché et les normes de l’industrie qui doivent être suivies. Une supposition pourrait être qu’elles ne changeront pas pendant le cycle de vie du projet. Si elles changent vraiment, vous devrez repenser le but et les objectifs du projet.
Finalement, vous devriez vous assurer votre charte inclut une liste des parties prenantes principales et leurs rôles. Ceci est important car ceci confirme leurs rôles et responsabilités sur le projet. Incluez aussi votre sponsor de projet dans la liste et notez lesquelles de ces personnes font partie de votre comité de projet ou autre forum de gouvernance. Vous pourriez aussi noter comment elles seront impliquées : prendront-elles des décisions ou agiront-elles seulement juste à titre consultatif ? Seront-elles responsables de fournir des ressources ou seront-elles les destinataires des produits livrés ? Cette section s’assure que tout le monde sait qui est responsable de quoi.
La charte projet est un début essentiel à un projet. Vous pouvez la réviser plus tard, particulièrement si votre projet va avoir des phases multiples, ne considérez donc qu’elle soit gravée dans la pierre. Cependant, une déclaration claire du travail à faire, comment il sera fait, l’environnement dans lequel ce sera fait et des gens qui le feront vous donne une clarté sur les objectifs du projet dès le début.
Rappelez-vous d’inclure le développement de la charte projet dans le planning de projet. Faites de ce processus un de vos jalons clés et enregistrez-le dans ProjectManager.com. Vous pouvez y documenter tous les jalons sommaires et en faire une copie d’écran pour votre charte de projet.
Article de CSP Formation: http://management-leadership.cultivezvostalents.fr/gerer-en-transverse-7-cles-pour-mobiliser-les-acteurs-du-projet
Sans lien hiérarchique, « le pouvoir et le respect se gagnent, ils ne se donnent pas », insiste Florentin Roche, formateur chez CSP Formation. Pour le chef de projet, affirmer sa légitimité suppose de développer son leadership et sa capacité d’écoute, d’utiliser son intelligence émotionnelle et de s’adapter à chacun.
Sans cadre, difficile de recadrer, et encore plus de mobiliser. « Le manager doit donc définir en amont l’objectif à atteindre, le rôle et la mission de chacun, les règles de fonctionnement, les étapes et les interactions nécessaires à la bonne réalisation du projet. »
Qu’est-ce qui intéresse chaque acteur ? Quelles sont ses priorités, ses contraintes ? « Tenir compte de la situation particulière de chaque collaborateur est capital. L’erreur serait de vouloir traiter tout le monde en bloc ! »
Quels sont les objectifs de l’entreprise ? Comment le projet s’inscrit-il dans sa stratégie ? En quoi mes actions contribuent-elles à son succès ? « Chaque acteur doit pouvoir répondre à ces questions pour lui-même afin de se sentir complètement impliqué et pas seulement concerné. »
Tout le monde n’ayant pas la même façon de travailler, les acteurs du projet doivent se connaître et se reconnaître dans leurs différences. « Il est impératif qu’ils se rencontrent au moins une fois au lancement du projet, afin que chacun puisse expliquer sa façon de fonctionner et comprendre les attentes et les besoins des autres. Il est ensuite souhaitable de s’ajuster régulièrement au cours du cycle de vie du projet. »
Pour mobiliser, le manager doit aussi savoir valoriser les réalisations des membres de son équipe : individuellement de manière régulière, et collectivement à chaque étape importante du projet. « D’autant plus que l’on se situe dans une relation de prestation de service interne et non pas de donneur d’ordre. »
Il est enfin essentiel d’avoir la sérénité d’accepter ce qui ne peut être changé dans des conditions données et d’avoir le courage de faire évoluer ce qui peut l’être dans le même temps. En d’autres termes, le manager doit « déterminer sa zone d’influence et agir là où c’est possible, recommande Florentin Roche. Certains acteurs seront par exemple très moteurs, d’autres moins, voire pas du tout. Mettre son énergie à mobiliser ceux qui sont déjà un peu motivés permettra d’obtenir plus de résultats à court terme et produira un effet d’entraînement sur le groupe à moyen terme. »
Pour en savoir plus, suivez ce lien : “Les clés du Management transversal”
http://smallbiztrends.com/2013/12/what-is-a-project-champion.html par Chris Mile
Au début de chaque projet, les espoirs sont au plus haut. Les attentes seront dépassées. Les produits seront livrés à temps. Les clients seront impressionnés par le résultat final et nous recommanderont ardemment à de nouveaux clients potentiels.
Malheureusement, ce n’est pas toujours le cas. Il y a des fois où les projets vont terriblement mal. Les échéances sont manquées, les produits ou services ne satisfont pas la vision du client et l’atteinte du succès est en péril, menaçant les relations avec client et, même plus destructeur, mettant en péril la réputation du business.
Qu’est-ce qui apporte systématiquement un résultat positif aux projets de toutes sortes et de toutes tailles ? La réponse tient beaucoup moins du QUOI que du QUI. Le vrai avocat d’un projet et le maître du succès héroïque ou dur morne échec d’un projet – est le champion de projet.
Le champion de projet est la personne dans une organisation implémentant un projet qui prend le fardeau de s’assurer que tout le monde impliqué est à bord et derrière le succès suprême du projet.
Identifier les objectifs stratégiques d’un projet.Il n’accepte par « Non » ni « je n’ai pas le temps » comme réponse. Il garde tout le monde focalisé sur les bénéfices que représente la mise en œuvre réussie de ce projet.
Un champion de projet est sincère, fait autorité et, de temps en temps, représente le champion de la vérité sur le projet.
En avocat sincère du projet, le champion de projet est typiquement un membre de la direction générale ou d’une expertise critique et il renforce la valeur d’un projet en ajoutant sa formidable expérience dans la balance. Délivrant précisément et efficacement le projet avec succès.
1) Qualifications et aptitude à comprendre tous les éléments du projet.
2) Capacité à atteindre et dépasser les attentes du management.
3) Capacité à motiver et inspirer une équipe pour s’approprier et s’engager au succès du projet.
4) Finesse dans les négociations avec toutes les parties prenantes pour garantir le succès du projet.
5) Compétences exceptionnelles en résolution de problème et les ressources pour abattre tout obstacle.
6) Talents organisationnels développés et un don pour garder en piste tous les membres de l’équipe.
7) Compétences de communications exceptionnelles, gardant toutes les parties prenantes du projet conscientes de l’avancement et engagées.
Un champion de projet réduit énormément la probabilité d’échec du projet. Sur les lignes de front de tout projet et en communication directe avec l’équipe entière à tout moment, le champion de projet est le défenseur du projet. Une sentinelle critique qui se consacre à la livraison d’un projet réussi qui émerveillera le management.
Une fois qu’un projet ou étape sont complétés, le champion de projet passe à l’action pour faire avancer le projet suivant : un héros dans le cycle de vie du management de projet.
Tous les ans ESI publie ses tendances du management de projet. Plutôt correctes il me semble, vérifiez par vous mêmes en relisant celles des 3 dernières années: 2013, 2012 et 2011.
1. Agile expands in Singapore, Japan and Hong Kong.
2. Portfolio management continues to take center stage with PMI’s new credential.
3. Whether they like it or not, project managers are learning to learn through virtual learning.
4. EPC companies admit they didn’t invent project management and seek professional help.
5. Think implementing one PPM tool was hard? Companies now need two!
6. Servant leadership makes a comeback, and not just in Agile.
7. Benchmarking takes on greater urgency as competition heats up.
8. Organisations, dissatisfied with their project management performance, will radically change their approaches to get back on track.
9. Even with high unemployment globally, key project management jobs will remain hard to fill.
10. Project and programme managers will be asked to spend more time “leading” rather than “managing” their teams.
J’avais comme beaucoup entendu parler de la loi de Parkinson dans le contexte du management de projet.
Elle se résume le plus souvent à dire que l’effort lié à la réalisation d’une tache du projet aura toujours tendance à correspondre au minimum à la durée préalablement estimée de ladite tache.
J’ai eu envie d’en apprendre davantage que ce raccourci réducteur sur ce qu’avait réellement exprimé Parkinson.
Je vous invite, si vous avez quelques minutes, à lire l’article original.
En effet, la Loi de Parkinson est l’adage d’abord articulé par Cyril Northcote Parkinson dans un essai plein d’humour publié dans The Economist en 1955, dont la première phase est :
DantotsuPM.com 